การสนับสนุน vLLM สำหรับ Nanbeige4.2-3B กำลังจะมา: โมเดล Agent แบบวนซ้ำขนาด 3B ของ BOSS Zhipin ก้าวออกจากยุคที่ต้องใช้ Fork เท่านั้น

Nanbeige4.2-3B — โมเดลเอเจนต์ขนาดกะทัดรัดจาก Nanbeige Lab ของ BOSS Zhipin ที่ปล่อยออกมาในช่วงปลายเดือนกรกฎาคม 2026 — กำลังจะพร้อมใช้งานบน vLLM ที่ติดตั้งแบบมาตรฐานเป็นครั้งแรก คำขอ pull request ที่เปิดเมื่อวันที่ 9 กันยายน 2026 เพิ่มสถาปัตยกรรมนี้เข้าไปในทะเบียนโมเดลของ vLLM ผ่านแบ็กเอนด์ transformers ถ้ามันถูกรวมเข้าด้วยกัน คำสั่ง vllm serve Nanbeige/Nanbeige4.2-3B จะกลายเป็นคำสั่งมาตรฐาน แทนที่จะเป็นพิธีกรรมที่ต้องใช้ fork จากผู้จำหน่าย นั่นคือการเปลี่ยนแปลงที่แท้จริงในสิ่งที่ผู้โฮสต์เองสามารถทำได้: ตลอดหกสัปดาห์นับตั้งแต่โมเดลออกมา ทุกเซิร์ฟเวอร์เอ็นจินที่โมเดลการ์ดระบุไว้ — vLLM, SGLang, llama.cpp, Ollama — ล้วนชี้ไปที่ fork ที่ดูแลโดย Nanbeige ไม่ใช่ตัวติดตั้งที่ไม่ได้แก้ไข

ตัวโมเดลเองไม่ใช่ข่าว; มันสามารถดาวน์โหลดได้ตั้งแต่สัปดาห์สุดท้ายของเดือนกรกฎาคม ข่าวคือยุคที่ต้องใช้ fork เท่านั้นกำลังจะสิ้นสุดลง และมันกำลังสิ้นสุดในสัปดาห์นี้ SGLang รวมการใช้งาน Nanbeige4.2 แบบเนทีฟเข้าไปใน main branch เมื่อวันที่ 5 กันยายน และ pull request ของ vLLM ก็ถูกเปิดขึ้นสี่วันต่อมา ทั้งคู่เป็นการสนับสนุนแบบ upstream ที่ติดตั้งได้จากแพ็กเกจมาตรฐาน สำหรับสถาปัตยกรรมที่ทุกเอนจินเคยปฏิบัติเสมือนเป็นกรณีพิเศษ ด้านล่างนี้ ทุกอย่างถูกติดป้ายกำกับไว้: สิ่งที่ pull requests ทำจริง, สิ่งที่ได้รับการยืนยันแล้วเทียบกับที่ยังค้างอยู่, คำกล่าวอ้างด้าน benchmark ของผู้ผลิต, และตัวเลขจากแหล่งอิสระที่ช่วยให้เห็นบริบท

สัปดาห์นี้มีอะไรเปลี่ยนแปลงบ้าง อย่างแม่นยำ

คำขอ pull request ของ vLLM คือ vllm-project/vllm #56071 เรื่อง "[Model] Add support for Nanbeige4.2 (transformers backend)" ซึ่งเปิดโดยวิศวกรของ Nanbeige เมื่อวันที่ 9 กันยายน และยังคงเปิดอยู่ ณ เวลาที่เขียนข้อความนี้ โดยตั้งใจให้เล็กมาก — แค่สองไฟล์ ไฟล์แรกเพิ่มบรรทัดลงใน registry โมเดลของ vLLM เพื่อจับคู่ชื่อสถาปัตยกรรมของ Hugging Face อย่าง NanbeigeForCausalLM เข้ากับ TransformersForCausalLM ซึ่งเป็น fallback ทั่วไปของ vLLM ที่ใช้เรียกโมเดลผ่าน backend ของ transformers ไฟล์ที่สองเพิ่ม NanbeigeModelArchConfigConvertor ซึ่งมีหน้าที่เดียวคือบอก vLLM ว่าควรจัดสรรเลเยอร์จำนวนเท่าใด: มันคืนค่า num_hidden_layers ของ config คูณด้วย num_loops เนื่องจาก transformer แบบวนซ้ำของ Nanbeige ทำซ้ำเลเยอร์สแตกของมัน และ vLLM ต้องปรับขนาด KV-cache และอินสแตนซ์ attention ให้สอดคล้องกัน

สำหรับผู้ที่ติดตามเรื่องนี้ มีรายละเอียดสองจุดจากเธรดรีวิวที่สำคัญ ประการแรก การแมปรีจิสทรี (registry mapping) คือสิ่งที่ทำให้โมเดลทำงานผ่านแบ็กเอนด์ transformers โดยอัตโนมัติ — นักพัฒนาหลักของ vLLM ระบุว่าเมื่อแมปนี้มีอยู่แล้ว แฟล็ก --model-impl transformers ที่ระบุอย่างชัดเจนก็จะกลายเป็นสิ่งซ้ำซ้อน และงานที่เหลือก่อนการ merge คือรายการเอกสารและการทดสอบ CI สำหรับการแมปรีจิสทรี ประการที่สอง ผู้รีวิวชี้ให้เห็นว่าการเปลี่ยนแปลง vLLM ที่เพิ่งรวมเข้าไปเมื่อเร็วๆ นี้ (PR #54941) อาจทำให้คอนเวอร์เตอร์นับเลเยอร์ (layer-count convertor) ไม่จำเป็นอีกต่อไป เนื่องจากตรวจพบโมดูล attention โดยตรงแทนที่จะอนุมานจากจำนวนเลเยอร์ พูดง่ายๆ คือ ฟิกซ์นี้อาจจะเรียบง่ายลงก่อนที่จะปล่อยออกมา ไม่ใช่ซับซ้อนมากขึ้น

เส้นทาง vLLM มีความสำคัญมากขึ้นเนื่องจากสิ่งที่มันไม่ใช่ นี่ไม่ใช่ความพยายามครั้งแรกที่จะนำ Nanbeige4.2 เข้าสู่ vLLM แบบเนทีฟ PR #49433 ซึ่งเปิดโดยวิศวกรคนเดียวกันในช่วงปลายเดือนกรกฎาคมในฐานะการนำไปใช้งานเนทีฟตั้งแต่วันแรก ถูกปิดเมื่อวันที่ 9 กันยายน — วันเดียวกับที่ PR ของ transformers-backend ปรากฏขึ้น — หลังจากที่ผู้ดูแลแย้งว่าการ implement โมเดลแบบเฉพาะกิจนั้นเป็นงานที่มากเกินกว่าที่สถาปัตยกรรมจะสมเหตุสมผล และชี้ไปที่ transformers backend แทน ประเด็นสำคัญสำหรับผู้อ่าน: การสนับสนุน vLLM ต้นทางกำลังมาทางเส้นทางความเข้ากันได้ ไม่ใช่การ implement แบบเนทีฟที่ปรับแต่งด้วยมือ และความแตกต่างนั้นมีผลกระทบด้านประสิทธิภาพจริงตามที่กล่าวถึงด้านล่าง

โมเดลที่ต้องได้รับการจัดการพิเศษทั้งหมดนี้

เพื่อจะเข้าใจว่าทำไม Nanbeige4.2-3B จึงทำลายสมมติฐานของรันไทม์ทุกตัว เราควรรู้ก่อนว่าโมเดลนี้คืออะไร มันคือโมเดลที่มีพารามิเตอร์ประมาณ 4 พันล้านตัว โดยมีพารามิเตอร์ที่ไม่ใช่เอมเบดดิ้ง 3 พันล้านตัว เปิดตัวภายใต้สัญญาอนุญาต Apache-2.0 ในสองภาษา คืออังกฤษและจีน มุ่งเป้าไปที่งานแบบ agentic โดยตรง: ตัวแทนเขียนโค้ด ระบบอัตโนมัติในสำนักงาน การใช้เครื่องมือ การปฏิบัติการบนเทอร์มินัล รายงานทางเทคนิค (arXiv 2607.22083 ลงวันที่ 24 กรกฎาคม 2026) อธิบายการฝึกจากศูนย์ด้วยโทเคน 28 ล้านล้านตัว ตามด้วยสูตร SFT บวก RL สามขั้นตอนที่สร้างขึ้นจากการโต้ตอบกับสภาพแวดล้อมในโลกจริง หน้าต่างบริบทยาวถึง 262,144 โทเคน ทั้งหมดนี้ตรวจสอบได้

ส่วนที่ไม่ธรรมดาคือสถาปัตยกรรม Nanbeige4.2-3B ใช้ "Looped Transformer": สแต็กของเลเยอร์ทรานส์ฟอร์เมอร์ 22 ชั้นชุดเดียวกันถูกเรียกใช้สองครั้ง ทำให้โมเดลขนาด 3B พารามิเตอร์ใช้การคำนวณต่อโทเค็นประมาณสองเท่าของโมเดล 3B ทั่วไป โดยไม่เพิ่มน้ำหนักใดๆ นั่นคือวิธีที่ห้องแล็บทำให้จำนวนพารามิเตอร์ที่น้อยสอดคล้องกับการอ้างสิทธิ์ด้าน benchmark ที่สูงเกินระดับของมัน — โมเดลได้รับการประมวลผลซ้ำบนรีพรีเซนเทชันของตัวเองเป็นครั้งที่สอง และคอนฟิกแสดงการนำกลับมาใช้นั้นด้วย num_loops เท่ากับ 2 เหนือเลเยอร์ซ่อน 22 ชั้น (รวมเป็นสเตจ attention ที่มีผลจริง 44 สเตจ) ข้อแลกเปลี่ยนคือเอ็นจินการอนุมานทุกตัวต้องได้รับการบอกวิธีจัดการกับสแต็กเลเยอร์ที่ถูกใช้สองครั้ง: วิธีจัดทำดัชนี attention สำหรับ KV cache และ CUDA graphs วิธีกำหนดขนาดแคช วิธีสตรีมน้ำหนัก เอ็นจินมาตรฐานที่สร้างขึ้นสำหรับทรานส์ฟอร์เมอร์แบบผ่านครั้งเดียวไม่รู้จะจัดการกับมันอย่างไร ซึ่งเป็นเหตุผลที่โค้ดการสร้างโมเดลแบบกำหนดเองจึงมาพร้อมใน repo และต้องใช้ trust_remote_code=True ใน Hugging Face Transformers

โค้ดที่กำหนดขึ้นเองนี้คือจุดขรุขระที่สุดของโมเดลเช่นกัน รายงานอิสระ (arXiv 2608.13987, กลางเดือนสิงหาคม) ระบุข้อบกพร่องห้าประการที่ทำให้ checkpoint ที่เผยแพร่ออกมาไม่สามารถโหลดใช้งานได้ทันทีใน Hugging Face Transformers — ในจำนวนนี้รวมถึงบัฟเฟอร์ rotary-position-embedding ที่ถูกเซ็ตเป็นศูนย์อย่างเงียบ ๆ และการเรียกใช้ cache APIs ที่ถูกลบออกไป — และบทความจากชุมชนต่างอธิบายวิธีแก้ไขเฉพาะหน้า เช่น การใช้ use_cache=False ก่อนที่โมเดลจะรันได้เลย ปัญหาเหล่านี้แก้ไขได้ และตอนนี้ checkpoint และ harness ที่ถูกแพตช์แล้วก็มีการเผยแพร่กันทั่วไป แต่ประเด็นสำคัญอยู่ที่รูปแบบ: นี่คือสถาปัตยกรรมอันชาญฉลาดที่ต้องแบกรับความฝืดในการปรับใช้งานอย่างผิดปกติมาตั้งแต่วันแรก

ตัวเลข ผู้ขาย และอิสระ

ข้ออ้างเรื่องเกณฑ์ชี้วัดหลัก ซึ่งตรงจากรายงานทางเทคนิค คือ Nanbeige4.2-3B ทำผลงานได้ดีกว่าโมเดลโอเพนขนาดใหญ่กว่า — Qwen3.5-9B และ Gemma4-12B — ในการประเมินเชิงเอเจนต์ ตัวเลขเรือธงคือ SWE-Bench Verified ที่ 63.6 เทียบกับ Qwen3.5-9B ได้ 53.1 และ Gemma4-12B ได้ 44.2 รายงานยังระบุ GPQA-Diamond ที่ 87.4, HMMT-Feb-2026 ที่ 82.8, Terminal-Bench 2.0 ที่ 44.1 และ SWE-Bench Pro ที่ 46.9 ไม่มีผลลัพธ์ใดในนี้ที่ถูกทำซ้ำอย่างอิสระบนแฮร์เนสที่ผู้จำหน่ายเลือก และควรอ่านผลลัพธ์เหล่านี้เป็นคำรายงานของห้องแล็บเองเกี่ยวกับโมเดลของตน — ซึ่งเป็นคำรายงานเดียวกับที่การ์ดโมเดลสรุปว่าโมเดลอยู่บนสุดของลีดเดอร์บอร์ดโมเดลขนาดเล็กของ Artificial Analysis

สิ่งที่ใกล้เคียงที่สุดกับการตรวจสอบอย่างอิสระเท่าที่มีมา กลับมาจากอีกบริบทหนึ่งที่ต่างออกไปโดยสิ้นเชิง ในการรันเกณฑ์มาตรฐานบนอุปกรณ์ Artificial Analysis × Liquid AI บน iPhone 17 Pro ซึ่งเผยแพร่ในปลายเดือนสิงหาคม บิลด์ 4-bit ของ Nanbeige4.2-3B ทำคะแนนเฉลี่ยสูงสุดร่วมกันในบรรดาโมเดลที่ทำงานได้ 33 รุ่นซึ่งมีขนาดต่ำกว่า 8GB ที่คอนเท็กซ์ 16K (ได้ 63 เท่ากับ LFM2.5-2.6B และนำหน้าโมเดลระดับ 9B หลายรุ่น) และที่คอนเท็กซ์ 64K ได้ 65 เป็นรองเพียง Ling 3.0 Tiny ที่ได้ 66 เท่านั้น โปรไฟล์รายการทดสอบของมันน่าทึ่ง: ดีที่สุดในกลุ่มบน MATH-500 (96%) และแข็งแกร่งในการเรียกใช้ฟังก์ชัน (76% บน BFCL) แต่อัตราการไม่หลอนบน AA-Omniscience อ่อนแอที่ 33% และที่ชี้ขาดสำหรับการใช้งานจริงคือมันช้า มันสร้างประมาณ 14 โทเค็นต่อวินาที และใช้เวลา 21.4 วินาที และหน่วยความจำ 4.0 GB ในการตอบพรอมพ์ 1,024 โทเค็น ภายใต้ขีดจำกัดเวลาตอบ 60 วินาที คะแนนเฉลี่ยของมันดิ่งลงจาก 63 เป็น 18 กล่าวอีกนัยหนึ่ง: คุณภาพที่เหนือกว่าโมเดล 9B นั้นมีจริง และต้นทุนของสถาปัตยกรรมแบบวนซ้ำที่สร้างคุณภาพนี้ก็มีจริงเช่นกัน

การสนับสนุนจากต้นน้ำให้อะไรกับคุณจริงๆ

เมื่อนำเหตุการณ์ต้นทางทั้งสองมารวมกัน ภาพเชิงปฏิบัติสำหรับผู้ที่โฮสต์เองก็ตรงไปตรงมา {{1}}หากคุณใช้ SGLang โมเดล Nanbeige4.2-3B ก็ให้บริการได้แล้วจากการติดตั้งแบบมาตรฐานบนการสนับสนุน main branch ที่รวมเข้าแล้ว — ไม่ต้อง fork โดยตัวแยกวิเคราะห์การเรียกใช้เครื่องมือและการให้เหตุผลของโมเดลเชื่อมต่อกับตัวตรวจจับ qwen3 ชุดเดียวกับที่ SGLang มีอยู่แล้ว หากคุณใช้ vLLM การสนับสนุนแบบมาตรฐานก็ห่างออกไปแค่การ merge ครั้งเดียว: บรรทัดใน registry จะส่งโมเดลไปยังแบ็กเอนด์ transformers ตัวแปลงสถาปัตยกรรมจะปรับขนาดแคชให้ถูกต้อง และตัวแยกวิเคราะห์การให้เหตุผลและการเรียกใช้เครื่องมือของ qwen3 ถูกใช้ซ้ำ ซึ่งเป็นวิธีที่พื้นผิวการเรียกใช้เครื่องมือที่เข้ากันได้กับ OpenAI ทำงาน{{/1}}

ข้อแม้ที่ตรงไปตรงมาก็คือ เส้นทางของ vLLM เป็นเส้นทางเพื่อความเข้ากันได้ ไม่ใช่เส้นทางที่ถูกปรับแต่งมาโดยเฉพาะ การรัน NanbeigeForCausalLM ผ่าน TransformersForCausalLM หมายความว่า vLLM จะประมวลผลโค้ด Hugging Face ของตัวแบบเองภายในเลเยอร์ serving แทนที่จะเป็นการ implement แบบเนทีฟที่มี custom kernels และการจัดการ CUDA-graph — ความแตกต่างนี้คือสิ่งที่ SGLang เลือกที่จะสร้างแบบเนทีฟนั่นเอง สำหรับโมเดล 3B ที่ต้นทุนต่อโทเคนถูกทำให้เพิ่มเป็นสองเท่าอยู่แล้วจากลูป เส้นทางที่ใช้ backend แบบ transformers จึงไม่น่าจะเป็นเส้นทาง serving ที่เร็วที่สุดได้ และประวัติบั๊กห้าตัวของโค้ด custom ที่อยู่ข้างใต้นั้นหมายความว่าเส้นทางนี้จะสืบทอดความผิดปกติใดๆ ที่ยังหลงเหลืออยู่มา สำหรับงานแบบ agentic ที่ความถูกต้องของการเรียกใช้ tool และพฤติกรรมบริบทระยะยาวมักสำคัญกว่าอัตราโทเคนดิบต่อวินาที นั่นอาจเป็นการแลกเปลี่ยนที่ยอมรับได้ สำหรับแชตที่อ่อนไหวต่อความหน่วงก็ควร benchmark ก่อนที่จะเดิมพันเส้นทาง production กับมัน และอีกสองเอนจินยังคงเป็นแบบ fork เท่านั้น: llama.cpp และ Ollama ยังคงชี้ไปที่สาขา Nanbeige โดยเซิร์ฟเวอร์ llama.cpp ที่มาพร้อมกับ LM Studio ยังไม่รองรับสถาปัตยกรรมนี้

สิ่งที่ควรดูต่อไป

สามสิ่งที่จะเปลี่ยนภาพรวมได้ ประการแรก PR ของ vLLM ต้องถูก merge และปล่อยออกมาใน release — จับตาดูเธรดและบันทึก release ของ vLLM; ผู้รีวิวได้ระบุแล้วว่ายังมี docs entry และ CI checkpoint mapping ที่ต้องทำก่อนที่จะพร้อม merge ประการที่สอง จับตาดูว่า layer-count convertor จะผ่านการรีวิวหรือไม่ เนื่องจากผู้ดูแลเชื่อว่า PR #54941 อาจทำให้มันไม่จำเป็นอีกต่อไป — นี่เป็นสัญญาณว่างานแก้ไขชั่วคราวนี้ส่วนใหญ่เป็นแค่โครงสร้างประกอบรอบสถาปัตยกรรมแบบวนลูป ประการที่สาม จับตาดูคำถามเรื่องผู้ให้บริการโฮสต์: การ์ด Hugging Face ในตอนนี้ไม่แสดงผู้ให้บริการ inference ใดที่ serving โมเดลนี้ และเราก็ไม่ได้โฮสต์มันเช่นกัน ดังนั้นวันนี้จึงเป็นเรื่องของการโฮสต์เอง (self-host) เมื่อผู้ให้บริการรายใดเริ่มแสดงโมเดลนี้ ฝั่ง routing ก็จะกลายเป็นเรื่องปกติ — API เดียวที่ครอบคลุมแคตตาล็อกโมเดลขนาดใหญ่ โดยส่งผ่านราคารายการจากผู้ให้บริการโดยไม่บวกกำไร คือวิธีที่มีแรงเสียดทานต่ำในการ A/B ทดสอบ Nanbeige4.2-3B ที่โฮสต์เอง กับโมเดลที่โฮสต์แล้วซึ่งมันอ้างว่าเหนือกว่า จนกว่าจะถึงตอนนั้น เหตุการณ์สำคัญที่ควรจดบันทึกคือสิ่งที่เพิ่งเกิดขึ้น: หกสัปดาห์หลังการเปิดตัวที่ทุก runtime หลักตอบรับด้วยความเฉยเมยแล้วก็ fork ไป ตอนนี้สองในนั้นให้บริการ Nanbeige4.2-3B จากการติดตั้งที่ไม่มีการแก้ไขใดๆ