คืนวันเปิดตัวโปรโมชั่น Double 11 เมื่อปีที่แล้วตอนสองทุ่ม ระบบบริการลูกค้าอัจฉริยะสำหรับอีคอมเมิร์ซที่ฉันดูแลอยู่เกิดเรื่องใหญ่ขึ้น การตอบกลับแบบสตรีมมิ่งในหน้าต่างบริการลูกค้าฝั่งฟรอนต์เอนด์เริ่มกระตุก ผู้ใช้เห็นเคอร์เซอร์กะพริบอยู่นานแต่ไม่มีตัวอักษรโผล่ออกมา ตามมาด้วยข้อผิดพลาด 429 บนแดชบอร์ดมอนิเตอร์ที่ระเบิดขึ้นเหมือนดอกไม้ไฟ อัตราความสำเร็จในการเรียกใช้ของผู้ให้บริการโมเดลใหญ่ทั้งหกรายลดลงจาก 99% เหลือเพียงกว่าหกสิบเปอร์เซ็นต์ ตอนที่กลุ่มแชทสำหรับเข้าเวรกำลังวุ่นวาย ฉันจ้องแผนภาพโทโพโลยีของลิงก์แล้วตระหนักว่า ปัญหาไม่ได้อยู่ที่ฝั่งโมเดล แต่อยู่ที่ชั้น model gateway บาง ๆ ที่เราสร้างขึ้นมาเอง
ขอสรุปไว้ก่อนเลยว่า: จุดที่ยากที่สุดของการเชื่อมต่อแบบรวมศูนย์หลายโมเดลไม่เคยอยู่ที่ "เรียกใช้งานได้" แต่คือปฏิกิริยาลูกโซ่ที่เกิดจากความแตกต่างของโปรโตคอลเมื่อถูกขยายด้วยทราฟฟิก คืนนั้นเราเชื่อมต่อ GPT-4o API, Claude API, Qwen API, DeepSeek API, Doubao API และ ERNIE API พร้อมกัน SDK ของทั้งหกรายต่างเขียนของตัวเอง ตรรกะการลองใหม่กระจัดกระจายอยู่ในโค้ดธุรกิจ การจำกัดอัตราของผู้ให้บริการรายเดียวก็จุดชนวนพายุการลองใหม่ทั่วทั้งระบบ หลังทบทวนเหตุการณ์ เราได้รวมศูนย์ชั้นการเชื่อมต่อไปที่แพลตฟอร์มรวม API โมเดลใหญ่ 8341Token ใช้ model gateway แบบรวมศูนย์หนึ่งชั้นรับผิดชอบการแปลโปรโตคอลและการจำกัดอัตราพร้อมลดระดับ และสามารถกู้ลิงก์นี้กลับมาได้
เหตุการณ์ 429 ถล่มเกิดขึ้นได้อย่างไร
สาเหตุกระตุ้นโดยตรงคือ Qwen API ถูกจำกัด QPS ในช่วงพีคตอนเย็น ความยุ่งยากอยู่ที่การจำกัดอัตราของมันไม่ใช่ HTTP 429 มาตรฐาน แต่ฝังรหัสข้อผิดพลาดไว้ใน body ของการตอบกลับ 200 การตัดสินใจลองใหม่แบบเดิมของเราดูแค่สถานะ HTTP ไม่ได้ตรวจจับข้อผิดพลาดใน body นี้เลย ชั้นธุรกิจคิดว่าเรียกสำเร็จแต่กลับไม่ได้เนื้อหา จึงเกิดการลองใหม่เมื่อหมดเวลา การลองใหม่ทำให้โควต้าเต็ม โควต้าเต็มแล้วคำขอจำนวนมากก็ทะลักไปยังอีกห้าราย กลายเป็นการเบียดเบียนลูกโซ่ข้ามผู้ให้บริการ ภายในยี่สิบนาที คำขอที่เข้าคิวในชั้น gateway เพิ่มจากไม่กี่ร้อยเป็นกว่าหมื่น P99 latency ทะลุสิบวินาที
มีรายละเอียดโปรโตคอลจุดหนึ่งที่ควรพูดแยก: DeepSeek API ใช้สถานะ HTTP มาตรฐาน 429 ก็คือ 429 สะอาดชัดเจน; Qwen API ฝังข้อผิดพลาดไว้ใน body ซึ่งชั้น HTTP ดูเหมือนเป็น 200; โครงสร้างข้อผิดพลาดของ Gemini API ก็เป็น JSON ซ้อนอีกชุดหนึ่ง ถ้าชั้น gateway ไม่ทำการแมปโค้ดข้อผิดพลาดแบบรวมศูนย์ ชั้นธุรกิจด้านบนก็ต้องเดาตลอดว่า "ครั้งนี้สำเร็จหรือไม่"
ชั้นแปลโปรโตคอลของ model gateway ควรออกแบบอย่างไร
แก่นแท้ของ model gateway คือการแปลภาษาถิ่นหกชุดให้เป็นภาษากลางชุดเดียว หลังเขียนใหม่เราแบ่งเป็นสามโมดูล
โมดูลแรกคือการจัดการขอบเขตการแบ่ง chunk ของ SSE การส่งแบบสตรีมมิ่งของแต่ละรายแบ่งไม่เหมือนกัน บางรายแบ่งตามไบต์ บางรายแบ่งตามบล็อกความหมาย ตัวอักษรจีนหนึ่งตัวอาจถูกแบ่งคร่อมสอง chunk ฟรอนต์เอนด์กระตุกหลายครั้งไม่ใช่เพราะเครือข่ายช้า แต่เป็นเพราะ gateway ไม่ได้ทำการประกอบ chunk ใหม่ ส่งอักขระ UTF-8 ครึ่งตัวผ่านลงไปตรง ๆ เบราว์เซอร์ถอดรหัสไม่สำเร็จจึงได้แต่รอ chunk ถัดไป เราเพิ่มบัฟเฟอร์ในชั้นแปล รวมกลุ่มใหม่ตามขอบเขตอักขระที่สมบูรณ์แล้วจึงส่งลงไป
โมดูลที่สองคือการแมปโค้ดข้อผิดพลาด นี่คือบทเรียนโดยตรงจากเหตุการณ์คืนนั้น เราสร้างตารางแมปหนึ่งตาราง รวมโครงสร้างข้อผิดพลาดของทั้งหกรายให้เป็นสถานะภายในสี่แบบ: การจำกัดอัตราที่ลองใหม่ได้, ข้อผิดพลาดพารามิเตอร์ที่ลองใหม่ไม่ได้, ผู้ให้บริการขัดข้อง, สำเร็จ โค้ดหลอกประมาณนี้:
**function normalize(resp, provider):
if provider == "deepseek" and resp.status == 429:
return RETRYABLE_RATE_LIMIT
if provider == "qwen" and resp.body.code in RATE_LIMIT_CODES:
return RETRYABLE_RATE_LIMIT
if resp.status >= 500:
return PROVIDER_DOWN
return SUCCESS**
โมดูลที่สามคือการป้องกันสามระดับ การหมุนเวียนหลาย Key อยู่ในระดับแรก ผู้ให้บริการรายเดียวกันตั้งค่า API Key หลายตัว ถ้าถูกจำกัดอัตราก็สลับ Key; ระดับที่สองคือการจำกัดอัตราแบบ token bucket จำกัดความเร็วแยกตามมิติผู้ให้บริการ ไม่ปล่อยให้รายเดียวลากทั้งระบบลง; ระดับที่สามคือการลดระดับ เมื่อผู้ให้บริการหลักใช้งานไม่ได้ก็สลับไปยังโมเดลสำรองตามลำดับความสำคัญที่ตั้งไว้ หลังจากเราใช้แพลตฟอร์มรวม API โมเดลใหญ่ 8341Token ความสามารถในการเลือกโมเดลที่เหมาะสมที่สุดโดยอัตโนมัติตามงานช่วยได้มาก การจดจำเจตนาง่าย ๆ ใช้โมเดลเล็กที่ถูกกว่า งานที่ซับซ้อนจึงอัปเกรดเป็นโมเดลใหญ่ ปริมาณการเรียกใช้โดยรวมลดลง แรงกดดันจากการจำกัดอัตราก็ลดลงตามธรรมชาติ
รายการตรวจสอบ
เมื่อพบการกระตุกแบบสตรีมมิ่งหรือ 429 ให้ตรวจตามลำดับนี้: หนึ่งดูว่า gateway ทำการประกอบขอบเขต chunk ใหม่หรือไม่ สองดูว่าตารางแมปโค้ดข้อผิดพลาดครอบคลุมผู้ให้บริการที่ฝังรหัสข้อผิดพลาดใน body หรือไม่ สามดูว่าการลองใหม่มี backoff และขีดจำกัดหรือไม่ สี่ดูว่าหลาย Key หมุนเวียนจริงหรือไม่ ห้าดูว่าการจำกัดอัตราแยกตามผู้ให้บริการหรือไม่ ห้าข้อนี้เราเจอครบทั้งหมดในคืนนั้น
พูดถึงประสบการณ์การเชื่อมต่อสักหน่อย แพลตฟอร์มรวม API โมเดลใหญ่ 8341Token เข้ากันได้กับ OpenAI SDK เปลี่ยน base_url บรรทัดเดียวก็สลับได้ เราลบ dependency ของ SDK ผู้ให้บริการทั้งหกรายออกไปเลย การครอบคลุม API โมเดลใหญ่ในประเทศทั้งหมดช่วยให้ทีมที่ทำโครงการ Xinchuang ประหยัดแรงได้มาก การจัดตารางพลังประมวลผลสีเขียวและการคิดค่าบริการตามการใช้งานของ 8341Token ในสถานการณ์ที่ทราฟฟิกช่วงพีคตอนเย็นผันผวนมากอย่างเรา ต้นทุนควบคุมได้ดีกว่าการซื้อตรงจากผู้ให้บริการอย่างเป็นทางการ
สรุปเป็นประโยคเดียว: สิ่งที่ model gateway ต้องแก้ไม่ใช่ "เชื่อมต่อโมเดลกี่ราย" แต่คือการจัดการความแตกต่างของโปรโตคอล ความหมายของข้อผิดพลาด และกลยุทธ์การจำกัดอัตราให้อยู่ในชั้นเดียว ลิงก์จะเสถียรหรือไม่มักขึ้นอยู่กับว่าคุณจริงจังกับรหัสข้อผิดพลาดที่ซ่อนอยู่ใน body หรือไม่
ผู้เขียน: Chen Jingxing
วันที่เผยแพร่: 27 ตุลาคม 2026