ลองนึกถึง coding agent ที่รับคำสั่งใหญ่ก้อนเดียวแล้วรันต่อเนื่องเป็นชั่วโมง งานที่มันทำซ้ำแทบทั้งวันคือสั่ง git pull เพื่อดึงโค้ดล่าสุด ตรวจว่าผลที่เครื่องมือคืนมาครบไหม จัดรูปผลลัพธ์ให้เรียบร้อย แล้วส่งต่อให้ subagent ตัวถัดไป NVIDIA เรียกงานกลุ่มนี้ว่า routine call และบอกว่านี่คือส่วนที่กินงบโทเคนมากที่สุดของ agent ที่รันต่อเนื่อง ส่วนการคิดแผนซึ่งเป็นเหตุผลให้เลือกโมเดลแพงตั้งแต่แรก กลับคิดเป็นเพียงเสี้ยวเดียวของบิล

NVIDIA Nemotron 3.5 Lightning ที่เพิ่งเปิดตัวคือโมเดลเปิดที่สร้างมารับงานฝั่งนี้โดยเฉพาะ โมเดลใช้สถาปัตยกรรม mixture-of-experts มีพารามิเตอร์รวม 30B แต่เรียกใช้จริงเพียง 3B ต่อโทเคน NVIDIA ระบุบทบาทไว้ชัดเจนว่าเป็นชั้นลงมือทำ หรือ execution layer ของ agent ที่รันตลอดเวลา ไม่ใช่ชั้นวางแผน ส่วนงาน orchestration และการวางแผนที่ซับซ้อนยังเป็นหน้าที่ของ frontier reasoning model ตัวใหญ่กว่าเหมือนเดิม ทั้งน้ำหนักโมเดลและเครื่องมือสำหรับรันในเครื่องพร้อมใช้ตั้งแต่วันแรก

เลข 30B กับ 3B ในโมเดลเดียวกันหมายความว่าอะไร

mixture-of-experts คือการแบ่งความรู้ภายในโมเดลไปไว้ใน expert หลายตัว แล้วให้ router เลือกว่าแต่ละโทเคนควรส่งไปให้ expert ตัวไหนคำนวณ แต่ละโทเคนจึงเรียกใช้พารามิเตอร์เพียงเศษเสี้ยวจากทั้งหมด ผลคือโมเดลมีพารามิเตอร์รวมมากกว่าจำนวนพารามิเตอร์ที่ต้องคำนวณในแต่ละโทเคน

เลข 30B กับ 3B เมื่อวางคู่กันจึงหมายความว่าโมเดลนี้มีพารามิเตอร์รวม 30B แต่เรียกใช้พารามิเตอร์เพียง 3B ต่อโทเคน นี่คือคำตอบว่าทำไมโลกที่มีโมเดลใหญ่อยู่แล้วจึงยังต้องมีโมเดลที่ใช้พารามิเตอร์น้อยต่อโทเคน เพราะในชั้นลงมือทำมีการเรียกโมเดลนับพันครั้งในหนึ่งภารกิจ เวลาและค่าใช้จ่ายต่อการเรียกแต่ละครั้งจึงเป็นตัวตัดสินว่าระบบจะใช้งานได้จริงหรือไม่

สามอย่างที่ใส่มาเพื่องานลงมือทำโดยเฉพาะ

ความเร็วของ Lightning ไม่ได้มาจากการย่อขนาดเพียงอย่างเดียว NVIDIA ระบุว่าหลังเลือกสถาปัตยกรรมแล้ว ยังเพิ่มอีกสามอย่างเข้ามา

เดาโทเคนล่วงหน้าแล้วตรวจทีเดียว speculative decoding คือวิธีเร่งความเร็วที่ให้ตัวเดาเสนอโทเคนถัดไปหลายตัวรวดเดียว แล้วส่งให้โมเดลหลักตรวจพร้อมกันว่าเดาถูกไหม ถ้าถูก ก็จะได้หลายโทเคนในเวลาที่ใกล้เคียงกับการผลิตเพียงโทเคนเดียว ตัวเดาที่ว่ามาได้สองทาง ทางแรกคือ multi-token prediction หรือ MTP ซึ่งเป็นความสามารถเดาล่วงหน้าที่อยู่ในตัวโมเดลเอง NVIDIA ใส่ MTP มาตั้งแต่ช่วง pre-training เพื่อฝึกการเดาล่วงหน้าโดยเฉพาะ แล้วตามด้วยเฟส MTP-boosting อีกชั้นเพื่อให้เดาแม่นขึ้น ทางที่สองคือใช้ draft model แยกอีกตัว ซึ่งรอบนี้แถมมาให้เลือกสองตัวคือ DSpark กับ DFlash

การเลือกตัวเดามีเงื่อนไขที่มองข้ามไม่ได้ และต้นทางเองก็เขียนไว้ไม่ตรงกันเสียทีเดียว หน้าโมเดลบอกว่าตอนนี้แนะนำ DSpark ในทุกกรณี แต่ตารางสรุปในหน้าเดียวกันกลับจำกัดขอบเขตของ DSpark ไว้แคบกว่านั้น คือใช้กับงาน data centre ที่มี concurrency ต่ำ และงานบน DGX Spark ซึ่งเป็นเครื่องตั้งโต๊ะสาย AI ของ NVIDIA ส่วนบล็อกเปิดตัวระบุว่า MTP ในตัวโมเดลเหมาะกับ concurrency ระดับปานกลางถึงสูง โดยความยาว draft ที่เหมาะสมจะลดลงเมื่อ concurrency สูงขึ้น เมื่อคำแนะนำแบบเหมารวมกับตารางขอบเขตไม่ตรงกัน อย่างน้อย concurrency ของงานตัวเองจึงเป็นเงื่อนไขที่ต้องดู ส่วน DFlash ต้นทางระบุว่าให้ลองวัดเทียบเองว่าเหมาะกับงานหรือไม่

เทรนให้เข้ากับ harness ของ agent โดยตรง harness คือโปรแกรมที่ครอบโมเดลไว้เพื่อให้ทำงานเป็น agent ได้ NVIDIA เทรนโมเดลนี้ให้เข้ากับ harness ที่นิยมใช้กัน โดยระบุชื่อ OpenClaw กับ Hermes Agent ต้นทางบอกว่าผลคือโมเดลเรียกเครื่องมือได้แม่นขึ้น และลด latency เมื่อต้องรับงานปริมาณมาก

ลดความละเอียดของตัวเลขในโมเดล quantization คือการใช้ตัวเลขที่มีความละเอียดต่ำลงเพื่อเก็บน้ำหนักโมเดล จึงใช้หน่วยความจำน้อยลงและคำนวณได้เร็วขึ้น รอบนี้มีเช็กพอยต์ให้เลือกสองแบบ คือ BF16 ที่เก็บน้ำหนักไว้ละเอียดกว่า กับ NVFP4 ที่บีบความละเอียดลงมาจนเช็กพอยต์นี้รันได้ทั้งใน data center และบนเครื่องตั้งโต๊ะอย่าง DGX Spark หน้าโมเดลวางคะแนนของเช็กพอยต์ทั้งสองแบบไว้เทียบกันให้ดูเอง และเพราะเช็กพอยต์ NVFP4 รันบนเครื่องตั้งโต๊ะได้ จึงลองรันบน DGX Spark ตามหัวข้อด้านล่างได้ตั้งแต่วันแรก

ตัวเลขที่ต้นทางเคลมและเงื่อนไขที่ต้องอ่านคู่กัน

ก่อนอ่านตัวเลขชุดนี้ ต้องรู้ไว้ก่อนว่าทั้งหมดเป็นผลที่ NVIDIA วัดด้วย harness ของตัวเอง หน้าโมเดลระบุไว้ด้วยว่าตัวเลขอาจต่างจากที่เจ้าอื่นรายงาน และยังไม่มีผลทดสอบจากบุคคลที่สามมายืนยัน

จะเห็นว่าตัวเลขที่ฟังดูแรงที่สุดสองตัวแรกมาจากบล็อกเปิดตัว ซึ่งไม่ได้บอกว่าใช้เครื่องอะไรทดสอบ ส่วนตัวเลขที่ระบุเงื่อนไขไว้ชัดที่สุดอย่าง 40+ TPS/User มาจากหน้าโมเดล ก่อนนำตัวเลขใดไปตั้งความคาดหวังให้ระบบของตัวเอง จึงต้องอ่านทั้งประเภทงาน เช็กพอยต์ เครื่องหรือ config ที่ใช้วัด ระดับ concurrency และตัวเดาที่เปิดไว้

ลองเองได้ยังไง

น้ำหนักโมเดล ข้อมูลเทรน และสูตรการเทรนทั้งหมดเปิดให้ใช้ภายใต้สัญญาอนุญาต OpenMDW-1.1 ส่วนตัวโมเดลรันได้บน GPU เดียว โดยรันได้ทั้งบน 1× DGX Spark และ 1× H100

ทางลัดสำหรับคนที่มีเครื่องอยู่แล้วคืออัปเดต Ollama เป็น v0.32.9 ซึ่งเพิ่งเพิ่มสถาปัตยกรรม Nemotron 3 เข้ามา แล้วสั่งรัน

ollama run nemotron-3.5-lightning

• ถ้ายังไม่อยากลงอะไรในเครื่อง ต้นทางชี้ไปที่ build.nvidia.com และ OpenRouter
• เครื่องมือสำหรับรันเองที่ต้นทางระบุว่ารองรับโมเดลนี้ ได้แก่ LM Studio · llama.cpp · Unsloth
• ถ้าอยากปรับจูนต่อเอง ทำได้ทั้ง LoRA และ full SFT รวมถึงต่อยอดด้วย reinforcement learning และการประเมินด้วย environment โดย NVIDIA ให้เหตุผลว่าโมเดลเล็ก fine-tune ได้เร็วกว่า ถูกกว่า และใช้ฮาร์ดแวร์น้อยกว่าโมเดลใหญ่

แผนวิ่งขึ้น งานลงมือทำวิ่งลง

NVIDIA สรุปวิธีคิดทั้งหมดนี้ไว้อย่างสั้นที่สุดในประโยคปิดว่า แผนวิ่งขึ้นไปหาโมเดล frontier ส่วนงานลงมือทำวิ่งลงมาหา Lightning เส้นแบ่งนี้ใช้ได้แม้จะไม่ได้ลงโมเดลตัวนี้เลย เพราะมันเปลี่ยนคำถามที่เราใช้กับระบบของตัวเอง จากเดิมที่ถามว่าโมเดลไหนเก่งที่สุด มาเป็นถามว่างานชิ้นนี้ต้องใช้ความคิดจริงๆ หรือแค่ต้องใช้มือ

สิ่งที่ทำได้ทันทีคือเปิด log ของ agent ที่ใช้อยู่ แล้วไล่ดูว่าแต่ละก้าวเป็นการตัดสินใจจริงๆ หรือเป็นเพียงงานหยิบจับที่ไม่ต้องวางแผนซับซ้อน จำนวนก้าวที่นับได้ยังไม่เท่ากับสัดส่วนของบิล เพราะแต่ละก้าวกินโทเคนไม่เท่ากัน แต่ก้าวฝั่งหยิบจับคือกลุ่มงานที่ต้นทางวางไว้ให้โมเดลชั้นลงมือทำรับไป จึงเป็นรายการแรกที่ควรหยิบมาลองวัดว่าย้ายออกไปแล้วผลยังเหมือนเดิมไหม ก่อนจะไล่ดูต่อว่าก้าวเหล่านั้นกินโทเคนไปเท่าไร

ส่วนขอบเขตที่ต้นทางกำหนดไว้ก็ควรนึกถึงตั้งแต่ต้น NVIDIA วาง Lightning ไว้ที่ชั้นลงมือทำเท่านั้น การนำไปแทนโมเดลใหญ่ทั้งระบบไม่ใช่สิ่งที่ต้นทางเคลม และยังไม่มีตัวเลขจากแหล่งอื่นมารองรับ

ที่มา:

• เอกสารทางการของ NVIDIA Nemotron 3.5 Lightning
• โปรเจกต์ Ollama v0.32.9 บน GitHub