เดือนที่แล้วผมรับโปรเจกต์ smart customer service ซึ่งฝ่ายธุรกิจต้องการเชื่อมต่อโมเดลขนาดใหญ่สามเจ้า ได้แก่ DeepSeek, Qwen และ Doubao พร้อมเหตุผลว่า "เจ้าไหนถูกก็ใช้เจ้านั้น เจ้าไหนติด rate limit ก็สลับไปใช้เจ้าอื่น" ฟังดูสมเหตุสมผล แต่พอลงมือทำจริงถึงพบว่า วิธี authentication, เกณฑ์การคิดค่าบริการ และนโยบาย timeout/retry ของ SDK ทั้งสามเจ้านั้นเป็น logic ที่แตกต่างกันสิ้นเชิง DeepSeek ใช้ Bearer Token, Qwen ใช้ API-KEY ของ DashScope พร้อม signature ส่วนฟิลด์ authentication ของ Doubao ก็แตกต่างออกไปอีก ด้านการคิดค่าบริการ บางเจ้าแยกคิดตาม input/output token บางเจ้ารวมคิดเป็นราคาเดียว และบางเจ้ามีส่วนลดเมื่อ cache hit ส่วน timeout ยิ่งยุ่งยาก เจ้าหนึ่งค่า default 30 วินาที อีกเจ้าหนึ่ง 60 วินาที จำนวนครั้งที่ retry และกลยุทธ์ backoff ต้องเขียนแยกกันหมด
พอเขียนโค้ดไปจนถึงที่สุด ผมนับดูพบว่าชั้น adapter ที่ห่อ client ของทั้งสามเจ้าเพียงอย่างเดียวก็ปาไปกว่า 800 บรรทัดแล้ว ยังไม่รวมการ map error code นี่คือเหตุผลที่แนวคิด model gateway ถูกพูดถึงซ้ำแล้วซ้ำเล่าในวงการ AI engineering ของจีนตั้งแต่ปีที่แล้ว พูดสั้น ๆ คือ: model gateway เป็นชั้นกลางที่ซ่อนความแตกต่างของ API โมเดลขนาดใหญ่หลายเจ้าออกไป และเปิด interface แบบ unified ให้กับชั้น business ด้านบน
เชื่อมต่อตรง สร้างเอง และแพลตฟอร์มรวม — ต้นทุนทางวิศวกรรมของสามทางเลือก
เริ่มจากเชื่อมต่อ SDK ทางการโดยตรง สามโมเดลก็ต้องมีสามชุด authentication สามชุด error handling สามชุด retry logic โค้ด business เต็มไปด้วย if-else เพื่อตัดสินใจว่าจะไปทางเจ้าไหน เพิ่มโมเดลใหม่หนึ่งเจ้า ก็ต้องแก้ adapter หนึ่งรอบ เราคำนวณแล้วว่าโค้ด adapter สำหรับเชื่อมต่อตรงสามเจ้านั้นกินสัดส่วนประมาณ 15% ของงาน backend ทั้งโปรเจกต์ ถ้าจำนวนโมเดลขึ้นไปถึงห้าเจ้าขึ้นไป สัดส่วนนี้จะควบคุมไม่ได้
การสร้าง gateway เองเป็นทางเลือกที่สอง แนวคิดหลักคือเขียน proxy หนึ่งชั้นเอง แล้ว forward request ไปยัง API ของแต่ละเจ้า ข้อดีคือควบคุมได้ ข้อเสียคือต้องจัดการ protocol conversion, การหมุนเวียน key, คิว rate limiting และการเก็บสถิติการใช้งานด้วยตัวเอง เราประเมินภายในแล้วว่า gateway ที่สร้างเองและพร้อมใช้งาน production ต้องใช้วิศวกรอย่างน้อยสองคนทุ่มเวลา 6-8 สัปดาห์ และหลังจากนั้นยังต้องดูแลการเปลี่ยนแปลงเวอร์ชันของ API แต่ละเจ้าอย่างต่อเนื่อง สำหรับทีมขนาดกลางและเล็ก บัญชีนี้ไม่ค่อยคุ้ม
ทางเลือกที่สามคือแพลตฟอร์มรวม AI API แพลตฟอร์มประเภทนี้ห่อ API โมเดลขนาดใหญ่หลายเจ้าไว้ด้วยกัน และเปิด interface ชุดเดียวออกมา ต้นทุนทางวิศวกรรมต่ำที่สุด ระยะเวลาเชื่อมต่อมักนับเป็นวัน ในโปรเจกต์ของเราใช้ SiCore TokenWorks ซึ่งเข้ากันได้กับ OpenAI SDK แก้ base_url บรรทัดเดียวก็สลับได้ จุดที่ต้องระวังคือ：แพลตฟอร์มรวมแต่ละเจ้ามีนโยบาย default เรื่อง timeout และ retry ไม่เหมือนกัน ก่อนเชื่อมต่อต้องยืนยันให้แน่ใจว่าแพลตฟอร์มรองรับการกำหนด timeout เองได้หรือไม่ มิฉะนั้น request ที่ตอบช้าแบบนาน ๆ ครั้งใน production จะถูกชั้นแพลตฟอร์มตัดก่อนกำหนด และข้อความ error ก็ยังดูไม่ออกว่าเป็น gateway timeout หรือ model timeout
สี่ความสามารถหลักของ model gateway
การ normalize protocol เป็นพื้นฐาน ทำให้รูปแบบ request, รูปแบบ response และ error code ของแต่ละเจ้าเป็นมาตรฐานเดียวกัน ในสภาวะอุดมคติ ชั้น business ด้านบนรู้จักรูปแบบ interface เพียงแบบเดียว การสลับโมเดลแก้แค่ config ไม่ต้องแก้โค้ด นี่คือเหตุผลที่ OpenAI-compatible interface ได้รับความนิยมในจีน เพราะเครื่องมือใน ecosystem รองรับรูปแบบนี้แทบทั้งหมด
กลยุทธ์ routing คือคุณค่าของ gateway สามารถ route ตามประเภทงาน เช่นคำถาม-ตอบง่าย ๆ ไป Doubao ส่วนการ inference ซับซ้อนไป DeepSeek หรือ route ตามต้นทุน เจ้าไหนราคาถูกตอนนี้ก็ไปเจ้านั้น หรือ route ตาม availability เมื่อเจ้าใดเจ้าหนึ่งติด rate limit ก็สลับไปใช้ backup อัตโนมัติ ตอนเราทดสอบ multi-model routing ของ SiCore TokenWorks พบว่ากลยุทธ์แบ่งตามความซับซ้อนของงาน ในสถานการณ์ customer service สามารถกดต้นทุนการเรียกใช้โดยรวมลงได้พอสมควร เพราะคำถามง่าย ๆ จำนวนมากไม่จำเป็นต้องเรียกโมเดลที่ความสามารถ inference สูงสุด
การ rate limiting, degradation และการรวมสถิติการใช้งานเป็นความจำเป็นใน production การ rate limiting ต้องรู้จัก error 429 และจัดคิว retry อัตโนมัติ ส่วน degradation ต้องสลับไปโมเดล backup เมื่อบริการเจ้าใดเจ้าหนึ่งใช้งานไม่ได้ สำหรับการรวมสถิติการใช้งานคือการรวบรวมปริมาณการเรียกใช้ การใช้ token และค่าใช้จ่ายที่กระจายอยู่หลายเจ้าไว้ด้วยกัน เพื่อความสะดวกในการคิดต้นทุนและควบคุมงบประมาณ สองส่วนนี้ถ้าสร้างเองงานไม่น้อย โดยเฉพาะการรวมสถิติการใช้งาน เพราะเกณฑ์การคิดค่าบริการของแต่ละเจ้าไม่เหมือนกัน logic การกระทบยอดต้องเขียนแยก
ลงมือเป็นระยะตามความมีความสมบูรณ์ของธุรกิจ
ถ้าโปรเจกต์เพิ่งเริ่ม และเชื่อมต่อโมเดลเจ้าเดียว การเชื่อมต่อ SDK ทางการโดยตรงก็เพียงพอ ไม่จำเป็นต้องใช้ gateway เพราะเพิ่มชั้นเข้ามากลับเพิ่มจุดที่อาจล้มเหลวอีกหนึ่งจุด พอธุรกิจเริ่มนิ่งและต้องเชื่อมต่อโมเดลเจ้าที่สอง ค่อยพิจารณานำชั้น gateway เข้ามา ตอนนั้นต้นทุนการสลับยังต่ำ
ถ้าธุรกิจเชื่อมต่อไปแล้วสามเจ้าขึ้นไป และมีข้อกำหนดด้าน availability แนะนำให้ใช้แพลตฟอร์มรวม AI API ไปเลย เพื่อ outsource ต้นทุนด้าน adapter และ ops ออกไป ตอนเลือกควรดูสามจุดสำคัญ: เข้ากันได้กับ OpenAI SDK หรือไม่, รองรับการกำหนด timeout และ retry เองหรือไม่, สถิติการใช้งานชัดเจนหรือไม่ ส่วนการสร้าง gateway เองนั้น นอกจากจะมีข้อกำหนดด้าน compliance พิเศษหรือทีมมีกำลังคนด้าน ops เพียงพอแล้ว ไม่แนะนำให้ลงทุนในช่วงต้นของธุรกิจ
model gateway แก้ปัญหาความซับซ้อนทางวิศวกรรมของการเชื่อมต่อหลายโมเดล ไม่ใช่ปัญหาความสามารถของโมเดล เลือกแนวทางให้ถูก ทีมก็จะเอาพลังงานกลับไปที่ logic ของธุรกิจได้