Google เปิด model routing ใน API Gateway — ยิง OpenAI-compatible ครั้งเดียวไปได้ทั้ง Gemini, Claude, GPT-OSS แต่มีข้อจำกัดหนึ่งบรรทัดที่เปลี่ยนความหมายของคำว่า 'router' ทั้งหมด

วันที่ 4 สิงหาคม Google ประกาศบน Developers Blog ว่า Cloud API Gateway รองรับ model routing แล้วในสถานะ Public Preview — เขียนโดย Mak Ahmad (Product Manager) และ Sanjay Pujare (Software Engineer)

แนวคิดตรงไปตรงมา: แอปของคุณยิง request รูปแบบ OpenAI-compatible ไปที่ gateway ตัวเดียว จากนั้น gateway จะ แปลง payload เป็น schema ดั้งเดิมของ backend แล้วส่งต่อไปยัง Gemini, Claude หรือ GPT-OSS ตามชื่อโมเดลที่คุณตั้งไว้เอง — โดยแอปไม่ต้องรู้จัก endpoint จริงของใครเลย

Google อธิบายปัญหาที่แก้ไว้ตรง ๆ ว่านักพัฒนา “ต้องการอิสระในการส่ง traffic ไปยังโมเดลที่เหมาะกับงานที่สุด โดยไม่ต้อง hardcode endpoint หรือดูแล proxy โอเพนซอร์สเอง”

กำหนดผ่าน OpenAPI ไม่ใช่โค้ด

การตั้งค่าไม่ได้อยู่ในโค้ดแอปหรือใน console แต่อยู่ในไฟล์ OpenAPI 3.x ผ่าน extension block ใหม่ชื่อ x-google-api-management ซึ่งให้คุณ map ชื่อโมเดลเสมือน ไปยัง backend target จริง พร้อมกำหนด deadline ต่อ route (ตัวอย่างในบทความใช้ 60 วินาที) และตั้ง router หลายตัวสำหรับชุดโมเดลที่ต่างกันได้

โมเดลที่ยกเป็นตัวอย่างคือ gemini-3.5-flash-lite, claude-opus-4-7 และ gpt-oss-120b — ทั้งหมดเป็นโมเดลที่ให้บริการผ่าน Vertex AI

ผลเชิงปฏิบัติคือการเปลี่ยนโมเดลกลายเป็น การ deploy config ไม่ใช่การ deploy โค้ด ทีมที่เคยต้องแก้ client, ทดสอบ, ปล่อยเวอร์ชันใหม่ทุกครั้งที่อยากสลับโมเดล จะแก้ไฟล์ spec แล้ว push ได้เลย

ข้อจำกัดหนึ่งบรรทัดที่ต้องอ่านให้จบ

นี่คือส่วนที่บทความเขียนไว้ชัดและเป็นส่วนที่ควรอ่านก่อนวางแผนสถาปัตยกรรม:

backend ทุกตัวที่อ้างถึงใน router เดียวกัน ต้องอยู่บน host เดียวกัน (เช่น aiplatform.googleapis.com) การ route คือการเลือกโมเดลและ path ที่ต่างกันบน Vertex host เดียวกัน — ไม่ได้ route ข้าม host

แปลว่าสิ่งนี้ไม่ใช่ router ข้ามผู้ให้บริการ คุณไม่สามารถตั้ง router ตัวเดียวที่วิ่งไป Vertex บ้าง ไป api.anthropic.com บ้าง ไป api.openai.com บ้าง ได้ Claude ที่อยู่ในรายการคือ Claude ที่ขายผ่าน Vertex AI ไม่ใช่ Claude จาก Anthropic โดยตรง — เช่นเดียวกับ GPT-OSS ที่เป็นน้ำหนักเปิดของ OpenAI ที่โฮสต์บน Vertex ไม่ใช่ API ของ OpenAI

พูดอีกแบบ: นี่คือ ตัวเลือกโมเดลภายใน Vertex ที่พูดภาษา OpenAI ได้ ซึ่งมีประโยชน์จริงและแก้ปัญหาจริง แต่ไม่ใช่ของแบบเดียวกับ LiteLLM หรือ OpenRouter ที่หลายคนอาจเข้าใจจากคำว่า “unified API”

อีกอย่างที่บทความไม่ได้พูดถึงเลยคือ rate limiting แบบละเอียด, การจัดการ quota, กลไก auth และฝั่ง observability — แม้ตัวประกาศจะบอกว่าใช้ร่วมกับการทำ rate limiting และ token tracking ได้ก็ตาม สำหรับใครที่หวังจะใช้แทน gateway ที่มีอยู่ ควรถามสามข้อนี้กับ Google ก่อน

สำหรับทีมที่ใช้ Gemini Enterprise Agent Platform อยู่แล้ว Google บอกว่าจับคู่กันได้ โดยให้ agent ส่ง egress ผ่าน Agent Gateway เพื่อผ่านชั้น security governance ก่อนแล้วค่อยเข้า API Gateway เพื่อ route ต่อ

มุมมอง AI Curator

น่าสนใจว่าประกาศนี้มาในจังหวะที่ตลาด router กำลังเดินสวนทางกันสองทิศ เมื่อ 2 สิงหาคมเราเพิ่งเขียนถึง Manifest ที่ประกาศเลิกทำ LLM router ของตัวเอง ขณะที่ Cursor เพิ่งเอา router มาขับ Auto mode เมื่อ 22 กรกฎาคม — ตอนนี้ Google เข้ามาอีกราย แต่เข้ามาในฐานะ โครงสร้างพื้นฐาน ไม่ใช่ความฉลาด

ความต่างตรงนี้สำคัญ router ของ Cursor พยายาม “ตัดสินใจแทนคุณ” ว่า request นี้ควรไปโมเดลไหน ส่วนของ Google ไม่ตัดสินใจอะไรเลย — คุณบอกชื่อโมเดล มันแค่พาไปถึงและแปลง schema ให้ ในระยะยาวผมคิดว่าแบบหลังยั่งยืนกว่า เพราะ router ที่ “ฉลาด” ต้องคอยปรับตัวตามโมเดลใหม่ตลอดเวลาและกลายเป็นหนี้ทางเทคนิคเร็วมาก ซึ่งเป็นเหตุผลเดียวกับที่ Manifest ถอย

สำหรับทีมไทยและ SEA มีสองประเด็นที่ควรคิดต่อ

ประเด็นแรก — ข้อจำกัด same-host ทำให้ Vertex กลายเป็นกำแพงล็อกอิน (lock-in) ที่นุ่มนวลกว่าเดิม ถ้าคุณย้ายไปใช้ gateway นี้เพื่อ “จะได้ไม่ต้องผูกกับโมเดลไหน” คุณกำลังแลกการผูกกับโมเดลไปเป็นการผูกกับ Vertex แทน มันเป็นการแลกที่สมเหตุสมผลถ้าทั้ง stack คุณอยู่บน Google Cloud อยู่แล้ว แต่ถ้าเหตุผลที่คุณอยากได้ router ตั้งแต่แรกคือ “อยากมีทางหนี” ของชิ้นนี้ไม่ได้ให้ทางหนีนั้น

ประเด็นที่สอง — ที่ตั้ง region ยังเป็นคำถามค้าง ประโยชน์ที่แท้จริงของการ route ระดับ config สำหรับองค์กรไทยคือการเลือกโมเดลตามข้อกำหนดเรื่องที่เก็บข้อมูล เช่นส่งงานที่มีข้อมูลส่วนบุคคลไปโมเดลใน region หนึ่ง ส่งงานทั่วไปไปอีก region หนึ่ง แต่บทความไม่ได้อธิบายเรื่อง region เลย และรายชื่อ backend ในตัวอย่างชี้ไปที่ host เดียวกันหมด ใครที่วางแผนใช้ท่านี้เพื่อรองรับ PDPA ควรทดสอบ region-pinning จริงในช่วง Preview ก่อนออกแบบระบบรอบมัน

ของยังอยู่ในสถานะ Public Preview และ Google ไม่ประกาศราคา — สองข้อนี้รวมกันแปลว่ายังไม่ควรเอาไปวางบนเส้นทางที่ขาดไม่ได้ของ production

แหล่งข่าว

• A unified API for AI model routing — Google Developers Blog
• Google Cloud API Gateway
• Manifest ประกาศเลิกทำ LLM router — blog.jjannet.com