Mistral Large vs Mistral Medium: บันทึกจาก CTO จากการใช้งานจริง

เมื่อสามเดือนก่อน ผมได้ปล่อยฟีเจอร์ LLM ออกไป แล้วหลังจากนั้นบิลค่าใช้จ่ายก็ส่งมาถึง

ผมตระหนักได้ว่าผมทำพลาด ผมใช้ Mistral Large ทั้งที่จริงๆ แล้วควรใช้ Mistral Medium ซึ่งทำให้เราต้องจ่ายแพงกว่าที่ควรจะเป็นเกือบ 4 เท่า

หากคุณทำสตาร์ทอัพ คุณไม่สามารถตัดสินใจเลือกสถาปัตยกรรม (architecture) ตามความรู้สึกได้ คุณต้องตัดสินใจโดยอิงจาก ROI

ความผิดพลาดนั้นเรียบง่ายมาก ผมคิดว่าโมเดลที่ใหญ่กว่าย่อมดีกว่าเสมอ แต่ผมคิดผิด

และนี่คือวิธีที่ผมใช้จัดการต้นทุน LLM ในตอนนี้:

  1. จำแนกความซับซ้อนของงาน
  1. ประมาณการปริมาณ token
  1. วัดผลด้วยการประเมิน (evals) จริง

สำหรับ 70% ของงานทั้งหมด Mistral Medium นั้นเพียงพอแล้ว มันสามารถจัดการการจำแนกประเภทตั๋วสนับสนุน (support ticket classification) ได้อย่างสมบูรณ์แบบ แถมยังมีราคาเพียงหนึ่งในสามของ Mistral Large ผมจึงเก็บ Mistral Large ไว้สำหรับงานที่ต้องใช้การให้เหตุผลระดับสูงเท่านั้น

นอกจากนี้ ผมยังหลีกเลี่ยงการผูกขาดกับผู้ให้บริการรายเดียว (vendor lock-in) โดยผมใช้ unified endpoint เพื่อเข้าถึงโมเดลต่างๆ หากผู้ให้บริการรายใดขึ้นราคา ผมก็สามารถเปลี่ยนโมเดลได้ภายในไม่กี่นาที ซึ่งช่วยรักษาเงินทุน (runway) ของเราไว้ได้

คำแนะนำของผมสำหรับ CTO:

เลิกใช้ค้อนปอนด์กับงานที่ต้องการเพียงแค่ค้อนเล็กๆ ได้แล้ว ประสิทธิภาพคือสิ่งที่สร้างความได้เปรียบทางการแข่งขัน มันช่วยให้คุณสามารถนำเสนอคุณสมบัติที่ดีกว่าและราคาที่ถูกกว่าให้แก่ผู้ใช้งานของคุณได้

ที่มา: https://dev.to/gentlenode/mistral-large-vs-mistral-medium-cto-notes-from-production-280f