DGX Spark เครื่องดับตอนรัน model — แก้ด้วย clock cap 2200 MHz

สารบัญ

• เจอกระทู้ที่อ่านแล้วเงียบ
• ทำไมถึงไม่มี log
• เจอ repo ที่แก้ปัญหานี้
• Memory pressure — ต้องทำเพิ่ม
• ทดลองยกระดับ clock
• ถ้า clock cap อย่างเดียวไม่พอ
• สรุป
• อ้างอิง

บันทึก — 23 สิงหาคม 2569 — บ่ายโน่น แก้ปัญหาเสร็จพอดี

เรื่องมันเริ่มจากผมเพิ่งเอา DGX Spark ขึ้นมาตั้งบนโต๊ะเมื่อเช้า ยังไม่ทันได้รัน model อะไรเลย — แค่ SSH เข้าไปเช็ค nvidia-smi ก็เห็น GPU GB10 ตรงตามสเปก, driver 580.173.02, CUDA 13.0 พร้อมใช้

แล้วก็เปิด NVIDIA Developer Forums ดู ด้วยความอยากรู้ว่า "คนอื่นใช้กันยังไง"

เจอกระทู้ที่อ่านแล้วเงียบ

ค้นคำว่า "DGX Spark shutdown" ใน forum — ผมเจอกระทู้ที่ทำเอานิ่งไปสักพัก:

• "DGX Spark Shutdown around 95°C during nanoChat Pretraining" — คนรัน Karpathy's nanoChat 20-30 นาที เครื่องดับ
• "DGX Spark (GB10) reproducibly hard powers-off under GPU load" — ทำซ้ำได้ด้วย vLLM stress test ภายใน 60 วินาที
• "Spark abruptly shuts down" — คนใช้ 2 เครื่องบอกอาการเหมือนกันเป๊ะ hard death ตอน sustained load
• "DGX Spark system hardware crashes at around 75W" — reboot วนซ้ำที่ 75W

ทุกกระทู้มีลายเซ็นเดียวกัน: เครื่องดับสนิท, ไม่มี log, ไม่มี kernel panic, ไม่มี thermal warning แค่ journal line สุดท้ายเป็นเรื่องปกติ (ssh, tailscale, audio daemon) แล้วก็เงียบ

อ่านแล้วก็คิดในใจ "เฮ้ย ที่ผมเพิ่งซื้อมามันเป็นแบบนี้เลยเหรอ" — เพราะถ้าเครื่องผมดับตอนรัน model หนักๆ ผมจะ track down ปัญหาได้จากตรงไหน ถ้าในเครื่องไม่มี log อะไรเลย?

ทำไมถึงไม่มี log

ปกติถ้าเครื่อง Linux มีปัญหา จะมีอย่างน้อยที่สุดหนึ่งในนี้:

• kernel panic ลง dmesg
• OOM killer log
• hung-task detector warning
• MCE (Machine Check Exception)
• Xid จาก NVIDIA driver
• thermal throttle warning ก่อนดับ

ที่นี่ ไม่มีอะไรเลย อธิบายได้ด้วย 2 ข้อ:

1. GB10 ไม่มี BMC/IPMI/SEL — ไม่มี Baseboard Management Controller, ไม่มี System Event Log, ไม่มี voltage/current hwmon class เลย ดังนั้น electrical cut ทุกชนิดจึง unloggable จากข้างใน

2. EC ตัดไฟเร็วกว่าที่ kernel จะเขียน log — Embedded Controller ของ GB10 ทำ thermal/over-current hard power cut เมื่อ hotspot พุ่ง ~90→98°C ใน ~2 วินาที — kernel threshold อยู่ที่ 104.8°C แต่ไม่มี throttle ก่อนหน้านั้น ดังนั้นระหว่าง 98°C กับ 104.8°C ผ่านไปแค่ 2 วินาที EC ก็ดึงปลั๊กแล้ว

last -Fx ก็บอกแค่ "still running" — ไม่มี shutdown record เพราะมันไม่ได้ shutdown แบบ graceful มันแค่ตาย

Note: สำคัญ — อย่าเพิ่งโทษว่าเป็น hardware อย่างเดียว

มีอีก root cause หนึ่งที่ให้ signature เดียวกันเป๊ะ: unified memory over-commit. บน GB10 GPU และ CPU share memory pool 121 GB เดียวกัน และ free -g โกหก — "available" ที่เห็น 15-20 GB จริงๆ CUDA allocate ได้แค่ 1-3 GB (page cache "available" ไม่ใช่ GPU-allocatable). ถ้ายิง LLM weight ใหญ่ๆ หลายตัว page cache จะบวมแล้วบีบ CUDA allocator จน NV_ERR_NO_MEMORY flood — แล้วก็ hard-fault เหมือน thermal cut เป๊ะ

เจอ repo ที่แก้ปัญหานี้

Search ต่ออีกนิด เจอ tonyd2wild/DGX-Spark-Hard-Poweroff-Fix — community documentation เขียนโดยคนที่เจอปัญหานี้กับ fleet 4 เครื่อง ไม่ใช่ official NVIDIA guidance แต่ field-tested

วิธีการ: cap GPU clock

ทำไม cap clock แล้วแก้ปัญหาได้? เพราะ GB10 ไม่รองรับ nvidia-smi -pl (power limit) เลย — software lever เดียวที่จะลดพลังงาน/ความร้อนก่อน EC ตัดไฟ คือ graphics clock ceiling

sudo nvidia-smi -lgc 300,2200
# min 300 MHz, max 2200 MHz
# default boost ~2418 MHz

ทำเสร็จแล้ว verify:

nvidia-smi -q -d CLOCK | head -20
# ดูบรรทัด "Clocks: Graphics" ตอนโหลดหนัก
# ต้องไม่เกิน 2200 MHz

# revert กลับ
sudo nvidia-smi -rgc

Note: ทำไมถึงเลือก 2200 MHz?

• 2455 MHz (stock): ~47 W, ~72°C
• 2300 MHz: ~34 W, ~67°C
• 2200 MHz: ~32 W, ~66°C
• 2000 MHz: ~27 W, ~63°C

(ข้อมูลจาก Ivan Fioravanti ที่วัด clock/power/temp ladder บน DGX Spark cluster)

LLM decode บน GB10 เป็น memory-bandwidth-bound — ลด clock 9% แต่ throughput ลดแค่ ~5% (จาก 32.3 → 30.8 tok/s) ส่วน compute-bound workload (prefill, training) จ่ายแพงกว่า

ทำให้อยู่ถาวรด้วย systemd

-lgc ไม่ persist ข้าม reboot repo เลยมี systemd unit เล็กๆ มาให้:

sudo cp systemd/gb10-clock-cap.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now gb10-clock-cap.service

# หรือใช้ script ที่มากับ repo:
sudo bash scripts/apply-clock-cap.sh

Unit file:

[Unit]
Description=GB10 GPU clock cap (DGX Spark hard power-off mitigation)
After=nvidia-persistenced.service multi-user.target
Wants=nvidia-persistenced.service

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -lgc 300,2200
RemainAfterExit=yes
ExecStop=/usr/bin/nvidia-smi -rgc

[Install]
WantedBy=multi-user.target

ผมทำเสร็จ reboot ทดสอบ — service run ตอน boot, nvidia-smi -lgc 300,2200 execute สำเร็จ, clock cap อยู่ครบ

Memory pressure — ต้องทำเพิ่ม

Repo เตือนว่า "the stable configuration came from doing both" — clock cap อย่างเดียวแก้ thermal cut แต่ไม่ได้แก้ memory over-commit สองเคสนี้ให้ signature เดียวกันแต่ต้นเหตุคนละแบบ

แนะนำให้ drop page cache เป็นระยะๆ เพราะตอน load LLM weight เข้า RAM, Linux จะเอา weight file (GB+) ไปแคชใน page cache → CUDA allocator ถูกบีบ:

# /etc/cron.d/drop-caches
*/5 * * * * root sync; echo 1 > /proc/sys/vm/drop_caches

แต่ผมใช้ model แค่ 1-2 ชั่วโมงต่อวัน — */5 (288 ครั้ง/วัน) overkill เลยเปลี่ยนเป็น manual mode:

# ลบ cron file
sudo rm /etc/cron.d/drop-caches

# สร้าง helper script
mkdir -p ~/bin
cat > ~/bin/drop-caches <<'EOF'
#!/bin/bash
sudo sync; echo 1 > /proc/sys/vm/drop_caches
EOF
chmod +x ~/bin/drop-caches

# ใช้ตอนจะรัน model
~/bin/drop-caches    # ใส่ password sudo ครั้งเดียว

Trade-off: เสีย disk I/O spike สั้นๆ 1-7 วินาทีทุกครั้ง แต่ป้องกัน memory over-commit ตอน load weight

Note: drop_caches ไม่ทำให้ NVMe wearout

echo 1 > drop_caches แค่ invalidate cache pointer ไม่ได้เขียน disk ส่วน sync flush dirty pages แต่ถ้า idle ไม่มีอะไรให้ sync ก็ไม่เขียน ส่วน next read (cache miss) เป็น read ไม่นับ write count NVMe ของ DGX ทน 1+ PBW ไม่ต้องห่วง

ทดลองยกระดับ clock

ทุกอย่างเสร็จแล้วเครื่องไม่ดับ ผมเลยลองขยับ cap จาก 2200 → 2250 MHz ดู — คำเตือนคืออันนี้คือเสี่ยง เพราะ 2200 MHz เป็น sweet spot ที่ผู้เขียน repo รายงานว่า stable ส่วน 2250 MHz อยู่ตรงกลางระหว่าง safe (2200) กับ risky (2300) ถ้าจะลองต้องสังเกตอย่างน้อย 3-5 วัน ถ้า crash ก็ลดกลับ 2200

sudo bash ~/DGX-Spark-Hard-Poweroff-Fix/scripts/apply-clock-cap.sh 2250

ถ้า clock cap อย่างเดียวไม่พอ

Repo จัดลำดับความเสี่ยงไว้:

1. Update firmware (SBIOS/EC/PD capsule) — ทำผ่าน DGX Dashboard ที่ http://localhost:11000 เท่านั้น — ระวัง brick-capable อย่าทำเองนอก dashboard ผู้เขียน repo รายงานว่า fleet 4 เครื่องของเขา crashing 2 เครื่องรัน pre-production firmware (SBIOS 5.36_0ACUM018) ส่วนเครื่อง production firmware (GX10DGX.0104) stable 2 เครื่อง — split 2×2 เป๊ะไม่ว่า workload
2. Physical — repaste TIM, ปรับ airflow (forum รายงานลดได้ ~15°C)
3. RMA — NVIDIA เคยรับเคลมเครื่องอาการนี้ fielddiag มักจะ throw thermal error 082-000-1-020000600139

Note: อย่าด่วนสรุปว่าเป็น hardware

ถ้า cap clock 2200 MHz + drop_caches แล้วยัง crash ให้ลดลงเป็น 2100, 2000 ก่อนค่อย RMA เพราะบางทีเครื่องแค่ unit ที่ thermal margin แคบกว่า peer

สรุป

ตอนนี้ DGX Spark ของผมรันได้เสถียร — clock cap 2200 MHz + systemd persistence + manual drop_caches ก่อนรัน ทุกอย่าง reversible ทั้งหมด ไม่มีอะไรผูกมัดถาวร (service มี ExecStop restore clocks) ถ้า NVIDIA ออก firmware update แก้ root cause จริงๆ ก็ disable service ได้ทันที

ส่วน throughput ที่ลดลง 5% — ผมยอมรับได้สบายๆ เพราะเครื่องที่ไม่ดับตอนกลางทางมันคุ้มกว่า

อ้างอิง

• tonyd2wild/DGX-Spark-Hard-Poweroff-Fix — field-tested clock cap fix + systemd persistence + memory mitigations
• NVIDIA Forums — DGX Spark / GB10 User Forum — community threads ทุกกระทู้ที่กล่าวถึงใน blog
• DGX Spark Known Issues — official known issues list
• Ivan Fioravanti — clock/power/temp measurements — ตารางเทียบ clock vs power vs temp บน 2× DGX Spark cluster
• DGX-Anti-OOM — anti-OOM watchdog ที่ repo แนะนำ (ผมยังไม่ได้ติดตั้ง)

dgx-sparkgb10blackwellnvidiahardwarellminferencetroubleshooting

แชร์บทความ

FacebookX

☕

เนื้อหานี้มีประโยชน์ไหม? ช่วยสนับสนุนค่ากาแฟให้ผู้เขียนสักแก้ว

Buy Me a Coffee