"ทุกคนกำลังสร้าง LLM router — เราปิดของเราทิ้ง" Manifest เล่าบทเรียน 4 เดือนกับผู้ใช้ 7,000 ราย ว่าทำไมการเลือกโมเดลอัตโนมัติถึงไม่คุ้ม

วันที่ 31 กรกฎาคม 2026 Bruno Perez จาก Manifest (แพลตฟอร์ม LLM gateway โอเพนซอร์ส — observability, auto-fix, รองรับหลายผู้ให้บริการ, ราว 7,344 ดาวบน GitHub) เผยแพร่บทความชื่อตรงไปตรงมาว่า “Everyone is building LLM routers, we deprecated ours”

ไทม์ไลน์สั้น ๆ: Manifest เปิดตัว LLM router เป็นฟีเจอร์หลักของ gateway เมื่อ มีนาคม 2026 โดยหวังลดต้นทุน inference ด้วยการส่ง request ไปยังโมเดลระดับที่เหมาะสมโดยอัตโนมัติ แบ่งเป็นสี่ระดับ — simple, standard, complex, reasoning จากนั้น มิถุนายน ประกาศเลิกทำ และจะ ปิดจริงวันที่ 1 กันยายน หลังผ่านการใช้งานจริงราวสี่เดือนกับ ผู้ใช้คลาวด์ 7,000 ราย

เหตุผลที่บทความให้ไม่ใช่ “ทำไม่ทัน” หรือ “ไม่มีคนใช้” แต่เป็นข้อสรุปเชิงวิศวกรรมสี่ข้อที่น่าสนใจกว่านั้นมาก

หนึ่ง: ความซับซ้อนของงานอ่านไม่ได้จาก prompt

ข้อนี้เป็นแกนกลางของบทความ และประโยคที่สรุปได้ดีที่สุดคือ

“The prompt alone does not contain the whole task; it is just the trigger.”

ตัวอย่างที่ยกมาชัดมาก — prompt ที่ว่า

“evaluate the tests for the repo $GIT_REPO and improve them”

ถ้า $GIT_REPO คือเว็บ HTML5 หน้าเดียว งานนี้ง่ายมาก แต่ถ้าเป็น Linux kernel งานเดียวกันซับซ้อนมหาศาล — และ router ไม่มีทางรู้ตอนที่ต้องตัดสินใจ เพราะข้อมูลที่กำหนดความยากจริง ๆ ยังไม่มีอยู่ตอนนั้น มันจะค่อย ๆ โผล่ออกมาระหว่างที่ agent เรียก tool อ่านไฟล์ และค้นหา

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

สอง: cache ลดต้นทุนได้ดีกว่าการ route

Manifest ระบุตัวเลขที่เป็นหัวใจของข้อโต้แย้งนี้: cache read ถูกกว่า input ที่ไม่ผ่าน cache ระหว่าง 75% ถึง 90%

และ prefix caching ได้ผลดีเป็นพิเศษกับสิ่งที่ระบบ agent มีอยู่แล้วโดยธรรมชาติ — system prompt ยาว ๆ และประวัติการสนทนาที่สะสมขึ้นเรื่อย ๆ ซึ่งเป็นส่วนที่ซ้ำในทุก request

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

สาม-สี่: ความสม่ำเสมอ และต้นทุนของความไม่แน่นอน

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

ข้อสี่คือการคิดบัญชีให้ครบ:

“The amount saved is paid somewhere else, and that cost is harder to estimate”

เงินที่ประหยัดจากการ route ไปโผล่เป็นค่าใช้จ่ายในที่อื่น — ต้องเขียน eval เพิ่มเพื่อตรวจว่าแต่ละเส้นทางยังใช้ได้, ต้องปรับ system prompt ให้ทำงานได้กับหลายโมเดล, ต้องลงทุน observability เพื่อรู้ว่า request ไหนวิ่งไปทางไหนตอนเกิดปัญหา สรุปเป็นประโยคเดียวว่า

“Managing that extra layer of uncertainty can cost more than it saves”

ข้อสรุปของบทความจึงไม่ใช่ “อย่าประหยัดต้นทุน” แต่คือ ให้วิศวกรเลือกโมเดลเองอย่างตั้งใจตามลักษณะงาน แล้วอยู่กับมัน เพื่อแลกความประหยัดส่วนเพิ่มกับความคาดเดาได้

มุมมอง AI Curator

ผมคิดว่าบทความนี้มีค่าเป็นพิเศษเพราะมันคือ หลักฐานเชิงลบที่มาจากคนที่ลงมือทำเองและมีแรงจูงใจจะบอกว่ามันเวิร์ก Manifest ขาย gateway — router คือฟีเจอร์ที่ช่วยขายของพวกเขาโดยตรง การออกมาบอกว่าตัวเองคิดผิดหลังปล่อยไปสี่เดือน มีน้ำหนักกว่าบทความ “10 เหตุผลที่ควรใช้ LLM router” ของคนที่ขาย router อยู่มาก

แต่ผมอยากเถียงเรื่องขอบเขตของข้อสรุปสักหน่อย เพราะบทความนี้กำลังจะถูกอ้างแบบเหมารวมเร็ว ๆ นี้ว่า “LLM router ไม่เวิร์ก”

สิ่งที่ Manifest พิสูจน์จริง ๆ คือ router แบบอ่าน prompt แล้วเดาความยากล่วงหน้า ไม่เวิร์กกับ workload แบบ agent ซึ่งเป็นข้อสรุปที่ผมเห็นด้วยเต็มที่และมีเหตุผลรองรับชัดเจน แต่มันไม่ได้แปลว่าการเลือกโมเดลตามงานทุกรูปแบบไม่มีประโยชน์ งานที่ ขอบเขตปิดและรู้ความยากตั้งแต่ต้นทาง — จัดหมวดหมู่ ticket, สกัดฟิลด์จากเอกสาร, กลั่นกรองเนื้อหา, แปลข้อความสั้น — การส่งไปโมเดลเล็กยังคุ้มมากและไม่มีปัญหาข้อหนึ่งเลย เพราะ prompt คือ งานทั้งหมดจริง ๆ เส้นแบ่งจึงไม่ใช่ “route หรือไม่ route” แต่คือ prompt บอกความยากของงานได้ครบหรือเปล่า ถ้าคำตอบคือใช่ การเลือกโมเดลตามงานยังสมเหตุสมผล ถ้าคำตอบคือไม่ — ซึ่งเป็นกรณีของ agent แทบทั้งหมด — router จะเดาผิดอย่างเป็นระบบ

จุดที่ผมคิดว่าสำคัญที่สุดและถูกพูดถึงน้อยที่สุดคือ ความขัดแย้งระหว่าง routing กับ caching เพราะตัวเลข 75-90% นั้นใหญ่กว่าส่วนต่างราคาระหว่างโมเดลระดับกลางกับระดับบนในหลายกรณี ทีมจำนวนมากในไทยที่กำลังจะสร้าง router เอง ควรเอาเวลานั้นไปทำสามอย่างนี้ก่อน เพราะให้ผลตอบแทนสูงกว่ามากและซับซ้อนน้อยกว่ามาก:

1. จัดโครงสร้าง prompt ให้ cache ติด — ส่วนที่คงที่ (system prompt, คำสั่ง, ตัวอย่าง, schema ของ tool) ต้องอยู่ต้น context และห้ามขยับ ทีมจำนวนมากเผลอแทรกวันเวลาหรือ user id ไว้บรรทัดแรกของ system prompt ซึ่งทำให้ cache พังทุก request โดยไม่รู้ตัว
2. วัดอัตรา cache hit จริงก่อน ค่อยคุยเรื่องเปลี่ยนโมเดล — ถ้ายังต่ำ นั่นคือเงินที่วางอยู่บนโต๊ะรอเก็บ
3. เลือกโมเดลตามชนิดงานอย่างตั้งใจ แล้ว pin ไว้ พร้อมจดเหตุผลกำกับ ไม่ใช่ให้ระบบเดาให้

สำหรับบริบทไทยและ SEA มีมุมที่ผมอยากเพิ่ม: ทีมในภูมิภาคเราอ่อนไหวต่อต้นทุน AI มากกว่าทีมในสหรัฐฯ อย่างมีนัยสำคัญ เพราะงบต่อหัวต่างกันหลายเท่าขณะที่ราคา API เท่ากันทั้งโลก ความอ่อนไหวนี้ทำให้ router ดูน่าดึงดูดเป็นพิเศษ — และนั่นแหละคือกับดัก เพราะต้นทุนที่บทความบอกว่า “ไปโผล่ที่อื่น” คือ เวลาวิศวกร ซึ่งเป็นทรัพยากรที่ทีมเล็กมีน้อยที่สุด การประหยัดค่า token เดือนละไม่กี่พันบาทแล้วต้องแลกกับการดีบักปัญหาที่สืบสาเหตุยากขึ้นมาก เป็นการแลกที่ขาดทุนสำหรับทีมขนาดเล็ก ไม่ใช่กำไร

และข้อสังเกตสุดท้ายที่กว้างกว่าเรื่อง router: การที่ราคา cache read ถูกกว่า 75-90% กำลังเปลี่ยนหลักการออกแบบระบบ AI เงียบ ๆ จาก “ส่ง context ให้น้อยที่สุด” ไปเป็น “ส่ง context ที่เหมือนเดิมให้มากที่สุด” สองอย่างนี้ให้คำแนะนำที่ต่างกันคนละทาง และทีมที่ยังออกแบบตามหลักการแรกอยู่ กำลังจ่ายแพงกว่าโดยไม่จำเป็น

แหล่งข่าว

• Everyone is building LLM routers, we deprecated ours — Manifest, 31 ก.ค. 2026
• Everyone is building LLM routers, we deprecated ours — Hacker News, 1 ส.ค. 2026