Khoản Đắt Thứ Nhì Không Phải Là Câu AI Trả Lời
Trang chủ/Tài Viết/AI
AI

Khoản Đắt Thứ Nhì Không Phải Là Câu AI Trả Lời

Quay lại Tài Viết

Bài 3/12 trong chuỗi Kinh tế Vibe Coding

Trước khi ngồi viết bài này, tôi đã có sẵn trong đầu một con số nghe rất được lòng người đọc: cache cắt phần lớn hoá đơn, tiết kiệm một khoản đáng kể mỗi tháng. Con số cụ thể tôi nhớ là 82,8% và 221,9 triệu đồng — không phải tôi bịa ra, mà là phép nhân nhẩm từ những gì tôi nhớ mang máng sau khi lướt qua bảng số của cả ba công cụ đang dùng. Chỉ đến khi mở lại đúng bảng số gốc của riêng Claude Code trên repo này và tính từng dòng, tôi mới thấy con số mình nhớ bị thổi phồng gần gấp đôi — nhiều khả năng vì tôi đã gộp cả token của Codex và Antigravity vào chung một phép tính, thay vì tách riêng từng công cụ.

Ghi cache đắt hơn đọc cache, và toàn bộ hoá đơn xoay quanh tỉ lệ giữa hai dòng đó
Ghi cache đắt hơn đọc cache, và toàn bộ hoá đơn xoay quanh tỉ lệ giữa hai dòng đó

Con số đúng, sau khi tính lại từ đầu

Trên đúng 946.786.932 token mà Claude Code xử lý trên repo này — 62 phiên làm việc, 4.794 lượt gọi API, cửa sổ nhật ký 14/07–02/09/2026, số gốc nằm ở bảng số của cả chuỗi — nếu tắt cache hoàn toàn, cùng khối lượng công việc đó tính theo giá niêm yết sẽ tốn 4.821 $, tương đương khoảng 125 triệu đồng ở tỉ giá 26.000. Có cache, hoá đơn thực tế chỉ còn 755,26 $. Cache đang cắt đúng 84,3% — cao hơn con số tôi nhớ, nhưng không đáng để ăn mừng, vì phần chênh lệch lớn hơn nhiều nằm ở chỗ tổng tiền giả định ban đầu của tôi sai lệch quy mô, không phải ở tỉ lệ phần trăm.

Bài học đầu tiên rút ra trước khi vào chuyện chính: một con số "nghe hợp lý" ghép từ trí nhớ của ba công cụ khác nhau không thay được một phép tính lại đúng phạm vi. 125 triệu và 221,9 triệu đều trả lời cùng một câu hỏi — "không có cache thì tốn bao nhiêu" — nhưng một cái đo đúng một công cụ trên một repo, cái kia lẫn cả những gì không thuộc phạm vi đó.

Khoản đắt thứ nhì trong hoá đơn

Nhìn vào cách 755,26 $ đó được ghép lại, có một thứ tự trái ngược với cảm giác thông thường. Phần lớn người mới dùng coding agent đoán khoản tốn nhất sau chi phí đọc lại ngữ cảnh phải là câu trả lời do AI viết ra — dù sao đó cũng là phần việc nhìn thấy được. Thực tế trên repo này thì khác: cache read đứng đầu với 61,2% hoá đơn, dễ hiểu vì nó chiếm tới 97,55% khối lượng token. Nhưng đứng ngay sau nó không phải output, mà là cache write — 23,8% hoá đơn, trong khi output chỉ 14,5%.

Lý do nằm ở khối lượng, không nằm ở đơn giá. Đơn giá ghi cache chỉ gấp 2 lần input, thấp hơn nhiều so với 5 lần của output. Nhưng khối lượng token ghi cache — 18.101.197 — lại nhiều hơn khối lượng output — 4.374.498 — tới hơn bốn lần. Nhân đơn giá với khối lượng, phần ghi cache vượt qua phần output dù đơn giá của nó rẻ hơn: khối lượng thắng đơn giá.

Vì sao ghi lại đắt hơn đọc lại

Cache hoạt động theo kiểu tiền tố, không phải theo từng đoạn rời rạc. Toàn bộ nội dung đứng trước một mốc đánh dấu trong ngữ cảnh — file hướng dẫn dự án, danh sách công cụ được cấp quyền, những lượt trao đổi đầu phiên — phải khớp y nguyên với lần gọi trước đó thì lượt gọi mới được tính giá đọc rẻ, chỉ bằng 0,1 lần input. Sai một chỗ ở phần đầu — một dòng file hướng dẫn vừa sửa, một công cụ vừa thêm hay bớt, một tin nhắn cũ vừa chỉnh — toàn bộ phần đứng sau mốc đó mất khớp, và lượt gọi kế tiếp phải ghi lại từ đầu ở giá 2 lần input.

Mỗi lượt ghi còn đi kèm một cửa sổ hiệu lực. Có hai bậc: bậc rẻ hết hạn sau 5 phút không có lượt gọi nào chạm vào, tính giá 1,25 lần input; bậc đắt hơn kéo dài 1 giờ, tính giá 2 lần input. Toàn bộ 18.101.197 token ghi cache đo được trên repo này đều rơi vào bậc 1 giờ — không một token nào ở bậc rẻ. Còn trong cửa sổ hiệu lực, lượt gọi tiếp theo vẫn đọc lại với giá 0,1 lần. Hết cửa sổ mà không có lượt gọi nào chạm vào, lượt kế tiếp coi như bắt đầu lại, ghi cache đầy đủ ở giá đắt.

Đây không phải luật chung của mọi công cụ. Cùng đo trên repo này, Codex không tính phí ghi cache riêng — toàn bộ phần được cache của nó vào thẳng giá đọc, không có dòng chi phí nào tương đương cache write. Cách Claude Code định giá bộ nhớ đệm là một lựa chọn thiết kế cụ thể của công cụ đó, không phải một sự thật vật lý áp dụng cho mọi coding agent.

Những thao tác âm thầm làm vỡ cache

Ba việc sau đây, xét riêng lẻ đều trông vô hại, nhưng đều buộc phần ngữ cảnh phía sau phải ghi cache lại từ đầu.

Sửa file hướng dẫn dự án hoặc đổi danh sách công cụ giữa chừng một phiên đang chạy. Nội dung đó nằm ở phần đầu tiền tố, nên một dòng vừa sửa làm mất khớp toàn bộ phần phía sau, dù phần việc thật sự đang làm không hề liên quan tới dòng vừa sửa.

Để một phiên im lặng quá lâu rồi quay lại làm tiếp. Nếu quá cửa sổ hiệu lực đang dùng — ở đây là 1 giờ — mà không có lượt gọi nào, lượt gọi kế tiếp không còn gì để đọc lại, phải ghi từ đầu.

Mở một phiên mới cho một việc mà bộ tài liệu nạp vào đầu phiên — file hướng dẫn, quy tắc dự án — không hề đổi so với phiên trước. Nội dung giống hệt cũng không giúp gì: mỗi phiên mới bắt đầu một tiền tố hoàn toàn riêng, lượt gọi đầu tiên luôn phải ghi cache lại từ đầu.

Luật giữ cache sống

Từ ba điều trên, quy tắc hành động khá gọn: giữ một phiên đủ lâu để làm trọn một việc, đừng tách nhỏ nó thành nhiều phiên chỉ vì cùng lúc đó cũng tiện đóng lại. Mỗi lần tách là một lượt ghi cache đầy đủ lặp lại cho đúng một khối tài liệu nền chẳng hề thay đổi.

Nhưng không giữ một phiên vô hạn để đổi lấy việc đó. Phiên càng dài, mỗi lượt gọi về cuối càng cõng theo nhiều ngữ cảnh hơn, nên dù giá đọc cache rẻ, tổng tiền mỗi lượt vẫn tăng dần theo khối lượng — cắt phiên đúng lúc việc đã xong vẫn rẻ hơn giữ nó chạy tiếp cho tiện. Việc đọc dàn trải, khảo sát rộng nhiều file nên tách sang một phiên phụ riêng thay vì kéo dài trong phiên chính đang giữ khối tài liệu nền còn nguyên trong cache.

Đừng sửa nội dung đã nạp từ đầu phiên — file hướng dẫn dự án, danh sách công cụ — giữa chừng nếu không bắt buộc. Cần đổi thì đổi ở đầu một phiên mới, chấp nhận một lượt ghi cache đầy đủ đúng một lần, còn hơn đổi giữa chừng và làm vỡ cache của toàn bộ phần còn lại của phiên đang chạy.

Điều tôi giữ lại từ lần tính sai này

Con số tôi nhớ trong đầu — 82,8%, 221,9 triệu — không sai vì tôi bịa, mà sai vì tôi tính gộp thứ không nên gộp. Cache read và cache write đọc riêng, mỗi dòng kể một câu chuyện khác nhau: dòng đầu nói cache rẻ tới mức nào khi dùng đúng cách, dòng sau nói ghi sai chỗ đắt tới mức nào. Nhìn gộp cả hai thành một tỉ lệ phần trăm duy nhất, cả câu chuyện thật bị che mất — và con số ước lượng cuối cùng cũng sai theo.

Gửi bài này cho người đang cần

Facebook

← Bài trước

Tôi Suýt Đăng Một Con Số Sai 76%