ปลุกชีพการ์ดจอ Rig เหมืองเก่า ให้มาทำงาน AI

ทำไมการ์ดขุดถึงกลับมามีค่า

หลังยุคขุดเหรียญจบลง P102-100 กลายเป็นการ์ดที่แทบไม่มีใครอยากได้ เพราะมันไม่มีพอร์ตต่อจอ ไดรเวอร์ก็เลือกเวอร์ชัน และหลายคนเชื่อว่ามันคือการ์ด "ตัดแข้งตัดขา" ที่ทำอะไรไม่ได้นอกจากขุด แต่บางคนก็นำไปเล่นเกมส์ อยู่เหมือนกันนะครับ

แต่ถ้ามองจากมุมของงาน AI สเปกของมันน่าสนใจกว่าที่คิดมาก P102-100 ใช้ชิป GP102 ตัวเดียวกับ GTX 1080 Ti และที่สำคัญที่สุดคือ แบนด์วิดท์หน่วยความจำ ซึ่งเป็นตัวชี้ขาดความเร็วของงาน LLM โดยตรง คำนวณจากค่า clock ที่อ่านได้จากการ์ดจริง

clocks.max.mem = 5505 MHz (GDDR5X)
5505 × 2 = 11 Gbps effective
11 Gbps × 320-bit ÷ 8 = ~440 GB/s ต่อใบ

440 GB/s อยู่ในระดับเดียวกับ GTX 1080 Ti และสามใบรวมกันได้ VRAM 30 GB ซึ่งมากพอจะใส่โมเดลระดับ 35B แบบ 4-bit ได้ทั้งก้อนโดยไม่ต้องพึ่ง RAM หรือ SSD เลย นั่นคือเส้นแบ่งระหว่าง "รันได้แบบทรมาน" กับ "รันได้จริง"

และที่สำคัญโดยปรกติแล้ว การ์ด P102-100 กับ Firmware จากโรงงานนั้น จะมองเห็น VRAM แค่ 5 GB แต่ในปัจจุบันนี้ได้มี Firmware MOD สำหรับ ปลดล็อกให้มองเห็น VRAM 10GB ซึ่งแท้จริงแล้ว P102-100 นั้น มี VRAM 10GB แต่กำเนิด แต่โดนล็อกด้วย Firmware ไว้ ส่วนการ FLASH FIRMWARE นั้นผมขอไม่อธิบายในบทความนี้นะครับ กลัวผิดกฏหมาย ฮ่าๆๆ

หัวใจของบทความนี้คือ เราวัดทุกอย่างจริง ไม่เดา — ผมได้ไปหาข้อมูลหลายๆอย่างตาม Community ต่างประเทศ หลายข้อที่เจอตามอินเทอร์เน็ต ก่อนตัดสินใจทำโปรเจคนี้ มีคำแนะนำต่างๆมากมาย แต่พอเอามาวัดบนเครื่องจริงแล้ว กลับผิดหรือไม่มีผลเลย ซึ่งผมจะมาเล่าให้ฟังทั้งหมด ทั้งหมดนี้เกิดขึ้นกับตัวผมทั้งหมด ซึ่งแต่ละคนที่มีสภาพแวดล้อมของอุปกรณ์ อาจจะแตกต่างกันออกไป

เริ่มกันเลยนี่คือ SPEC ที่ผมนำมาทดสอบรันในครั้งนี้

GPU - P102-100 × 3 / 10 GB ต่อใบ = VRAM รวม 30,431 MiB

PCIe - ×1 (riser)

Mainboard - BIOSTAR TB250-BTC+ ที่เหลือมาจากการขุดเหมือง

CPU - Pentium G4560 2C / 4T

RAM - 11 GB จากการหาเศษแรมในบ้าน 4 + 8 GB มาผสมๆกันให้พอจะสามารถใช้งานได้

OS - Ubuntu 24.04.1 kernel 6.8.0-41

PSU - GVIEW Mining 1000W

MODEL - Qwen 3.6 (35B) Q4_K_M

เลือก OS, Kernel และ Driver — จุดที่พลาดกันมากที่สุด และทำให้ผมเสียเวลาอยู่หลายวัน

P102-100 เป็นสถาปัตยกรรม Pascal (compute capability 6.1) ซึ่ง NVIDIA ยังรองรับผ่านไดรเวอร์สาย 550 การเลือกชุดนี้ต้องล็อกให้เข้ากันทั้งสามชั้น คือ kernel, driver และ CUDA toolkit

ชุดที่ทดสอบแล้วใช้งานได้จริง เชื่อผมเถอะผมเจ็บมาเยอะ ฮ่าๆ
ส่วนประกอบ	เวอร์ชัน	เหตุผล
OS	`Ubuntu 24.04.1 LTS`	LTS อายุยาว แพ็กเกจครบ
Kernel	`6.8.0-41-generic`	เวอร์ชันที่ไดรเวอร์ build ผ่าน
NVIDIA Driver	`550.144.03`	Verสุดท้ายที่รองรับ Pascal ได้ดี
CUDA	`12.4` (V12.4.99)	คู่กับไดรเวอร์ 550
Compiler	`gcc 13.3.0` / `cmake 3.28.3`	ของที่มากับ 24.04

ล็อก kernel ให้ถูก — ไม่งั้นไดรเวอร์หายทั้งระบบ

ไดรเวอร์ NVIDIA ผูกกับ kernel ที่มัน build ไว้ ถ้า Ubuntu อัปเกรด kernel แล้วรีบูต โมดูลจะหายทันที อาการคือ nvidia-smi แสดงว่าคุยกับไดรเวอร์ไม่ได้ และ llama.cpp ขึ้นว่า no CUDA-capable device is detected ผมเจอเหตุการ์ณแบบนี้อยู่หลายรอบมากๆ เรียกว่า ท้อเลยทีเดียวครับ เพราะเสียเวลาไปเกือบ 3 วัน กว่าผมจะหาสาเหตุได้นั่งคิดแล้วคิดอีกว่าเกิดจากอะไร ก็เลยนึกถึงเจ้า OS Windows นี่แหละครับว่า หรือเจ้า Ubuntu แอบอัปเดทอะไรแน่ๆเลย ก็เลยมาสังเกตุดูสรุปว่าจริงๆด้วยครับ น้อง Ubuntu แอบอัปเดท Kernel ผมก็เลยติดตั้ง OS ใหม่ และ HOLD update ไว้ แต่สุดท้ายก็ไม่รอดเพราะผม HOLD ไม่ครบอีก พยายามหาข้อมูลจนไล่ HOLD จนครบดังนี้

หลุมพราง — hold ไม่ครบชื่อ

คนส่วนใหญ่ apt-mark hold แค่ 3 ชื่อแรก ซึ่งไม่พอ เพราะ Ubuntu ใช้ meta-package สาย HWE ที่ชื่อคนละตัว และมันคือตัวที่จะลาก kernel ใหม่เข้ามา

sudo apt-mark hold 
  linux-generic linux-image-generic linux-headers-generic 
  linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 
  linux-headers-generic-hwe-24.04

apt-mark showhold   # ต้องได้ครบ 6 บรรทัด

และปิดตัวการที่จะอัปเกรดให้เองตอนเราเผลอ

sudo systemctl disable --now unattended-upgrades

วิธีตรวจว่าไดรเวอร์อยู่ที่ kernel ไหน ให้ใช้ modinfo เท่านั้น อย่าใช้ find หาไฟล์ชื่อ nvidia*.ko เพราะจะไปเจอ nvidiafb กับ nvidia-wmi-ec-backlight ซึ่งคนละตัวกันสิ้นเชิง

uname -r
modinfo -k $(uname -r) nvidia | grep -E "^(filename|version)"
# ต้องได้ version: 550.144.03

เตรียมระบบก่อนโหลดโมเดล 35B

โมเดล Qwen 4-bit ขนาด 35B กินพื้นที่ราว 20 GB บนดิสก์ เวลาโหลดขึ้น VRAM llama.cpp จะอ่านไฟล์ผ่านกลไกที่เรียกว่า mmap ซึ่งบนเครื่องที่ RAM น้อยกว่าขนาดโมเดล จะทำให้เกิดอาการที่เรียกว่า page cache churn และนี่คืออีกปัญหาที่ผมพบเจอ เพราะ ผม RAM น้อย ถ้า RAM คุณเยอะข้ามข้อนี้ไปได้เลยครับ

mmap และ page cache churn คืออะไร

mmap (memory-mapped file): แทนที่จะสั่ง "อ่านไฟล์ 20 GB เข้า RAM ให้หมดก่อน" โปรแกรมบอกระบบปฏิบัติการว่า "ขอผูกไฟล์นี้เข้ากับพื้นที่หน่วยความจำ แล้วค่อยดึงเฉพาะส่วนที่ใช้" ระบบจะค่อยโหลดตามที่โปรแกรมเรียกใช้จริง
ข้อดีคือโปรแกรมเปิดไฟล์ที่ใหญ่กว่า RAM ได้ — ซึ่งจำเป็นมากในกรณีนี้ เพราะโมเดล 20 GB แต่เครื่องมี RAM แค่ 11 GB
page cache: พื้นที่ RAM ที่ระบบปฏิบัติการใช้เก็บ ไฟล์ที่เพิ่งอ่านมา เผื่อว่าจะถูกเรียกใช้ซ้ำ จะได้ไม่ต้องไปอ่านดิสก์อีก
page cache churn (การปั่นแคช): เกิดเมื่อไฟล์ ใหญ่กว่า RAM ที่ว่าง ระบบอ่านหน้าใหม่เข้ามา แต่ไม่มีที่ว่าง จึงต้อง ไล่ของเก่าทิ้ง ตลอดเวลา กลายเป็นวงจรอ่าน-ทิ้ง-อ่าน-ทิ้ง ซ้ำๆ ระบบจะรายงานว่ามี "memory pressure" สูงมาก ทั้งที่จริงๆ แล้วหน่วยความจำก้อนนี้ คืนได้ตลอดเวลา ไม่ใช่ภาวะขาดแคลนจริง

และผมเจอหลุมพรางอีกแล้วครับ — systemd-oomd แอบฆ่า session ทิ้ง

Ubuntu 24.04 ตั้ง systemd-oomd ให้ฆ่า user session เมื่อ memory pressure เกิน 50% นานกว่า 20 วินาที ซึ่ง การโหลดโมเดลทำให้เข้าเงื่อนไขนี้พอดี อาการคือ terminal ดับไปเฉยๆ ทั้งที่เครื่องไม่ได้ค้างและไม่ได้รีบูต

systemd-oomd: Killed /user.slice/.../init.scope due to memory pressure
being 69.37% > 50.00% for > 20s with reclaim activity

แก้ด้วยคำสั่งเดียว มีผลทันที ไม่ต้อง logout

sudo systemctl set-property user@1000.service 
  ManagedOOMMemoryPressure=auto

ถ้าเครื่องคุณ RAM เยอะ จะเจอปัญหานี้ไหม

ไม่เจอครับ — และยังได้ของแถมด้วย ถ้า RAM ว่างมากกว่าขนาดไฟล์โมเดล ระบบจะเก็บไฟล์ทั้งก้อนไว้ใน page cache ได้ ไม่ต้องไล่หน้าเก่าทิ้ง จึงไม่เกิด memory pressure และ systemd-oomd ก็ไม่ทำงาน

RAM ของคุณ

สิ่งที่จะเกิดขึ้น

น้อยกว่าขนาดโมเดล
เช่น RAM 11 GB / โมเดล 20 GB

เกิด churn · เสี่ยงโดน oomd ฆ่า · ต้องแก้ค่าตามด้านบน

มากกว่าขนาดโมเดล + 8 GB
เช่น RAM 32–64 GB / โมเดล 20 GB

ไม่เกิด churn · ไม่ต้องแก้อะไร · เปิดโมเดลรอบที่ 2 เร็วขึ้นมาก เพราะไฟล์ยังอยู่ใน cache

กฎง่ายๆ: ถ้า RAM ≥ ขนาดไฟล์โมเดล + 8 GB ให้ข้ามหัวข้อ systemd-oomd ไปได้เลย

เตรียมติดตั้ง Engine (LLM) ผมเลือกใช้ llama.cpp เพราะดูแล้วน่าจะเหมาะกับ P102-100 มากที่สุด

ผมพยายามนั่งอ่านอยู่ซักพักนึงสำหรับคู่มือการใช้งาน และหาข้อมูลในอินเตอร์เน็ตหลายคนคัดลอกคำสั่ง cmake ยาวเหยียดมาใช้ ทั้งที่ค่า default ของ llama.cpp เหมาะกับงานนี้อยู่แล้วเกือบทั้งหมด ที่ผมใช้จริงๆมีแค่สามบรรทัด

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -B build 
  -DCMAKE_BUILD_TYPE=Release 
  -DGGML_CUDA=ON 
  -DCMAKE_CUDA_ARCHITECTURES=61

cmake --build build -j3

บรรทัดที่สำคัญที่สุดคือ `CMAKE_CUDA_ARCHITECTURES=61`

61 คือรหัสสถาปัตยกรรมของ Pascal (sm_61) ซึ่งตรงกับ P102-100 พอดี ถ้าไม่ระบุ nvcc จะ compile เผื่อทุกสถาปัตยกรรมตั้งแต่เก่าถึงใหม่ ซึ่งบน CPU 2 คอร์อาจกินเวลานานนนนน การระบุตรงๆ ทำให้เหลือสั้นลงอย่างแน่นอน

ส่วนค่าอื่นปล่อยเป็น default ได้หมด เพราะมันเปิดสิ่งที่เราต้องการอยู่แล้ว — Flash Attention, CUDA Graphs (ลดภาระ CPU ซึ่งช่วยมากเมื่อ CPU อ่อน), การดึงชุดคำสั่งของ CPU ออกมาใช้เอง และการ build llama-server

เลข `-j` ควรใส่เท่าไหร่ — ขึ้นกับ RAM ไม่ใช่แค่จำนวนคอร์

-j คือจำนวนงานที่ให้ compile พร้อมกัน หลายคนใส่เท่าจำนวน thread ของ CPU ซึ่งถูกในกรณีทั่วไป แต่ขั้นตอน link ของ llama.cpp กิน RAM หนักเป็นพิเศษ ถ้า RAM ไม่พอ process จะถูกฆ่ากลางทาง บทความนี้ใช้ -j3 เพราะเครื่องมี RAM แค่ 11 GB

สูตรเลือกค่า -j

-j = ค่าที่น้อยกว่าระหว่าง ( จำนวน thread ของ CPU , RAM เป็น GB ÷ 2 )

เครื่องของคุณ	ควรใช้	ทำไม
RAM 11 GB · 4 thread	-j3	RAM เป็นตัวจำกัด (11÷2 ≈ 5 แต่เผื่อ desktop ไว้)
RAM 16 GB · 8 thread	-j8	พอดีทั้งสองด้าน
RAM 32 GB · 12 thread	-j12	CPU เป็นตัวจำกัด ใช้เต็มได้
RAM 64 GB · 16 thread	-j16	RAM เหลือเฟือ ใช้เต็มได้เลย

ถ้า RAM มากกว่า 2 GB ต่อ 1 thread ให้ใช้คำสั่งนี้ได้เลย มันจะอ่านจำนวน thread ของเครื่องคุณเอง

cmake --build build -j$(nproc)

ถ้าเผลอใส่มากไปแล้วถูกฆ่ากลางทางแบบผม ไม่ต้องเริ่มใหม่ — ลดเลข -j แล้วสั่งซ้ำ มันจะ build ต่อจากจุดเดิม เพราะ ผมก็โดน Kill Process อยู่ 2 รอบคับผม

ตรวจว่าเห็นการ์ดครบ

./build/bin/llama-bench --list-devices

ggml_cuda_init: found 3 CUDA devices (Total VRAM: 30431 MiB):
  Device 0: NVIDIA P102-100, compute capability 6.1, VRAM: 10144 MiB
  Device 1: NVIDIA P102-100, compute capability 6.1, VRAM: 10144 MiB
  Device 2: NVIDIA P102-100, compute capability 6.1, VRAM: 10143 MiB

ผลทดสอบ ที่มาของทุก parameter ที่วัดค่าบนเครื่องผมจริงๆ

ทั้งหมดวัดด้วย llama-bench บนเครื่องจริง ไม่ใช่ค่าประมาณ

Flash Attention และขนาด micro-batch

llama-bench -m model.gguf -ngl 99 -fa 0,1 -ub 256,512,1024 -r 3

-b และ -ub คืออะไร

-b — logical batch: จำนวน token สูงสุดที่ server รับเข้ามาจัดคิวได้ในหนึ่งรอบ
-ub — micro-batch (physical batch): จำนวน token ที่ ส่งเข้าไปให้ GPU คำนวณจริงในหนึ่งครั้ง
ถ้า prompt ยาว 512 token และตั้ง -ub 256 GPU จะแบ่งทำ 2 ก้อน ก้อนละ 256
ก้อนใหญ่ = รอบน้อยลง แต่กินหน่วยความจำชั่วคราวมากขึ้น และข้อมูลอาจล้น cache ของ GPU
ก้อนเล็ก = รอบมากขึ้น แต่ข้อมูลพอดีกับ cache ทำงานได้ลื่นกว่า
ค่าที่ดีที่สุดขึ้นกับสถาปัตยกรรมการ์ด ต้องวัดเอาเท่านั้น

หมายเหตุ: -ub มีผลกับ PP เท่านั้น ไม่มีผลกับ TG เพราะการพิมพ์คำตอบทำทีละ token อยู่แล้ว

-ub	-fa	pp512 (tok/s)	tg128 (tok/s)
256	0	816.6 ± 63.0	40.83
256	1	981.3 ± 11.6	42.62
512	0	853.4 ± 11.5	41.68
512	1	863.5 ± 5.1	42.65
1024	0	864.5 ± 4.5	41.89
1024	1	877.5 ± 6.1	42.76

ข้อสรุปที่สวนความเชื่อทั่วไป: หลายแหล่งบอกว่า Flash Attention (เทคนิคคำนวณ attention ที่ประหยัดหน่วยความจำ) ออกแบบมาเพื่อการ์ดรุ่นใหม่ และอาจช้าลงบน Pascal แต่วัดจริงแล้ว -fa on เร็วกว่าทุกกรณี ทั้งตอนอ่าน prompt และตอนพิมพ์คำตอบ

และ -ub 256 เร็วกว่า -ub 1024 ถึง 12% สำหรับการอ่าน prompt — micro-batch เล็กเข้ากับ cache ของชิป GP102 ได้ดีกว่า

KV cache — เลือก f16 หรือ q8_0 ดี

type_k	type_v	depth	pp512	tg128
f16	f16	0	807.8	41.46
f16	f16	8192	798.0	41.34
q8_0	q8_0	0	802.2	37.51
q8_0	q8_0	8192	794.4	37.25
f16	q8_0	0	71.0	19.49

type_k/type_v = ชนิดข้อมูลที่ใช้เก็บ KV cache · f16 = ละเอียด 16 บิต · q8_0 = บีบเหลือ 8 บิต กินที่ครึ่งเดียว

หลุมพราง — จับคู่ K กับ V คนละชนิด

การใส่ --cache-type-v q8_0 โดยลืมใส่ฝั่ง K ทำให้ PP ตกจาก 808 เหลือ 71 tok/s (ช้าลง 10-11 เท่า)

ประเด็นคือ "การผสมชนิด" ไม่ใช่ตัว q8_0 — ถ้าใส่ q8_0 ทั้งคู่จะทำงานปกติ

แล้ว q8_0 คือ sweet spot หรือไม่

คำตอบคือ ไม่ใช่ สำหรับเครื่องนี้ของผมครับ — และนี่เป็นจุดที่คนเข้าใจผิดกันบ่อย

q8_0 ทั้งคู่ทำงานได้ปกติ แลก TG ช้าลง ~10% (41.5 → 37.5) เพื่อให้ KV cache เล็กลงครึ่งหนึ่ง คำถามคือ เราต้องการที่ว่างเพิ่มไหม

จากตารางในหัวข้อที่แล้ว แม้ตั้ง context สูงสุดที่โมเดลรองรับ (256K) แบบ f16 ก็ใช้ VRAM แค่ 5 GiB จาก 10 GiB ที่ว่างอยู่ ผมจึงไม่มีอะไรต้องประหยัดเลย การยอมเสียความเร็ว 10% ไปแลกที่ว่างที่ไม่ได้ใช้ จึงไม่คุ้ม

สถานการณ์

ควรใช้

VRAM เหลือ หลังโหลดโมเดล
(เช่นกรณีในบทความนี้)

f16 — ไม่ต้องใส่ parameter อะไร เป็นค่า default อยู่แล้ว TG เร็วสุด

VRAM ตึง หรืออยาก context ยาวมากแต่ที่ไม่พอ
(เช่นมีการ์ดน้อยใบ หรือโมเดล KV ใหญ่)

q8_0 ทั้ง K และ V — ยอมเสีย TG 10% แลกที่ว่างครึ่งหนึ่ง

ไม่ว่ากรณีใด

❌ ห้ามใส่แค่ตัวใดตัวหนึ่ง — ช้าลง 11 เท่า

อีกข่าวดีจากตารางนี้: ดูคอลัมน์ depth จะเห็นว่าที่ depth 8192 (คือคุยกันมาแล้ว 8 พัน token) ความเร็วตกจากตอนเริ่มคุยใหม่เพียง ~1% เท่านั้น บทสนทนายาวไม่ทำให้ช้าลงอย่างมีนัยสำคัญ

การแบ่งงานข้ามการ์ด

-sm	pp512	tg128
layer (ค่า default)	795.2	41.38
row	failed to load model

-sm คือวิธีแบ่งงานเมื่อมีการ์ดหลายใบ — layer คือแบ่งเป็นชั้นๆ ให้การ์ดใบละกลุ่ม ส่วน row คือผ่าทุกชั้นแบ่งกันทำทุกใบพร้อมกัน

-sm row เป็นคำแนะนำที่เจอบ่อย แต่บนเครื่องของผมนี้ โหลดโมเดลไม่ขึ้นเลยครับ 555555 ไม่ใช่แค่ช้า ผมพยายามหลายรอบแล้วบางครั้งเครื่องก็ค้าง เอ๋อไปเลย ฉนั้น sm row ผมไม่มีผลให้ชมครับ

คำสั่งรันที่แนะนำ

llama-server 
  -m /path/to/Qwen3.6-35B-A3B-Q4_K_M.gguf 
  -ngl 99 
  -c 32768 
  -fa on 
  -b 2048 -ub 256 
  -t 4 
  --host 127.0.0.1 --port 8080

ที่มาของแต่ละ parameter
Parameter	เหตุผล
`-ngl 99`	จำนวน layer ที่ดันขึ้น GPU — ใส่เลขสูงๆ แปลว่า "เอาขึ้นให้หมด" จำเป็นเมื่อ RAM น้อยกว่าขนาดโมเดล
`-fa on`	Flash Attention — วัดแล้วเร็วกว่าปิดทุกกรณี
`-ub 256`	เร็วกว่า 1024 ถึง 12% สำหรับ prompt
`-c 32768`	ความยาว context — KV แค่ 640 MiB ขยายได้อีกนะครับถ้าเพื่อนๆต้องการ
`-t 4`	จำนวน thread ของ CPU
`--host 127.0.0.1`	เปิดให้เฉพาะเครื่องตัวเอง ไม่เปิดสู่วงแลนโดยไม่มีรหัสผ่าน หรือจะเปิดเป็น 0.0.0.0 ก็ได้นะครับ ถ้าต้องการ

ทำไมไม่ใส่ `--cache-type-k q8_0 --cache-type-v q8_0`

เพราะ เครื่องนี้ VRAM เหลือ ตามที่อธิบายในหัวข้อที่แล้ว การใส่ q8_0 จะทำให้ TG ช้าลงราวเกือบ 10% (จาก 41.5 เหลือ 37.5 tok/s) เพื่อประหยัดที่ว่างที่เราไม่ได้ต้องการ

ที่ -c 32768 แบบ f16 ใช้ KV cache แค่ 640 MiB จาก VRAM ว่างราว 10 GiB — ต่อให้ตั้ง context สูงสุด 256K ก็ยังใช้แค่ 5 GiB จึงไม่มีเหตุผลให้ยอมเสียความเร็ว

ถ้าเครื่องคุณต่างจากนี้ เช่นมี VRAM 22-24 GB หรือรันโมเดลที่ KV cache ใหญ่กว่า แล้วพบว่า VRAM ไม่พอ ค่อยเติมสองตัวนี้เข้าไป พร้อมกันทั้งคู่

# เติมเมื่อ VRAM ไม่พอเท่านั้น และต้องใส่ทั้งคู่
  --cache-type-k q8_0 --cache-type-v q8_0

สิ่งที่ผมลองดูแล้วไม่ค่อยมีผล

ส่วนนี้เป็นคำแนะนำที่เจอบ่อยตามอินเทอร์เน็ต ตาม Community ต่างๆที่ผมไปหามา แต่พอวัดจริงบนเครื่องนี้แล้วกลับไม่เป็นอย่างที่เล่าต่อกันมา

ไม่มีผล ตั้ง power limit nvidia-smi -pl 140 — หลังจากที่ผมวัดแล้วการ์ดกินไฟสูงสุดแค่ 135 W และ ต่ำกว่าเพดานที่จะตั้งเสียอีก clock วิ่งเต็ม ตลอด อุณหภูมิแค่ 41–50 °C ไม่มีการลดความเร็วเพราะร้อนหรือไฟไม่พอเลย คำแนะนำนี้อาจจะมาจากบริบทการขุดที่การ์ดทำงาน 100% ทุกใบพร้อมกันจนแตะ 250 W จริง ซึ่งเป็นรูปแบบภาระงานคนละแบบกับงาน LLM ตามที่ผมทดสอบการใช้งานในแบบของผม แต่ก็ตั้งไว้ได้อุ่นใจกว่า
ได้ผล ปล่อยค่า default ของ llama.cpp ไว้ — นอกจาก -ub 256 ที่เราแก้ไขแล้ว ค่าที่ทีมพัฒนาตั้งมาเหมาะสมอยู่แล้ว การไปปรับเยอะๆ มักได้ผลลบมากกว่าบวก

สรุปและข้อจำกัดที่ต้องรู้ก่อนลงมือ

การ์ดขุด P102-100 สามใบราคาถูก บวกบอร์ดขุดที่เก่าเก็บไม่ได้ใช้ ให้ผลลัพธ์ที่ใช้งานได้จริง — โมเดล 35B ตอบกลับที่ 39-41 tok/s ซึ่งเร็วกว่าความเร็วอ่านของคนทั่วไป และรับ prompt ยาวๆ ได้ที่เกือบ 1,000 tok/s

แต่ควรรู้ข้อจำกัดเหล่านี้ก่อนตัดสินใจทำตาม

โหลดโมเดลช้ามากกกกก — ราว 3 นาทีครึ่งทุกครั้งที่เปิด เพราะต้องส่งModel 20 GB ผ่าน riser x1 แก้ได้ด้วยการเปิด server ค้างไว้ เพราะมีผลแค่ตอนโหลดครั้งแรกเท่านั้น อาจจะเป็นเพราะ RAM ผมที่มีน้อยด้วยครับ 11 GB เพื่อนๆที่มี RAM มากกว่านี้ ผมว่าโหลดได้เร็วกว่านี้มาก
ผูกกับ kernel และไดรเวอร์แน่นมาก — ต้องยอมไม่อัปเดต ซึ่งหมายถึงไม่ได้ security patch ของ kernel ด้วย ควรใช้เป็นเครื่องที่รัน offline เฉพาะทางที่ไม่เปิดสู่อินเทอร์เน็ตตรงๆ เนื่องจากความปลอดภัย
CPU , RAM ที่น้อยแบบเครื่องผมเป็นคอขวดในบางครั้ง — เห็นได้ชัดจากการทดสอบ Bench หลายๆครั้ง เครื่องมีอาการหน่วงอย่างชัดเจน ควรใช้ CPU , RAM ที่ดีกว่าเครื่องที่ผมทดสอบในครั้งนี้

คำแนะนำ: ถ้าเป้าหมายคือ ได้เครื่อง Local AI ส่วนตัวที่รันโมเดล 35Bได้จริง ในงบที่ต่ำมาก ทางนี้คุ้มมาก แต่ถ้าเป้าหมายคือ ความเร็วสูงสุด เงินก้อนเดียวกันนี้ควรไปลงที่การ์ดที่ใหม่กว่า