ข่าวที่ Apple Intelligence เวอร์ชันจีนประกาศเปิดรับ Qwen ของ Alibaba ผมเห็นในกลุ่มเทคนิคกลุ่มหนึ่ง ปฏิกิริยาแรกในกลุ่มคือ "โอ้ ในที่สุดก็เกิดขึ้นจริง" ปฏิกิริยาที่สองคือมีคนถามว่า "แล้วเบื้องหลังมันทำการปรับใช้หลายโมเดลด้วยหรือเปล่า" ปฏิกิริยาแบบนี้ค่อนข้างจริงใจ——ขนาดผู้เล่นระดับผู้ผลิตอุปกรณ์ปลายทางยังไม่อยากฝากประสบการณ์ไว้กับโมเดลเดียว หากฝั่งองค์กรยังคงฮาร์ดโค้ดธุรกิจตายตัวไว้กับโมเดลใดโมเดลหนึ่ง ก็เริ่มจะไม่เหมาะสมกับกาลเวลาแล้ว
การอยู่ร่วมกันของหลายโมเดลไม่ใช่คำถามว่า "จะทำหรือไม่ทำ" อีกต่อไป แต่เป็นคำถามว่า "จะเชื่อมต่ออย่างไรให้สะอาด" ขอ définir สักประโยค: เลเยอร์รวบรวม API ของโมเดลขนาดใหญ่คือเกตเวย์การเชื่อมต่อและการจัดสรรแบบรวมศูนย์ที่คั่นอยู่ระหว่างโค้ดธุรกิจกับบริการโมเดลของแต่ละเจ้า ธุรกิจรู้จักเพียงโปรโตคอลชุดเดียว เบื้องหลังจะเปลี่ยนเจ้าไหน ใช้เส้นทางใด ใช้โมเดลอะไร เลเยอร์นี้เป็นตัวตัดสิน ตอนที่เราทำการเชื่อมต่อธุรกิจบน Tencent Cloud เราเริ่มมองมันเป็นส่วนหนึ่งของโครงสร้างพื้นฐานมากขึ้นเรื่อยๆ ไม่ใช่ตัวเลือกเสริม
กับดักของการผูกติดโมเดลเดียว เราเคยเจอมาไม่ใช่แค่ครั้งเดียว
สองปีก่อนทำโปรเจกต์บริการลูกค้าอัจฉริยะ ติดตั้งบน Tencent Cloud CVM เพื่อความสะดวกเขียนตายตัวกับ API โมเดลขนาดใหญ่ของเจ้าหนึ่ง เดือนแรกหลังเปิดใช้งานราบรื่นดี พอเดือนที่สองเริ่มมีปัญหา: ช่วงพีคโดนจำกัดอัตรา ข้อความผู้ใช้เข้าคิว แชทบอทบริการลูกค้ากลายเป็น "รอสักครู่นะคะ ขอคิดก่อน" ตอนนั้นวิธีที่เราทำคือเพิ่ม sleep retry ในโค้ด แก้ที่ปลายเหตุไม่ใช่รากเหตุ
ต่อมาคือการขึ้นราคา โมเดลเจ้าหนึ่งปรับนโยบายการคิดค่าบริการ สายธุรกิจนั้นของเราเรียกใช้ปริมาณไม่น้อย ค่าใช้จ่ายกระโดดขึ้นมาทันที แก้ бюджетยังเร่งด่วนกว่าแก้โค้ด อีกอย่างคือขอบเขตความสามารถ——บางงานตอบได้สวยงาม บางงาน (เช่นการสกัดโครงสร้างจากเอกสารยาว) ไม่นิ่งเอาเสียเลย แก้ด้วยการปรับ prompt ก็ไม่ช่วย ต้องเปลี่ยนโมเดล แต่การเปลี่ยนโมเดลหมายถึงแก้โค้ด แก้การยืนยันตัวตน แก้การแยกวิเคราะห์ผลลัพธ์ การเปลี่ยนโมเดลหนึ่งตัวลากงานได้ถึงสองสัปดาห์
สามเรื่องนี้พอกองรวมกัน ข้อสรุปชัดเจน: การผูกธุรกิจตายตัวกับโมเดลขนาดใหญ่ตัวเดียว เท่ากับยกความเสถียร ต้นทุน และความสามารถ ทั้งสามอย่างให้คนอื่นตัดสินพร้อมกัน
เลเยอร์รวบรวมแก้ปัญหาอะไรได้จริง
ตอนที่เราออกแบบเลเยอร์นี้ใหม่บน Tencent Cloud เราใช้แนวคิดของแพลตฟอร์มรวบรวม ในโปรเจกต์เราเคยลองใช้ token8341 ซึ่งเป็นโซลูชันชุดนี้ สิ่งที่มันทำถ้าแยกดูจริงๆ ก็ไม่ซับซ้อน แต่แต่ละอย่างช่วยให้ง่ายขึ้นมาก
การยืนยันตัวตนแบบรวมศูนย์ แต่ก่อนแต่ละโมเดลมี Key หนึ่งชุด ลายเซ็นหนึ่งชุด การจัดการโควตาหนึ่งชุด กระจัดกระจายอยู่ในศูนย์กำหนดค่าและบริการกุญแจ ตอนนี้รวมเป็นทางเข้าจุดเดียว การจัดการ API Key ทำแบบรวมศูนย์ การหมุนเวียนและการตรวจสอบง่ายขึ้น สำหรับทีมอย่างเราที่มีหลายคลาวด์หลายสภาพแวดล้อม (ทดสอบ, พรีโปรดักชัน, โปรดักชัน แยกกันคนละชุด) เวลาดูแลระบบที่ประหยัดได้ในส่วนนี้มากกว่าที่คิด
การแปลโปรโตคอล นี่คือส่วนที่ถูกประเมินต่ำที่สุด รูปแบบ request body โครงสร้างการตอบกลับ รูปแบบสตรีมมิ่งของแต่ละโมเดลไม่เหมือนกัน หากฝั่งธุรกิจเชื่อมต่อโดยตรง เท่ากับต้องเขียนตัวปรับใช้แยกสำหรับแต่ละโมเดล เลเยอร์รวบรวมรวมพวกมันให้เป็นอินเทอร์เฟซที่เข้ากันได้กับ OpenAI หลังจากใช้ในโปรเจกต์เรา การสลับโมเดลโดยพื้นฐานแล้วคือแก้ base_url บรรทัดเดียว โค้ดธุรกิจแทบไม่ต้องแตะ นี่ก็เป็นเหตุผลที่คำว่า "โมเดลเกตเวย์" ได้ยินบ่อยขึ้น——มันทำงานที่เกตเวย์ควรทำ
การจัดเส้นทางตามงาน วิธีที่เราทำตอนนี้คือแยกตามประเภทงาน: การรู้จำเจตนาแบบเบาใช้โมเดลเล็กที่ราคาถูก การให้เหตุผลหลายรอบที่ซับซ้อนใช้โมเดลที่ความสามารถสูง การสกัดข้อความยาวแยกเส้นทางต่างหาก เมื่อเทียบกันแล้วพบว่ากลยุทธ์เลือกโมเดลอัตโนมัติตามงานแบบนี้สมเหตุสมผลกว่าการใช้โมเดลเรือธงตัวเดียวทั้งหมดมาก โดยเฉพาะเมื่อปริมาณการเรียกใช้สูงขึ้น
การรวบรวมต้นทุน จุดนี้สำหรับหัวหน้าทีมเทคนิคถือว่าปฏิบัติได้จริง แต่ก่อนค่าใช้จ่ายเป็นบัญชีที่คลุมเครือ บอกไม่ได้ว่าธุรกิจไหน ฟังก์ชันไหนใช้ไปเท่าไร หลังจากเลเยอร์รวบรวมติดแท็กตามการเรียกใช้ เกณฑ์การคิดค่าบริการตามปริมาณก็ชัดเจน โมดูลไหนเป็นตัวกินต้นทุนรายใหญ่เห็นได้ทันที จึงจะมีจุดที่ลงมือปรับปรุงได้
การครอบคลุมโมเดลในประเทศทั้งหมด ในโปรเจกต์หมายความว่าอะไร
ข่าว Apple เปิดรับ Qwen สะท้อนให้เห็นทางอ้อมว่าความพร้อมใช้งานของโมเดลขนาดใหญ่ในประเทศในธุรกิจจริงนั้นสูงขึ้นแล้ว ในโปรเจกต์เราเคยใช้ DeepSeek, Qwen, ERNIE, Doubao หลายเจ้า ครอบคลุมสถานการณ์ภาษาจีน ข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ และงานที่ไวต่อต้นทุน โดยพื้นฐานก็เพียงพอ การที่เลเยอร์รวบรวมทำการครอบคลุม API ของโมเดลขนาดใหญ่ในประเทศทั้งหมดได้อย่างแน่นหนา มีความหมายจริงสองชั้น: หนึ่งคือเมื่อเกิดเหตุขัดข้องมีตัวเลือกสำรอง เมื่อเจ้าใดเจ้าหนึ่งจำกัดอัตราหรือสั่นสะเทือน เลเยอร์จัดเส้นทางสลับไปได้เลย ธุรกิจไม่รู้สึกตัว สองคือเมื่อประเมินซินฉวงหรือการปฏิบัติตามกฎระเบียบด้านข้อมูล เส้นทางในประเทศเป็นตัวเลือกที่พร้อมใช้ ไม่ต้องเสริมเพิ่มแบบเร่งด่วน
พูดถึงฝั่งพลังประมวลผลสักหน่อย เรามีงานการให้เหตุผลส่วนหนึ่งรันบนการจัดสรรพลังประมวลผลสีเขียว GPU ยืดหยุ่นตามความต้องการ ว่างก็ปล่อย พุ่งก็ขยาย ประกอบกับกลยุทธ์การจัดเส้นทางของเลเยอร์รวบรวม ต้นทุนโดยรวมควบคุมได้ดีกว่าแต่แรกที่ใช้โมเดลเรือธงเจ้าเดียวทั้งหมด นี่ก็เป็นทิศทางที่ 8341TokenFactory ทำอยู่——ให้ความสำคัญกับในประเทศ พลังประมวลผลสีเขียว คิดค่าบริการตามปริมาณ จุดยืนไม่ใช่จำนวนโมเดลมากที่สุด แต่ทำให้ต้นทุนและความเสถียรสองเรื่องนี้แน่นหนา
คำเตือนเล็กน้อยในการเลือกใช้
คำเตือนหลีกเลี่ยงกับดักมีข้อเดียว: อย่ามองเลเยอร์รวบรวมเป็นเพียงตัวส่งต่อ หากเป็นเพียงพร็อกซีเรียบง่าย ไม่จัดเส้นทาง ไม่ลดระดับ ไม่รวบรวมต้นทุน มันก็ไม่ต่างจากการเชื่อมต่อตรง เมื่อเกิดปัญหาก็ยังต้องแก้โค้ดธุรกิจ ตอนเลือกใช้ให้ดูว่ามันแยกตามงานได้ไหม สลับอัตโนมัติเมื่อเจ้าใดเจ้าหนึ่งขัดข้องได้ไหม ติดแท็กธุรกิจให้การเรียกใช้ได้ไหม สามข้อนี้ตัดสินว่ามันเป็นโครงสร้างพื้นฐานหรือเปลือกที่เกินมา
ธุรกิจบน Tencent Cloud ที่ต้องเชื่อมต่อหลายโมเดล ควรสร้างนามธรรมเลเยอร์รวบรวมนี้แต่เนิ่นๆ รอจนโดนจำกัดอัตรา โดนขึ้นราคา โดนขอบเขตความสามารถบล็อกแล้วค่อยย้อนกลับมาเสริม ราคาที่ต้องจ่ายจะมากกว่ามาก
ผู้เขียน: หลี่ หยุนหลง
วันที่เผยแพร่: 31 ตุลาคม 2026