17 posts tagged with "vllm"

"ผมเชื่อว่า vLLM integration คือเรื่องง่าย — จนกว่าจะเจอ 3 pitfalls: reasoning_content → reasoning, ContextWindowExceededError ไม่บอกชัด, และ drop_params มี 3 ระดับ"

Part 1 — drop_params ทำไมต้อง recreate Part 2 — 3 flags ที่ใช้บ่อย Part 3 — DB mode + 3-way sync Part 4 — vLLM integration + pitfalls

บันทึก 17 กันยายน 2569 — เคส OOM debug ที่ทำให้รู้ว่า regex เงียบๆ fail ได้

วันนี้ผม debug เคส vLLM hard-freeze บน DGX Spark (GB10, 119 GiB unified memory) — เครื่องค้าง ต้องถอดปลั๊ก 3 ครั้ง ทั้งๆ ที่ติด earlyoom ไว้แล้ว pattern ก็ดูถูก ผ่านไปหลายชั่วโมงจนเจอว่า ทั้ง --prefer และ --avoid ไม่เคย match process จริงเลย regex silent failure ที่ไม่มี error, ไม่มี warning, ไม่มี log อะไรทั้งสิ้น

บันทึก 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 น่าจะเจอปัญหาคล้ายกัน

บันทึก — 26 สิงหาคม 2569 — Qwen ปล่อย Qwen3.8-Flash-Next จริงตามที่ teaser ไว้เมื่อวาน — เป็น Qwen4 architecture preview แรกที่มี n-gram embedding (PLE) เป็น native component

Qwen ปล่อย Qwen3.8-Flash-Next บน Hugging Face เมื่อเช้าตามเวลาไทย — บทความนี้คือการรวบ spec, benchmark, quant ที่ออกแล้ว, และ feasibility บน DGX Spark (GB10) ที่ผมมีอยู่ 1 node

ตัวเลขที่ทำให้หยุดอ่าน: 6B active params แต่ agentic coding (DeepSWE 1.1) ทำได้ 58.7 — Qwen3.8-27B ทำได้ 42.2, Qwen3.7-Plus ทำได้แค่ 16.5, และ DeepSeek-V4-Flash ทำได้ 54.4

บันทึก — 25 สิงหาคม 2569 — เช้ามืด เจอกระทู้ reproducible benchmark ที่น่าสนใจ

คนใน r/LocalLLM โพสต์ benchmark ละเอียดมาก — Qwen3.8-27B-NVFP4 บน DGX Spark / ASUS Ascent GX10 เครื่องเดียว ใช้ DFlash2 (W4A16) + lookup speculation ได้:

• ~39 tok/s ใน chat ทั่วไป (consolidated profile)
• ~42.49 tok/s เมื่อ optimize สำหรับ chat ล้วง (k9 profile)
• ~117 tok/s สำหรับ context replay (RAG, code edits, document conversion)
• Cold TTFT @ 50k ลดจาก 29.94 → 23.46s ด้วย chunk 4,096 + O2 interactivity

ที่สำคัญที่สุด: reproducible ผ่าน spark run qwen38-dflash2-lookup — ไม่ใช่แค่บอก "ผมได้ X tok/s" แต่ bundle config ทั้งหมด (model, drafter, patched vLLM image, revisions ที่ pin, runtime arguments) ใน 1 command

บันทึกกลางดึก — 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

บันทึก 27 มิถุนายน 2569 — หลังจากใช้ vLLM มาสักพัก อยากรู้ว่าจริง ๆ แล้ว params ที่ส่งได้ใน /v1/chat/completions มีอะไรบ้าง และอันไหนส่งผ่าน LiteLLM ได้โดยตรง อันไหนต้องใช้ extra_body

ผมใช้ vLLM เป็น inference backend มาสักพัก แต่ไม่เคยนั่งดูจริง ๆ ว่า /v1/chat/completions endpoint รองรับ parameters อะไรบ้างเต็ม ๆ ส่วนใหญ่ก็แค่ส่ง temperature, top_p, max_tokens ไปแล้วก็จบ — จนวันนี้ลองเปิด OpenAPI schema ดู ถึงรู้ว่ามี params ที่ใช้ไม่เคยรู้จักตั้งหลายตัว

บันทึก 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 คะแนน แต่ก็เจอบทเรียนหลายอย่างระหว่างทาง