Skip to main content

23 posts tagged with "llm"

View All Tags

TypeSafe Jev — System One Model ที่ไม่ generate text แต่ลด token ของ agent ได้จริง

· 10 min read

"Jev ไม่ใช่ LLM — มันไม่ generate text, ไม่ parse string, และ schema-lock output จน type error เป็นไปไม่ได้. คำถามคือ: เอามันไปทำอะไรใน pipeline ของเราได้บ้าง?"

LiteLLM guardrail blog — Jev + LiteLLM compaction DataCamp explainer — System One Model + benchmarks tamaratran/fast-jev-compaction — Claude Code plugin ที่ hook /compact (4.2k stars)

ผมเพิ่งเห็น post ใน Facebook ของ Geek Consult บอกว่า TypeSafe ปล่อย skill ให้ใช้ Jev ผ่าน Codex/Claude ได้แล้ว + คนเริ่มเอาไปใช้แล้ว "ลด token ได้จริง"

ทีแรกผมคิดว่าเป็น hype แบบเดิม — แต่พออ่าน docs + benchmark + community projects แล้วพบว่า มันเป็นแนวคิดที่ต่างจาก LLM จริงๆ และ token reduction ในบาง use case ไม่ใช่ marketing

OpenAI x MHESI AI Accelerator: โครงการที่ดูดี แต่พลาดตรงที่สำคัญที่สุด

· 11 min read

โครงการ OpenAI x MHESI AI Accelerator เปิดตัวเมื่อ 28 สิงหาคม 2569 ที่งาน Techsauce Global Summit 2026[1][3] — ดูเหมือนข่าวดี แต่เมื่อมองให้ลึก มันเป็น window dressing (ฉากหน้าสวยหรู) ไม่ใช่ infra (โครงสร้างพื้นฐาน) ที่ไทยต้องการจริง ๆ บทความนี้คือมุมมองส่วนตัวว่าทำไม

ลด Cost ใน Hermes — คุม background_review fork ให้ไม่กิน token ฟรี

· 8 min read

T14 ของผมรัน Hermes มา 3 เดือน วันหนึ่งเปิดดู queue ใน ~/.hermes/pending/memory/ แล้วเจอ 48 ไฟล์ที่ค้างมาเป็นเดือน — บทความนี้คือการเดินย้อนจากอาการ "queue เต็ม" หาสาเหตุที่แท้จริง แล้วค่อย tune config ทีละขั้น

มีงบ $10,000 สำหรับ local AI — ซื้อ 2× DGX Spark เลย หรือรอ?

· 8 min read

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

มีคนโพสต์ใน r/LocalLLM ถามคำถามที่ผมเห็นแล้วต้องหยุดอ่าน: "I have about $10,000 for local AI hardware. would you buy two DGX Sparks or something else?" — เป็นคำถามที่ดีมาก เพราะมันไม่ได้ถามแค่ "ซื้ออะไรดี" แต่ถามเชิง timing: "ซื้อตอนนี้ หรือรอ"

ผมเลยลองนั่งอ่านคอมเมนต์ทั้งหมด + เทียบกับบล็อก deep-dive ที่คนเขียนไว้จริงๆ ทั้ง Orhan Yildirim (256GB cluster บนโต๊ะ) และ Conselara Labs (Ray cluster + NCCL) — แล้วสรุปเป็น 3 มุมมองที่ขัดแย้งกัน

EXL3 Quantization กับ λ=2.8 — ทำไม 3-bit ถึงให้คุณภาพระดับ Q5 และ ablation ที่ 2.8 ถึงเป็น sweet spot

· 7 min read

EXL3 3.0 bpw ให้คุณภาพระดับ Q5 GGUF ในขนาดครึ่งเดียว — และค่า λ=2.8 สำหรับ runtime ablation เป็นจุดสมดุลระหว่าง bypass strength กับ reasoning stability

TL;DR​

  • EXL3/Trellis 3.0 bpw เป็น quantization format แบบ non-uniform bit allocation ที่ให้คุณภาพระดับ GGUF Q4–Q5 ในขนาดที่เล็กกว่ามาก (~60% ของ Q5 size)
  • Runtime ablation ด้วย projection ที่ wo_b output space เป็นทางเลือกที่ดีกว่าการแก้ quantized weights ในทุกกรณี (LoRA-style weight edits ไม่ทำงานกับ MoE ที่มี mHC residual pathway)
  • λ=2.8 อยู่กลางระหว่าง loveseko preset (λ=2.5, conservative) กับ drowzeys default (λ=3.5, validated) — ให้ bypass strength ที่พอใช้โดยไม่ทำให้ long-CoT reasoning loop

ซื้อ DGX Spark เครื่องเดียว เพื่อเรียนรู้ + Hermes agent คุ้มไหม — เมื่อตลาดบอกว่ามันอยู่ใน awkward spot

· 10 min read

บันทึก — 25 สิงหาคม 2569 — เช้ามืด ต่อจาก Part 1

ต่อจาก Part 1 ที่พูดถึง $10K + 2× Spark — มีโพสต์ใน r/LocalLLM อีกอันที่ถามคำถามที่ต่างออกไป: "ซื้อ DGX Spark เครื่องเดียว เพื่อเรียนรู้ AI engineering + ตั้ง Hermes agent ทำ security research คุ้มไหม?"

คำถามนี้น่าสนใจกว่าที่คิด เพราะคำตอบไม่ใช่ "คุ้ม" หรือ "ไม่คุ้ม" — มันขึ้นอยู่กับว่าจะเอาไปทำอะไร และคอมเมนต์ในโพสต์นี้มีคนที่ใช้จริงบอกตรงๆ ว่า Spark 1 เครื่อง "อยู่ใน awkward spot" ถ้าใช้ผิด use case

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

· 8 min read

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

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

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

DeepSeek-V4-Flash-0731 Reasoning Effort: เทสจริง 7 รอบ พบว่า docs กับ serving ไม่ตรงกัน (มีอัปเดต)

· 10 min read

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

DeepSeek-V4-Flash Parameter Tuning: สิ่งที่ต้องเข้าใจก่อนปรับแต่ละตัว

· 7 min read

บันทึกกลางดึก — 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 ที่ใช้งานได้จริงๆ เป็นยังไง

ทดสอบโมเดล LLM ด้วย prompt 'Generate an SVG of [A] [doing] [B]'

· 4 min read

เรื่องมันเริ่มจากคำถามง่ายๆ คำเดียว: "โมเดล AI ตัวไหนเก่งเรื่องการสร้างภาพ SVG กันแน่?" ถ้าพี่เคยลองให้โมเดลวาดรูปดู จะพบว่าแต่ละตัวตอบต่างกันมาก บางตัววาดได้สวย บางตัวออกมาเพี้ยนจนขำ

มีคนคนหนึ่งที่ทำ benchmark แบบนี้จนเป็นที่รู้จัก คือ Simon Willison — เขาใช้ prompt เดียวกันทดสอบโมเดลหลายตัวซ้ำๆ แล้วรวบรวมผลไว้ ทำให้มันกลายเป็น "ไม้บรรทัด" วัดความสามารถโมเดลที่ไม่เป็นทางการแต่ได้ผลจริง