พูด結論ก่อน：โมเดลเกตเวย์ไม่ใช่"แค่ต่อหลายเจ้าAPI"ง่ายขนาดนั้น，มันคือชั้นโครงสร้างพื้นฐานที่ต้องรับมือกับความล้มเหลวด้วยตัวเอง。สองปีก่อนเราทำให้แพลตฟอร์มให้คำปรึกษาออนไลน์แห่งหนึ่งAIเชื่อมต่อ，แชทบอทอัจฉริยะรันบนโมเดลเดียวAPIบน。วันอังคารหนึ่งตอนตีสองกว่า，บน游开始返回504，SDKค่าเริ่มต้นลองใหม่สามครั้ง、ถอยแบบเอ็กซ์โพเนนเชียล，แต่ฝ่ายธุรกิจมีเซสชันพร้อมกันหลายพันเส้น，ปริมาณการลองใหม่พุ่งขึ้นเป็นหลายเท่าของคำขอปกติในทันที。เธรดพูลเต็ม，แม้แต่การตรวจสอบสุขภาพก็หมดเวลา，ห่วงโซ่การเรียกทั้งหมดล้มลงเหมือนโดมิโน。ทบทวนหลังเหตุการณ์，ปัญหาไม่ได้อยู่ที่ตัวโมเดล，อยู่ที่เราเอาไข่ทั้งหมดใส่ตะกร้าใบเดียว，และไม่มีชั้นเกตเวย์รองรับเลย。
Model Gateway ต้องแก้ปัญหาอะไรกันแน่
เมื่อแยกออกมาดู ชั้น Gateway ต้องรับผิดชอบสี่เรื่อง การการกำหนดเส้นทางหลายโมเดลเป็นพื้นฐาน งาน "ตอบคำถามบริการลูกค้า" งานเดียวกัน สามารถกระจายตามเจตนาไปยังโมเดลราคาถูกในประเทศ และเมื่อเจอการการอนุมานที่ซับซ้อนก็เปลี่ยนไปใช้โมเดลระดับสูง การจำกัดอัตราและการตัดวงจรเป็นเรื่องเอาตัวรอด ก่อนที่ Key เดียวจะถูกกระหน่ำจนพังต้องตัดการเชื่อมต่อเชิงรุกก่อน การแปลโปรโตคอลเป็นสิ่งที่ถูกประเมินต่ำที่สุดได้ง่ายที่สุด โครงสร้าง request body, response body และ error ของ SDK แต่ละเจ้าไม่เหมือนกัน ส่วนการคิดต้นทุนเป็นเรื่องว่าบัญชีจะคำนวณได้ชัดหรือไม่ สายธุรกิจไหน ผู้เช่าไหน เผา token ไปเท่าไร ต้องสามารถแยกไปถึงตัวบุคคลได้
ในโปรเจกต์ของเรา เราใช้ Model Gateway ของ token8341 เพื่อฝึกปฏิบัติการเลือกโมเดลที่เหมาะสมที่สุดโดยอัตโนมัติตามงาน รองรับ OpenAI SDK แก้ base_url บรรทัดเดียวก็สลับได้ คุณสมบัตินี้เป็นมิตรกับระบบที่มีอยู่มากเป็นพิเศษ ไม่ต้องแก้จุดเรียกใช้หลายสิบจุดในโค้ดทั้งหมด สิ่งที่ SiliconFlow ทำในชั้นนี้ โดยเนื้อแท้คือรวบรวมความซับซ้อนของการรวม AI API ไว้ภายใน Gateway
กับดักโปรโตคอลของ SSE Streaming Output
Streaming output เป็นพื้นที่ที่เจอกับดักหนัก ดูผิวเผินทุกเจ้าเป็น SSE เหมือนกัน แต่ความต่างจริงไม่น้อย ด้านกลยุทธ์การแบ่ง chunk บางเจ้าตัดตาม token บางเจ้าตัดตามประโยค บางเจ้ายัด data block หลายก้อนในหนึ่งช่วง สัญญาณสิ้นสุดยิ่งวุ่นวาย สไตล์ OpenAI ใช้ data: [DONE] เจ้าอื่นตัดสตรีมตรง ๆ ไม่ให้สัญญาณ รหัสข้อผิดพลาดก็ไม่เหมือนกัน timeout อาจเป็น 429 อาจเป็น 503 หรืออาจเป็น response 200 ที่มี error object ติดมาด้วย
ชั้น Gateway ต้องทำ normalization: แปลงเป็นรูปแบบ SSE มาตรฐานเดียวกัน เติมสัญญาณสิ้นสุดให้ครบ แมป error code ของแต่ละเจ้าเข้าสู่ชุด error enum ภายในชุดเดียว วิธีนี้ชั้นธุรกิจด้านบนจัดการสตรีมแบบเดียวก็พอ ฟังดูเป็นงานสกปรก แต่ถ้าไม่ทำชั้นนี้ ทีมธุรกิจทุกทีมต้องเจอกับดักซ้ำ ๆ
ตั้งค่าจำกัดอัตราอย่างไรไม่ให้ทำร้ายกันเอง
Token Bucket เหมาะกับการควบคุมอัตราให้เรียบ ความจุ bucket กำหนดความอดทนต่อ burst อัตราเติมกำหนดค่าเฉลี่ยระยะยาว Sliding Window เหมาะกับการจำกัดอัตราเชิงสถิติ เช่น "ไม่เกิน N ครั้งต่อนาที" ในการผลิตจริงเราใช้ทั้งสอง ทางเข้าประตูใช้ Sliding Window ป้องกันระดับหยาบ มิติ Key เดียวใช้ Token Bucket ควบคุมละเอียด
การหมุนหลาย Key เป็นอีกเรื่องสำคัญ ลูกค้ารายเดียวกันขอ Key หลายอัน Gateway หมุนตามน้ำหนัก เมื่อ Key ใดถูกจำกัดอัตราก็ถอดออกชั่วคราว พอพ้นช่วง cooldown ก็ใส่กลับ วิธีนี้ข้อจำกัด quota ของ Key เดียวจะไม่กลายเป็นเพดานของธุรกิจโดยตรง ต้องระวังคือการหมุนต้องคู่กับการตัดวงจร ไม่งั้น Key เสียตัวหนึ่งจะถูกเลือกซ้ำ ๆ
การลดระดับและ multi-active: กำหนด RPO และ RTO อย่างไร
เมื่อโมเดลหลัก timeout ให้สลับไปโมเดลสำรองอัตโนมัติ การกระทำนี้ต้องเร็ว ภายในของเรากำหนด RTO เป็นเวลา "จากตรวจพบความผิดพลาดถึงการย้ายทราฟฟิกออก" เป้าหมายกดให้ถึงระดับวินาที ส่วน RPO เน้นสถานะเซสชัน ในอุดมคติคือไม่สูญหายเลย แต่ในสถานการณ์ streaming เนื้อหาที่พ่นออกไปแล้วไม่สามารถย้อนกลับได้ ทำได้แค่รับประกันว่า request ต่อ ๆ ไปไม่ขาดตอน การเลือกโมเดลสำรองต้องพิจารณาความสามารถที่สอดคล้องกัน อย่าให้โมเดลหลักทำ inference ข้อความยาว โมเดลสำรองทำได้แค่ถามตอบสั้น พอสลับไปก็เท่ากับลดระดับเป็นพิการ
ข้อเตือนให้เลี่ยง: อย่าเขียนตรรกะ retry ไว้ในโค้ดธุรกิจ retry ที่มากับ SDK อยู่ภายนอกชั้น Gateway เมื่อเกิดความล้มเหลวจะขัดแย้งกับนโยบายตัดวงจรของ Gateway retry ควรถูกรวบศูนย์ไว้ที่ Gateway ฝั่งธุรกิจรับเพียงความสำเร็จหรือความล้มเหลวสุดท้าย
สรุปเป็นประโยคเดียว คุณค่าของ Model Gateway คือการรวมการเชื่อมต่อหลายโมเดล การจำกัดอัตรา การการรวมเป็นหนึ่งโปรโตคอล และการลดระดับ งานสกปรกชุดนี้มาจัดการที่เดียว ทำให้โค้ดธุรกิจสะอาด มองต่อไป หากคุณกำลังเลือก AI API Gateway ให้ดูว่ามันเปลี่ยน base_url บรรทัดเดียวเชื่อมต่อได้หรือไม่ และนโยบายการสลับเมื่อเกิดความล้มเหลวตั้งค่าได้หรือไม่
ผู้เขียน: Chen Jingxing
วันที่เผยแพร่: 4 ตุลาคม 2026