Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ra mắt một tính năng AI rất "ngầu": chatbot tư vấn sản phẩm trên website thương mại điện tử. Người dùng khen, traffic tăng, sếp gật gù. Rồi cuối tháng, hóa đơn từ nhà cung cấp mô hình về tới: 4.200 USD — gần 110 triệu đồng — chỉ riêng cho phần gọi LLM. Trong khi doanh thu tăng thêm từ tính năng đó chỉ khoảng 40 triệu. Bạn vừa xây một tính năng làm công ty lỗ mỗi khi người dùng tương tác.
Đây là tình huống có thật mà rất nhiều PM gặp phải khi lần đầu đưa AI vào sản phẩm. Khác với phần mềm truyền thống — nơi chi phí biên (marginal cost) của mỗi user gần như bằng 0 — sản phẩm AI có một đặc điểm kinh tế hoàn toàn mới: mỗi request đều tốn tiền thật, và chi phí đó tỷ lệ thuận với mức độ sử dụng. Càng nhiều người dùng yêu thích sản phẩm, hóa đơn càng phình to.
Là một AI Product Manager, bạn không cần biết cách code mô hình, nhưng bạn bắt buộc phải hiểu token economics — kinh tế học của token. Đây là kỹ năng phân biệt một PM "biết dùng AI" với một PM "xây được sản phẩm AI bền vững về tài chính". Bài này tập trung hoàn toàn vào một câu hỏi cốt lõi: một request tốn bao nhiêu tiền, và làm sao tính được con số đó trước khi nó biến thành hóa đơn?
Khái niệm cốt lõi
Token là gì và vì sao lại tính tiền theo token
Token là đơn vị nhỏ nhất mà LLM xử lý văn bản. Một token không phải là một từ — nó là một mảnh từ (subword). Theo quy ước thực tế của hầu hết mô hình tiếng Anh, 1 token ≈ 4 ký tự ≈ 0,75 từ. Nói cách khác, 1.000 từ tiếng Anh tương đương khoảng 1.300–1.400 token.
Với tiếng Việt, tỷ lệ này kém thuận lợi hơn nhiều. Do dấu thanh và cách các tokenizer (bộ tách token) phổ biến được huấn luyện chủ yếu trên tiếng Anh, một câu tiếng Việt thường tốn nhiều token hơn câu tiếng Anh cùng nghĩa — có khi gấp 1,5 đến 2 lần. Ví dụ: chữ "Nguyễn" có thể bị tách thành 3–4 token. Đây là một sự thật quan trọng mà PM Việt Nam hay bỏ qua: cùng một sản phẩm, vận hành bằng tiếng Việt thường đắt hơn vận hành bằng tiếng Anh xét trên mỗi đơn vị nội dung.
Nhà cung cấp tính tiền theo token vì đó là đơn vị tương ứng trực tiếp với lượng tính toán (compute) mà GPU phải thực hiện. Mỗi token mô hình sinh ra đều cần một lượt chạy qua toàn bộ mạng nơ-ron.
Input và output được tính riêng — và output đắt hơn nhiều
Đây là điểm mấu chốt của cả bài. Một request gửi tới LLM có hai dòng token tách biệt:
- Input token (prompt token): mọi thứ bạn gửi vào — system prompt, lịch sử hội thoại, tài liệu đính kèm, câu hỏi của người dùng.
- Output token (completion token): mọi thứ mô hình sinh ra trả lại cho bạn.
Hãy nhìn một bảng giá minh họa (giá tham khảo, mỗi triệu token):
| Hạng mô hình | Input (USD/1M token) | Output (USD/1M token) | Tỷ lệ out/in |
|---|---|---|---|
| Mô hình cao cấp (frontier) | 3,00 | 15,00 | 5x |
| Mô hình tầm trung | 0,80 | 4,00 | 5x |
| Mô hình nhỏ/nhanh | 0,15 | 0,60 | 4x |
Công thức tính chi phí một request
Công thức cốt lõi mà bạn cần thuộc lòng:
Chi phí 1 request = (số input token / 1.000.000) × giá input
+ (số output token / 1.000.000) × giá output
Và để lập kế hoạch tài chính, mở rộng ra quy mô:
Chi phí tháng = Chi phí 1 request × số request trung bình / user / tháng × số user hoạt động
Nắm được hai công thức này, bạn đã có thể trả lời câu hỏi mà mọi CEO sẽ hỏi: "Nếu chúng ta có 100.000 người dùng, tính năng này tốn bao nhiêu một tháng?"
Phân biệt cost-per-request và unit economics
Đừng nhầm hai khái niệm. Cost-per-request là chi phí kỹ thuật thuần của một lượt gọi mô hình. Unit economics là bức tranh rộng hơn: chi phí AI trên mỗi đơn vị giá trị kinh doanh (mỗi user, mỗi đơn hàng, mỗi vé hỗ trợ được giải quyết). Một request có thể chỉ tốn 200 đồng, nhưng nếu để giải quyết xong một yêu cầu của khách hàng cần 15 lượt gọi qua lại, thì unit economics thực sự là 3.000 đồng — gấp 15 lần. PM giỏi luôn tính ở tầng unit economics, không dừng ở từng request lẻ.
Tình huống thực tế
Ví dụ 1 — Chatbot hỗ trợ khách hàng của một sàn TMĐT Việt Nam
Bối cảnh: Một sàn thương mại điện tử tầm trung tại TP.HCM triển khai chatbot trả lời câu hỏi về đơn hàng. Mỗi cuộc hội thoại trung bình:
- System prompt + hướng dẫn: 800 token
- Ngữ cảnh đơn hàng kéo từ database: 600 token
- Câu hỏi người dùng: 150 token
- → Tổng input ≈ 1.550 token
- Output trung bình: 250 token
- Input: 1.550 / 1.000.000 × 0,80 = 0,00124 USD
- Output: 250 / 1.000.000 × 4,00 = 0,001 USD
- Tổng 1 lượt ≈ 0,00224 USD ≈ 58 đồng
Bài học rút ra: chi phí "tí hon" mỗi lượt đánh lừa trực giác. Cái giết bạn là cấp số nhân của lịch sử hội thoại và quy mô. Luôn tính tới cấp tháng, không bao giờ đánh giá ở cấp một request.
Ví dụ 2 — Tính năng tóm tắt văn bản dài bị "vung tay output"
Bối cảnh: Một startup legaltech ở Hà Nội làm công cụ tóm tắt hợp đồng. Phiên bản đầu, prompt yêu cầu mô hình "tóm tắt chi tiết, đầy đủ mọi điều khoản". Kết quả: input 8.000 token (hợp đồng dài), output trung bình 2.500 token.
- Input: 8.000 / 1M × 3,00 = 0,024 USD
- Output: 2.500 / 1M × 15,00 = 0,0375 USD (dùng mô hình cao cấp)
- Tổng ≈ 0,0615 USD ≈ 1.600 đồng/bản tóm tắt
Bài học rút ra: output token là đòn bẩy tối ưu chi phí mạnh nhất. Một câu lệnh "hãy trả lời ngắn gọn trong 3 gạch đầu dòng" có thể tiết kiệm hơn cả việc đổi mô hình.
Ví dụ 3 — Định giá sản phẩm dựa trên cost-per-request
Bối cảnh: Một app học tiếng Anh ở Đông Nam Á muốn bán gói "luyện nói AI không giới hạn" giá 99.000đ/tháng. Trước khi chốt giá, PM tính: mỗi phút luyện nói tiêu tốn ≈ 0,02 USD chi phí AI (gồm cả speech-to-text và LLM). Một user nhiệt tình luyện 60 phút/tháng → 1,2 USD ≈ 31.000đ chi phí. Một "power user" luyện 200 phút → 4 USD ≈ 104.000đ — vượt cả giá gói.
PM quyết định: gói "không giới hạn" thực chất đặt giới hạn mềm 90 phút/tháng (đủ cho 95% user), và thiết kế gói cao cấp cho power user. Nhờ tính cost-per-request trước khi định giá, công ty tránh được mô hình kinh doanh thua lỗ ngay từ thiết kế.
Bài học rút ra: cost-per-request phải là một đầu vào của quyết định pricing, không phải con số khám phá sau khi đã ra mắt. "Unlimited" trong sản phẩm AS gần như luôn cần một trần ẩn.
Hướng dẫn từng bước
Đây là quy trình để bạn ước tính chi phí một tính năng AI trước khi xây:
Bước 1 — Vẽ ra anatomy của một request. Liệt kê mọi thành phần đi vào input: system prompt, few-shot example, ngữ cảnh/tài liệu, lịch sử hội thoại, câu hỏi người dùng. Ước lượng độ dài từng phần bằng từ, rồi nhân ~1,3 (tiếng Anh) hoặc ~1,8–2,0 (tiếng Việt) để ra token.
Bước 2 — Ước lượng output. Output dài bao nhiêu là quyết định thiết kế của bạn, không phải định mệnh. Hãy đặt một con số mục tiêu (ví dụ "tối đa 300 token") và đưa nó vào prompt.
Bước 3 — Tra bảng giá và áp công thức. Lấy đúng cặp giá input/output của mô hình bạn định dùng, tính chi phí một request bằng công thức ở trên.
Bước 4 — Nhân tần suất. Một user dùng bao nhiêu request/ngày? Bao nhiêu lượt trong một "task" hoàn chỉnh? Nhân lên ra chi phí/user/tháng.
Bước 5 — Nhân quy mô và so với doanh thu. Nhân với số user kỳ vọng. Đặt cạnh ARPU (doanh thu trung bình/user). Nếu chi phí AI ăn quá 20–30% doanh thu của tính năng, hãy quay lại tối ưu trước khi ra mắt.
Bước 6 — Đo thực tế và hiệu chỉnh. Sau khi ra mắt, log số token thật của từng request. Ước lượng của bạn gần như chắc chắn lệch — thường là output dài hơn dự kiến. Dùng dữ liệu thật để cập nhật mô hình tài chính.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ nhìn giá input. Nhiều người so sánh mô hình chỉ qua giá input vì nó là con số được quảng cáo nhiều. Luôn tính cả input lẫn output theo tỷ lệ thực tế của sản phẩm bạn (blended cost). Một app sinh nhiều output sẽ chịu ảnh hưởng của giá output nhiều hơn.
Lỗi 2 — Quên rằng lịch sử hội thoại được gửi lại mỗi lượt. Đây là cái bẫy đắt đỏ nhất. Trong chatbot, input phình lên theo từng lượt. Mẹo: cắt bớt lịch sử cũ, hoặc tóm tắt lịch sử thành một đoạn ngắn — đây là phần "context window management" sẽ bàn kỹ ở bài khác, nhưng về kinh tế thì bạn phải ý thức ngay.
Lỗi 3 — Bỏ qua chi phí tiếng Việt. Lập kế hoạch bằng số token tiếng Anh rồi triển khai sản phẩm tiếng Việt → ngân sách thực tế đội lên 50–100%. Luôn đo token trên dữ liệu tiếng Việt thật.
Lỗi 4 — Dùng mô hình cao cấp cho mọi việc. Phân loại email, trích xuất thông tin, gắn nhãn... không cần mô hình đắt nhất. Mẹo lớn: hãy nghĩ "bài toán này cần IQ bao nhiêu?" và chọn mô hình rẻ nhất đủ giải. (Chiến lược chọn và định tuyến mô hình là chủ đề của bài tiếp theo.)
Mẹo vàng — Tận dụng prompt caching. Nhiều nhà cung cấp cho phép cache phần input lặp lại (như system prompt dài, tài liệu cố định) với giá rẻ hơn nhiều — có khi chỉ 10% giá input thường. Nếu sản phẩm của bạn gửi đi gửi lại cùng một khối ngữ cảnh, caching có thể cắt 50–80% chi phí input. Đây là "bữa trưa miễn phí" hiếm hoi trong token economics.
Mẹo — Đặt max_tokens cho output. Đừng để mô hình tự do "nói dài". Tham số max_tokens đặt trần cứng, vừa kiểm soát chi phí vừa giữ UX gọn gàng.
Bài tập thực hành
- Tính cost-per-request cho sản phẩm của bạn. Chọn một tính năng AI (có thật hoặc giả định). Vẽ anatomy của một request, ước lượng input và output token (nhớ nhân hệ số tiếng Việt), rồi áp công thức với một bảng giá mô hình tầm trung. Ghi ra con số bằng đồng.
- Mô phỏng cấp tháng. Giả định 50.000 user hoạt động, mỗi người dùng 3 task/tháng, mỗi task 4 lượt gọi (input phình theo lịch sử). Tính tổng chi phí tháng. Nếu ARPU là 30.000đ, chi phí AI chiếm bao nhiêu phần trăm doanh thu?
- Bài toán tối ưu. Lấy kết quả bài 2. Hãy đề xuất 3 thay đổi cụ thể (về độ dài output, về quản lý lịch sử, về chọn mô hình hoặc caching) và ước tính phần trăm tiết kiệm của mỗi thay đổi. Mục tiêu: giảm tổng chi phí xuống dưới 20% doanh thu.
- So sánh tiếng Anh vs tiếng Việt. Lấy cùng một prompt, viết bản tiếng Anh và bản tiếng Việt, đếm độ dài ký tự. Ước lượng chênh lệch token và chênh lệch chi phí. Rút ra kết luận cho roadmap đa ngôn ngữ.
Tóm tắt
Token economics là nền tảng tài chính của mọi sản phẩm AI, và là điểm khác biệt căn bản giữa phần mềm AI với phần mềm truyền thống: chi phí biên không còn bằng 0. Những điều cốt lõi cần nhớ:
- LLM tính tiền theo token, input và output riêng biệt, và output thường đắt hơn input 3–5 lần vì phải sinh tuần tự.
- Công thức cost-per-request = (input token × giá input) + (output token × giá output), rồi nhân tần suất và quy mô để ra chi phí tháng.
- Output token là đòn bẩy tối ưu mạnh nhất — kiểm soát độ dài câu trả lời trước khi nghĩ tới việc đổi mô hình.
- Tiếng Việt tốn nhiều token hơn tiếng Anh; lịch sử hội thoại gửi lại mỗi lượt là cái bẫy chi phí phổ biến nhất; prompt caching là vũ khí tiết kiệm lớn.
- Cost-per-request phải là đầu vào của quyết định pricing, không phải phát hiện sau khi ra mắt.