Multi-model routing สำหรับ Coding Agent คุ้มค่าจริงหรือ

ผลกระทบของการทำ multi-model routing ต่อ coding agent

Multi-model routing จะส่งแต่ละคำขอไปยังโมเดลที่ราคาถูกที่สุดซึ่งสามารถประมวลผลคำขอนั้นได้ สำหรับการแชททั่วไปวิธีนี้ได้ผลดี แต่สำหรับ coding agent แล้ว วิธีนี้มักจะมีค่าใช้จ่ายสูงกว่าที่ประหยัดได้ เนื่องจากค่าใช้จ่ายส่วนใหญ่ของ agent มาจาก prompt prefix ที่ถูกทำ cache ไว้ในแต่ละโมเดล และการสลับโมเดลจะทำให้ cache ดังกล่าวสูญหายไป

กฎที่บทความนี้เสนอคือ ให้ทำ routing ข้ามผู้ให้บริการเพื่อความพร้อมใช้งาน (availability) ให้ทำ routing ข้ามระดับ (tier) เพื่อประหยัดต้นทุนเฉพาะที่ขอบเขตของงาน (task boundaries) เท่านั้น และให้ตรึงโมเดลไว้หนึ่งตัวต่อหนึ่งเซสชันสำหรับงานที่เป็น agent ทั้งหมด เนื้อหาด้านล่างนี้คือเหตุผลประกอบ

คำศัพท์ 4 คำที่นิยามไว้ดังนี้ router คือตัวเลือกโมเดลต่อหนึ่งคำขอ gateway คือ proxy ที่คำขอวิ่งผ่าน ซึ่งอาจทำหน้าที่ routing หรือไม่ก็ได้ prompt cache คือการที่ผู้ให้บริการจัดเก็บ prefix ของ prompt ที่ประมวลผลแล้วไว้ เพื่อให้คำขอถัดไปที่ใช้ prefix เดิมถูกคิดค่าบริการในราคาเพียงเศษเสี้ยวของราคา input ปกติ KV cache (key value cache) คือแนวคิดเดียวกันที่เกิดขึ้นภายในเซิร์ฟเวอร์ที่คุณดูแลเอง

เหตุใด traffic ของแชทจึงกำหนดเส้นทางได้ดี แต่ traffic ของเอเจนต์กลับทำไม่ได้

คำขอแชทหนึ่งรายการคือการโต้ตอบหนึ่งรอบ โดยจะเข้ามาที่ระบบ ถูกจำแนกประเภท ส่งต่อไปยังโมเดล และส่งผลลัพธ์กลับไป โดยไม่มีข้อมูลใดตกค้างไปยังรอบถัดไป ตัวกำหนดเส้นทาง (router) สามารถส่งคำถามนี้ไปยังโมเดลขนาดเล็ก และส่งคำถามถัดไปไปยังโมเดลขนาดใหญ่ได้ โดยที่คำขอทั้งสองไม่รับรู้ถึงการมีอยู่ของกันและกัน นี่คือภาระงานที่เกณฑ์มาตรฐานการกำหนดเส้นทางเกือบทุกตัวใช้วัดผล และตัวกำหนดเส้นทางที่ดีก็สามารถจัดการส่วนนี้ได้เป็นอย่างดี

รอบการทำงานของเอเจนต์ไม่ใช่คำขอเพียงรายการเดียว คำสั่งเดียวเช่น "แก้ไข test ที่ล้มเหลว" อาจกลายเป็นการเรียก API ถึง 20 ถึง 60 ครั้ง แต่ละครั้งจะส่งบทสนทนาทั้งหมดซ้ำไปใหม่ ไม่ว่าจะเป็น system prompt, นิยามของเครื่องมือทุกตัว, ไฟล์ทุกไฟล์ที่เอเจนต์อ่าน และผลลัพธ์ของคำสั่งทุกอย่างที่เคยเห็น บริบทจะเพิ่มขึ้นเรื่อยๆ เมื่อถึงการเรียกครั้งที่ 30 ส่วนนำ (prefix) ที่ถูกส่งซ้ำอาจมีขนาดหลายหมื่น token ในขณะที่เนื้อหาใหม่จริงๆ ในแต่ละครั้งมีเพียงไม่กี่ร้อย token เท่านั้น

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

แคชของพรอมต์จะแยกตามโมเดล และเอเจนต์จะทำงานอยู่ภายในแคชนั้น

Anthropic กำหนดราคาการอ่านแคชไว้ที่ 0.1 เท่าของราคาอินพุตพื้นฐาน และการเขียนแคชที่มีอายุ 5 นาทีไว้ที่ 1.25 เท่า นี่คือราคาตามรายการที่ประกาศไว้ ณ เดือนสิงหาคม 2026

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

ให้เปรียบเทียบข้อมูลชุดที่สองกับชุดแรกโดยดูตามแถวแทนที่จะดูตามคอลัมน์ การอ่านแคชบน Opus 5 มีราคา 0.50 ดอลลาร์ต่อล้านโทเค็น ในขณะที่อินพุตที่ไม่ได้แคชบน Haiku 4.5 ซึ่งเป็นโมเดลที่ราคาถูกที่สุดในรายการ มีราคา 1.00 ดอลลาร์ ดังนั้น การอ่าน prefix ที่อยู่ในแคชบนโมเดลที่แพงที่สุดจึงมีต้นทุนต่อโทเค็นอินพุตถูกกว่าการอ่าน prefix เดียวกันแบบไม่มีแคชบนโมเดลที่ถูกที่สุด

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

แคชจะถูกอ้างอิงด้วยค่าแฮชของ prefix ของพรอมต์ และแยกตามโมเดล คำขอไปยังโมเดลอื่นจะถูกนำไปตรวจสอบกับที่เก็บข้อมูลที่ไม่เคยพบค่าแฮชนั้นมาก่อน จึงไม่พบข้อมูลและต้องจ่ายราคาเต็ม นอกจากนี้ แคชยังมีลักษณะเป็นลำดับชั้น โดยเริ่มจากเครื่องมือ (tools) ตามด้วยระบบ (system) และข้อความ (messages) การเปลี่ยนแปลงในระดับใดก็ตามจะทำให้ระดับนั้นและข้อมูลทั้งหมดที่ตามมาเป็นโมฆะ ซึ่งหมายความว่าการแก้ไขคำจำกัดความของเครื่องมือเพียงรายการเดียวจะทำให้แคชของพรอมต์ระบบที่อยู่เบื้องหลังถูกยกเลิกไปด้วย เอเจนต์ที่ลงทะเบียนเครื่องมือในขณะรันไทม์จะประสบปัญหานี้โดยไม่ต้องผ่านตัวจัดเส้นทางเลย

ต้นทุนที่แท้จริงของการสลับโมเดลระหว่างเซสชัน

พิจารณาเซสชันที่มี stable prefix ขนาด 40,000 token ซึ่งเป็นขนาดปกติเมื่อเอเจนต์อ่านไฟล์ไปแล้วจำนวนหนึ่ง ด้านล่างนี้คือต้นทุน prefix ของการโต้ตอบหนึ่งครั้ง โดยคำนวณจากราคาตามรายการข้างต้น

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

การใช้งาน Opus 5 ต่อไปโดยใช้ warm cache จะมีค่าใช้จ่าย 0.020 ดอลลาร์สำหรับ prefix ในการโต้ตอบนั้น การโต้ตอบครั้งแรกหลังจากสลับลงไปใช้ Sonnet 5 จะมีค่าใช้จ่าย 0.100 ดอลลาร์ เนื่องจาก Sonnet ไม่มีข้อมูลของ prefix นี้และจำเป็นต้องเขียนข้อมูลใหม่ การสลับกลับมาที่ Opus 5 จะมีค่าใช้จ่าย 0.250 ดอลลาร์ เนื่องจากข้อมูลเดิมหมดอายุไปแล้วในระหว่างที่เซสชันไม่ได้ใช้งาน

ดังนั้น การสลับไปและกลับจะต้องจ่ายค่า cache write สองครั้งเพื่อหลีกเลี่ยงค่า cache read สองครั้ง ในทางกลับกัน การสลับนี้ทำให้ได้ output หนึ่งครั้งในราคาของ Sonnet แทนที่จะเป็นราคาของ Opus รายละเอียดในส่วนขยายด้านล่างแสดงการคำนวณตลอดทั้งกระบวนการ: เงินที่ประหยัดได้มีมูลค่าเพียงเศษเสี้ยวของเซนต์ ในขณะที่ค่าปรับจาก cache อยู่ที่หลักสิบเซนต์ ค่าปรับนี้สูงกว่าเงินที่ประหยัดได้มากกว่าหนึ่งลำดับขั้น และจะเพิ่มขึ้นตามความยาวของ prefix ในขณะที่เงินที่ประหยัดได้นั้นไม่เพิ่มขึ้น

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

รูปแบบการเรียกใช้เครื่องมือ (Tool call) ของแต่ละผู้ให้บริการไม่เหมือนกัน

เอเจนต์ทำงานในรูปแบบลูปการเรียกใช้เครื่องมือ ดังนั้นรูปแบบของ tool call จึงมีความสำคัญในระดับที่ไม่เคยเกิดขึ้นมาก่อนในการแชททั่วไป Messages API ของ Anthropic จะส่งคืนบล็อกเนื้อหา tool_use และคาดหวังบล็อก tool_result กลับมา ในขณะที่ API ที่รองรับ OpenAI จะส่งคืนอาร์เรย์ tool_calls ซึ่ง function.arguments จะเป็น สตริง ที่เข้ารหัส JSON แทนที่จะเป็นออบเจกต์ซ้อนกัน เกตเวย์จะทำหน้าที่แปลข้อมูลระหว่างสองรูปแบบนี้ ซึ่งสำหรับการเรียกใช้งานทั่วไปการแปลข้อมูลจะทำได้อย่างราบรื่น

ปัญหาจะปรากฏขึ้นที่จุดขอบเขตของการทำงาน การเรียกใช้เครื่องมือแบบขนาน (Parallel tool calls) ซึ่งโมเดลส่งคำสั่งหลายรายการในการตอบกลับครั้งเดียว จะถูกนำเสนอในรูปแบบที่ต่างกันและไม่ได้รับการรองรับเหมือนกันในทุกที่ การบังคับใช้สคีมาอย่างเคร่งครัด (Strict schema enforcement) เป็นฟีเจอร์เฉพาะของผู้ให้บริการ ดังนั้นโมเดลที่รับประกันอาร์กิวเมนต์ที่ถูกต้องตามสคีมาบน endpoint หนึ่ง อาจมีแนวโน้มที่จะสร้างอาร์กิวเมนต์ที่ถูกต้องเพียงบางส่วนบนอีก endpoint หนึ่ง เอเจนต์จะมองเห็นความแตกต่างนี้เป็นผลลัพธ์ของเครื่องมือที่แจ้งว่าเกิดข้อผิดพลาดในการแยกวิเคราะห์ (parse error) ซึ่งเอเจนต์จะพยายามแก้ไขโดยใช้รอบการทำงานเพิ่มอีกหนึ่งรอบ รอบการแก้ไขเหล่านี้จะถูกเรียกเก็บเงินในราคาเต็มของ prefix ดังนั้นความไม่เข้ากันของรูปแบบจึงปรากฏให้เห็นทั้งในใบแจ้งหนี้และในบันทึกการสนทนา

endpoint ที่โฮสต์เองจำเป็นต้องมีการกำหนดค่านี้อย่างชัดเจน เซิร์ฟเวอร์ที่รองรับ OpenAI ของ vLLM ต้องการ --enable-auto-tool-choice ร่วมกับ --tool-call-parser ที่จับคู่กับตระกูลโมเดล (hermes, mistral, llama3_json และอื่นๆ) รวมถึงเทมเพลตการแชทที่จัดการข้อความในบทบาทเครื่องมือ เอกสารของ vLLM ระบุไว้อย่างชัดเจนเกี่ยวกับข้อจำกัดของแนวทางนี้: ด้วย tool_choice="auto" และไม่มีการบังคับใช้สคีมาที่เคร่งครัด vLLM จะดึงข้อมูล tool call ออกจากข้อความดิบ ดังนั้นอาร์กิวเมนต์อาจมีรูปแบบไม่ถูกต้องหรือละเมิดสคีมาพารามิเตอร์ของฟังก์ชันในบางครั้ง การเลือกตัวแยกวิเคราะห์ (parser) ผิดสำหรับโมเดลของคุณถือเป็นข้อผิดพลาดในการกำหนดค่า ซึ่งจะแสดงผลลัพธ์ออกมาในรูปแบบเอเจนต์ที่ไม่สามารถเรียกใช้เครื่องมือได้ ซึ่งเป็นสิ่งที่ควรทราบก่อนที่คุณจะส่ง traffic เข้าไปหา ความแตกต่างระหว่าง Ollama และ vLLM สำหรับการให้บริการโมเดลด้วยตนเอง มีความสำคัญในจุดนี้ เนื่องจากทั้งสองเครื่องมือเปิดให้ใช้งานการเรียกใช้เครื่องมือภายใต้เงื่อนไขที่แตกต่างกัน

การเปลี่ยนพฤติกรรมของระบบสำรองระหว่างทำงานโดยไม่มีการแจ้งเตือน

การกำหนดเส้นทางสำรอง (fallback routing) เป็นฟีเจอร์ที่มักถูกเปิดใช้งานโดยไม่ตั้งใจ เกตเวย์ถูกตั้งค่าให้ลองใช้โมเดลอื่นเมื่อโมเดลแรกส่งค่า rate limit หรือข้อผิดพลาด 5xx กลับมา จากนั้นจะนำโมเดลที่ล้มเหลวไปพักการใช้งาน (cooldown) เป็นเวลาหลายวินาที สำหรับการรับส่งข้อมูลแชททั่วไปวิธีนี้ถือว่าเหมาะสม แต่สำหรับงานของเอเจนต์ที่ใช้เวลานาน หมายความว่างานครึ่งหลังของคุณอาจถูกประมวลผลโดยโมเดลที่คุณไม่ได้เลือกไว้

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

กับดักเดียวกันนี้ยังเกิดขึ้นกับการบีบอัดบริบท (context compression) เอเจนต์จำนวนมากสรุปประวัติการทำงานที่ยาวนานโดยการเรียกใช้โมเดลขนาดเล็ก หากการเรียกนั้นใช้โมเดลที่ต่างออกไปหรือใช้ system prompt ที่แตกต่าง ระบบจะเขียนรายการแคชของตนเองและไม่รีเฟรชแคชของเซสชันหลัก ส่งผลให้การทำงานในรอบถัดไปต้องเสียเวลาประมวลผล prefix ใหม่ทั้งหมด การบีบอัดช่วยประหยัดโทเค็นแต่ทำให้สูญเสียประโยชน์จากแคชไป

ภาระงานในการกำหนดเส้นทาง (Routing overhead) เป็นเรื่องจริง แต่ความหน่วงไม่ใช่จุดที่สร้างปัญหา

Router เพิ่มภาระงานต่อคำขอจริง และควรระบุให้ชัดเจนว่ามากน้อยเพียงใด DigitalOcean รายงานว่าโมเดล Arch-Router ของพวกเขาสามารถประมวลผลความต้องการในการกำหนดเส้นทางได้ในเวลาประมาณ 51 มิลลิวินาที โดยมีความแม่นยำในการกำหนดเส้นทางที่ 93.17% จากการประเมินของพวกเขาเอง ตัวเลขเหล่านี้มาจากผลการวัดและเกณฑ์มาตรฐานของพวกเขา ไม่ใช่ของเราและไม่ใช่ผลลัพธ์ที่เป็นสากล หากพิจารณาตามตัวเลขดังกล่าว ข้อสรุปที่ได้ก็น่าอุ่นใจ กล่าวคือ 51 มิลลิวินาทีจากการเรียกใช้งาน agent 40 ครั้ง เพิ่มเวลาเพียงประมาณ 2 วินาทีให้กับงานที่ใช้เวลาดำเนินการหลายนาที

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

บนเซิร์ฟเวอร์ที่คุณดูแลเอง กฎเดียวกันนี้ก็ยังคงใช้ได้โดยมีพื้นที่ให้ปรับเปลี่ยนน้อยกว่า แคชของ prompt ในระดับท้องถิ่นเทียบเท่ากับการทำ prefix caching ใน KV cache ซึ่งอยู่ในหน่วยความจำ GPU การโฮสต์โมเดลสองตัวบน GPU ตัวเดียวจะแบ่งหน่วยความจำระหว่างโมเดลเหล่านั้น ทำให้แต่ละโมเดลเก็บ KV cache ได้น้อยลงและต้องลบ prefix ทิ้งเร็วขึ้น ดังนั้น การกำหนดเส้นทางระหว่างโมเดลในเครื่องสองตัวจึงอาจลดอัตราการเข้าถึงแคช (cache hit rate) ของทั้งสองโมเดลลงพร้อมกัน หากคุณกำลังประเมินขนาดฮาร์ดแวร์สำหรับงานนี้ การดู หน่วยความจำและ CPU ที่ coding agent จำเป็นต้องใช้จริงบน VPS จะเป็นจุดเริ่มต้นที่มีประโยชน์มากกว่าการพิจารณาเรื่อง Router

กฎการตัดสินใจ

• กำหนดเส้นทางข้ามผู้ให้บริการเพื่อความพร้อมใช้งาน เมื่อทางเลือกอื่นคือคำขอที่ล้มเหลว ค่าใช้จ่ายใดๆ ก็ถือเป็นค่าใช้จ่ายที่คุ้มค่า ให้กำหนด fallback ไปยังโมเดลที่มีรูปแบบการเรียกใช้เครื่องมือ (tool call) เดียวกัน เพื่อให้ลูปการทำงานของ agent ดำเนินต่อไปได้ และบันทึกว่าโมเดลใดเป็นผู้ให้บริการในแต่ละการเรียก
• กำหนดเส้นทางข้ามระดับ (tier) เพื่อประหยัดต้นทุนเฉพาะที่ขอบเขตของงานเท่านั้น การเลือก Haiku สำหรับการเปลี่ยนชื่อไฟล์ และ Opus สำหรับการปรับโครงสร้างโค้ด (refactor) เป็นการตัดสินใจที่ดีหากทำเพียงครั้งเดียวก่อนเริ่มเซสชัน แต่จะเป็นการตัดสินใจที่แย่หากทำในเทิร์นที่ 30 ของเซสชันนั้น
• กำหนดโมเดลเดียวต่อหนึ่งเซสชันสำหรับงานที่เป็น agentic คุณค่าของเซสชันคือ warm cache ของมัน ให้มองว่าการสลับโมเดลเหมือนกับการล้างแคช เพราะนั่นคือสิ่งที่เกิดขึ้นจริง
• กำหนดเส้นทางให้ subagent ได้อย่างอิสระ subagent ที่เริ่มต้นด้วยบริบทใหม่และมีขนาดเล็กจะไม่มี warm cache ให้สูญเสีย จึงสามารถรันบนโมเดลใดก็ได้ที่เหมาะสมกับงาน นี่เป็นจุดเดียวภายใน agent ที่การกำหนดเส้นทางแทบไม่มีต้นทุน

สำหรับการสร้างระบบนี้ gateway จะเป็นผู้จัดการงานทั้งหมด ทั้งการใช้ model aliases และรายการ fallback ที่ชัดเจน ตัวอย่าง config ขั้นต่ำของ LiteLLM proxy มีลักษณะดังนี้

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

ให้ชี้ agent ไปที่ agent-primary แล้วมันจะคงอยู่กับโมเดลนั้นจนกว่าโมเดลดังกล่าวจะไม่สามารถเข้าถึงได้ รายการทั้งสองอยู่ในผู้ให้บริการรายเดียวกัน ดังนั้นรูปแบบการเรียกใช้เครื่องมือจึงไม่เปลี่ยนแปลงเมื่อ fallback ทำงาน คุณยังคงยอมรับการเปลี่ยนระดับ (tier) ในขณะนั้น ซึ่งเป็นการแลกเปลี่ยนที่คุ้มค่าเฉพาะในกรณีที่ทางเลือกอื่นคือคำขอที่ล้มเหลว นี่คือการกำหนดเส้นทางเพื่อความพร้อมใช้งานโดยไม่มีต้นทุนแฝง ซึ่งเป็นรูปแบบที่ coding agent ส่วนใหญ่ต้องการ สำหรับการสร้างระบบเต็มรูปแบบ รวมถึงการจัดการคีย์และงบประมาณ ได้ครอบคลุมไว้ใน การรัน LiteLLM gateway แบบ self-hosted บน VPS ของคุณเอง และบทความนี้จงใจที่จะไม่กล่าวซ้ำในส่วนดังกล่าว

เมื่อโมเดลที่เลือกมาอย่างดีเพียงหนึ่งเดียวเหนือกว่า Router ใดๆ

การทำ Routing เป็นวิธีแก้ปัญหาความแปรปรวนของระดับความยากในคำขอ (request) อย่างไรก็ตาม Coding agent มีความแปรปรวนน้อยกว่าที่เห็น เพราะส่วนที่สิ้นเปลืองของทุกการเรียกใช้คือ prefix ชุดเดียวกัน ไม่ว่าคำขอนั้นจะถามถึงอะไรก็ตาม เมื่อ prefix กลายเป็นส่วนหลักของต้นทุน ความแตกต่างระหว่าง tier ราคาถูกและ tier ราคาแพงจะลดลงจนเหลือเพียงส่วนต่างของราคา output เท่านั้น และ output ก็เป็นเพียงส่วนเล็กน้อยของจำนวน token ทั้งหมดใน agent

ดังนั้น ค่าเริ่มต้นที่ตรงไปตรงมาที่สุดคือการใช้โมเดลเพียงหนึ่งเดียวที่เลือกมาอย่างดี โดยเปิดใช้งาน caching และตั้งค่า TTL (time to live) ให้ยาวนานพอที่จะครอบคลุมช่วงเวลาที่คุณหยุดอ่าน diff Anthropic มีบริการ cache write นาน 1 ชั่วโมงที่ราคา 2 เท่าของ input พื้นฐาน ซึ่งจะคุ้มทุนหลังจากอ่านซ้ำเพียง 2 ครั้ง และนั่นมักจะเป็นกลยุทธ์ที่มีประสิทธิภาพมากกว่าการใช้ Router ใดๆ ให้เลือก tier อย่างตั้งใจโดยใช้ การเปรียบเทียบ Opus, Sonnet และ Haiku โดยตรง และหากค่าใช้จ่ายยังคงเป็นปัญหา ให้ลดต้นทุนด้วยการกำหนดงบประมาณและจำกัด context ให้เล็กลงตามที่ระบุใน การควบคุมค่าใช้จ่าย AI agent บน VPS แทนการสลับโมเดลระหว่างเซสชัน

ให้ใช้การทำ Route เมื่อคำขอมีความเป็นอิสระและสั้น หรือเมื่อ subagent เริ่มต้นด้วย context ใหม่ แต่ให้ตรึงโมเดล (pin) ไว้เมื่อคุณมีเซสชันยาวที่ทำภารกิจเดียว งานส่วนใหญ่ของ Coding agent เป็นแบบหลัง ซึ่งเป็นเหตุผลว่าทำไม Router ที่ช่วยประหยัดเงินในผลิตภัณฑ์แชทของคุณ อาจทำให้คุณเสียเงินเพิ่มขึ้นในกรณีนี้ หากคุณยังไม่ได้ตัดสินใจเลือกตัว agent การเปรียบเทียบ Claude Code กับ Cursor, Codex และ Copilot จะครอบคลุมถึงวิธีการจัดการการเลือกโมเดลของแต่ละตัว ซึ่งบางตัวจะตัดสินใจเรื่องนี้แทนคุณโดยอัตโนมัติ

FAQ

การเปลี่ยนโมเดลระหว่างเซสชันทำให้ prompt cache หายไปจริงหรือไม่?

จริง Prompt cache จะถูกอ้างอิงด้วยค่าแฮชของ prefix ใน prompt และจัดเก็บแยกตามโมเดล ดังนั้นคำขอที่ส่งไปยังโมเดลอื่นจะถูกนำไปตรวจสอบกับที่เก็บข้อมูลที่ไม่เคยเห็น prefix นั้นมาก่อน ระบบจึงไม่พบข้อมูลและต้องเสียค่าใช้จ่ายสำหรับ input เต็มจำนวนโดยไม่ได้รับส่วนลดจาก cache และหากเปิดใช้งานการทำ cache ไว้ก็จะเสียค่าใช้จ่ายในการเขียน cache เพิ่มเติมด้วย การสลับกลับไปใช้โมเดลเดิมก็ไม่สามารถกู้คืนรายการเดิมได้ เนื่องจากโดยปกติแล้วอายุการใช้งานเริ่มต้น 5 นาทีมักจะหมดลงไปแล้ว ให้ตรวจสอบฟิลด์ cache_read_input_tokens และ cache_creation_input_tokens ในออบเจกต์การใช้งาน (usage object) ของการตอบกลับ หากพบว่ารอบการทำงานใดอ่านค่า cached tokens ได้เป็นศูนย์ในเซสชันที่ยาวนาน นั่นคือสัญญาณของปัญหานี้

การส่งคำขอไปยังโมเดลที่ราคาถูกกว่าจะช่วยประหยัดค่าใช้จ่ายสำหรับเอเจนต์ได้จริงหรือไม่?

ประหยัดได้เฉพาะในกรณีที่ไม่มี warm cache ให้สูญเสียเท่านั้น การอ่าน cache บน Anthropic มีค่าใช้จ่าย 0.1 เท่าของราคา input พื้นฐาน ซึ่งทำให้การอ่านข้อมูลที่อยู่ใน cache ของ Opus 5 มีราคาถูกกว่าราคา input แบบไม่ใช้ cache ของ Haiku 4.5 เมื่อเซสชันมี prefix ที่อยู่ใน cache ขนาดใหญ่ โมเดลเดิมที่ใช้งานอยู่จึงกลายเป็นตัวเลือกที่ถูกกว่าในแง่ของ input การส่งคำขอไปยังโมเดลอื่นจะคุ้มค่าก็ต่อเมื่อบริบทข้อมูลยังใหม่และมีขนาดเล็ก เช่น ในช่วงเริ่มต้นของงาน หรือใน subagent ที่พกพาเฉพาะบริบทที่จำเป็นเท่านั้น

เหตุใดเอเจนต์ของฉันจึงมีพฤติกรรมเปลี่ยนไปในระหว่างการทำงาน?

ให้ตรวจสอบว่ามีการทำงานของ gateway fallback หรือไม่ หากเกิดข้อจำกัดด้านอัตราการใช้งาน (rate limit) หรือข้อผิดพลาด 5xx บนโมเดลหลัก เกตเวย์จะลองส่งคำขอใหม่ไปยังโมเดลสำรองและพักการใช้งานโมเดลหลักไว้ชั่วคราว ทำให้ส่วนที่เหลือของงานถูกประมวลผลในโมเดลอื่นแทน เหตุการณ์นี้จะไม่แสดงข้อผิดพลาดหรือคำเตือนใดๆ และงานยังคงรายงานว่าสำเร็จ ฟิลด์ model ใน log ของคำขอเกตเวย์หรือ metadata ของการตอบกลับเป็นบันทึกเดียวที่เชื่อถือได้ ดังนั้นหากคุณมีการตั้งค่า fallback ไว้ ควรบันทึกค่านี้ไว้ในทุกคำขอ

การเรียกใช้เครื่องมือ (tool calls) ทำงานเหมือนกันในทุกผู้ให้บริการหรือไม่?

ไม่เหมือนกันเสียทีเดียว Messages API ของ Anthropic ใช้บล็อกเนื้อหา tool_use และ tool_result ในขณะที่ API ที่รองรับ OpenAI จะใช้ชุดข้อมูล tool_calls ซึ่งมี function.arguments เป็นสตริงที่เข้ารหัสแบบ JSON เกตเวย์สามารถแปลกรณีทั่วไปได้ดี แต่การเรียกใช้เครื่องมือแบบขนาน (parallel tool calls) และการบังคับใช้ schema อย่างเคร่งครัดจะแตกต่างกันไปตามผู้ให้บริการ สำหรับการใช้งาน vLLM แบบ self-hosted คุณต้องตั้งค่า --enable-auto-tool-choice และ --tool-call-parser ให้ตรงกับตระกูลโมเดลของคุณ และเอกสารของ vLLM ระบุว่าหากไม่มีการกำหนดข้อจำกัด schema ที่เข้มงวด เซิร์ฟเวอร์จะดึงข้อมูลการเรียกใช้เครื่องมือจากข้อความดิบ ซึ่งอาจทำให้ argument มีรูปแบบที่ไม่ถูกต้องในบางครั้ง

ฉันควรตั้งค่า cache TTL สำหรับเซสชันการเขียนโค้ดไว้นานเท่าใด?

ให้ใช้อายุการใช้งานเริ่มต้น 5 นาทีสำหรับการทำงานต่อเนื่อง และใช้ตัวเลือก 1 ชั่วโมงเมื่อมีการอ่าน diff ระหว่างรอบการทำงาน Anthropic คิดราคาการเขียน cache แบบ 5 นาทีที่ 1.25 เท่าของ input พื้นฐาน และแบบ 1 ชั่วโมงที่ 2 เท่า โดยมีค่าอ่านอยู่ที่ 0.1 เท่า การเขียนแบบ 5 นาทีจะคุ้มทุนด้วยการอ่านเพียงครั้งเดียว ส่วนการเขียนแบบ 1 ชั่วโมงจะคุ้มทุนด้วยการอ่านสองครั้ง ดังนั้นในเซสชันใดก็ตามที่คุณคาดว่าจะกลับมาทำงานต่อ การตั้งค่าอายุการใช้งานที่นานกว่ามักจะมีค่าใช้จ่ายน้อยกว่าการต้องจ่ายค่า input ใหม่ทั้งหมดเมื่อ cache หายไป