7 posts tagged with "inference"

บันทึก 13 กันยายน 2569 — โปรเจกต์ optimize single Spark

วันนี้ผม optimize Qwen3.8-Flash-Next (180B MoE, 6B active) บน single DGX Spark (GB10, ARM64, 119 GiB unified memory) จนได้ TTFT warm ลดลงจาก 5 วินาที เหลือ 1.4 วินาที ทั้งหมดนี้ใช้แค่ 2 patches + 1 config tweak ผมขอเล่าเรื่องนี้เพราะว่ามันเป็น pattern ที่ generalize ได้ — ถ้าใคร serve hybrid MoE (Linear Attention + State-Space) บน single box น่าจะเจอปัญหาคล้ายกัน

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

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

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

บันทึกกลางดึก — 17 สิงหาคม 2569 — ตี 2 (อัปเดตคืน 23 ส.ค. 2569 — เพิ่ม Test #5–#7)

TL;DR: ถ้าใช้ vLLM local serving อยากปิด reasoning ให้ใช้ chat_template_kwargs: {"thinking": false} (วิธีทางการ) หรือ reasoning_effort: "none" — อย่าใช้ thinking: {type: "disabled"} เพราะ vLLM serving นี้ ignore param นี้

เรื่องมันเริ่มจากที่ผมเพิ่งเซ็ต self-hosted vLLM เสร็จ แล้วอยากรู้ว่า reasoning_effort มันมีผลจริงไหม — เพราะ docs ของ DeepSeek บอกว่ามี mapping แบบนี้:

low → low
medium → high
high → high
xhigh → high
max → max

แต่พอยิง API จริงๆ ผลออกมาไม่ตรงกับที่ docs บอกเลย — low กับ high ให้ output identical, ส่วน xhigh ก็ไม่ได้ map ไป high อย่างที่ docs ว่า

แล้วคืนนี้ผมก็ไปเจออีกว่า — thinking: {type: "disabled"} ที่ดูเหมือน toggle ตรงๆ ก็ไม่มีผลใน serving นี้ด้วย (เพราะมันถูก reasoning_effort ทับ) — แต่มี 2 วิธีที่ปิด reasoning ได้จริง ซึ่งจะเล่าใน Test #5–#6

บันทึกกลางดึก — 15 สิงหาคม 2569 — ตี 3

เรื่องมันเริ่มจากตอนที่ผมกำลังรัน agent ผ่าน self-hosted vLLM ที่ใช้ DeepSeek-V4-Flash-0731 อยู่ดีๆ model ก็เริ่มติด loop ใน thinking block — พิมพ์ reasoning วนไปวนมา ไม่ยอมจบสักที

ผมนั่งดู log อยู่สักพัก แล้วก็เริ่มเข้าใจว่า — การปรับ parameter ของ reasoning model มันไม่เหมือนกับ LLM ทั่วไป ถ้าใช้ค่า default แบบ OpenAI API ตรงๆ จะเจอ behavior ที่ไม่คาดคิด

เล่าให้ฟังว่าผมเจออะไรบ้าง แล้ว config ที่ใช้งานได้จริงๆ เป็นยังไง

บันทึก 27 มิถุนายน 2569 — อยากรู้ว่า DGX Spark รัน vLLM กับโมเดล 35B NVFP4 แล้วรับโหลดหลาย concurrent request ได้แค่ไหน ก็เลยเขียน script วัดง่าย ๆ ด้วย Python แล้วรันผ่าน SSH

ผมมี vLLM server รันอยู่บน DGX Spark ตั้งแต่เมื่อวาน แต่ไม่เคยได้วัดจริง ๆ ว่ามันรับโหลดได้แค่ไหน ส่วนใหญ่ก็แค่เรียกใช้ทีละ request ก็จบ วันนี้เลยเขียน benchmark script ง่าย ๆ ด้วย Python concurrent.futures + requests แล้วยิงที่ 1, 2, 4, 6, 12 concurrent requests เพื่อดู throughput และ latency

บันทึก 26 มิถุนายน 2569 — เรื่องของการเปลี่ยน Qwen3.6-35B-A3B ไปเป็น Ornith-1.0-35B แล้วเจออะไรหลายอย่าง

หลังจากรัน Qwen3.6-35B-A3B-NVFP4 บน DGX Spark มาได้พักใหญ่ วันนี้ลองเปลี่ยนไปเป็น Ornith-1.0-35B-NVFP4 ดู — เป็นโมเดลที่เพิ่งออก (MIT license) เน้น agentic coding โดยเฉพาะ และ Terminal-Bench 2.1 สูงกว่า Qwen3.6-35B ถึง 11.7 คะแนน แต่ก็เจอบทเรียนหลายอย่างระหว่างทาง

บันทึก 26 มิถุนายน 2569 — ตี 2 — เรื่องของการ tune vLLM บน GB10

เมื่อวาน (2026-06-25) ผมรัน benchmark v2 ที่ gpu_mem=0.7 แล้ว RAM ขึ้นไป 99% เครื่องเกือบค้าง ส่วน v1 ที่ gpu_mem=0.5 ก็เจออาการเดียวกันตอนมี request stuck วันนี้เลยลอง tune ต่อจนมาถึง v5 ที่ gpu_mem=0.75 ซึ่งน่าจะเป็น sweet spot สำหรับ workload จริงที่ผมใช้