Hóa đơn LLM tăng vọt: 4 chỗ rò tiền và số đo cắt token

Hóa đơn LLM tháng này nhảy một bậc trong khi traffic chỉ nhích vài phần trăm. Phản xạ đầu tiên của cả team là đi tìm model rẻ hơn. Bài này đi ngược lại: bốn chỗ tiền hay rò nhất, bài audit 30 phút, và số đo thật của mấy mẹo cắt token đang lan truyền.

Bốn nghi phạm, hai trong số đó không lộ ra trên một request

Một bài phân tích chi phí trên Dev.to xếp nguyên nhân thành bốn nhóm, kèm nhận định của tác giả: "A and B show up the moment you look at a single request. C and D only show up when you look at the whole workflow."

• Prompt dài. Input token rẻ trên đầu token, nhưng bạn trả cho nó ở mọi request: system prompt 6.000 token không đổi vẫn bị tính 6.000 token ở lần gọi thứ một triệu. Kiểm tra phần tĩnh có nằm trên cùng để prompt caching bắt được prefix giống hệt, và có đang lấy 20 chunk cho câu chỉ cần 3 không.
• Output dài dòng. Trên phần lớn bảng giá, output token đắt gấp nhiều lần input token. Đặt max_tokens theo use case; output để máy đọc thì xin JSON thay vì văn xuôi rồi parse.
• Retry và agent loop. Một thao tác của user nở ra thành validation fail → hỏi lại, timeout → retry, agent gọi tool rồi thử lại tám lần. Số cần theo dõi là cost per completed task: nếu "summarize ticket" tốn trung bình bốn lần gọi LLM, bốn lần đó mới là đơn giá thật.
• Sai tier model. Gắn nhãn từng call site là reasoning-heavy hay routine, rồi chạy eval set trên model nhỏ cho nhóm routine. Việc không nhạy latency thì xem batch endpoint — tác giả dẫn OpenAI Batch và Anthropic Message Batches là các API định giá thấp hơn bản synchronous.

Audit 30 phút, chạy được ngay tuần này

Lấy log một ngày, gom chi phí theo task chứ không theo request. Với ba task tốn nhất, ghi ra bốn con số: input token, output token, số call mỗi task, model đang dùng — con số lớn nhất chính là câu trả lời. Chốt của tác giả: fix thường không phải đổi vendor, mà là một cái cap, một prompt thân thiện với cache, hoặc một model nhỏ hơn.

Trước khi cài thêm thứ gì để tiết kiệm token, hãy thử xin ít lại

Một bài đo khác lấy repo caveman — quảng cáo "cuts 65% of tokens by talking like a caveman" — đo bằng chính tokenizer o200k_base mà docs của nó chỉ định: cùng prompt 276 token, cùng một bug C# có pass/fail kiểm chứng được, ba lần chạy mỗi biến thể:

Biến thể	Output token (mean)	So với plain
plain (không hướng dẫn)	845	—
"Be concise." (hai chữ)	603	−28,7%
/caveman	482	−42,9%
/ultracave	308	−63,6%

Hai chữ miễn phí lấy được −28,7%. Skill thì không miễn phí: file rules gửi kèm mỗi session tốn 1.158 token (caveman) và 608 token (ultracave) — hòa vốn sau khoảng 10 và 2 câu trả lời. Chất lượng không giảm: cả bốn biến thể đều compile được và in ra PASS.

Chi tiết đáng giá hơn con số headline: nén làm giảm phương sai. Plain dao động 688–951 token (±15%), ultracave chỉ 293–317 (±4%) — quan trọng hơn giá trị trung bình khi dự toán một agent run dài. Phần proxy nén input thì kén dữ liệu: 96,3% trên CSV 400 dòng, 87,5% trên 400 JSON record, nhưng đúng 0% trên build log và JSON lồng nhau. Tác giả tự giới hạn: n=3, một task, một model.

Làm gì tiếp

Rẻ dần theo công sức: thêm một câu yêu cầu ngắn gọn vào system prompt rồi đo lại output token trong một ngày; đặt cap cứng cho vòng lặp agent và retry; đẩy phần prompt tĩnh lên trên cùng; cuối cùng mới tính chuyện đổi model hay mua công cụ. Nếu context của bạn chủ yếu là build log và response API lồng nhau, đừng kỳ vọng vào proxy nén — chúng nén shape, không nén format.