Hóa đơn LLM tăng vọt: tìm cache miss trước khi hạ model

Bạn thêm RAG vào trợ lý nội bộ, system prompt dài thêm vài trăm dòng, và hóa đơn API tháng này tăng vọt — trong khi câu trả lời vẫn dài y như cũ. Phản xạ của hầu hết team là hạ model xuống bản rẻ hơn. Khoan: dành 30 phút đọc đúng ba con số trong usage đã, vì phần lớn trường hợp tiền rò ở chỗ khác.

Đọc đúng usage object trước khi đổ lỗi cho model

Theo bài phân tích chi phí LLM trên Dev.to, "nguyên nhân gần như luôn là input tokens bị xử lý lại ở giá đầy đủ trong mọi request — không phải model bạn chọn". Bẫy nằm ở tên trường: tác giả nhấn mạnh input_tokens là phần dư chưa cache, không phải kích thước prompt. Tổng prompt thật sự bằng input_tokens + cache_creation_input_tokens + cache_read_input_tokens. Bài viết kể một team kết luận prompt của họ nhỏ vì input_tokens chỉ 4K, trong khi hai trường kia cộng lại gấp mười lần.

Cách kiểm tra rẻ nhất: gửi cùng một request hai lần liên tiếp. Request thứ hai khỏe mạnh sẽ đọc lại prefix dùng chung và chỉ ghi phần delta. Nếu nó ghi cache gần bằng cả prompt và đọc bằng 0, prefix không ổn định — đó là bug, không phải vấn đề giá.

Những thứ âm thầm phá prefix cache

Prompt caching là so khớp prefix trên đúng chuỗi byte đã render; theo nguồn, thứ tự render là tools → system → messages, nên một byte đổi sớm vô hiệu hóa mọi thứ phía sau. Request vẫn thành công, output vẫn đúng, chỉ hóa đơn là biết chuyện. Hãy grep trong code sinh prompt:

• Timestamp hoặc thông tin user nhét thẳng vào system prompt — "mỗi request" bao gồm cả đồng hồ.
• json.dumps() không có sort_keys=True, và vòng lặp trên set.
• Tool list lắp theo từng user — tools render ở vị trí 0, nên không tái dùng được giữa các user.
• Section system bật tắt theo feature flag: mỗi tổ hợp flag thành một prefix riêng.
• Đổi model cũng vô hiệu hóa cache — cache gắn theo model.

Breakpoint đặt ở cuối phần lặp lại, không phải cuối prompt

Nếu block cuối là câu hỏi riêng của user hoặc các dòng vừa retrieve, breakpoint rơi vào vùng byte không bao giờ lặp lại — mọi request trả phí ghi, không request nào đọc lại được. Dấu hiệu trong log: cache write ở mọi request, read không bao giờ phủ prefix chung. Nguồn mô tả kinh tế của nó như một tỉ lệ: ghi cache đắt hơn input token thường, đọc cache chỉ tốn một phần nhỏ, nên một prefix đọc lại dù chỉ hai lần đã có lãi.

Agent loop: trần chi phí phải nằm trong loop

Với agent, chi phí cao không vì model đắt mà vì không có gì dừng vòng lặp. Một bài viết khác dẫn khảo sát KPMG Q3 2026 — và tự lưu ý con số chỉ có một nguồn, nên đọc theo hướng chứ đừng coi là chính xác — cho rằng 93% người trả lời vượt ngân sách AI, và chỉ 43% tổ chức có đặt hạn mức usage hoặc token.

Đặt trần ở dashboard provider chỉ chặn tiền sau khi tiền đã đi. Tác giả đề xuất ngân sách theo task chứ không theo process, và ghi nhận token sau mỗi lời gọi: pre-flight check không bắt được retry loop vì vòng lặp nằm bên trong một call. Hai chi tiết dễ bỏ sót: với streaming nhiều provider không trả usage, mà guard âm thầm ghi 0 còn tệ hơn không có guard; và định tuyến theo bước — model nhỏ cho read/extract/summarise, model lớn chỉ cho bước quyết định, vì theo nguồn các bước đọc và tóm tắt nhiều gấp ba lần.

Làm gì trong tuần này

Log ba trường token cho mỗi request trong 48 giờ, chạy thử nghiệm gửi-hai-lần trên route tốn nhất, rồi grep codebase theo danh sách trên. Nếu cache read vẫn bằng 0 sau khi đã cố định prefix, lúc đó mới là lúc bàn chuyện đổi model.