DEV Community

BeanBean
BeanBean

Posted on Originally published at nextfuture.io.vn

Giảm 71% hóa đơn LLM bằng cheap-first routing và gate cấu trúc

Originally published on NextFuture

Hóa đơn LLM tháng này gấp ba lần dự toán, trong khi log cho thấy phần lớn request chỉ là đặt tiêu đề thread, tóm tắt diff, trích field từ form. Bạn biết nên đẩy đám việc vặt đó sang model rẻ, nhưng không ai dám ký vì sợ ba tuần sau nhận support ticket. Có cách rẻ hơn đoán: chạy model rẻ trước, rồi chấm output bằng gate cấu trúc.

Đừng phân loại prompt — hãy chấm output

Thiết kế ai cũng viết đầu tiên là đặt classifier trước router: nhìn request, đoán dễ hay khó, chọn model. Tác giả bài gốc làm vậy rồi bỏ. Classifier rẻ là thêm một lời gọi và ~300ms cho mọi request; classifier chính xác lại chính là model đắt bạn đang tránh. Độ dài cũng không phản ánh độ khó — "Fix the timezone bug" rất ngắn nhưng cần tất cả những gì model có.

Luật thay thế: độ khó là thuộc tính của công việc, không phải của prompt — cách trung thực duy nhất để biết là làm thử. Gửi cho model rẻ, nhìn kết quả, trượt gate thì chạy lại bằng model mạnh.

Double-billing không phải là vấn đề, số học nói vậy

Với request shape trung bình của họ (~3.000 input token, 700 output), model rẻ tốn khoảng $0,0014 một lời gọi, model mạnh khoảng $0,0145 — tỷ lệ 10:1. Request bị escalate tốn $0,0159 thay vì $0,0145, đắt hơn ~10%: tỷ lệ escalate phải chạm 9/10 thì cheap-first mới lỗ. Thực tế họ escalate 15%. Kết quả: 81% request do model rẻ phục vụ trọn vẹn, chi phí mỗi 1.000 request giảm từ $14,50 xuống $4,16 — 71%.

Bốn gate, không cái nào hỏi model

Gate mới là sản phẩm, router chỉ là ống dẫn. Bốn gate của họ đều thuần cấu trúc: SchemaInvalid (output không khớp schema), ToolArgsMissing (thiếu argument bắt buộc khi gọi tool), Truncated (finish reason khác stop), EmptyOrHedged (dưới 24 ký tự hoặc khớp danh sách câu né). Riêng gate schema bắt khoảng 60% số lần escalate.

Cái họ bỏ còn đáng nhớ hơn: gate hỏi chính model rẻ "có tự tin không" chỉ kích hoạt trên 0,4% response, trong khi lỗi đo được trên cùng traffic khoảng 15%.

Giá thật nằm ở p95

Kết quả họ công bố: p50 giảm từ 2,9s xuống 1,4s, nhưng p95 tăng từ 7,8s lên 9,6s và p99 từ 11,2s lên 16,4s — nhóm escalate trả tiền cho hai lời gọi nối tiếp. Nên đừng đưa chat streaming vào router: không thể stream một câu trả lời có thể bị vứt đi. Chỉ định tuyến việc có cấu trúc, chạy nền — trích field, gán nhãn, đặt tiêu đề, chọn tool.

Một chi tiết dễ sai: khi escalate hãy gửi lại request gốc, đừng đưa bản nháp của model rẻ cho model mạnh "sửa giúp" — trên các ca họ kiểm tay, đường đó tệ hơn chạy sạch khoảng một phần ba số lần.

Router cũng biết đi lạc

Một postmortem khác nhắc phần hạ tầng: sau một lần cập nhật dependency, bảng route đổi cách phân giải tên model sang endpoint, router vẫn đẩy hàng nghìn item batch sang đích đắt hơn vì đích đó vẫn "healthy". Latency không nhúc nhích, error budget không cháy; 9:30 sáng mới có người mở billing và thấy chi tiêu một ngày gần bằng ngân sách cả tuần. Cách chặn: mỗi batch job tự khai model group nó mong đợi, router phải chứng minh endpoint vẫn báo đúng group trước khi mở traffic. Health check trả 200 không nói gì về việc model nào đang trả lời.

Bản tối giản ship được trong tuần

Chọn một job khối lượng lớn, không streaming, có cấu trúc — titling hoặc field extraction. Thêm đúng một gate: validate schema bạn đã có. Chạy shadow một ngày (gọi cả hai model, trả kết quả model mạnh, chỉ log chỗ gate sẽ kích hoạt) để biết escalate thật là 15% hay 60%. Rồi mới bật, kèm log model đã trả lời và kill switch trong config. Dưới vài trăm nghìn request/tháng thì đừng làm — đàm phán lại giá seat nhanh hơn.


This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.

Top comments (0)