NVIDIA เปิดตัว Switchyard ไลบรารีอัจฉริยะช่วยสลับโมเดล AI ลดต้นทุน

AI Agent ส่วนใหญ่ในปัจจุบันมักส่งคำขอทุกอย่างไปยังโมเดลระดับ Frontier ที่มีราคาสูง ไม่ว่าจะเป็นการคัดแยกประเภทข้อมูล การเรียกใช้เครื่องมือพื้นฐาน ไปจนถึงการใช้เหตุผลที่ซับซ้อน ส่งผลให้เกิดต้นทุนและความหน่วงที่ไม่จำเป็น NVIDIA NeMo Switchyard จึงถูกพัฒนาขึ้นมาเพื่อแก้ปัญหานี้โดยเฉพาะ

Switchyard คือเลเยอร์กำหนดเส้นทางแบบ Open-source ที่ทำหน้าที่เป็นตัวกลางระหว่าง Agent และโมเดลต่างๆ โดยจะตัดสินใจแบบรายคำขอ (Request by request) ว่าควรส่งงานให้โมเดลใดจัดการ บทความนี้จะสอนสร้างเราเตอร์สองโมเดลที่ใช้งานได้จริง ตั้งแต่ระดับพื้นฐานไปจนถึงการกำหนดเส้นทางตามเนื้อหา (Content-aware routing)

Switchyard ทำหน้าที่อะไรกันแน่?

ตามปกติแอปพลิเคชัน LLM จะเชื่อมต่อกับโมเดลโดยตรง แต่ Switchyard จะแทรกตัวอยู่ตรงกลางเพื่อกระจายงาน:

Application
    |
    v
Switchyard
   /   \
  v     v
Cheap   Powerful
Model   Model

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

ขั้นตอนที่ 1: การติดตั้ง Switchyard

สำหรับการติดตั้งผ่าน CLI หรือ Server แนะนำให้ใช้เครื่องมือ uv ตามคำสั่งนี้:

uv tool install "nemo-switchyard[cli,server]"

ตรวจสอบความเรียบร้อยของการติดตั้ง:

switchyard --version

ผลลัพธ์:

switchyard 0.2.0
nemo-switchyard v0.2.0

นอกจากนี้ยังสามารถติดตั้ง native Rust server ได้ผ่าน Cargo:

cargo install --locked switchyard-server

ในบทช่วยสอนนี้ เราจะกำหนดเส้นทางโมเดลผ่าน OpenRouter ดังนั้นต้องทำการ Export API key ก่อน (ห้ามบันทึก Key ไว้ในไฟล์คอนฟิกโดยตรงเพื่อความปลอดภัย):

export OPENROUTER_API_KEY="your-key-here"

ขั้นตอนที่ 2: ทำความเข้าใจการคอนฟิก Switchyard

เริ่มต้นจากการตั้งค่าพื้นฐาน คือการกำหนดเส้นทางแบบสุ่ม (Random routing) ระหว่างสองโมเดล ให้สร้างไฟล์ YAML ชื่อ routes.random.yaml ดังนี้:

defaults:
  base_url: https://openrouter.ai/api/v1
  api_key: ${OPENROUTER_API_KEY}
 
routes:
  ab-test:
    type: random_routing
 
strong:
      model: openai/gpt-4o
 
weak:
      model: openai/gpt-4o-mini
 
strong_probability: 0.3
    rng_seed: 42
    fallback_target_on_evict: weak

ค่า strong_probability: 0.3 หมายความว่าคำขอ 30% จะถูกส่งไปโมเดลตัวแรง (Strong) และอีก 70% จะไปที่โมเดลตัวเล็ก (Weak) แม้จะไม่ใช่การสลับแบบอัจฉริยะ แต่ก็มีประโยชน์มากสำหรับการทำ A/B Test เพื่อทดสอบประสิทธิภาพของ Proxy ก่อนเริ่มใช้งานจริง

ขั้นตอนที่ 3: การเริ่ม Routing Server

รันคำสั่งเพื่อเริ่มทำงาน Switchyard:

switchyard serve \
  -c routes.random.yaml \
  --host 127.0.0.1 \
  --port 4000

ระบบจะทำการตรวจสอบความถูกต้องของไฟล์คอนฟิกทันที หากการตั้งค่าผิดพลาดเซิร์ฟเวอร์จะไม่ทำงาน คุณสามารถตรวจสอบสถานะได้ทาง:

curl -s http://127.0.0.1:4000/health

ผลลัพธ์:

{"status":"ok"}

ขั้นตอนที่ 4: การส่งคำขอผ่าน Router

ทดสอบส่งคำขอโดยใช้รูปแบบที่รองรับ OpenAI:

curl http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"ab-test","messages":[{"role":"user","content":"Explain gradient descent in simple terms."}]}'

สังเกตว่าเราใช้ชื่อโมเดลเป็น "model": "ab-test" ตามที่ตั้งไว้ในไฟล์ YAML จากนั้น Switchyard จะเลือกโมเดลจริงให้เอง ตัวอย่างนี้คำขอถูกส่งไปยังโมเดลราคาประหยัด:

"model": "openai/gpt-4o-mini",
"usage": { "prompt_tokens": 14, "completion_tokens": 247, "cost": 0.0001503 }

ผลลัพธ์ที่ได้: คำอธิบายเรื่อง Gradient Descent ที่ชัดเจนและมีโครงสร้างครบถ้วน แม้จะใช้โมเดลขนาดเล็กประมวลผลก็ตาม

ขั้นตอนที่ 5: การอัปเกรดเป็นการกำหนดเส้นทางอัจฉริยะ เพื่อให้เกิดความคุ้มค่าสูงสุด เราควรส่งคำของ่ายๆ ไปยังโมเดลราคาถูก และเก็บงานยากไว้ให้โมเดลประสิทธิภาพสูง Switchyard มีฟีเจอร์ classifier เพื่อการนี้โดยเฉพาะ ให้สร้างไฟล์ routes.smart.yaml ดังนี้:

defaults:
  base_url: https://openrouter.ai/api/v1
  api_key: ${OPENROUTER_API_KEY}
 
routes:
  smart:
    type: deterministic
 
classifier:
      model: openai/gpt-4o-mini
 
strong:
      model: openai/gpt-4o
 
weak:
      model: openai/gpt-4o-mini
 
profile: general
    session_affinity: true
    fallback_target_on_evict: weak

ระบบจะทำงานโดยให้ Classifier ประเมินค่า p_solve หรือความน่าจะเป็นที่โมเดลตัวเล็กจะแก้ปัญหานั้นได้สำเร็จ หากประเมินแล้วว่าไหวก็จะส่งไปที่ Weak Model แต่ถ้างานดูหินเกินไปก็จะส่งต่อให้ Strong Model ทันที

ขั้นตอนที่ 6: ทดสอบ Smart Route

เมื่อทดสอบด้วยคำถามคณิตศาสตร์ง่ายๆ อย่าง "15% ของ 200 คืออะไร?" ผลลัพธ์จะถูกประมวลผลผ่านโมเดลประหยัด แต่ถ้าเป็นโจทย์โปรแกรมมิ่งเชิงลึก เช่น การแก้ปัญหา Race Condition ใน Redis ระบบจะเลือกใช้โมเดลตัวท็อปแทน

จากการทดสอบเปรียบเทียบ:

วิธีการนี้ช่วยให้คุณไม่ต้องระบุชื่อโมเดลแบบ Hard-code ในระบบ แต่ปล่อยให้ตัวจำแนกประเภทเป็นผู้ตัดสินใจตามความเหมาะสมของเนื้อหา

ขั้นตอนที่ 7: การกำหนดเส้นทาง Coding Agent ตามความคืบหน้า

สำหรับ Coding Agent ที่ต้องทำงานหลายขั้นตอน (Multi-turn) การใช้โมเดลตัวแรงทุกขั้นตอนเป็นเรื่องสิ้นเปลือง Switchyard จึงมี stage_router ที่วิเคราะห์จากสัญญาณการสนทนาและผลลัพธ์ของเครื่องมือ เพื่อเลือกระหว่างความสามารถสูง (Capable) หรือเน้นประหยัด (Efficient)

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

ขั้นตอนที่ 8: ยกระดับเฉพาะหลังจากที่โมเดลแบบ Weak เริ่มมีปัญหา

อีกหนึ่งกลยุทธ์คือ Escalation Routing ซึ่งแตกต่างจากการทำนายความยากล่วงหน้า แต่วิธีนี้จะปล่อยให้โมเดลราคาถูกลองทำไปก่อน หากผลลัพธ์ที่ได้ (ตรวจสอบโดย Judge Model) พบว่ามีปัญหาต่อเนื่อง จึงค่อยสลับไปใช้โมเดลระดับสูง

วิธีนี้เหมาะอย่างยิ่งสำหรับเซสชันของ Agent ที่ทำงานต่อเนื่องยาวนาน เพราะความยากของงานในแต่ละขั้นตอนอาจเปลี่ยนแปลงได้ตลอดเวลา ช่วยให้ประหยัดงบประมาณ Inference ได้มหาศาล

ขั้นตอนที่ 9: การวัดผลว่าการกำหนดเส้นทางช่วยได้จริงหรือไม่

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

ผู้ใช้งานสามารถตรวจสอบสถิติแบบ JSON ได้ทาง:

curl -s http://localhost:4000/v1/stats | python3 -m json.tool

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

บทสรุป

ในยุคที่ระบบ LLM ก้าวสู่การเป็น Agent เต็มตัว การตัดสินใจเลือกใช้โมเดลต้องมีความยืดหยุ่นตามบริบท งบประมาณ และเวลา Switchyard จาก NVIDIA คือเครื่องมือที่จะเปลี่ยนการตัดสินใจเหล่านี้ให้กลายเป็นโครงสร้างพื้นฐานที่จัดการง่าย

คำแนะนำสำหรับผู้เริ่มต้นคือ ให้เริ่มจากการตั้งค่าเราเตอร์สองโมเดลแบบง่ายๆ วัดผลลัพธ์แยกกัน แล้วจึงค่อยขยับไปสู่การกำหนดเส้นทางตามความสามารถ (Capability-based routing) เพื่อหาจุดที่คุ้มค่าที่สุดสำหรับภาระงานจริงของคุณเอง