Cost và latency AI feature: tính từ token trước khi code

TL;DR: Cost và latency của một AI feature tính được trước khi viết dòng code nào, chỉ từ số token vào/ra: cost = (token vào × giá vào + token ra × giá ra) × số request, latency = thời gian tới token đầu tiên + thời gian mỗi token × số token ra. Token ra luôn có giá cao hơn token vào, vì model xử lý token vào trong một lượt nhưng phải sinh token ra tuần tự, từng token một — và khi token ra đủ dài, chính vòng lặp sinh đó chiếm phần lớn thời gian chờ. Bốn đòn bẩy giảm — cache, model nhỏ hơn cho việc dễ, cắt context, streaming — không đổi công thức, chỉ đổi các biến trong đó. Bẫy lớn nhất khi ước lượng cho người dùng Việt: cùng nội dung tốn token hơn tiếng Anh, nên đếm từ rồi suy ra token là sai ngay từ bước đầu.

Sếp hỏi trước khi bạn viết dòng code đầu tiên: "Chatbot này chạy một tháng tốn bao nhiêu, người dùng chờ bao lâu mới thấy câu trả lời?" Bài này trả lời bằng công thức, không bằng cảm tính — chọn đòn bẩy nào cho một tình huống cụ thể thuộc bài mini-challenge cuối module.

1. Analogy — bài thi tự luận: đọc đề vs viết bài

Đọc đề thi tốn một lượt: mắt lướt qua toàn bộ câu hỏi gần như cùng lúc, đề dài thêm vài dòng không kéo dài thời gian đọc bao nhiêu. Viết bài luận thì khác — bạn viết ra từng câu một, và bài dài gấp đôi thì thời gian viết cũng gần gấp đôi thật.

2. Hai công thức — cost và latency tính từ token vào/ra

function cost_moi_request(token_vao, token_ra, gia_vao, gia_ra):
    return token_vao * gia_vao + token_ra * gia_ra   -- gia tinh theo don vi tien / token

function cost_moi_thang(token_vao, token_ra, gia_vao, gia_ra, request_moi_ngay):
    return cost_moi_request(token_vao, token_ra, gia_vao, gia_ra) * request_moi_ngay * 30

function latency_moi_request(ttft, thoi_gian_moi_token, token_ra):
    return ttft + thoi_gian_moi_token * token_ra       -- token ra dai la thu pham chinh

ttft — time-to-first-token: khoảng chờ từ lúc gửi request tới lúc chữ đầu tiên xuất hiện. thoi_gian_moi_token là thời gian sinh thêm một token ra sau đó.

Giá token ra luôn cao hơn giá token vào — không ngẫu nhiên, mà đúng theo cơ chế ở mục 3.

3. Vì sao token vào rẻ và nhanh hơn token ra?

Prefill (đọc token vào): model xử lý toàn bộ N token vào trong một lượt song song — như đọc cả đề bài cùng lúc.

Decode (sinh token ra): sinh token thứ hai cần biết token thứ nhất vừa sinh ra là gì — token trước làm đầu vào cho bước sinh token sau, nên vòng lặp này bắt buộc chạy tuần tự. Sinh M token tốn đúng M bước, không rút gọn thành một lượt như prefill được.

Đây là căn nguyên của cả hai vế: token ra tốn nhiều bước tính toán hơn nên giá cao hơn, và token ra chiếm phần lớn thời gian chờ vì decode là vòng lặp còn prefill chỉ một lượt (mục 4 tính rõ tỉ lệ này bằng số).

4. Bài tập ước lượng — chatbot hỗ trợ nội bộ ngân hàng (môi trường dev)

Tình huống: một ngân hàng thử nghiệm chatbot tra cứu quy trình nội bộ ở môi trường dev, chưa lên production. Mỗi request gồm system prompt + câu hỏi + ngữ cảnh trích từ tài liệu, tổng 1600 token vào; câu trả lời trung bình 300 token ra. Khối lượng dùng thử: 200 request/ngày.

Gợi ý: 200 request/ngày là bao nhiêu request/tháng? Với chỉ 300 token ra so với 1600 token vào, phần nào đóng góp nhiều hơn vào cost một request (nhớ: giá ra cao hơn giá vào)? Với latency, bạn cần giả định thêm hai đại lượng nào để tính được (mục 2 đã đặt tên chúng) — và tra chúng ở đâu cho một model thật?

Lời giải — dùng mức giá minh hoạ bậc độ lớn cho một model tầm trung, giữa 2026 (không phải giá chính xác của model cụ thể — luôn tra provider tại thời điểm ước lượng thật): giá vào cỡ 0,5 USD/1 triệu token, giá ra cỡ 2,5 USD/1 triệu token.

cost_vao = 1600 * 0,5 USD/1_000_000 = 0,0008 USD
cost_ra  =  300 * 2,5 USD/1_000_000 = 0,00075 USD
cost_1_request ≈ 0,0016 USD

request_thang = 200 * 30 = 6000
cost_thang = 6000 * 0,0016 USD ≈ 9-10 USD/thang

Dù token ra chỉ bằng chưa tới 1/5 số lượng token vào, phần đóng góp cost gần bằng nhau — giá ra cao hơn bù lại số lượng ít hơn. Bậc độ lớn: cỡ chục đô-la một tháng cho dev.

Tương tự, TTFT và thời gian mỗi token dưới đây là giả định minh hoạ bậc độ lớn cho một model tầm trung, giữa 2026 — không phải số đo thật; luôn đo lại khi ước lượng thật:

ttft = 0,4 giay
thoi_gian_decode = 300 * 0,025 giay/token = 7,5 giay
latency_1_request = 0,4 + 7,5 = 7,9 giay

Decode chiếm 7,5/7,9 ≈ 95% tổng latency — bằng chứng bằng số cho cơ chế mục 3: gần như toàn bộ độ trễ nằm ở sinh 300 token ra, không phải đọc 1600 token vào. Lưu lượng gấp 100 lần thì cost gấp 100 lần (cộng dồn theo số request), nhưng latency mỗi request không đổi — công thức mục 2 không có biến số request.

5. Bốn đòn bẩy giảm cost và latency (tham chiếu)

6. Vì sao đếm từ tiếng Việt để suy ra token là sai?

Petrov và cộng sự (arXiv:2305.15425) đo chênh lệch token giữa các cặp ngôn ngữ tới 15 lần ở trường hợp cực đoan (script khác Latin) — không phải số đo riêng cho Việt-Anh. Tiếng Việt tốn token hơn tiếng Anh cùng nội dung, nhưng muốn con số cụ thể phải tự đo bằng tokenizer định dùng (đưa văn bản mẫu qua, đếm token trả về) — 1600 và 300 token ở mục 4 đến từ phép đo đó, không phải đoán theo số từ.

7. Pitfall tổng hợp

❌ Nhầm 1 — gộp chung cost và latency khi lưu lượng tăng:

✅ Cost cộng dồn theo số request (mục 4: gấp 100 lần request thì cost gấp 100 lần); latency mỗi request chỉ phụ thuộc độ dài chính nó, không phụ thuộc số request khác đang chạy (bỏ qua nghẽn hàng đợi hạ tầng). Tăng lưu lượng làm hoá đơn phình to, không tự làm mỗi lượt chậm hơn.

❌ Nhầm 2 — cắt token vào để tiết kiệm khi token ra mới là phần đắt của request đó:

✅ Nếu request có token ra dài (tóm tắt dài, sinh nhiều code), đòn bẩy đúng là giảm token ra — giới hạn độ dài câu trả lời — không phải cắt token vào trong khi token ra vẫn giữ nguyên.

❌ Nhầm 3 — tưởng streaming giảm cost hoặc giảm tổng thời gian sinh:

✅ Streaming chỉ đổi cách hiển thị. Tổng token phải sinh, tổng thời gian, tổng tiền đều không đổi (mục 5).

8. 📚 Deep Dive

9. Liên hệ các bài khác

• Bài 01 — Nguyên tắc prompt bám cơ chế — prompt dài (few-shot, hướng dẫn chi tiết) cộng thêm token vào, đúng cái giá công thức mục 2 tính.
• Bài 04 — Eval & golden set — chạy eval qua nhiều request thật cũng tính hoá đơn theo công thức này.
• Bài 07 — Mini-challenge: ship checklist — nơi bạn chọn đòn bẩy nào cho một scenario cụ thể.
• Cỗ máy LLM — Tokenization — nguồn của mọi con số token trong bài này.

10. Tóm tắt

• Cost một request = token vào × giá vào + token ra × giá ra; nhân với số request/tháng ra hoá đơn thật.
• Latency một request = thời gian tới token đầu tiên (TTFT) + thời gian mỗi token × số token ra.
• Token vào xử lý một lượt (prefill), token ra sinh tuần tự (decode) — đây là lý do token ra vừa đắt hơn vừa là thủ phạm chính của latency khi đủ dài.
• Bài tập ước lượng: 1600 token vào + 300 token ra, 200 request/ngày → cost cỡ chục đô/tháng, latency cỡ 8 giây, decode chiếm khoảng 95% latency.
• Bốn đòn bẩy tham chiếu: cache, model nhỏ hơn cho việc dễ, cắt context, streaming — chỉ đổi biến trong công thức, không đổi công thức.
• Ước lượng token cho tiếng Việt phải đo bằng tokenizer thật — đếm từ rồi suy ra token là sai.
• Cost cộng dồn theo số request; latency mỗi request không phụ thuộc số request khác đang chạy cùng lúc.

11. Tự kiểm tra

Bài tiếp theo: Privacy & prompt injection