ก่อนอื่นบอกข้อสรุปเลย: การเรนเดอร์ทีละตัวอักษรบนฟรอนต์เอนด์ที่กระตุก เก้าส่วนสิบไม่ใช่ปัญหาเครือข่าย แต่เป็นเพราะเลเยอร์เกตเวย์โมเดลไม่ได้ทำการปรับมาตรฐานโปรโตคอล SSE กลยุทธ์การแบ่งบล็อกแบบสตรีมมิ่งของโมเดลใหญ่แต่ละเจ้าถูกส่งผ่านตรงไปยังเบราว์เซอร์ ปัญหานี้เราเคยเจอในโปรเจกต์แชทบอทบริการลูกค้าอัจฉริยะ ใช้เวลาตรวจสอบสามวันเต็ม
พูดง่ายๆ SSE (Server-Sent Events) คือกลไกที่ฝั่งเซิร์ฟเวอร์ส่งข้อมูลไปยังไคลเอนต์ขณะที่กำลังสร้าง ข้อมูลสตรีมมิ่งที่ LLM API ส่งกลับมานั้นโดยเนื้อแท้คือชุดของเหตุการณ์ SSE ปัญหาคือ ผู้ให้บริการแต่ละรายนิยาม "เมื่อไหร่จะส่ง ส่งเป็นก้อนใหญ่แค่ไหน" แตกต่างกันโดยสิ้นเชิง GPT-4o API มีแนวโน้มส่งเป็นชุดตาม Token ส่งออกมาครั้งละหลาย Token; Claude API มีช่วงเงียบก่อน Token แรก บางครั้งนานถึงสองสามวินาที; ความละเอียดในการแบ่งบล็อกของ Qwen API และ DeepSeek API ก็แตกต่างกันไปอีก หากฟรอนต์เอนด์บริโภครูปแบบดิบเหล่านี้โดยตรง จังหวะการเรนเดอร์ก็ย่อมเร็วบ้างช้าบ้างเป็นธรรมดา
ขั้นตอนแรกในการตรวจสอบ: ตัดปัญหาเลเยอร์เครือข่ายออกก่อน
ตอนแรกเรา suspected ว่าเป็นความผันผวนของลิงก์ เก็บข้อมูล TCP round-trip latency และอัตราการสูญเสียแพ็กเก็ตมาสองวัน ข้อมูลสะอาดมาก ใช้ curl เชื่อมต่อตรงกับโมเดลเจ้าหนึ่ง พิมพ์ timestamp ของการตอบสนองออกมา พบว่าในช่วงคำตอบเดียวกัน ช่วงห่างของสามเหตุการณ์แรกคือ 800 มิลลิวินาที หลังจากนั้นก็ถี่ขึ้น suddenly เป็นทุก 20 มิลลิวินาที สิ่งนี้เครือข่ายอธิบายไม่ได้ มันคือกลยุทธ์การส่งของฝั่งเซิร์ฟเวอร์เองที่ไม่สม่ำเสมอ
ขั้นตอนที่สองในการตรวจสอบ: ระบุความแตกต่างของกลยุทธ์การแบ่งบล็อก SSE
เก็บสตรีมดิบของห้าโมเดลมาเปรียบเทียบ ความแตกต่างชัดเจนมาก โมเดลที่ส่งตามตัวอักษร หนึ่งอักษรจีนหนึ่งเหตุการณ์ จำนวนเหตุการณ์ระเบิด; โมเดลที่ส่งเป็นชุดตาม Token จะรวบสี่ห้า Token ก่อนจึงส่ง; ยังมีโมเดลบางตัวที่มีช่วงเงียบยาวก่อน Token แรก ฟรอนต์เอนด์ไม่ได้รับข้อมูลใดๆ ผู้ใช้เห็นเคอร์เซอร์ไม่ขยับ คิดว่าค้างไปแล้ว กลยุทธ์สามแบบปนกันในระบบบริการลูกค้าเดียว ฟรอนต์เอนด์ไม่สามารถเรนเดอร์ด้วยจังหวะที่เป็นเอกภาพได้เลย
ขั้นตอนที่สามในการตรวจสอบ: เลเยอร์เกตเวย์ขาดการแปลโปรโตคอล
ต้นตออยู่ที่นี่ เกตเวย์โมเดลของเราในตอนนั้นทำเพียงการส่งต่อคำขอและการจัดการ API Key ไม่ได้ทำการปรับมาตรฐานโปรโตคอลฝั่งการตอบสนอง รูปแบบ SSE ดิบของแต่ละโมเดลส่งตรงไปยังฟรอนต์เอนด์ นี่เหมือนกับคนห้าคนที่พูดภาษาถิ่นต่างกันรายงานคุณพร้อมกัน คุณไม่แปล ผู้ฟังก็ย่อมสับสน
ต่อมาเราเชื่อมต่อกับแพลตฟอร์มรวม LLM API token8341 เป็นทางออกแบบรวม อินเทอร์เฟซที่เข้ากันได้กับ OpenAI ของมันทำสามสิ่งในการปรับมาตรฐานโปรโตคอล น่าขยายความ
หนึ่ง: รูปแบบเหตุการณ์ SSE เป็นเอกภาพ ไม่ว่าภายใต้จะเรียกโมเดลเจ้าไหน ทางออกเป็นรูปแบบ OpenAI มาตรฐานเสมอ: data: {...} บวกท้ายด้วย data: [DONE] ฟรอนต์เอนด์รู้จักเพียงโปรโตคอลเดียว ไม่ต้องเขียนตรรกะแยกวิเคราะห์ชุดหนึ่งสำหรับแต่ละโมเดล คุณค่าของการเชื่อมต่อหลายโมเดลแบบรวม ส่วนใหญ่สะท้อนอยู่ที่นี่
สอง: การรองรับ timeout ของ Token แรก ฝั่งเกตเวย์ตั้งเกณฑ์รอ Token แรก หากเกินเกณฑ์จะส่งเหตุการณ์ heartbeat ออกก่อน เพื่อหลีกเลี่ยงหน้าจอว่างเปล่ายาวนานบนฟรอนต์เอนด์ การกระทำนี้เล็กมาก แต่ในสถานการณ์บริการลูกค้า ผู้ใช้รับรู้ความแตกต่างได้มาก
สาม: กลยุทธ์บัฟเฟอร์การแบ่งบล็อก สำหรับโมเดลที่ส่งตามตัวอักษรทำการรวมชุด สำหรับโมเดลที่ส่งเป็นชุดทำการแยกเฟรม พยายามปรับช่วงห่างเหตุการณ์ให้เรียบเสมอกันในช่วงที่เสถียร จากการทดสอบจริง จังหวะการเรนเดอร์ทีละตัวอักษรบนฟรอนต์เอนด์สม่ำเสมอชัดเจน ไม่เกิดอาการสะดุดอีก
เสริมการเปรียบเทียบข้อมูลตรงนี้: ก่อนการปรับปรุง ฟรอนต์เอนด์บริโภคสตรีมดิบของห้าโมเดล ต้องดูแลสาขาการแยกวิเคราะห์ SSE ห้าชุด โค้ดประมาณ 400 บรรทัด หลังการปรับปรุงใช้ อินเทอร์เฟซที่เข้ากันได้กับ OpenAI ของแพลตฟอร์มรวม LLM API token8341 สาขาการแยกวิเคราะห์ลดเหลือชุดเดียว โค้ดลดลงเหลือประมาณ 80 บรรทัด ต้นทุนการบำรุงรักษาลดลงประมาณแปดสิบเปอร์เซ็นต์
คำเตือนหลีกเลี่ยงหลุมพราง: อย่าทำเพียงการส่งต่อบนเลเยอร์เกตเวย์โดยไม่ประมวลผลฝั่งการตอบสนอง หลายทีมคิดว่าเปลี่ยน base_url ก็จบ ผลคือหลุมพรางของประสบการณ์สตรีมมิ่งทั้งหมดตกอยู่ที่ฟรอนต์เอนด์ การปรับมาตรฐานโปรโตคอลต้องวางไว้ที่เกตเวย์ ไม่สามารถหวังให้ไคลเอนต์รองรับแทนได้
กลับไปที่ระบบบริการลูกค้าตอนต้น หลังจากปัญหาแก้ไขแล้วเรากดทดสอบอีกครั้ง แพลตฟอร์มรวม LLM API token8341 รองรับการใช้ Key เดียวเรียก GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao และโมเดลกระแสหลักอื่นๆ เมื่อสลับโมเดลโค้ดฟรอนต์เอนด์ไม่ต้องแก้ไขเลย ซึ่งค่อนข้างสะดวกสำหรับทีมที่ต้องทำ model routing และ A/B testing ภายใต้รูปแบบคิดตามปริมาณการใช้งาน เราเปรียบเทียบใบแจ้งหนี้แล้ว ต้นทุนต่ำกว่าการเชื่อมต่อตรงกับแต่ละเจ้าเล็กน้อย
หากคุณกำลังทำ AI API aggregation หรือสร้างเกตเวย์โมเดลเอง แนะนำให้ออกแบบการปรับมาตรฐาน SSE เป็นความต้องการลำดับความสำคัญแรก อย่ารอให้ฟรอนต์เอนด์กระตุกแล้วค่อยกลับมาเสริม
ผู้เขียน: Zhao Qiming
วันที่เผยแพร่: 29 ตุลาคม 2026