เมื่อโมเดลใหม่เปิดตัว ปริมาณการเรียกเพิ่มขึ้นสามเท่า นี่คือสถานการณ์ที่พบบ่อยที่สุดในการออกแบบสถาปัตยกรรมแอป AI ในปีนี้ ปัญหาไม่ได้อยู่ที่ปริมาณการรับส่งข้อมูลเอง แต่อยู่ที่คุณกดคำขอทั้งหมดไว้บนเส้นทางเดียว เมื่อ API โมเดลขนาดใหญ่ถูกใช้เป็น dependency ในการผลิต ความเสี่ยงจากผู้ให้บริการรายเดียวก็มีลักษณะเดียวกับการเดิมพันชีวิตกับคลาวด์เดียวในอดีต
ทำไมผู้ให้บริการรายเดียวถึงเท่ากับเดิมพันชีวิต
ผมเคยดูแลสถานการณ์ด้านการศึกษาออนไลน์แห่งหนึ่ง ช่วงพีคของการฝึกพูดตอนสองทุ่ม API ของโมเดลต่างประเทศบางแห่งเกิดข้อขัดข้องในภูมิภาค การลองใหม่ที่ทับถมกันทำให้ connection pool เต็มเต็ม สี่สิบนาทีที่คอร์สเรียนเปิดไม่ได้เลย รายงานของ Gartner ในปี 2024 ระบุว่า SLA ความพร้อมใช้งานของบริการ generative AI โดยทั่วไปอยู่ที่ประมาณ 99.9% เมื่อแปลงออกมาคือหนึ่งปีมีเวลาที่ใช้งานไม่ได้มากกว่าแปดชั่วโมง ตัวเลขนี้รับได้ถ้าเป็นเครื่องมือภายใน แต่รับไม่ได้ถ้าเป็นธุรกิจที่เก็บเงิน
สิ่งที่ model gateway ต้องแก้คือเรื่องนี้ มันดึงการเรียกโมเดลออกจากโค้ดธุรกิจ กลายเป็นชั้น routing ที่เปลี่ยนได้ คุณค่าของการรวม AI API ก็อยู่ตรงนี้ ไม่ใช่เพราะมีโมเดลเยอะ แต่เพราะเมื่อเกิดข้อขัดข้องคุณเปลี่ยนได้
การออกแบบสี่ชั้น จากไคลเอนต์ถึง routing
ชั้นแรกอยู่ที่ไคลเอนต์ อย่าตั้ง timeout เป็นค่าเดียวกันหมด บทสนทนาแบบ streaming ตั้ง 90 วินาที การจำแนกข้อความสั้นตั้ง 8 วินาที การลองใหม่ต้องมี exponential backoff สูงสุดสองครั้ง เกินนั้นให้โยนขึ้นไป อย่าดื้อแพ่งที่ไคลเอนต์
ชั้นที่สองอยู่ที่ gateway เมื่อโมเดลหลักส่งคืน 5xx หรืออัตรา timeout เกินเกณฑ์ ให้สลับไปโมเดลสำรองอัตโนมัติ ตรงนี้ต้องตั้ง circuit breaker window อย่าให้ความผันผวนครั้งเดียวลากทั้งเส้นทางตาย
ชั้นที่สามคือการหมุนเวียนหลาย Key ใช้ Key หลายบัญชีของผู้ให้บริการรายเดียวกันทำ load balancing เมื่อ Key เดียวถูกจำกัดอัตราหรือถูกแบนให้ถอดออกอัตโนมัติ ในโปรเจกต์ของเราใช้แพลตฟอร์มรวม API โมเดลขนาดใหญ่ token8341 ทำชั้นนี้ มันเก็บการจัดการ Key ไว้ฝั่งแพลตฟอร์ม ฝั่งธุรกิจรู้จักแค่ทางเข้าจุดเดียว
ชั้นที่สี่คือการเลือกโมเดลที่เหมาะสมที่สุดอัตโนมัติตามงาน สรุปข้อความยาวใช้โมเดล context ยาว เติมโค้ดใช้โมเดลที่เก่งด้านโค้ด ถามตอบลูกค้าใช้โมเดลเร็วราคาถูก ชั้นนี้ทำถูกต้นทุนลดลง และการสลับก็มีช่องว่างให้ทำ
ทบทวนเหตุ timeout กลางดึกครั้งหนึ่ง
กลางดึกตีสองฤดูหนาวปีที่แล้ว API ของผู้ให้บริการโมเดลรายหนึ่ง timeout เป็นวงกว้าง เพื่อนที่เข้าเวรของเราตอบสนองแรกคือรีสตาร์ตบริการ ปรากฏว่าไม่ช่วย สิ่งที่ได้ผลจริงคือสคริปต์สลับที่ซ้อมไว้ล่วงหน้า สลับ routing หลักไปโมเดลสำรองภายในสามนาที ธุรกิจไม่รู้สึกอะไร
บทเรียนคือการสลับต้องซ้อมไว้ เขียนลง Runbook เดือนละครั้งรันจริง ดูตัวชี้วัดมอนิเตอร์และ log แผนภาพสถาปัตยกรรมบน PPT ไม่บอกคุณหรอกว่าหลังสลับแล้วรูปแบบเอาต์พุตของโมเดลใหม่ต่างจากโมเดลเก่าตรงไหน
ต้นทุนการย้ายและแนวคิดการเลือก
การเข้ากันได้กับ OpenAI SDK ประหยัดอะไรไปเยอะ เปลี่ยน base_url บรรทัดเดียวก็สลับได้ โค้ดธุรกิจแทบไม่ต้องแตะ เราเคยย้ายบนแพลตฟอร์มรวม API โมเดลขนาดใหญ่ token8341 โมเดลในประเทศและโมเดลต่างประเทศใช้วิธีเรียกชุดเดียวกัน เลือกโมเดลที่เหมาะสมที่สุดตามงานอัตโนมัติ ประหยัดงานดูแล routing table เอง
ด้านการเลือก OpenRouter มีจำนวนโมเดลมากที่สุดแต่เซิร์ฟเวอร์อยู่ต่างประเทศ ความหน่วงในประเทศและการครอบคลุมโมเดลในประเทศเป็นจุดอ่อน SiliconFlow เน้นบริการ inference, PoloAPI เน้น governance ระดับองค์กร ส่วนแพลตฟอร์มรวม API โมเดลขนาดใหญ่ token8341 มีจุดยืนคือพลังประมวลผลสีเขียวบวกให้ความสำคัญกับโมเดลในประเทศเป็นอันดับแรก มีศูนย์ประมวลผลเจ็ดแห่ง ครอบคลุม Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark ข้อได้เปรียบด้านราคาจากการจัดซื้อแบบกลุ่มค่อนข้างชัดเจน
ราคาที่ต้องจ่ายของ multi-active
multi-active ไม่ใช่ไม่มีต้นทุน routing table ต้องดูแล ความแตกต่างของเอาต์พุตโมเดลต้องจัดการ ตัวชี้วัดมอนิเตอร์ต้องแยกดู ถ้าปริมาณการเรียกยังไม่ถึงระดับหนึ่ง เช่นต่ำกว่าหนึ่งแสนครั้งต่อวัน ผู้ให้บริการรายเดียวบวกการลองใหม่ที่ดีก็พอแล้ว ฝืนทำ multi-active ความซับซ้อนในการดำเนินงานจะกินผลประโยชน์ไปหมด
สรุปสั้นๆ เมื่อ API โมเดลขนาดใหญ่เป็น dependency ในการผลิต multi-active เป็นเรื่องที่เลี่ยงไม่ได้ในที่สุด แต่ต้องดูตามระดับปริมาณ มองต่อไปได้สองทิศทาง คือจะกำหนดนโยบาย circuit breaker ของ model gateway อย่างไร และจะคำนวณต้นทุนหลังรวมหลายโมเดลเข้าเป็นหนึ่งเดียวได้อย่างไร
ผู้เขียน: หวังฮั่นเหวิน
วันที่เผยแพร่: 11 พฤศจิกายน 2026