4 posts tagged with "benchmark"

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

ผมเจอคำถามใน r/LocalLLM ที่ผมว่าสำคัญมาก: "agent ของฉันเปรียบเทียบกับ OpenClaw/Hermes ยังไง" — ไม่ได้ถามแบบ feel-based แต่ใช้ harness-bench วัดผลจริง โดยแยก agent เป็นตัวแปรควบคุม + LLM เป็นตัวแปรอิสระ

OP (donotfire) สร้าง agent ชื่อ "Second Brain" ติดอันดับ 2 ใน leaderboard (จาก heatmap ในโพสต์)

บล็อกนี้ต่างจากบล็อกอื่นในซีรีส์ — แทนที่จะเน้น tool หรือ hardware ผมจะเน้น methodology ของการวัด agent เพราะเป็นปัญหาที่ community ทั้งหมดต้องเจอ

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

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

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

บันทึก 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