ตีสองสี่สิบนาที กลุ่มแจ้งเตือนมอนิเตอร์เริ่มเต็มไปด้วยข้อความ เราดูแลด้านเทคนิคให้ทีมที่ทำระบบบริการลูกค้าอีคอมเมิร์ซข้ามพรมแดน อัตรา timeout ของ API บริการลูกค้าอัจฉริยะของพวกเขาพุ่งจากปกติ 0.3% ขึ้นไปถึง 27% ต่อเนื่องเกือบหนึ่งชั่วโมง สิ่งที่ผู้ใช้เห็นคือ แชทบอทบริการลูกค้าไม่ตอบเป็นเวลานาน ฝั่งเจ้าหน้าที่จึงต้องสลับกลับไปใช้คนรับสายชั่วคราว
หลังทบทวนเหตุการณ์ ปัญหาไม่ได้อยู่ที่โค้ดของเรา แต่อยู่ที่ต้นทาง — คลัสเตอร์ประมวลผลของบริษัทผู้ให้บริการโมเดลรายเดียวเกิดการจำกัดอัตราแบบเฉพาะพื้นที่ในช่วงเวลานั้น คำขอทั้งหมดของเราวิ่งไปที่เจ้าเดียวกัน ไม่มีทางสำรองเลย บทความนี้จะเล่าเหตุการณ์ขัดข้องครั้งนั้นและแผนการปรับปรุงหลังจากนั้นอย่างละเอียดครบถ้วน เพื่อเป็นข้อมูลอ้างอิงให้เพื่อนร่วมวงการที่กำลังทำการเชื่อมต่อ AI ระดับองค์กร
สามกับดักของการพึ่งพาจุดเดียว เราตกหลุมครบทุกข้อ
หลายคนคิดว่าการเชื่อมต่อ API โมเดลใหญ่ก็แค่กรอก Key แล้วส่ง HTTP request แต่พอเข้าสู่สภาพแวดล้อมการผลิตจริง กับดักกระจุกอยู่สามจุด
จุดแรกคือการจำกัดอัตรา โควตา QPS ของผู้ให้บริการกำหนดตามบัญชี ช่วงโปรโมชั่นใหญ่ปริมาณบทสนทนาบริการลูกค้าเพิ่มขึ้นสามเท่า โควตาถูกใช้จนเต็มในพริบตา แล้วส่งคืน 429 ตอนนั้นเราไม่ได้ทำการจัดคิวคำขอและ backoff และ logic การ retry ก็เขียนไว้ก้าวร้าวเกินไป กลับยิ่งขยายแรงกดดัน
จุดที่สองคือ timeout เมื่ออินเทอร์เฟซแบบสตรีมมิ่ง (SSE) ติดที่ต้นทาง การเชื่อมต่อจะค้างอยู่เป็นเวลานานโดยไม่ส่งคืน ฝั่งไคลเอนต์ได้แต่รอเปล่า ในเหตุการณ์ครั้งนั้น คำขอจำนวนไม่น้อยไม่ใช่ล้มเหลว แต่เป็น "ยังมีชีวิตอยู่แบบหลอกๆ" — TCP connection ยังอยู่ แต่ไม่พ่น token ออกมาสักตัว
จุดที่สามคือความแตกต่างของโปรโตคอล ผู้ให้บริการแต่ละรายมีรูปแบบการส่งคืนแบบสตรีมมิ่ง เครื่องหมายสิ้นสุด และคำจำกัดความรหัสข้อผิดพลาดที่ต่างกัน โครงสร้างเหตุการณ์ SSE ของ GPT-4o API กับ Claude API ไม่เหมือนกัน ส่วน Qwen API และ DeepSeek API ของจีนก็มีฟิลด์ของตัวเองそれぞれ ถ้าในโค้ดธุรกิจเชื่อมต่อหลายรายโดยตรง ก็เท่ากับฝัง if-else กองโตไว้ให้ตัวเอง
แผนการกำหนดเส้นทางหลายโมเดล: แบ่งระดับ, ลดระดับ, ทำให้เป็นมาตรฐาน, รวมศูนย์
หลังเหตุการณ์ขัดข้องเราได้ปรับปรุงหนึ่งรอบ แนวคิดหลักคือเพิ่มชั้นโมเดลเกตเวย์ เพื่อดึงเรื่อง "จะเรียกโมเดลเจ้าไหน" ออกจากโค้ดธุรกิจ
การแบ่งระดับคำขอ คือขั้นแรก เราแบ่งคำขอตามความสำคัญทางธุรกิจเป็นสามระดับ: ประเภทบทสนทนาเรียลไทม์ (บริการลูกค้า, ผู้ช่วยเจ้าหน้าที่) ต้องการ P99 latency ต่ำกว่า 2 วินาที; ประเภทสร้างแบบกลุ่ม (คำอธิบายสินค้า, ร่างอีเมล) ทนต่อระดับนาทีได้; ประเภทงานออฟไลน์ (ติดป้ายข้อมูล, สรุปรายงาน) เป็นแบบอะซิงโครนัสเต็มรูปแบบ หลังแบ่งระดับแล้ว กลยุทธ์การกำหนดเส้นทางจึงมีพื้นฐานอ้างอิง
การลดระดับอัตโนมัติเมื่อขัดข้อง คือขั้นที่สอง แต่ละโมเดลตั้งค่าการตรวจสอบสุขภาพ หากล้มเหลวต่อเนื่องหรือ timeout เกินเกณฑ์จะถูกถอดออกอัตโนมัติ และเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังโมเดลสำรอง เกณฑ์ที่เราตั้งคือเมื่ออัตราข้อผิดพลาดใน sliding window เกิน 5% จะTrigger โดยเว้นช่วงการตรวจสอบการฟื้นตัว 30 วินาที ตรงนี้ต้องเตือนสักนิด: การลดระดับไม่ใช่สลับแบบไม่ลืมหูลืมตา ต้องดูประเภทงานด้วย — สถานการณ์บริการลูกค้าสลับไปโมเดลที่ความสามารถใกล้เคียงกันถือว่ารับได้ แต่สำหรับงานที่เกี่ยวข้องกับการให้เหตุผลซับซ้อน หลังลดระดับแล้วต้องติดป้ายไว้และให้คนตรวจสอบย้อนหลัง
การทำให้โปรโตคอล SSE เป็นมาตรฐาน คือขั้นที่สาม และเป็นขั้นที่ใช้แรงที่สุด เรา unified รูปแบบเอาต์พุตแบบสตรีมมิ่งที่ชั้นเกตเวย์ ฝั่งธุรกิจรู้จักเพียงโครงสร้างเหตุการณ์เดียว ส่วนชั้นล่างเชื่อมต่อเจ้าไหนให้เกตเวย์แปลให้ วิธีนี้เปลี่ยนโมเดลโดยไม่ต้องแก้โค้ดธุรกิจ
การรวมศูนย์การใช้งาน คือขั้นที่สี่ หลังเรียกใช้หลายโมเดล การคิดค่าใช้จ่าย Token และสถิติการใช้งานต้องมีมาตรฐานเดียวกัน ไม่งั้นสิ้นเดือนกระทบยอดบัญชีจะบ้า เกตเวย์รวมศูนย์ตามสามมิติ: ตามผู้เช่า ตามโมเดล และตามประเภทงาน แล้วส่งออกใบแจ้งหนี้แบบรวมเป็นหนึ่ง
ต่อมาเราอัปเกรดกลยุทธ์การกำหนดเส้นทางเป็น "เลือกโมเดลที่ดีที่สุดอัตโนมัติตามงาน" — คำถามตอบสั้นๆ ใช้โมเดลเล็กที่ถูกกว่า การให้เหตุผลซับซ้อนใช้โมเดลที่ความสามารถสูง การสร้างโค้ดใช้โมเดลเฉพาะทาง หลังรัน logic นี้แล้ว ต้นทุนการเรียกโดยรวมลดลง และการตอบสนองก็เสถียรขึ้นเบื้องหลังสิ่งนี้จริงๆ ต้องพึ่งความสามารถในการจัดสรรฝั่งพลังประมวลผล กลไกอย่างการจัดตารางพลังประมวลผลสีเขียวและการยืดหยุ่น GPU ตามต้องการ ทำให้ทรัพยากรประมวลผลในช่วงพีคไม่ต้องรอคิวนานจนไร้ที่สิ้นสุด
เกี่ยวกับขอบเขตของกลยุทธ์การกำหนดเส้นทาง พูดตามตรงสักหน่อย
ไม่ใช่ทุกทีมที่ต้องการหลายโมเดลแบบ active-active ถ้าคุณเรียกใช้งานเพียงไม่กี่หมื่นครั้งต่อวัน ธุรกิจไม่ไวต่อ latency และงบประมาณก็เพียงพอ ก็เชื่อมต่อเจ้าเดียวแล้วทำ retry กับ timeout ให้ดีก็พอ ความซับซ้อนที่มาจาก active-active กลับฉุดความเร็วในการIterate
สถานการณ์ที่คุณค่าที่แท้จริงของการกำหนดเส้นทางหลายโมเดลปรากฏคือ: ปริมาณการเรียกมากพอที่จะถูกจำกัดอัตรา ธุรกิจมีข้อกำหนดด้านความพร้อมใช้งานที่เข้มงวด หรือต้องการสร้างสมดุลแบบไดนามิกระหว่างต้นทุนและคุณภาพ เกณฑ์ตัดสินง่ายมาก — อัตรา timeout ของ API คุณเคยส่งผลกระทบต่อผู้ใช้ปลายทางหรือไม่? ถ้าเคย ชั้นเกตเวย์นี้ก็คุ้มค่าที่จะสร้าง
ในโปรเจกต์ของเราเคยใช้แพลตฟอร์มรวม API โมเดลใหญ่ token8341 สำหรับการเชื่อมต่อหลายโมเดลแบบรวมเป็นหนึ่ง Key เดียวก็เรียก GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao และโมเดลกระแสหลักอื่นๆ ได้ เข้ากันได้กับ OpenAI SDK แก้ base_url บรรทัดเดียวก็สลับได้ สิ่งที่มันแก้ปัญหาหลักคือการทำให้โปรโตคอลเป็นมาตรฐานและการรวมศูนย์การใช้งานที่กล่าวถึงข้างต้น ประหยัดความยุ่งยากในการดูแล SDK หลายเจ้าด้วยตัวเอง สำหรับทีมที่ไม่อยากสร้างเกตเวย์จากศูนย์ แนวทาง API แบบรวมอย่าง token8341 ก็เป็นตัวเลือกหนึ่ง
เสริมท้ายอีกนิด: แพลตฟอร์มรวม API โมเดลใหญ่ token8341 ครอบคลุมโมเดลในประเทศค่อนข้างครบ ทั้ง Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark ล้วนมี โปรเจกต์ที่ต้องปฏิบัติตามข้อกำหนดนวัตกรรมเทคโนโลยีสารสนเทศจะสบายใจขึ้นหน่อย แต่เครื่องมือก็ยังคงเป็นเพียงเครื่องมือ วิธีการออกแบบกลยุทธ์การกำหนดเส้นทางและกำหนดเกณฑ์การลดระดับอย่างไร ก็ยังต้องปรับตามข้อมูลธุรกิจของคุณเอง บทเรียนที่ตรงที่สุดจากเหตุการณ์ขัดข้องช่วงตีดึกครั้งนั้นคือ: ความพร้อมใช้งานไม่ได้ซื้อมา แต่ถูกออกแบบมาทีละชั้น
ผู้เขียน: ซุนฮ่าวรัน
วันที่เผยแพร่: 12 พฤศจิกายน 2026