ทีม VIDRAFT เปิด config เต็มที่ทำสถิติ Fast Gemma Challenge — 510.58 TPS บน A10G ใบเดียว โดยไม่ให้คุณภาพหลุดเพดาน

งานปรับจูน inference มักจบลงที่บล็อกซึ่งบอกว่า “เราเร็วขึ้น 3 เท่า” แล้วไม่บอกว่าหมุนอะไรบ้าง วันที่ 3 สิงหาคม 2026 ทีม VIDRAFT (แข่งในชื่อ vidraft-darwin) ทำตรงข้าม — เผยแพร่ manifest.json ทั้งไฟล์ของสถิติที่ผ่านการตรวจซ้ำสูงสุดใน Fast Gemma Challenge พร้อมคำอธิบายว่าแต่ละค่าทำอะไรและทำไม

โจทย์ของการแข่งนี้แคบและตรงไปตรงมามาก: บนฮาร์ดแวร์เดียวกันคือ NVIDIA A10G ใบเดียว (24GB) ให้ดัน google/gemma-4-E4B-it ให้พ่น token ต่อวินาทีสูงที่สุด ด้วยการปรับซอฟต์แวร์เท่านั้น ห้ามเปลี่ยนโมเดล ห้ามปิดโมดัลลิตี (ข้อความ ภาพ เสียง ต้องใช้ได้ครบ) และห้ามทำให้คุณภาพตก — ถ้า perplexity ทะลุเพดานราว 2.42 ถือว่ารันไม่ผ่าน (bf16 baseline อยู่ราว 2.30) ที่สำคัญคือ อันดับนับเฉพาะผลที่ผู้จัดรันซ้ำเองบนชุด prompt ลับแล้วติดป้าย VERIFIED

ตัวเลขที่ได้ และตัวเลขที่ตกรอบ

ผลของ VIDRAFT คือ 510.58 TPS ที่ PPL 2.3930 (single-stream, ทำครบ 128/128 token, ผ่านการตรวจซ้ำ) ภายใต้ชื่อ submission vidraft-fw188-ctk49-n64-patchbridge-v1

จุดที่ทีมเขียนไว้อย่างตรงไปตรงมาคือ ถ้าวัดที่ TPS ดิบ มีรันที่เร็วกว่านี้ เช่น 535.91 TPS — แต่มันอยู่ที่ PPL 2.44 ขึ้นไป ซึ่งเกินเพดานคุณภาพ และไม่ผ่านการ verify สิ่งที่เขาบอกว่าภูมิใจจึงไม่ใช่ “เร็วที่สุด” แต่คือ “เร็วที่สุดในบรรดาผลที่ตรวจซ้ำผ่าน โดยไม่แลกคุณภาพ”

หลักการเดียวที่ร้อยทุกอย่างเข้าด้วยกัน เขาสรุปไว้ประโยคเดียว — ซ้อนเฉพาะการเร่งที่เป็นกลางต่อคุณภาพ อะไรที่ทำให้ PPL ขยับ ต่อให้เร็วแค่ไหนก็ทิ้ง

ปุ่มที่หมุน: sliding window คือปุ่มที่แรงที่สุด

สแต็กรันบน vLLM (dev wheel 0.22.1rc1) กับ transformers==5.9.0 โดยตั้ง MAX_MODEL_LEN=4096, MAX_NUM_SEQS=1, PERFORMANCE_MODE=interactivity — คือปรับเพื่อ latency ของสตรีมเดียว ไม่ใช่ throughput รวม

• SLIDING_WINDOW=188 (คู่กับ FA_SLIDING) — เหตุผลตรงประเด็นมาก: คอขวดของช่วง decode คือแบนด์วิดท์หน่วยความจำของ KV cache จึงจำกัดความสนใจไว้ที่ 188 token ล่าสุด ทีมบอกว่าแคบไป (128) ทำให้ PPL พัง กว้างไปก็ช้า จุดหวานอยู่ที่ W188–192 และแพตช์ค่านี้เข้า config โมเดลผ่าน HF_OVERRIDES
• CENTROID_TOP_K=49 — ค่าจูนระดับ kernel ที่ throughput กับ PPL ขยับไปด้วยกัน เป้าหมายคือหาค่าที่เร็วที่สุดที่ยังอยู่ในงบ PPL (กวาดที่ 44 / 48 / 49)
• speculative decoding — drafter แบบ multi-token prediction ที่ num_speculative_tokens=7
• LM_HEAD_PRUNE=1 — ตัด lm-head โดยใช้ keepset ขนาด 12k
• ONEGRAPH / FUSED_SPARSE_ARGMAX / SPLITKV_VERIFY / DETOK_ENDONLY — กำจัด overhead ของการ launch kernel, การ sampling และการถอดโทเคน

บทเรียนที่มีค่าที่สุดไม่ใช่ตัวเลข แต่คือวิธีวัด

สองค่าใน manifest ไม่ได้ทำให้โมเดลเร็วขึ้นเลย แต่ทำให้ ตัวเลขที่วัดเองตรงกับตัวเลขที่ผู้จัดวัด ซึ่งคือทั้งหมดของการแข่งนี้

WARMUP_BRIDGE=1 กับ WARMUP_NUM_PROMPTS=64 — ก่อนเริ่มจับเวลา ยิง prompt สังเคราะห์ 64 ชุด (ชุดละ 1 token) เพื่อให้ CUDA-graph capture และ JIT ทำงานจนจบ ไม่มี overhead ของการคอมไพล์หลงเหลืออยู่ในหน้าต่างที่วัด ผลคือส่วนต่างระหว่างตัวเลขสาธารณะกับตัวเลข verified แคบลงและสถิติเสถียร — ถ้าไม่ทำ เสียไปราว 15 TPS

PRECACHE_BENCH=0 — อันนี้คือบทเรียนตัวจริง ทีมอธิบายว่าเส้นทาง precache สามารถพอง TPS ที่วัดเองได้ แต่ตัวเลขนั้นไม่ reproduce ตอนผู้จัดรันซ้ำบนชุดลับ แล้วกลับมาเป็น INVALID จึงปิดทิ้ง เพื่อให้ค่าที่วัดเอง ≈ ค่าที่ verified — “ตัวเลขที่คุณรายงาน คือตัวเลขที่ผ่านการตรวจ”

สถิตินี้ไม่ใช่ของทีมเดียว

ถ้าอ่าน manifest จะเห็นว่าค่าสภาพแวดล้อมหลายตัวชี้ไปที่ bucket ของคนอื่น: WEIGHTS_BUCKET คือน้ำหนัก INT4-baked ของ @chiku-inu, DRAFTER_BUCKET คือ drafter สำหรับ speculative decoding ของ @kenyan-duma, LM_HEAD_KEEPSET_BUCKET คือ keepset 12k ของ @dixie-flatline, ฐานของ warmup bridge มาจาก @firfir-cast และ config แนวหน้าถูกแชร์/ทำซ้ำ/ตรวจสอบโดย @gemma-slayer

องค์กร gemma-challenge บน Hugging Face ตอนนี้มีสมาชิก 284 ราย, 195 bucket และ 8 Space สำหรับติดตามความคืบหน้า ทีม VIDRAFT เขียนว่าเพราะมีคนโพสต์แม้กระทั่งการรันที่ล้มเหลว สถิติของชุมชนจึงไต่ขึ้นอย่างเห็นได้ชัด ภายในหกวัน

ไฟล์ทั้งหมดโหลดได้จาก bucket สาธารณะ — serve.py, serve_patch_warmup_bridge.py, fa_sliding_patch.py, splitkv_verify_patch.py และแพตช์ tokenization/decode อีกหลายตัว รันได้ด้วยการตั้ง env ตาม manifest แล้วสั่ง python serve.py

มุมมอง AI Curator

สิ่งที่ควรหยิบไปใช้จากโพสต์นี้มีสามอย่าง และไม่มีอันไหนเกี่ยวกับ Gemma โดยเฉพาะ

หนึ่ง — sliding window คือปุ่มที่ถูกมองข้ามที่สุดสำหรับงาน single-stream ทีมส่วนใหญ่ไปลง quantization ก่อนเพราะเป็นเรื่องที่คนพูดถึงเยอะ แต่บนงานแชท/เอเจนต์ที่ตอบทีละสตรีม คอขวดคือแบนด์วิดท์การอ่าน KV cache ต่อ token การจำกัดหน้าต่างความสนใจให้แคบลงจึงให้ผลตรง ๆ และค่า 188 กับคำอธิบายว่า 128 ทำ PPL พังคือข้อมูลที่ประหยัดเวลาคนอื่นได้เป็นวัน

สอง — บทเรียน PRECACHE_BENCH=0 ควรถูกแปะไว้บนกำแพงทุกทีมที่ทำ eval เกือบทุกองค์กรที่รายงานตัวเลข inference ของตัวเอง วัดบนเงื่อนไขที่ตัวเองเลือก และ “การเร่งที่พองตัวเลขแต่ไม่ reproduce” คือรูปแบบความผิดพลาดที่พบบ่อยที่สุด ที่นี่มีผู้จัดรันซ้ำบนชุดลับคอยจับ — แต่ในทีมของคุณไม่มีใครจับ นอกจากคุณจะสร้างกลไกนั้นขึ้นมาเอง

สาม — รูปแบบการแข่งเองน่าสนใจกว่าผลการแข่ง ฮาร์ดแวร์ล็อกตายที่ A10G ใบเดียว, คุณภาพมีเพดานบังคับ, ผู้จัดตรวจซ้ำ, และทุกคนแชร์ผลบนบอร์ดเดียวกันรวมถึงผลที่ล้ม โครงสร้างแบบนี้ทำให้ความรู้สะสมแทนที่จะกระจัดกระจาย — ต่างจากลีดเดอร์บอร์ดโมเดลที่แต่ละเจ้ารายงานตัวเลขตัวเองแล้วไม่มีใครตรวจได้

ประเด็นสุดท้ายสำหรับผู้อ่านในไทยและ SEA: A10G คือการ์ดคลาวด์ที่เช่าได้ในราคาระดับที่สตาร์ทอัพและแล็บมหาวิทยาลัยจ่ายไหว ไม่ใช่ H200 หรือ B200 การที่มี recipe สาธารณะซึ่งดันโมเดลระดับ E4B ไปถึง 500+ TPS บนการ์ดใบเดียวได้ แปลว่าข้อจำกัดของงาน inference ในภูมิภาคนี้ขยับจาก “ซื้อการ์ดไม่ไหว” มาเป็น “ยังไม่ได้อ่านว่าคนอื่นจูนยังไง” ซึ่งเป็นปัญหาที่แก้ได้ถูกกว่ามาก และทีมยังชวนให้ช่วยพอร์ตไปยัง GPU รุ่นอื่นด้วย — ถ้าใครทดสอบบน L4 หรือ RTX 4090 แล้วได้ตัวเลข นั่นคือของที่ชุมชนอยากได้จริง ๆ

แหล่งข่าว

• The Fast Gemma Challenge: our verified-SOTA recipe, in full — Hugging Face Blog (3 ส.ค. 2026)
• Fast Gemma Challenge — ลีดเดอร์บอร์ดบน Hugging Face Spaces
• gemma-challenge — องค์กรและ bucket ทั้งหมดบน Hugging Face