Mistral Large vs Mistral Medium: Ghi chép từ CTO khi triển khai thực tế
Ba tháng trước, tôi đã tung ra một tính năng LLM. Sau đó, hóa đơn gửi đến.
Tôi nhận ra mình đã mắc sai lầm. Tôi đã dùng Mistral Large trong khi đáng lẽ nên dùng Mistral Medium. Việc này khiến chúng tôi tốn kém gần gấp 4 lần mức cần thiết.
Nếu bạn đang điều hành một startup, bạn không thể đưa ra các lựa chọn về kiến trúc dựa trên cảm tính. Bạn phải dựa trên ROI.
Sai lầm này rất đơn giản. Tôi đã nghĩ rằng các mô hình lớn hơn thì luôn tốt hơn. Tôi đã lầm.
Đây là cách tôi quản lý chi phí LLM hiện nay:
- Phân loại độ phức tạp của tác vụ
- Sử dụng các mô hình nhỏ hơn cho việc phân loại hoặc trích xuất đơn giản.
- Chỉ sử dụng các mô hình lớn hơn cho multi-step reasoning.
- Ước tính token volume
- Kiểm tra logs của bạn.
- Dự phóng mức tăng trưởng.
- Tính toán kỹ lưỡng trước khi deploy.
- Đo lường bằng các real evals
- Đừng tin vào trực giác của mình.
- Chạy các test sets qua cả hai mô hình.
- So sánh các metrics quan trọng đối với sản phẩm của bạn.
Với 70% tác vụ của tôi, Mistral Medium là đủ. Nó xử lý việc phân loại support ticket một cách hoàn hảo. Chi phí của nó chỉ bằng một phần ba so với Large. Tôi dành Large cho các tác vụ high-level reasoning.
Tôi cũng tránh vendor lock-in. Tôi sử dụng một unified endpoint để truy cập nhiều mô hình. Nếu một provider tăng giá, tôi có thể chuyển đổi mô hình chỉ trong vài phút. Điều này giúp bảo vệ runway của tôi.
Lời khuyên của tôi dành cho các CTO:
- Cache triệt để để cắt giảm hóa đơn.
- Stream responses để cải thiện trải nghiệm người dùng.
- Xây dựng fallback logic để hệ thống luôn online.
- Chọn mô hình trước khi optimize prompt.
- Kiểm tra yêu cầu về context window cho mọi tác vụ.
Đừng dùng búa tạ cho những tác vụ chỉ cần một chiếc búa nhỏ. Sự hiệu quả tạo ra lợi thế cạnh tranh. Nó cho phép bạn cung cấp các tính năng tốt hơn và mức giá thấp hơn cho người dùng.
Nguồn: https://dev.to/gentlenode/mistral-large-vs-mistral-medium-cto-notes-from-production-280f