บอกข้อสรุก่อน: บิลเพิ่มขึ้น แปดในสิบไม่ใช่เพราะปริมาณเพิ่มขึ้น ผมเคยทำโปรเจกต์ศูนย์บริการอัจฉริยะ ช่วงครึ่งปีแรกของปีที่แล้วบิลรายเดือนทรงตัวอยู่ที่ประมาณ 8,000 หยวน พอถึงไตรมาสสี่กระโดดไปที่ 23,000 หยวน แต่ในช่วงเดียวกันปริมาณการเรียกใช้เพิ่มขึ้นเพียง 40% เงินที่เพิ่มขึ้นไปไหน? ผมดึงบันทึกการเรียกใช้สามเดือนออกมาจัดกลุ่มตามสี่มิติ คือประเภทงาน ความยาวอินพุต ความยาวเอาต์พุต และจำนวนครั้งที่ลองใหม่ ปัญหาชัดเจนมาก มีหลุมดำต้นทุนแฝงสี่จุดที่กำลังเสียเลือดพร้อมกัน
ขอนิยามก่อน เพื่อไม่ให้คุยกันไม่ตรง later โครงสร้างต้นทุนของ API โมเดลขนาดใหญ่ แท้จริงคือผลรวมของสามส่วน คือ "โทเคนอินพุต + โทเคนเอาต์พุต + โทเคนไร้ประสิทธิภาพที่เกิดจากการลองใหม่เมื่อล้มเหลว" การคิดเงินตามปริมาณเป็นเพียงวิธีคิดราคา มันไม่รับผิดชอบที่จะช่วยคุณประหยัดเงิน สิ่งที่กำหนดบิลจริง ๆ คือกลยุทธ์การกำหนดเส้นทางบนเกตเวย์โมเดลและกลยุทธ์การจัดการบริบท
หลุมดำที่หนึ่ง: โมเดลเรือธงทำงานหยาบ
นี่คือรายการที่แพงที่สุด ในระบบศูนย์บริการนั้นมีงานสามประเภท คือการจำแนกตั๋วงาน การติดป้ายอารมณ์ และการระบุเจตนา วันละประมาณ 120,000 ครั้ง ตอนนั้นเพื่อความสะดวก ทุกอย่างวิ่งผ่านโมเดลเรือธงตัวเดียวกัน แต่สามงานนี้ยากแค่ไหน? ให้ข้อความผู้ใช้สักสองร้อยคำมาตัดสินว่าเป็น "สอบถามเกี่ยวกับขนส่ง" หรือ "ขอคืนเงินหลังการขาย" งานแบบนี้โมเดลเล็กทำได้เสถียรกว่าโมเดลใหญ่ด้วยซ้ำ เพราะพื้นที่ป้ายมีจำกัดแค่นั้น
ผมรันการประเมินใหม่ตามประเภทงาน งานจำแนกเปลี่ยนไปใช้โมเดลขนาดกลาง ความแม่นยำลดจาก 96.2% เหลือ 95.7% ต่างกัน 0.5 จุด ราคาต่อหน่วยต่างกันหนึ่งหลัก รายการนี้อย่างเดียวตัดบิลได้ถึงสี่สิบเปอร์เซ็นต์
หลุมดำที่สอง: ยัดประวัติบริบททั้งหมดซ้ำทุกครั้ง
ศูนย์บริการเป็นการสนทนาหลายรอบ เฉลี่ย 7.3 รอบ ทีมพัฒนาขี้เกียจ ทุกรอบจึงต่อประวัติทั้งหมดเข้าไป รอบแรกอินพุต 800 โทเคน พอรอบเจ็ดอินพุตกลายเป็น 4,200 โทเคน และทุกรอบจ่ายซ้ำให้หกรอบก่อนหน้า เส้นต้นทุนนี้เป็นกำลังสอง พอปริมาณขึ้นก็ระเบิด
ที่ยุ่งกว่านั้นคือ เนื้อหาส่วนใหญ่ในประวัติไม่มีคุณค่าต่อรอบปัจจุบันเลย ผู้ใช้พูดในรอบที่สามว่า "ฉันต้องการคืนสินค้า" (ฉันจะคืนสินค้า) รอบที่เจ็ดถามว่า "ค่าค่าขนส่งใครออก" (ค่าค่าขนส่งใครออก) พวกบทสนทนาเกริ่นนำและคำอธิบายสินค้าข้างหน้านั้นเป็นโทเคนเสียเปล่าทั้งหมด
หลุมดำที่สาม: การลองใหม่เมื่อล้มเหลวทำให้บานปลาย
อันนี้ซ่อนเร้นที่สุด เวลาต้นทางจำกัดอัตราหรือหมดเวลา SDK โดยค่าเริ่มต้นจะลองใหม่สามครั้ง ปัญหาคือ คำขอที่ลองใหม่มักส่งบริบทยาวเดิมไปอีกครั้งแบบเต็ม ๆ ผมเคยสถิติ พบว่าประมาณ 11% ของโทเคนในบิลมาจากการลองใหม่เมื่อล้มเหลว และการเรียกเหล่านี้สุดท้ายยังล้มเหลวถึงหกสิบเปอร์เซ็นต์ เผาเปล่าล้วน ๆ ถ้าการลองใหม่ไม่มีการถอยระยะและการควบคุมแบบ idempotent เหตุขัดข้องครั้งเดียวสามารถขยายการบริโภคไร้ประสิทธิภาพได้ถึงสามเท่า
หลุมดำที่สี่: เอาต์พุตแบบสตรีมไม่ได้ตัด
โทเคนเอาต์พุตมักแพงกว่าอินพุตตอนนั้นการตอบกลับของศูนย์บริการไม่ได้ตั้ง max_tokens บางครั้งโมเดลก็ "สร้างสรรค์" คำอธิบายการคืนเงินที่พูดสองประโยคจบ กลับเขียนออกมาเป็นขั้นตอนมีหมายเลขกำกับ ในกราฟการกระจายความยาวเอาต์พุต P99 มากกว่า P50 ถึงหกเท่า ตัวอักษรส่วนเกินเหล่านี้ผู้ใช้ไม่ดูเลย แต่ก็ยังจ่ายเงินตามจริง
ห้าการกระทำเพื่อหยุดเลือด
หนึ่ง การกำหนดเส้นทางโมเดลแบบแบ่งระดับ ผมสร้างสามระดับตามประเภทงาน: การจำแนกแบบง่ายใช้โมเดลเล็ก การถามตอบมาตรฐานใช้ระดับกลาง เฉพาะการร้องเรียนซับซ้อนและการไกล่เกลี่ยข้อพิพาทเท่านั้นจึงใช้โมเดลเรือธง ชั้นนี้ผมตั้งค่าบนแพลตฟอร์มรวม API โมเดลขนาดใหญ่ token8341 ติดป้ายตามประเภทงานเพื่อแบ่งเส้นทางอัตโนมัติ ไม่ต้องแก้โค้ดธุรกิจ เพียงเพิ่มกฎฝั่งเกตเวย์ หลังสลับสัปดาห์แรก ต้นทุนส่วนงานจำแนกลดลงหนึ่งระดับทันที
สอง หน้าต่างเลื่อนบริบทพร้อมสรุป เก็บข้อความต้นฉบับสามรอบล่าสุด บทสนทนาที่เก่ากว่าบีบอัดเป็นสรุปไม่เกินหนึ่งร้อยคำ จากการวัดจริงความยาวอินพุตเฉลี่ยลดจาก 3,200 โทเคนเหลือ 1,400 โทเคน ความต่อเนื่องของบริบทในศูนย์บริการไม่ได้รับผลกระทบ
สาม การลองใหม่แบบ idempotent ให้แต่ละคำขอมี ID เฉพาะ ฝั่งเกตเวย์ระบุคำขอซ้ำแล้วนำผลลัพธ์มาใช้ซ้ำทันที การลองใหม่ส่งเฉพาะส่วนที่ล้มเหลวใหม่ ไม่ใช่บริบททั้งหมด รายการนี้บีบโทเคนไร้ประสิทธิภาพจากการลองใหม่จาก 11% เหลือต่ำกว่า 3%
สี่ จำกัดความยาวเอาต์พุต ตั้งเพดาน max_tokens ตามประเภทงาน ฉากคงที่อย่างคำอธิบายการคืนเงินให้เทมเพลตไปเลย โมเดลเพียงเติมตัวแปร โทเคนเอาต์พุตลดลงประมาณสามสิบเปอร์เซ็นต์
ห้า เลือกโมเดลตามงาน ไม่ใช่เลือกตามความเคยชิน ข้อนี้ฟังดูเหมือนพูดเล่น แต่หลายทีมขี้เกียจ ใช้โมเดลเดียวไปทุกงาน ต่อมาเราบนแพลตฟอร์มรวม API โมเดลขนาดใหญ่ token8341 เอาโมเดลในประเทศและต่างประเทศมาไว้ในอินเทอร์เฟซชุดเดียวกันเพื่อทดสอบเปรียบเทียบ กับชุดข้อมูลศูนย์บริการชุดเดียวกัน DeepSeek และ Qwen ให้ผลในฉากภาษาจีนเพียงพอ ราคาเหมาะกับการใช้งานปริมาณมากกว่า ข้อดีของการเชื่อมต่อหลายโมเดลแบบรวมศูนย์อยู่ตรงนี้ เปลี่ยนโมเดลไม่ต้องแก้ SDK แค่เปลี่ยน base_url บรรทัดเดียว
เงื่อนไขของการคิดเงินตามปริมาณคือการกำหนดเส้นทางที่ถูกต้อง
ประโยคที่ว่า "คิดเงินตามปริมาณ ต้นทุนดีกว่า" ตัวมันเองไม่ผิด แต่มีเงื่อนไข: กลยุทธ์การกำหนดเส้นทางของคุณต้องถูกต้อง การคิดเงินตามปริมาณเพียงรับประกันว่าคุณไม่จ่ายเงินให้พลังประมวลผลที่ว่างเปล่า มันไม่รับประกันว่าคุณไม่จ่ายเงินให้กับการเลือกโมเดลที่ผิด บิลจาก 23,000 หยวนกลับมาที่เก้าพันกว่าหยวน ปริมาณยังเพิ่มขึ้น สิ่งที่พึ่งไม่ใช่การเปลี่ยนไปแพลตฟอร์มที่ถูกกว่า แต่คือการทำสองเรื่องนี้ให้ถูก นั่นคือการกำหนดเส้นทางและบริบท
ถ้าตอนนี้คุณก็กำลังจ้องบิลที่อ่านไม่เข้าใจอยู่ แนะนำให้แยกบันทึกการเรียกใช้ตามประเภทงานและความยาวอินพุตเอาต์พุตดูก่อน หลุมดำมักไม่ได้อยู่ที่ที่คุณคิด แพลตฟอร์มรวม API โมเดลขนาดใหญ่ token8341 ในฉากการปรับต้นทุนแบบนี้ช่วยได้mainlyที่ชั้นเกตเวย์โมเดล การกำหนดเส้นทางแบบแบ่งระดับ การจำกัดอัตราแบบสำรอง และการเชื่อมต่อหลายโมเดลแบบรวมศูนย์ ฝั่งธุรกิจแทบไม่รู้สึก
ผู้เขียน: หลี่ หยุนหลง
วันที่เผยแพร่: 24 ตุลาคม 2026