
DGX Spark + Qwen3.6-27B เร็วขึ้นประมาณ 300%
เรื่องคือ @SpaceTimeViking / ÆON FORGE บอกว่าสามารถ boost ความเร็วบน DGX Spark ตอนรัน Qwen3.6-27B Dense model ได้ราว 300%
แก่นของงานนี้คือไม่ได้เปลี่ยนโมเดลใหม่ แต่รีดระบบ inference ให้เร็วขึ้นจากฝั่ง software + runtime
patches และ custom flags
DFlash
block decoding
การ optimize ให้เข้ากับ DGX Spark / GB10
พูดง่าย ๆ คือทำให้เครื่องเดิมใช้พลังของ hardware ได้คุ้มขึ้นมาก
DFlash สำคัญตรงช่วงที่โมเดลกำลัง “พิมพ์คำตอบ”
หลายคนที่ใช้ local LLM จะรู้เลยว่า ถ้า decode ช้า ต่อให้โมเดลเก่งแค่ไหนก็เหนื่อย ใช้จริงแล้ว flow ขาด
แต่ถ้าช่วงตอบเร็วขึ้น มันเริ่มกลายเป็นผู้ช่วยที่ใช้งานได้จริง
ตัวที่ปล่อยคือ qwen36-v4 container:
ghcr.io/aeon-7/vllm-aeon-ultimate-dflash:qwen36-v4
ทำมาสำหรับ Qwen3.6-27B บน DGX Spark / GB10 โดยเน้นงานแบบ agent และ long-context
256K context
prefix caching
Qwen3.6 hybrid-state support
DFlash speculative decoding k=15
sliding-window attention fix
OpenAI-compatible serving
แปลว่าเอาไปต่อกับ workflow เดิมได้ง่ายขึ้น
เพราะงานจริงไม่ใช่ถามตอบสั้น ๆ ตลอดเวลา
ถ้า local model รับ context ยาวและตอบเร็วพอ เราสามารถโยน repo, docs, logs, transcript, notes หรือ requirement ยาว ๆ ให้มันช่วยทำงานต่อเนื่องได้
flow จะประมาณนี้:
มีเครื่อง DGX Spark / GB10
pull container qwen36-v4
เปิด server แบบ OpenAI-compatible
ชี้ agent/client เดิมไปที่ endpoint ใหม่
ลองงาน long-context แล้วดู latency ตอนตอบจริง
สิ่งที่ควรดูไม่ใช่แค่ token/sec
แต่ดูว่าใช้แล้ว flow ดีขึ้นไหม:
prompt ยาวแล้วยังตอบไวไหม
งาน agent ต่อเนื่องลื่นไหม
context reuse ผ่าน prefix caching ช่วยจริงไหม
latency ตอน decode ยังน่ารำคาญหรือเปล่า
ข่าวนี้น่าสนใจเพราะมันทำให้ local AI ดู practical ขึ้น
จากเดิมที่หลายอย่าง “รันได้” แต่ยังไม่ค่อยน่าใช้
ถ้าเร็วขึ้น 300% พร้อม context 256K และเสียบผ่าน OpenAI API ได้ง่าย มันเริ่มขยับจากของเล่นสาย hardware ไปเป็น infrastructure ส่วนตัว
Original post by @SpaceTimeViking / ÆON FORGE
https://x.com/SpaceTimeViking/status/2053427507601269153qwen36-v4 release post
https://x.com/SpaceTimeViking/status/2053415517923250255Container
ghcr.io/aeon-7/vllm-aeon-ultimate-dflash:qwen36-v4
