Nanbeige4.2-3B: โมเดล agent 3B ที่ชนะ Qwen3.5-9B และ Gemma4-12B — SWE-bench Verified 63.6 บนพารามิเตอร์แค่เศษเสี้ยว

ช่วงนี้โมเดลเปิดขนาดเล็กออกกันแทบทุกสัปดาห์ ส่วนใหญ่เป็น fine-tune ที่ขยับตัวเลขทีละนิด แต่ Nanbeige4.2-3B ที่ขึ้นมาติดเทรนด์บน Hugging Face (อัปเดตล่าสุด 26 ก.ค. 2026, ดาวน์โหลดไปแล้วกว่า 14,000 ครั้ง) เป็นคนละเรื่อง — มันเป็นโมเดล agent ขนาด 4B พารามิเตอร์รวม (นับเฉพาะส่วนที่ไม่ใช่ embedding คือ 3B) ที่การ์ดโมเดลกล้าเอาไปเทียบกับ Qwen3.5-9B และ Gemma4-12B ตรง ๆ แล้วชนะเกือบทุกช่อง

ตัวเลขที่สะดุดตาที่สุดคือ SWE-bench Verified 63.6 เทียบกับ Qwen3.5-9B ที่ 53.1 และ Gemma4-12B ที่ 44.2 — และมันมาพร้อมสัญญาอนุญาต Apache-2.0 ที่ใช้เชิงพาณิชย์ได้เต็มที่

Looped Transformer: เพิ่มความจุโดยไม่เพิ่มพารามิเตอร์

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

ดูจาก config.json ของโมเดลจะเห็นชัด:

• num_hidden_layers: 22 แต่ num_loops: 2 — คือมี 22 เลเยอร์จริง แต่รันผ่านมัน 2 รอบ
• hidden_size: 3072, num_attention_heads: 48, num_key_value_heads: 8 (GQA)
• max_position_embeddings: 262144 — คอนเท็กซ์ 256K เต็ม
• rope_theta: 70000000 — ค่า RoPE base สูงมาก ซึ่งเป็นวิธีมาตรฐานของการยืดคอนเท็กซ์ยาว

พูดง่าย ๆ คือ คุณจ่ายค่า VRAM เท่าโมเดล 3B แต่จ่ายค่าเวลาคำนวณเท่าโมเดล 6B ซึ่งเป็นการแลกที่คุ้มมากสำหรับคนรันเครื่องตัวเอง — เพราะข้อจำกัดของ local LLM แทบทุกครั้งคือ “การ์ดใส่ไม่พอ” ไม่ใช่ “ช้าไปหนึ่งวินาที”

ทีมยังบอกด้วยว่าไฟล์ modeling_nanbeige.py มีของใหม่อีกสามอย่างที่ยังไม่ค่อยเห็นในโมเดลเปิดตัวอื่น คือ LoopSplit, mHC with depth attention และ concatenated n-gram embeddings ซึ่งจะถูกยกไปใช้เต็มรูปแบบใน Nanbeige4.5 ที่กำลังเทรนอยู่และมีกำหนดออกภายในปีนี้

ตัวเลขที่ควรอ่านให้ละเอียด

การ์ดโมเดลวัดในโหมด thinking (preserve_thinking=true) และแจกแจงสแคฟโฟลด์ที่ใช้ไว้ชัดเจน — ซึ่งเป็นสัญญาณที่ดีของงานวัดผลที่ตรวจสอบได้:

หมวด	เบนช์มาร์ก	Nanbeige4.2-3B	Qwen3.5-9B	Gemma4-12B
Code agent	SWE-Bench Verified (OpenHands)	63.6	53.1	44.2
Code agent	SWE-Bench Pro (SWE-agent)	46.9	33.8	21.9
Code agent	Terminal-Bench 2.0 (Terminus 2)	44.1	29.2	21.1
General agent	MCP-Atlas	57.8	47.4	30.5
General agent	GDPval rubrics	74.3	61.9	68.5
Reasoning	GPQA-Diamond	87.4	81.7	78.8
Reasoning	HMMT-Feb-2026	82.8	69.6	51.5
Reasoning	LiveCodeBench-V6	72.5	65.6	72.0

จุดที่น่าสนใจคือ ช่องที่มันแพ้: IF-Bench (การทำตามคำสั่ง) ได้ 54.6 ขณะที่ Gemma4-12B ได้ 73.5 และ SciCode ก็ยังตามหลัง Gemma4 อยู่ นี่คือรูปแบบที่พบบ่อยในโมเดลที่เทรนหนักด้าน agent — เก่งงานที่มีเป้าหมายวัดผลได้ (แก้บั๊กให้เทสต์ผ่าน, เรียกเครื่องมือให้ถูก) แต่ยังไม่เนียนเท่ากับงานที่ต้องตามข้อกำหนดยิบย่อยของมนุษย์

ทีมยังมีเบนช์มาร์กภายในชื่อ Recruit-Bench ที่วัดสถานการณ์การจ้างงาน ซึ่งเข้ากับที่มาของทีม — อีเมลติดต่อในการ์ดโมเดลคือโดเมน kanzhun.com (บริษัทแม่ของแพลตฟอร์มหางาน BOSS Zhipin) นั่นบอกว่าโมเดลนี้ไม่ได้เกิดจากแล็บวิจัยล้วน ๆ แต่มีงานจริงในองค์กรรออยู่เบื้องหลัง

รันเองได้จริง — Ollama, MLX, SGLang มาครบในการ์ดโมเดล

สิ่งที่ทำให้โมเดลนี้ต่างจาก “โมเดลเล็กที่อ้างว่าเก่ง” ทั่วไปคือ การ์ดโมเดลเขียนวิธี deploy ไว้ให้เลย ไม่ต้องรอชุมชนมาแกะ:

• Ollama — มีทั้งเส้นทาง GGUF (Q4_K_M) และเส้นทาง safetensors ผ่าน MLX พร้อม RENDERER nanbeige / PARSER nanbeige
• MLX บน macOS arm64 — สั่ง quantize ตอน import ได้เลย (--quantize int4 / int8 / mxfp4 / nvfp4)
• SGLang — ต้องใช้ fork สาขา nbg42 ของทีมเอง พร้อม --reasoning-parser nanbeige และ --tp-size 1 (การ์ดใบเดียวพอ)

การตั้งค่าที่ทีมแนะนำก็แยกตามงานชัดเจน: งาน agent/tool-use ใช้ temperature 1.0 กับ max_new_tokens 65,536 ส่วนงาน reasoning/แชตใช้ temperature 0.6 กับ 131,072 โทเคน และมีสวิตช์ enable_thinking / preserve_thinking ให้คุมว่าจะเก็บ reasoning ของเทิร์นก่อนหน้าไว้หรือไม่ — ทีมแนะนำให้เปิด preserve_thinking=True เฉพาะงาน multi-turn tool use และ code agent เท่านั้น

ที่ 3B แบบ 4-bit โมเดลนี้จะกินราว ๆ 2–3 GB — อยู่ในระดับที่ โน้ตบุ๊กและการ์ดจอราคาหมื่นต้น ๆ รันได้สบาย แม้คอนเท็กซ์ 256K เต็มจะยังกิน KV cache หนักอยู่ก็ตาม

มุมมอง AI Curator

เรื่องที่ควรจับตาไม่ใช่ตัวเลข SWE-bench แต่คือ Looped Transformer กลับมาอีกครั้งในฐานะทางเลือกที่ใช้งานได้จริง ไอเดีย “วนเลเยอร์ซ้ำแทนที่จะซ้อนให้ลึก” มีมาหลายปีแล้วในงานวิจัย แต่แทบไม่เคยถูกส่งออกมาเป็นโมเดลเปิดที่มีเบนช์มาร์กแข่งขันได้จริง ถ้าตัวเลขชุดนี้ทนต่อการตรวจสอบอิสระ มันจะเป็นหลักฐานว่าเราสามารถ แลกเวลาคำนวณเพื่อความจุโมเดล ได้ในอัตราที่คุ้ม — ซึ่งพลิกสมการของ local LLM ทั้งหมด เพราะข้อจำกัดของคนรันเครื่องตัวเองคือ VRAM ไม่ใช่ FLOPs

สำหรับนักพัฒนาไทย นี่คือของที่ควรลองจริงจังกว่าโมเดล 3B ทั่วไป เหตุผลง่าย ๆ คือ มันเป็น agent model ไม่ใช่แชตบอต — MCP-Atlas 57.8 กับ Terminal-Bench 44.1 หมายความว่ามันเรียกเครื่องมือและทำงานหลายขั้นตอนได้พอใช้ ไม่ใช่แค่ตอบคำถาม ทีมที่กำลังสร้าง agent ภายในองค์กรแล้วติดปัญหา “ส่งข้อมูลลูกค้าออกไปที่ API ต่างประเทศไม่ได้” มีทางเลือกเพิ่มขึ้นหนึ่งทางที่รันบนเครื่องในออฟฟิศได้จริง

ข้อควรระวังสองข้อ: หนึ่ง — โมเดลรองรับแค่ อังกฤษกับจีน ตามการ์ดโมเดล ภาษาไทยไม่ได้อยู่ในรายการ ดังนั้นอย่าคาดหวังคุณภาพภาษาไทยระดับใช้งานหน้าบ้าน ให้มองเป็น เครื่องยนต์ agent หลังบ้าน ที่คุยกับเครื่องมือและโค้ดมากกว่าคุยกับลูกค้า สอง — สถาปัตยกรรมนี้ต้อง trust_remote_code=True และ SGLang ต้องใช้ fork ของทีมเอง แปลว่ายังไม่ถูก merge เข้า upstream ให้ใช้ในโปรดักชันแบบสบายใจ รอ vLLM/llama.cpp รองรับ native ก่อนค่อยวางแผนใหญ่จะปลอดภัยกว่า

และอย่าลืมภาพรวม: นี่คือโมเดลจีนอีกตัวที่ปล่อยน้ำหนักฟรีภายใต้ Apache-2.0 ในสัปดาห์เดียวกับที่ KAT-Coder-V2.5-Dev เปิดน้ำหนัก และ Kimi K3 กำลังจะตามมา จังหวะการปล่อยของฝั่งจีนตอนนี้ถี่กว่าฝั่งตะวันตกอย่างเห็นได้ชัด — ซึ่งเป็นข่าวดีของคนที่แค่อยากได้ของมาใช้ แต่เป็นโจทย์ที่ซับซ้อนขึ้นเรื่อย ๆ สำหรับคนที่ต้องตอบคำถามฝ่ายกำกับดูแลว่า “โมเดลนี้มาจากไหน”

แหล่งข่าว

• Nanbeige/Nanbeige4.2-3B — Hugging Face
• Nanbeige4.2 Technical Report (PDF)
• Nanbeige/Nanbeige4.2-3B-Base — Hugging Face