เวลาต่อระบบ agent ขึ้นมาสักตัว คำถามว่าจะใช้โมเดลไหนมักถูกตอบให้จบตั้งแต่ตอนออกแบบ ด้วยการเทียบคะแนนรวมของแต่ละตัว เลือกตัวที่นำมาใช้ แล้วผูกทั้งระบบไว้กับมัน NVIDIA เพิ่งเปิด NeMo Switchyard พร็อกซีและไลบรารีโอเพนซอร์สที่เขียนด้วย Rust สำหรับจัดการทราฟฟิก LLM ซึ่งย้ายการตัดสินใจนั้นไปไว้ตอนรันไทม์ โดยตัดสินใหม่ในแต่ละคำขอหรือแต่ละเทิร์นว่างานตรงหน้าควรส่งไปหาโมเดลตัวไหน

เหตุผลเห็นได้จากผลทดสอบที่ NVIDIA นำมาแสดง บนเบนช์มาร์กงานเทอร์มินัลระดับยาก Terminal-Bench Hard ที่รันด้วย Terminus Agent มีงาน 47 ชิ้น แบ่งเป็น 8 กลุ่ม แล้ววัด avg pass rate ของสามโมเดลแยกตามกลุ่ม ผลคือไม่มีโมเดลตัวไหนกวาดทุกกลุ่ม

DeepSeek-V4 มีความแม่นรวมสูงสุดในชุดนี้และนำอยู่ 5 กลุ่มงาน โดยทิ้งห่างชัดที่สุดในกลุ่ม Security & Crypto ที่ทำได้ 50% ขณะที่ Kimi-K2.6 ได้ 22% และ Qwen3.5 ได้ 12% แต่ในกลุ่ม Systems & Low-Level ซึ่งมีงานมากที่สุดคือ 9 ชิ้น DeepSeek-V4 กลับทำได้เพียง 17% แพ้ Kimi-K2.6 ที่ได้ 24% ส่วนกลุ่ม Math & Science เป็นของ Qwen3.5 ที่ 54% ขณะที่อีกสองตัวได้ 46% กับ 43% เมื่อมองทั้งตาราง ผู้ชนะจึงกระจายเป็น DeepSeek-V4 5 กลุ่ม · Kimi-K2.6 2 กลุ่ม · Qwen3.5 1 กลุ่ม

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

ราคาต่อโทเคนบอกไม่ได้ว่างานหนึ่งชิ้นจะจบที่เท่าไหร่

เมื่อคิดเรื่องเงินกับเวลาด้วย การตัดสินใจยิ่งซับซ้อนขึ้น เพราะต้นทุนจริงไม่ได้ขึ้นกับราคาต่อโทเคนอย่างเดียว โมเดลแต่ละตัวมี verbosity profile ของตัวเอง ซึ่งในที่นี้วัดว่ากว่าจะปิดงานได้ใช้โทเคนเท่าไรและมี tool call กี่ครั้ง โมเดลที่ราคาต่อโทเคนถูกกว่าจึงอาจมีต้นทุนรวมสูงกว่าเมื่อจบงาน

กราฟเปรียบเทียบความแม่นกับจำนวนโทเคนของสามโมเดลเดิมชี้ให้เห็นจุดนั้น Qwen3.5 อิ่มตัวอยู่ราว 37% แล้วไม่ขยับต่อ ส่วน DeepSeek-V4 ไปได้ถึงราว 48% แต่ใช้ prompt token มากกว่ามาก คำถามว่าโมเดลไหนคุ้มกว่ากันจึงตอบไม่ได้เลย หากยังไม่รู้ว่างานที่จะส่งไปเป็นงานแบบไหน

ปัญหาจึงเกิดขึ้นพร้อมกันสองด้าน ถ้าส่งทุกคำขอไปโมเดลใหญ่ที่สุด ต้นทุนกับ latency ก็สูงขึ้นทั้งระบบ ทั้งที่งานง่ายๆ ไม่ต้องใช้โมเดลขนาดนั้น แต่ถ้าส่งทุกคำขอไปโมเดลเล็ก คุณภาพก็ตกในงานที่ซับซ้อน

สัญญาณสามด้านที่ router ใช้ตัดสินตอนงานเข้ามา

ตอนรันไทม์ router จะประเมินคำขอพร้อม context ที่มีอยู่ แล้วส่งงานไปยังโมเดลที่ตรงกับข้อกำหนด ข้อจำกัด และ policy ของงานชิ้นนั้น การตัดสินใจอาศัยสัญญาณสามด้าน คือความสามารถของโมเดลว่าตัวไหนแก้งานแบบนี้ได้ถูกต้อง · โปรไฟล์ต้นทุนกับ latency ของแต่ละตัว · และสัญญาณระดับ infrastructure ที่ช่วยให้ส่งต่องานได้ราบรื่นและเชื่อถือได้

เมื่อมองตามจุดที่ระบบอ่านค่า สัญญาณเหล่านี้มาจากสามจุด

• ดูจากตัวคำขอ ใช้ classifier จัดหมวดหัวข้อหรือประเมินความยากของงาน แล้วจับคู่กับโมเดลที่มีอยู่ใน pool หรือใช้ embedding model กับ feature crafter ดึงฟีเจอร์จาก query ก่อนตัดสิน
• ดูจากพฤติกรรมของโมเดลระหว่างทำงาน เช่น logprobs · cascades · agentic trace
• ดูจากสภาพระบบ ทั้ง pricing · latency · load · และสัญญาณเฉพาะของงาน agent อย่าง error ที่เพิ่งเกิดขึ้น

นอกจากเลือกว่าจะใช้สัญญาณอะไร ยังต้องกำหนดว่าจะประเมินเมื่อไรและที่จุดไหน งาน agent ที่ยาวหลายเทิร์นจะ route งานทั้งชิ้นไปโมเดลเดียว หรือ route ใหม่ทุก step ก็ได้ จะให้ทั้งระบบใช้ model pool ร่วมกัน หรือให้ sub-agent แต่ละตัวมี pool ของตัวเองก็ได้ คำตอบขึ้นกับ use case ความซับซ้อนของ deployment ความทนต่อความผิดพลาด ตลอดจน latency และ throughput ที่รับได้

กฎสามแบบที่ตั้งได้เลยโดยไม่ต้องเทรนอะไรเพิ่ม

อัลกอริทึมที่หยิบไปใช้ได้โดยไม่ต้องเทรนกับข้อมูล workload ก่อน มีสามแบบที่เห็นได้ชัดว่าแต่ละแบบตัดสินจากอะไร

เกณฑ์ของ stage_router จำง่ายที่สุดในสามแบบ ถ้าเจอ error รุนแรง ทำงานวนโดยไม่คืบหน้า หรือสำรวจยืดเยื้อ ให้ขยับขึ้นไปใช้โมเดลที่เก่งกว่า แต่ถ้ากำลังเขียนและแก้งานไปได้อย่างต่อเนื่อง โดยเฉพาะเมื่อเทสต์ผ่านแล้ว ให้ใช้ตัวที่ประหยัดกว่า หากสัญญาณยังไม่ชัด router จะเรียก LLM judge มาช่วยตัดสินก่อน ถ้ายังตัดสินไม่ได้จึงค่อยใช้ค่า default ที่ตั้งไว้ ข้อดีที่รีโประบุไว้คือ อัลกอริทึมนี้อ่านสัญญาณที่มีอยู่แล้วในบทสนทนา เช่นผลจาก tool และ error จึงตัดสินได้เกือบทุกเทิร์นโดยไม่ต้องเรียกโมเดลเพิ่ม

ประหยัดได้เท่าไหร่ แลกความแม่นไปกี่จุด

NVIDIA นำสามอัลกอริทึมนี้ไปเทียบกับการใช้โมเดลเดี่ยว โดยให้ route ระหว่าง Opus 4.8 กับ GLM 5.2 เมื่อใช้ GLM 5.2 ตัวเดียว งานเสร็จราว 74% ที่ต้นทุนราว 70 ดอลลาร์ · Opus 4.8 ตัวเดียวทำได้ราว 77% ที่ราว 150 ดอลลาร์ ส่วน router ทั้งสามแบบทำได้ราว 79% ถึง 80% ที่ราว 105 ถึง 118 ดอลลาร์ จึงทั้งทำงานเสร็จได้มากกว่าและจ่ายน้อยกว่าการใช้โมเดลแพงตัวเดียว

ตัวเลขจากพาร์ตเนอร์ทำให้เห็น trade-off ชัดกว่านั้น LangChain นำ escalation router ไปวัดกับชุดประเมิน deep agent ภายในของตัวเอง ซึ่งประกอบด้วยงานหลายเทิร์น 145 งานที่สะท้อนงานโปรดักชัน ทดสอบ 5 รอบ และ route ระหว่าง NVIDIA Nemotron 3.5 Lightning กับ Claude Opus 4.8 ผลคือต้นทุนลดลง 74% เมื่อเทียบกับ baseline ที่ใช้โมเดล frontier อย่างเดียว โดยมีเพียง 7% ของ call ที่ส่งไปหาโมเดล frontier แลกกับความแม่นที่ลดลงราว 6 จุด

Cognition เป็นอีกรายที่นำวิธี staged routing ไปใส่ใน Devin Desktop ให้ผู้ใช้ภายใน NVIDIA ทดสอบกับงานจริง และรายงานผลบนเบนช์มาร์ก FrontierCode Main ด้วย เมื่อ route ระหว่าง Opus 5 กับ Kimi K2.7 ระบบทำได้ 50.6% ที่ต้นทุนเฉลี่ย 3.11 ดอลลาร์ ความแม่นต่ำกว่า Opus 5 อยู่ 2.8 จุด แต่ต้นทุนเฉลี่ยต่ำกว่าราว 28% ทั้งสองกรณีจึงสะท้อนเรื่องเดียวกัน คือประหยัดต้นทุนได้มาก แลกกับความแม่นที่ลดลงไม่กี่จุด และตัวเลขเหล่านี้ทำให้ตัดสินใจได้ว่า trade-off ดังกล่าวรับได้หรือไม่

ผลจะออกมาแบบไหน ขึ้นกับ pool ที่ตั้งเอง

ตัวเลขเหล่านั้นไม่ได้เกิดขึ้นเองหลังติดตั้ง ผลด้านต้นทุนขึ้นกับกลุ่มโมเดลที่เลือกใส่ใน pool และอัลกอริทึมที่เลือกใช้ ซึ่งต้องกำหนดเองทั้งคู่ โดยเขียน route กับ target ลงใน routes.toml ตาม คู่มือตั้งค่าของโปรเจกต์ หรือใช้ packaged deployment ที่มีมาให้ ซึ่งต้องมีคีย์ OpenRouter ก่อน

Switchyard มีจุดเชื่อมต่อกับระบบเดิมสองแบบ เมื่อใช้เป็นพร็อกซี ระบบรับคำขอในรูปแบบ OpenAI Chat Completions · OpenAI Responses · Anthropic Messages แล้วแปลงเป็นรูปแบบภายใน ส่งต่อไปยัง backend ในรูปแบบที่ backend นั้นเข้าใจ ก่อนแปลงคำตอบกลับเป็นรูปแบบที่ client รออยู่ ส่วนเมื่อใช้เป็นไลบรารี ตัวไลบรารีจะไม่เรียกโมเดลเอง อัลกอริทึมเพียงตัดสินว่าจะใช้ target ไหน แล้วคืนคำสั่งเรียกโมเดลให้แอปต้นทางจัดการต่อ จึงนำไปเสียบกับ proxy · gateway · หรือ agent runtime ที่มีอยู่แล้วได้

ระบบยังเก็บบันทึกการทำงานว่าคำขอนี้ไปโมเดลไหน เพราะอะไร ใช้โทเคนเท่าไร ช้าแค่ไหน และ call นั้นจบแบบไหน ฝั่งรีโประบุว่ามี Prometheus metrics ครอบคลุมทั้ง requests · errors · latency · tokens · และ routing overhead เมื่อมีร่องรอยละเอียดระดับนี้ คำถามว่าเงินหายไปตรงไหนก็ตรวจย้อนหลังได้จริง แทนที่จะเดาจากยอดรวมปลายเดือน

ยังเป็นซอฟต์แวร์ขั้นทดลอง แต่เอาหลักไปใช้ได้เลย

ข้อแรกที่ต้องแบ่งให้ชัดคือ รีโปของโปรเจกต์ระบุว่านี่เป็นซอฟต์แวร์ขั้น pre-alpha ที่ยังเปลี่ยนเร็ว เป็น experimental software ที่ไม่พร้อมใช้ใน production และ API กับอัลกอริทึมจะเปลี่ยนอย่างมีนัยสำคัญก่อนถึง v1.0 ขณะเดียวกัน โพสต์เปิดตัวก็ระบุว่าเป็นโอเพนซอร์สเต็มตัวภายใต้สัญญาอนุญาต Apache-2.0 และมีพาร์ตเนอร์นำไปทดสอบกับงานจริงแล้ว ทั้งสองอย่างเป็นจริงพร้อมกันได้ กล่าวคือ ตัวซอฟต์แวร์มีอยู่จริงและติดตั้งได้จริง แต่ตัวโปรเจกต์ยังไม่รับรองว่าพร้อมขึ้นระบบจริง

อีกข้อที่ต้องแบ่งให้ชัดคือ มันไม่ได้ทำให้โมเดลเก่งขึ้นเลย router เลือกได้เฉพาะโมเดลที่มีอยู่ใน pool สิ่งที่เปลี่ยนมีเพียงว่างานแต่ละชิ้นจะไปตกที่โมเดลตัวไหน และซอฟต์แวร์ชิ้นนี้ทำมาสำหรับคนที่วางระบบ agent เอง ไม่ใช่แอปที่กดติดตั้งแล้วใช้ได้ทันที

แต่หลักการข้างใต้ไม่ต้องรอ v1.0 ตารางรายกลุ่มงานกับกราฟโทเคนสะท้อนเรื่องเดียวกัน คือความเก่งของโมเดลต้องวัดแยกตามกลุ่มงาน ไม่ใช่ดูจากตัวเลขรวมเพียงตัวเดียว ใครที่จ่ายค่า AI ทุกเดือนและเปิดโมเดลตัวท็อปค้างไว้ทำทุกอย่าง ลองแยกงานด้วยเกณฑ์เดียวกับที่ router ใช้ก็ได้ งานร่าง · งานสรุป · งานตอบเมล ถ้าวัดแล้วว่าตัวประหยัดทำได้ก็ส่งให้ตัวประหยัด แล้วส่งงานที่ติดขัดจริงหรือต้องคิดหลายชั้นไปยังโมเดลที่วัดแล้วว่าทำงานกลุ่มนั้นได้ดีกว่า ส่วนคนที่วางระบบเอง สัญญาณสามด้านกับกฎสามแบบข้างต้นคือแผนที่ที่นำไปเขียน policy ของตัวเองได้ตั้งแต่วันนี้ โดยไม่ต้องรอให้ไลบรารีนิ่งก่อน

---

ที่มา:

• บทความ Route AI Agent Workloads Across Models with NVIDIA NeMo Switchyard จาก NVIDIA Developer Blog
• โปรเจกต์ NVIDIA-NeMo/Switchyard บน GitHub