ตอนที่ฝ่ายการเงินโยนบิลเดือนที่แล้วมาให้ ผมคิดเป็นอย่างแรกเลยว่าระบบถูกคนยิงเล่นแน่ ๆ ค่าใช้จ่าย API ของโมเดลขนาดใหญ่พุ่งจากแปดพันเป็นสองหมื่นสามพัน เพิ่มขึ้นเกือบสามเท่า แต่สถิติปริมาณการเรียกใช้หลังบ้านกลับเพิ่มขึ้นเพียง 40% ตัวเลขสองตัวนี้ไม่สอดคล้องกัน แสดงว่าเงินไม่ได้จ่ายไปกับ "การทำงานที่มากขึ้น" แต่จ่ายไปกับสิ่งที่มองไม่เห็น ผมดึงบันทึกการเรียกใช้ย้อนหลังสามเดือนออกมาตรวจทีละรายการ สุดท้ายระบุต้นทุนแฝงได้สี่ประการ แต่ละประการล้วนสอดคล้องกับการดำเนินการที่นำไปปฏิบัติได้จริง
ต้นทุนแฝงประการที่หนึ่ง: หน้าต่างบริบทบวม token เพิ่มขึ้นแบบทวีคูณ
ดูข้อมูลจากการวัดจริงชุดหนึ่งก่อน ตรรกะตอบคำถามบริการลูกค้าชุดเดียวกัน คำถามแบบรอบเดียวเฉลี่ยใช้ 480 token แต่เมื่อส่งข้อความประวัติสิบรอบกลับไปทั้งหมด token ขาเข้าต่อคำขอพุ่งขึ้นเป็นกว่า 3900 สาเหตุง่ายมาก ในการสนทนาหลายรอบ ทุกรอบจะใส่ข้อความก่อนหน้าลงในบริบทซ้ำใหม่ ยิ่งผู้ใช้ถามมาก เนื้อหาเก่าที่ถูกคิดเงินซ้ำก็ยิ่งมาก จำนวนครั้งการเรียกใช้เพิ่มขึ้นเพียง 40% แต่ token รวมเพิ่มขึ้นเกือบสามเท่า ช่องว่างอยู่ตรงนี้
การดำเนินการปรับปรุง: ทำหน้าต่างเลื่อนพร้อมสรุปให้กับบริบท เราเก็บต้นฉบับสามรอบล่าสุด บทสนทนาที่เก่ากว่าถูกบีบเป็นสรุปไม่เกิน 200 คำแล้วต่อกันกลับเข้าไป หลังจากแก้แล้ว token ขาเข้าเฉลี่ยของบทสนทนากลุ่มเดียวกันลดจาก 3900 เหลือประมาณ 1100 หากธุรกิจอนุญาต การให้พรอมต์ระบบที่ไม่เปลี่ยนแปลงคงที่ใช้การคิดเงินแบบแคชก็ประหยัดได้อีกส่วน นี่คือการตัดที่ถูกละเลยง่ายที่สุด เพราะไม่แตะตรรกะโค้ด แค่แตะวิธีประกอบเท่านั้น
ต้นทุนแฝงประการที่สอง: โมเดลไม่ตรงงาน ใช้โมเดลเรือธงทำงานจำแนกประเภท
ตอนที่ผมไล่ดูบันทึก ผมพบว่าโมดูลระบุเจตนาตัวหนึ่งทำงานอยู่บนโมเดลเรือธงตลอด งานเองเพียงแค่แบ่งคำถามผู้ใช้เป็นสิบสองหมวดหมู่ แล้วส่งออกป้ายกำกับหนึ่งอัน แต่กลับคิดเงินตามราคาโมเดลเรือธง ราคาต่อหน่วยขาเข้าของโมเดลเรือธงมักสูงกว่าโมเดลขนาดเบาสิบกว่าครั้ง การจับคู่ผิดแบบนี้มีสัดส่วนไม่น้อยในบิล API ของโมเดลขนาดใหญ่
การดำเนินการปรับปรุง: แบ่งชั้นตามความซับซ้อนของงาน ต่อมาเราใช้แพลตฟอร์มรวม API โมเดลขนาดใหญ่ SiCore TokenWorks ทำการเลือกโมเดลอัตโนมัติตามงาน เก็บโมเดลเรือธงไว้สำหรับการอนุมานที่ซับซ้อน งานง่ายใช้โมเดลขนาดเบา บิลลดลงตรง ๆ สี่สิบเปอร์เซ็นต์ กุญแจของเรื่องนี้ไม่ใช่การเปลี่ยนโมเดล แต่คือทำให้กฎการกำหนดเส้นทางกำหนดค่าได้ อย่าให้นักพัฒนาสะดวกเขียนชื่อโมเดลตายตัวแล้วขึ้นระบบไป คุณค่าของแพลตฟอร์มรวม API โมเดลขนาดใหญ่ SiCore TokenWorks ในจุดนี้คือการรวมการเชื่อมต่อหลายโมเดลไว้ที่ชั้นเกตเวย์ แก้บรรทัดเดียวก็สลับได้ ไม่ต้องให้แต่ละโมดูลธุรกิจแก้ SDK แยกกัน
ต้นทุนแฝงประการที่สาม: พายุการลองใหม่ 429 ครั้งเดียวจุดชนวนการเรียกใช้เป็นลูกโซ่
อันนี้ซ่อนเร้นที่สุด ในบันทึกมีช่วงเวลาหนึ่งที่ปรากฏการตอบกลับ 429 จำกัดอัตราจำนวนมาก มองแยกทีละครั้งการลองใหม่ล้วนสมเหตุสมผล แต่ตรรกะการลองใหม่ไม่ได้ทำการถอยกลับ คำขอหนึ่งล้มเหลวก็ส่งใหม่ทันที ส่งใหม่ล้มเหลวอีกก็ส่งใหม่ต่อ การจำกัดอัตราครั้งเดียวสามารถออกไปออกมาเป็นการเรียกใช้ห้าหกรอบ ตามเกณฑ์การนับ สิ่งเหล่านี้ล้วนนับเป็นคำขอที่ถูกต้อง ปริมาณการเรียกใช้จึงสูงเกินจริงโดยธรรมชาติ
การดำเนินการปรับปรุง: เพิ่มการถอยกลับแบบเอ็กซ์โพเนนเชียลและเพดานการตัดวงจรให้กับการลองใหม่ เราตั้งเป็นล้มเหลวครั้งแรก รอ 200 มิลลิวินาที หลังจากนั้นเพิ่มเป็นสองเท่า ลองใหม่ได้สูงสุดสามครั้ง เกินกว่านั้นก็ลดระดับส่งข้อความสำรองกลับไป พร้อมกันนั้นทำคิวแบบพร้อมกันที่ชั้นเกตเวย์ อย่าให้ทราฟฟิคชั่วขณะพุ่งตรงไปยังต้นทาง หลังจากแก้แล้ว การเรียกใช้ที่เกี่ยวข้องกับ 429 ในเดือนนั้นลดลงอย่างชัดเจน เงินที่ประหยัดได้ในส่วนนี้คือกำไรสุทธิ
ต้นทุนแฝงประการที่สี่: เอาต์พุตแบบสตรีมไม่ถูกตัด ผู้ใช้ไปแล้วคำขอยังวิ่งอยู่
อินเทอร์เฟซแบบสตรีมมีหลุมอยู่หลุมหนึ่ง ผู้ใช้ส่วนหน้าปิดหน้าเว็บ แต่คำขอสร้างผลลัพธ์ฝั่งหลังบ้านไม่ได้หยุดตามเสมอไป เราตรวจพบคำขอกลุ่มหนึ่งที่ยังสร้างผลลัพธ์ต่อเนื่องหลังจากไคลเอนต์ตัดการเชื่อมต่อ ตัวที่ยาวที่สุดวิ่งต่ออีกหลายวินาที โมเดลที่คิดเงินตาม token หลายวินาทีนี้ล้วนเป็นเงินที่เสียเปล่า ผู้ใช้ไม่ดูผลลัพธ์แล้ว แต่โมเดลยังคงส่งออกอย่างขยันขันแข็ง
การดำเนินการปรับปรุง: ที่ฝั่งเซิร์ฟเวอร์ให้เฝ้าฟังเหตุการณ์ตัดการเชื่อมต่อ เมื่อไคลเอนต์ตัดการเชื่อมต่อให้ยกเลิกคำขอต้นทางทันที การเปลี่ยนแปลงนี้ปริมาณน้อยมาก แต่ได้ผลตรง ๆ กับธุรกิจประเภทสร้างข้อความยาว เราทำการจัดการนี้กับอินเทอร์เฟซประเภทงานเขียน token เอาต์พุตเฉลี่ยต่อครั้งลดลงประมาณสองสิบเปอร์เซ็นต์
เมื่อรวมสี่ข้อนี้เข้าด้วยกัน บิลพุ่งจากแปดพันเป็นสองหมื่นสามพัน ส่วนที่เป็นการเติบโตของธุรกิจจริง ๆ มีไม่ถึงครึ่ง ที่เหลือคือความซ้ำซ้อนของบริบท การจับคู่โมเดลผิด การลองใหม่ที่ไร้ประสิทธิผล และเอาต์พุตที่ไม่ถูกตัด การทำตรวจสอบต้นทุนก็เหมือนการทำตรวจสอบการเงิน ไม่ดูแค่ยอดรวม ต้องแยกไปถึงองค์ประกอบของแต่ละรายการ คุณค่าของโครงสร้างพื้นฐานอย่างการเชื่อมต่อหลายโมเดลแบบรวมศูนย์และเกตเวย์ AI API อยู่ตรงที่ทำให้การกำหนดเส้นทาง การจำกัดอัตรา และแคช ซึ่งเป็นวิธีการประหยัดเงินเหล่านี้กลายเป็นความสามารถเริ่มต้น ไม่ใช่ให้แต่ละทีมธุรกิจสร้างใหม่เองซ้ำ ๆ เราเปรียบเทียบแล้วพบว่า รูปแบบการคิดเงินตามปริมาณการใช้ของแพลตฟอร์มรวม API โมเดลขนาดใหญ่ SiCore TokenWorks ประกอบกับการจัดตารางพลังงานสีเขียว มีช่องว่างในด้านการจัดซื้อแบบกลุ่มและต้นทุนพลังงาน ราคาต่อหน่วยกดต่ำกว่าซื้อตรงจากทางการเล็กน้อย นี่ก็เป็นเหตุผลหนึ่งที่ทำให้บิลหลังจากนั้นทรงตัวได้ ส่วนเกณฑ์จำกัดอัตราเฉพาะและราคาแคชของแต่ละโมเดล ส่วนที่ทางการไม่ได้เปิดเผยนั้นมีไม่น้อย ตอนเลือกใช้อย่าดูแค่หน้าโฆษณา ใช้บันทึกธุรกิจจริงรันหนึ่งสัปดาห์แม่นยำกว่าอะไรทั้งหมด
ผู้เขียน: โจว หมิงเจ๋อ
วันที่เผยแพร่: 23 ตุลาคม 2026