รายงานผลการทดสอบ: NVIDIA GeForce RTX 5060 Ti 16GB กับการรัน Local LLM บน Windows — ประชัน CUDA vs Vulkan บน Dense 12B และ MoE 26B

โดย ลุงจุ้ยคุยเรื่องคอม · 26 ส.ค. 2026

ประเภท: Benchmark · วันที่ทดสอบ: 2026-08-26 · เครื่องมือ: PromptMark v0.4.0 (llama.cpp Build b10566, Clang 20.1.8 Windows x86_64)

ไฮไลท์และผลการทดสอบ

NVIDIA GeForce RTX 5060 Ti (รุ่น VRAM 16GB) เป็นการ์ดจอสถาปัตยกรรม Blackwell ระดับเมนสตรีมที่ได้รับความสนใจอย่างสูงในกลุ่มผู้ใช้งาน Local AI ด้วยการติดตั้งหน่วยความจำ 16GB GDDR7 (บัส 128-bit แบนด์วิดท์ 448 GB/s) ซึ่งเปิดโอกาสให้ออฟโหลดโมเดลขนาดกลาง (8B – 14B) ได้เต็ม 100% สบาย ๆ รวมถึงรองรับโมเดลตระกูล Mixture-of-Experts (MoE) ขนาด 26B–30B ในระดับควอนไทซ์ Q4

ในการทดสอบรอบนี้ AIPCMag ได้นำการ์ด RTX 5060 Ti 16GB มาประเมินผลเชิงลึกผ่านชุดเครื่องมือ PromptMark v0.4.0 (รัน 6 เวิร์กโหลดมาตรฐาน ทดสอบ 1 Warm-up + 5 Measured Runs แบบ Round-Robin เพื่อหาค่ามัธยฐาน) เพื่อตอบ 2 คำถามสำคัญ:

CUDA vs Vulkan บนการ์ดจอ NVIDIA ใครคือคำตอบที่ดีที่สุด?
ขีดจำกัดหน่วยความจำ 16GB เมื่อต้องแบกโมเดล MoE ขนาดไฟล์ 15.64 GB (Gemma-4-26B-A4B) ในภาวะ VRAM-Tight จะเป็นอย่างไร

สรุปประเด็นสำคัญจากการทดสอบ:

CUDA ชนะ Vulkan อย่างเด็ดขาดในทุกมิติ: บนโมเดล Dense Gemma-4-12B-it รันไทม์ CUDA แสดงพลังของ Tensor Cores สถาปัตยกรรม Blackwell ด้วยความเร็ว Prefill ที่สูงกว่า Vulkan ถึง +16.7% ถึง +32.1% (ทะลุ 2,012 tokens/s ในบริบท 8K) และทำความเร็ว Decode สูงกว่า Vulkan อย่างคงที่สม่ำเสมอประมาณ +5% (~47–49 tokens/s)
Time to First Token (TTFT) ของ CUDA ตอบสนองไวกว่า 13% – 17%: ด้วยความเร็ว Prefill ที่เหนือกว่า ทำให้ CUDA ส่งโทเค็นแรกกลับมาได้เร็วกว่า Vulkan ในทุกเวิร์กโหลด โดยในบริบท 8K Tokens นั้น CUDA ใช้เวลาเพียง 4.108 วินาที เทียบกับ Vulkan ที่ต้องใช้ 4.824 วินาที (เร็วขึ้น 14.8%)
การบริหารหน่วยความจำ (Memory Management): CUDA ผ่านฉลุย ส่วน Vulkan ล้มเหลว (OOM): เมื่อทดสอบความทนทานด้วยโมเดล MoE Gemma-4-26B-A4B-it ซึ่งมีขนาดไฟล์ 15.64 GB บนการ์ด VRAM 16 GB (16,310 MiB):
- CUDA: จัดสรรหน่วยความจำและ KV Cache ได้อย่างแม่นยำ สามารถรันแบบ 100% Full GPU Offload ผ่านครบทั้ง 6 เวิร์กโหลด (5/5 PASS)
- Vulkan: เกิดข้อผิดพลาดหน่วยความจำไม่พอ (ErrorOutOfDeviceMemory: failed to allocate Vulkan2 buffer of size 555105280) เนื่องจาก Vulkan Driver บน Windows มี Memory Overhead สูงกว่า จึงไม่สามารถ Offload ทั้งหมดลงบนการ์ด 16 GB ได้
พฤติกรรมของ MoE ในภาวะ VRAM-Tight บน CUDA: แม้ Gemma-4-26B-A4B จะเปิดใช้งานพารามิเตอร์เพียง ~4B ต่อโทเค็น แต่การที่ตัว Weight ทั้ง 26B กินพื้นที่ไปแล้ว 15.64 GB ทำให้เมื่อขยาย Context จาก 512 เป็น 8,192 tokens แรงกดดันของ KV Cache ส่งผลให้ความเร็ว Decode ลดลงจาก 23.27 tokens/s เหลือ 12.10 tokens/s และ TTFT เพิ่มขึ้นแตะ 50.06 วินาที
ประสิทธิภาพการดึง Memory Bandwidth: RTX 5060 Ti มีแบนด์วิดท์ 448 GB/s เมื่อรันโมเดล Dense 12B (ขนาด ~7.5 GB) ที่ความเร็ว 49.11 tokens/s คิดเป็นประสิทธิภาพการดึงแบนด์วิดท์สูงถึง 82.2% ของเพดานทฤษฎี

สภาพแวดล้อมในการทดสอบ

การทดสอบนี้ดำเนินการบนระบบปฏิบัติการ Windows x86_64 ภายใต้การควบคุมตัวแปรอย่างเข้มงวดตามมาตรฐาน PromptMark Suite:

รายการ	รายละเอียดการตั้งค่าฮาร์ดแวร์และซอฟต์แวร์
GPU Setup	1× NVIDIA GeForce RTX 5060 Ti
หน่วยความจำ VRAM	16,310 MiB GDDR7 (บัส 128-bit แบนด์วิดท์ 448 GB/s)
สถาปัตยกรรม GPU	Blackwell, CUDA Compute Capability 12.0, 5th Gen Tensor Cores
ไดรเวอร์และการประมวลผล	NVIDIA Display Driver 591.86 / CUDA Runtime 13.1
Inference Engine	`llama-server.exe` Build 10566 (commit `bb4caa754`, Clang 20.1.8 Windows x86_64)
CUDA Backend	`promptmark-b10566-cuda` (Target Device: `CUDA0`)
Vulkan Backend	`promptmark-b10566-vulkan` (Target Device: `Vulkan2`)
เป้าหมาย Context Window	12,288 tokens (`-c 12288`)
นโยบายการกระจายงาน	Full GPU Offload 100% (`-ngl 999`, `--fit off`)
นโยบาย Slot และ Cache	Single Slot (`-np 1`), ปิด Prompt Cache (`--no-cache-prompt`) เพื่อวัดพลังคำนวณจริงทุกรอบ
เกณฑ์การเก็บสถิติ	1 Warm-up Run + 5 Measured Runs ต่อเวิร์กโหลดแบบ Round-Robin คำนวณค่ามัธยฐาน (Median)

[!NOTE] พารามิเตอร์ --fit off ถูกบังคับใช้ในทุกการทดสอบ เพื่อป้องกันไม่ให้ llama.cpp แอบลดขนาดบริบท (Context) หรือแอบแบ่งเลเยอร์โมเดลไปประมวลผลบนแรมระบบ (CPU Offload) อัตโนมัติ ทำให้มั่นใจได้ว่าตัวเลขที่ได้สะท้อนประสิทธิภาพจริงของ GPU 100%

เวิร์กโหลดการทดสอบทั้ง 6 รูปแบบใน PromptMark v0.4.0:

Content Generation (512 In / 256 Out): จำลองงานร่างคอนเทนต์และบทความทั่วไป
Creative Writing (512 In / 512 Out): จำลองงานแต่งเนื้อเรื่องที่ต้องการการ Generate โทเค็นต่อเนื่อง
Summarization Light (2K In / 256 Out): สรุปเอกสารทางเทคนิคขนาดสั้น วัดความสมดุล Prefill / Decode
Summarization Moderate (4K In / 256 Out): สรุปรายงานขนาดกลาง จุดเริ่มเห็นภาระของ Prefill
Summarization Long (8K In / 256 Out): สรุปเอกสารขนาดยาวระดับ 8K tokens วัดบทลงโทษด้าน Prefill และ TTFT
Code Analysis (4K In / 256 Out): วิเคราะห์โครงสร้างโค้ด Python ขนาดยาว 4K พร้อมสรุปผล

การทดสอบที่ 1: ศึกสถาปัตยกรรม Dense (`Gemma-4-12B-it`)

โมเดล: gemma-4-12B-it-Q4_K_M.gguf
ขนาดไฟล์โมเดล: ~7.50 GB
การใช้ VRAM โดยประมาณ: ~9.5 GB (Model Weights + KV Cache 12K)
สถานะการทดสอบ: ผ่านครบถ้วน 5/5 PASS ทั้ง CUDA และ Vulkan

1. ความเร็วประมวลผลคำสั่งเริ่มต้น (Prefill) และระยะเวลาตอบสนองคำแรก (TTFT)

เวิร์กโหลด (Workload)	Input Tokens	CUDA Prefill (tok/s)	Vulkan Prefill (tok/s)	ผลต่าง Prefill (%)	CUDA TTFT (s)	Vulkan TTFT (s)	ความเร็ว TTFT
Content Generation / 512-256	511	1,653.7	1,251.7	+32.1%	0.548s	0.629s	CUDA ไวกว่า 12.9%
Creative Writing / 512-512	512	1,695.8	1,338.8	+26.7%	0.415s	0.498s	CUDA ไวกว่า 16.7%
Summarization Light / 2K-256	2,048	1,950.9	1,647.4	+18.4%	1.138s	1.348s	CUDA ไวกว่า 15.6%
Summarization Moderate / 4K-256	4,096	2,008.2	1,714.6	+17.1%	2.063s	2.424s	CUDA ไวกว่า 14.9%
Summarization Long / 8K-256	8,192	2,012.0	1,708.5	+17.8%	4.108s	4.824s	CUDA ไวกว่า 14.8%
Code Analysis / 4K-256	4,096	2,003.4	1,716.3	+16.7%	2.131s	2.463s	CUDA ไวกว่า 13.5%

2. ความเร็วการสร้างคำตอบ (Decode) และเวลารวม (End-to-End Latency)

เวิร์กโหลด (Workload)	Output Target	CUDA Decode (tok/s)	Vulkan Decode (tok/s)	ผลต่าง Decode (%)	CUDA E2E (s)	Vulkan E2E (s)	ผลต่าง E2E (%)
Content Generation / 512-256	256	49.11	46.76	+5.0%	5.759s	6.084s	CUDA ไวกว่า 5.3%
Creative Writing / 512-512	512	48.87	46.48	+5.1%	10.881s	11.491s	CUDA ไวกว่า 5.3%
Summarization Light / 2K-256	256	47.57	45.18	+5.3%	6.511s	6.990s	CUDA ไวกว่า 6.9%
Summarization Moderate / 4K-256	256	47.30	44.99	+5.1%	7.460s	8.092s	CUDA ไวกว่า 7.8%
Summarization Long / 8K-256	256	47.00	44.68	+5.2%	9.539s	10.535s	CUDA ไวกว่า 9.5%
Code Analysis / 4K-256	256	47.23	45.00	+5.0%	7.510s	8.130s	CUDA ไวกว่า 7.6%

ข้อสังเกตเชิงลึกสำหรับโมเดล Dense 12B:

พลัง Tensor Cores ของ Blackwell ดัน Prefill ทะลุ 2,000 tok/s: รันไทม์ CUDA สามารถดึงศักยภาพ Tensor Cores เจนเนอเรชันที่ 5 ของ RTX 5060 Ti ออกมาได้เต็มที่ โดยทำความเร็ว Prefill ไต่ระดับจาก ~1,650 tokens/s ที่บริบท 512 ขึ้นไปทะลุ 2,012 tokens/s ในบริบท 8K สูงกว่า Vulkan ที่ทำได้ราว 1,708 tokens/s อยู่ถึง +17.8%
Decode Retention นิ่งสนิทแทบไม่ตก (98.8%): เมื่อขยาย Context จาก 2K เป็น 8K โทเค็น ความเร็ว Decode บน CUDA ลดลงเพียงเล็กน้อยจาก 47.57 เหลือ 47.00 tokens/s (รักษาความเร็วไว้ได้ถึง 98.8%) และ Vulkan ก็รักษาไว้ได้ที่ 98.9% เช่นกัน สะท้อนว่าขนาดโมเดล 7.5 GB ยังไม่สร้างแรงกดดันต่อ VRAM 16 GB แต่อย่างใด
ความเหนือกว่าของ CUDA ต่อ Vulkan คงที่ตลอดสาย: ในทุกเวิร์กโหลด CUDA ให้ Decode เร็วกว่า Vulkan อยู่เฉลี่ย +5.1% อย่างสม่ำเสมอ

การทดสอบที่ 2: บททดสอบขีดจำกัดสถาปัตยกรรม MoE (`Gemma-4-26B-A4B-it`) ในภาวะ VRAM-Tight

โมเดล: gemma-4-26B-A4B-it-Q4_K_M.gguf
ขนาดไฟล์โมเดล: 15.64 GB
หน่วยความจำ VRAM ของการ์ด: 16.00 GB (16,310 MiB)
สภาพแวดล้อม: VRAM-Tight Stress Test (เหลือพื้นที่ VRAM เพียง ~670 MiB ก่อนโหลด)

1. การประชันความสามารถในการจัดสรรหน่วยความจำ (Memory Management)

ผลลัพธ์ในการโหลดโมเดลเข้าสู่ VRAM ขนาด 16 GB แสดงให้เห็นความแตกต่างอย่างมีนัยสำคัญระหว่าง 2 แบ็กเอนด์:

CUDA Backend — ผ่านฉลุย 100%: ไดรเวอร์ CUDA และ memory allocator ของ llama.cpp สามารถจัดสรรพื้นที่ VRAM 16 GB ได้อย่างรัดกุมจนสามารถบรรจุ Weights ทั้ง 15.64 GB และจัดสรร KV Cache บน VRAM ได้อย่างพอดี ทำให้รันผ่านครบทั้ง 36 รอบวัดผล (5/5 PASS ทุกเวิร์กโหลด)
Vulkan Backend — ล้มเหลวทันที (OOM Crash): เซิร์ฟเวอร์ไม่สามารถเริ่มต้นทำงานได้ โดยแครชขณะพยายามจัดสรร Buffer:

สาเหตุเชิงเทคนิค: รันไทม์ Vulkan บน Windows มีค่า Overhead ของ Descriptor Pools, Buffer Alignment และ Uniform Buffer Object (UBO) สูงกว่า Native CUDA เล็กน้อย เมื่อต้องโหลดโมเดลขนาด 15.64 GB ซึ่งเกือบชนเพดาน VRAM 16,310 MiB ค่า Overhead ส่วนเกินราว ~529 MB (555,105,280 bytes) นี้จึงทำให้หน่วยความจำทะลุขอบเขตการ์ดทันที

2. ประสิทธิภาพของ CUDA บนโมเดล MoE 26B-A4B ในภาวะ VRAM-Tight

เวิร์กโหลด (Workload)	Context / Gen	Prefill Speed (tok/s)	Decode Speed (tok/s)	TTFT (s)	E2E Latency (s)	สถานะผลการทดสอบ
Content Generation / 512-256	511 / 256	355.7	23.27	1.610s	12.563s	5/5 PASS
Creative Writing / 512-512	512 / 512	356.4	22.17	1.526s	24.571s	5/5 PASS
Summarization Light / 2K-256	2,048 / 256	237.2	17.26	8.700s	23.472s	5/5 PASS
Summarization Moderate / 4K-256	4,096 / 256	202.5	14.98	20.250s	37.271s	5/5 PASS
Summarization Long / 8K-256	8,192 / 256	163.7	12.10	50.063s	71.149s	5/5 PASS
Code Analysis / 4K-256	4,096 / 256	202.5	14.98	20.308s	37.326s	5/5 PASS

บทวิเคราะห์เปรียบเทียบเชิงสถาปัตยกรรม: Dense 12B ปะทะ MoE 26B-A4B บน CUDA

การเปรียบเทียบระหว่างโมเดล Dense 12B และ MoE 26B (Active 4B) บนการ์ด RTX 5060 Ti ใบเดียวกัน เผยให้เห็นพฤติกรรมของฮาร์ดแวร์เมื่อต้องรับมือกับโมเดลต่างสถาปัตยกรรม:

ตัวชี้วัด (Metric)	Gemma-4 12B (Dense)	Gemma-4 26B-A4B (MoE)	การเปลี่ยนแปลง (Impact)
ขนาดไฟล์โมเดล (Q4_K_M)	~7.50 GB	~15.64 GB	ใช้ VRAM เพิ่มขึ้น +108.5%
ความเร็ว Prefill (512 ctx)	1,653.7 tok/s	355.7 tok/s	ช้าลง 78.5%
ความเร็ว Prefill (8K ctx)	2,012.0 tok/s	163.7 tok/s	ช้าลง 91.9%
ความเร็ว Decode (Short ctx 512)	49.11 tok/s	23.27 tok/s	ช้าลง 52.6%
ความเร็ว Decode (Long ctx 8K)	47.00 tok/s	12.10 tok/s	ช้าลง 74.3% (Decode Retained เหลือเพียง 70.1%)
TTFT ที่บริบท 8K Tokens	4.108 วินาที	50.063 วินาที	รอนานขึ้น 12.2 เท่า

เหตุใด MoE 26B-A4B จึงชะลอตัวลงอย่างรุนแรงเมื่อบริบทขยายขึ้น?

ภาวะ VRAM-Tight และแรงกดดันของ KV Cache: ที่บริบทสั้น 512 โทเค็น โมเดล MoE ทำ Decode ได้ถึง 23.27 tokens/s ซึ่งเร็วพอสำหรับการอ่านแบบ Interactive แต่เมื่อบริบทสะสมเพิ่มเป็น 4K และ 8K ขนาดของ KV Cache จะขยายตัวจนกินพื้นที่ VRAM ที่เหลือเพียงไม่กี่ร้อยเมกะไบต์อย่างหนักหน่วง ทำให้ระบบ Memory Controller ของ GPU ต้องจัดการหน่วยความจำภายใต้ความกดดันสูง ส่งผลให้อัตรา Decode ดรอปลงเหลือเพียง 12.10 tokens/s (Decode Retention เหลือเพียง 70.1% เทียบกับ 12B ที่คงไว้ได้ถึง 98.8%)
ต้นทุน Prefill และ TTFT พุ่งสูงถึง 50 วินาที: ในโมเดล MoE ขั้นตอน Prompt Processing ต้องคำนวณ Gating Network และสลับ Experts ไปมา การอ่านเอกสารยาว 8,192 tokens ต้องใช้เวลาถึง 50 วินาทีกว่าจะเริ่มพ่นโทเค็นแรกออกมา ซึ่งถือว่านานเกินไปสำหรับงานสรุปเอกสารแบบ Real-time บนการ์ดใบเดียว

การใช้ประโยชน์จากแบนด์วิดท์หน่วยความจำ GDDR7 (448 GB/s):

ตามทฤษฎี ความเร็ว Decode สูงสุดคำนวณได้จาก: Max Theoretical Decode (tok/s) ≈ Memory Bandwidth (GB/s) ÷ Model Weight Size (GB)

สำหรับ Gemma-4-12B (7.50 GB): เพดานทฤษฎีคือ 448 ÷ 7.50 ≈ 59.73 tok/s
- การ์ด RTX 5060 Ti บน CUDA ทำได้ 49.11 tok/s คิดเป็น 82.2% ของเพดานทฤษฎี ถือเป็นประสิทธิภาพที่ยอดเยี่ยมมาก
สำหรับ Gemma-4-26B-A4B (15.64 GB): แม้จะมี Active Parameters เพียง ~4B แต่เนื่องจากการเข้าถึง Weights ต้องผ่านโครงข่าย Router และ VRAM แทบไม่เหลือพื้นที่ให้แคช ความเร็วที่ทำได้ 23.27 tok/s จึงสะท้อนขีดจำกัดจริงของฮาร์ดแวร์ 16GB

สรุปคำแนะนำสำหรับการใช้งานจริง

[!TIP] 1. ผู้ใช้ NVIDIA RTX บน Windows ควรเลือกใช้ CUDA เป็นค่าเริ่มต้นเสมอ
จากผลการทดสอบ ชัดเจนว่า CUDA มอบประสิทธิภาพที่เหนือกว่า Vulkan ในทุกด้าน:

ความเร็ว Prefill สูงกว่า 16.7% ถึง 32.1%

ความเร็ว Decode สูงกว่า ~5%

การบริหารจัดการหน่วยความจำรัดกุมกว่ามาก ไม่มีปัญหา Crash จาก OOM เมื่อโหลดโมเดลใหญ่ระดับชนเพดาน VRAM

[!IMPORTANT] 2. ขนาดโมเดลที่แนะนำ (Sweet Spot) สำหรับ RTX 5060 Ti 16GB

โมเดล Dense ระดับ 8B – 14B (เช่น Gemma-4-12B, Qwen-2.5-14B Q4/Q8): คือจุดสมดุลที่ดีที่สุด ให้ความเร็ว Decode ระดับ 47–50 tokens/s ตอบสนองคำแรก (TTFT) ภายใน 0.4–4 วินาที และรองรับบริบทกว้างระดับ 12K ได้อย่างสบายใจโดย VRAM ไม่ล้น

โมเดล MoE ระดับ 26B-A4B: แม้จะสามารถรันแบบ Full Offload บน CUDA ได้ แต่ควรจำกัดขนาด Context Window ไว้ไม่เกิน 2,048 – 4,096 tokens เพื่อรักษาความเร็ว Decode ให้อยู่ในเกณฑ์ใช้งานได้ (15–23 tokens/s) และป้องกันไม่ให้ TTFT ลากยาวเกินไป