Mở đầu — vì sao bài này quan trọng
Khi bạn còn ngồi nghịch prompt trong playground, chi phí gần như là con số zero — vài đồng lẻ, không ai để ý. Nhưng khoảnh khắc prompt của bạn được đưa vào production, chạy hàng nghìn, hàng chục nghìn lần mỗi ngày, mọi chuyện thay đổi hoàn toàn. Một prompt "chạy được" nhưng thừa 300 token có thể trông vô hại, nhưng nhân với 50.000 lượt gọi mỗi ngày, nó biến thành một hóa đơn khiến CFO nhíu mày cuối tháng.
Đây chính là điểm khác biệt giữa một người "biết viết prompt" và một prompt engineer thực thụ làm việc trong môi trường doanh nghiệp. Kỹ năng viết prompt hay đã được các bài trước (Bài 4 đến Bài 37) trang bị cho bạn. Bài này tập trung vào một câu hỏi rất thực tế mà mọi startup và doanh nghiệp Việt Nam đang triển khai AI đều phải trả lời: làm sao để cùng một chất lượng output nhưng tốn ít tiền nhất?
Token là đơn vị tiền tệ của thế giới LLM. Hiểu được token economy — cách token được tính, cách chúng biến thành chi phí, và cách cắt giảm mà không hy sinh chất lượng — là kỹ năng phân biệt giữa một dự án AI có lãi và một dự án "đốt tiền" rồi bị đóng cửa. Trong bài này, tôi sẽ chỉ cho bạn cách tư duy như một người quản lý ngân sách token, không phải chỉ như một người viết chữ.
Khái niệm cốt lõi
Công thức chi phí nền tảng
Mọi tính toán tối ưu đều bắt đầu từ công thức đơn giản này:
Tổng chi phí = (input_tokens × giá_input + output_tokens × giá_output) × số_request_trong_kỳ
Bốn biến số này chính là bốn "cần gạt" (levers) bạn có thể kéo để giảm chi phí:
- input_tokens — độ dài prompt gửi đi (system prompt + user prompt + context + few-shot examples).
- output_tokens — độ dài câu trả lời model sinh ra.
- giá mỗi token — phụ thuộc bạn chọn model nào.
- số request — có thực sự cần gọi LLM mỗi lần không, hay có thể cache/gộp?
Token không phải là từ
Một hiểu lầm phổ biến: token không bằng từ. Với tiếng Anh, trung bình 1 token ≈ 0,75 từ (khoảng 4 ký tự). Nhưng với tiếng Việt, tỷ lệ tệ hơn nhiều — do dấu thanh, ký tự Unicode và cách tokenizer chia nhỏ. Một câu tiếng Việt có thể tốn gấp 1,5 đến 2 lần số token so với câu tiếng Anh cùng nghĩa. Đây là điều mọi doanh nghiệp Việt Nam cần khắc cốt ghi tâm: cùng một sản phẩm, phục vụ khách Việt sẽ tốn nhiều token hơn phục vụ khách nói tiếng Anh. Điều này ảnh hưởng trực tiếp đến bài toán đơn giá.
Ba tầng đòn bẩy tối ưu
Tôi thường phân loại các chiến thuật tối ưu thành ba tầng, theo thứ tự ưu tiên áp dụng:
Tầng 1 — Chọn đúng model (đòn bẩy lớn nhất). Khoảng cách giá giữa model "flagship" và model "nhỏ/nhanh" có thể lên tới 10–20 lần. Không phải task nào cũng cần con model mạnh nhất. Phân loại email, gắn nhãn sentiment, trích xuất trường dữ liệu đơn giản — dùng model nhỏ là quá đủ. Chỉ dành model đắt cho các tác vụ đòi hỏi suy luận sâu.
Tầng 2 — Cắt giảm token (đòn bẩy trung bình). Rút gọn system prompt, giảm số few-shot example xuống mức tối thiểu cần thiết, giới hạn max_tokens đầu ra, yêu cầu output ngắn gọn (JSON thay vì văn xuôi giải thích).
Tầng 3 — Giảm số lần gọi (đòn bẩy dễ bị quên). Caching (bao gồm prompt caching của nhà cung cấp), batching nhiều item vào một request, và routing thông minh (không phải câu hỏi nào cũng cần LLM — nhiều câu có thể trả lời bằng rule hoặc lookup).
Prompt caching — vũ khí bị đánh giá thấp
Nhiều nhà cung cấp lớn hiện hỗ trợ prompt caching: nếu phần đầu prompt (system prompt, tài liệu tham chiếu, few-shot examples) lặp lại giống hệt nhau qua nhiều request, phần đó được cache lại và tính giá rẻ hơn nhiều — thường chỉ bằng 10% giá gốc — trong lần dùng lại. Với một chatbot hỗ trợ khách hàng có system prompt dài 2000 token dùng chung cho mọi cuộc hội thoại, caching có thể cắt giảm 40–60% chi phí input mà bạn gần như không phải thay đổi gì trong logic.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT "Chợ Việt" và bài toán 500.000 mô tả sản phẩm
Một sàn thương mại điện tử giả định tên "Chợ Việt" muốn tự động sinh mô tả sản phẩm cho 500.000 mặt hàng của các nhà bán nhỏ lẻ. Nhóm kỹ thuật ban đầu dùng model flagship với prompt chứa 6 few-shot example dài, mỗi mô tả sinh ra khoảng 400 token văn xuôi.
Con số ban đầu: mỗi request tốn khoảng 1500 input token + 400 output token. Với đơn giá flagship, chi phí xử lý toàn bộ danh mục lên tới hơn 300 triệu đồng — vượt xa ngân sách.
Nhóm áp dụng ba tầng đòn bẩy. Tầng 1: họ nhận ra sinh mô tả sản phẩm không cần suy luận phức tạp, nên chuyển sang model tầm trung, rẻ hơn 8 lần. Tầng 2: giảm từ 6 example xuống 2 example được chọn lọc kỹ, và giới hạn mô tả xuống 150 token — vừa đủ cho một đoạn bán hàng súc tích. Tầng 3: vì system prompt và example giống nhau cho mọi sản phẩm, họ bật prompt caching.
Kết quả: chi phí giảm còn khoảng 22 triệu đồng cho toàn bộ danh mục — cắt hơn 90%. Chất lượng mô tả, sau kiểm tra thủ công 200 mẫu, thậm chí còn tốt hơn vì ngắn gọn và đúng trọng tâm hơn.
Bài học: đừng bắt đầu bằng model mạnh nhất. Bắt đầu bằng model rẻ, đo chất lượng, chỉ nâng cấp khi thực sự cần. Và output ngắn không chỉ rẻ hơn — nó thường tốt hơn.
Ví dụ 2 — Fintech "MoMoney" và chatbot chăm sóc khách hàng
Một công ty fintech giả định "MoMoney" vận hành chatbot hỗ trợ với khoảng 40.000 cuộc hội thoại mỗi ngày. Mỗi cuộc trung bình 5 lượt trao đổi. Vấn đề: họ nhồi toàn bộ lịch sử hội thoại vào mỗi lượt gọi, khiến input token phình to dần theo mỗi lượt — lượt thứ 5 có thể mang theo 4000 token lịch sử.
Sau khi phân tích, họ làm ba việc. Thứ nhất, tóm tắt lịch sử cũ thay vì gửi nguyên văn: sau mỗi 3 lượt, một bản tóm tắt ngắn thay thế toàn bộ đoạn hội thoại trước đó, giữ nguyên ngữ cảnh quan trọng nhưng cắt 70% token. Thứ hai, routing: khoảng 35% câu hỏi là các FAQ lặp đi lặp lại ("Số dư của tôi là bao nhiêu?", "Phí chuyển khoản?") — những câu này được xử lý bằng logic rule hoặc câu trả lời template, không hề gọi LLM. Thứ ba, họ bật prompt caching cho system prompt dài chứa chính sách và tone giọng.
Chi phí LLM mỗi tháng giảm từ khoảng 180 triệu xuống còn 65 triệu đồng, trong khi thời gian phản hồi trung bình còn nhanh hơn vì nhiều câu được trả lời tức thì bằng rule.
Bài học: không phải câu hỏi nào cũng đáng gọi LLM. Một "cửa lọc" (router) đặt trước model là một trong những khoản đầu tư có ROI cao nhất. Và trong hội thoại nhiều lượt, quản lý lịch sử là mặt trận tiết kiệm token quan trọng nhất.
Ví dụ 3 — Agency marketing gộp batch để tiết kiệm
Một agency nhỏ ở TP.HCM dùng LLM để phân loại sentiment cho bình luận mạng xã hội của khách hàng — khoảng 200.000 bình luận mỗi tháng. Ban đầu, mỗi bình luận là một request riêng, mỗi request phải mang theo system prompt hướng dẫn phân loại dài 250 token. Nghĩa là 250 token "phí cố định" bị lặp lại 200.000 lần.
Họ chuyển sang batching: gộp 20 bình luận vào một request, yêu cầu model trả về một mảng JSON gồm 20 nhãn. Giờ 250 token system prompt được chia đều cho 20 item thay vì gánh bởi 1 item. Số request giảm 20 lần, và phần input token cố định gần như bốc hơi khỏi công thức.
Chi phí giảm khoảng 65%. Cần lưu ý một cái bẫy: batch quá lớn (ví dụ 100 item) khiến model dễ nhầm lẫn thứ tự hoặc bỏ sót — họ thử nghiệm và thấy 20 là điểm cân bằng tốt giữa tiết kiệm và độ chính xác.
Bài học: khi task giống nhau và độc lập, batching là đòn bẩy mạnh mà nhiều người quên. Nhưng phải tìm "sweet spot" của kích thước batch qua thử nghiệm thực tế, đừng đẩy tối đa.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng khi đưa bất kỳ prompt nào lên production:
Bước 1 — Đo lường trước khi tối ưu. Bạn không thể tối ưu thứ mình không đo. Đếm chính xác input token, output token trung bình mỗi request, và ước lượng số request mỗi ngày/tháng. Dùng công cụ đếm token của nhà cung cấp. Ghi lại con số chi phí cơ sở (baseline).
Bước 2 — Áp dụng công thức để tìm "điểm đau". Đưa số liệu vào công thức chi phí. Xác định biến số nào đang chiếm phần lớn hóa đơn: input hay output? Số request có bất thường không? Đây là bước giúp bạn nhắm đúng đòn bẩy thay vì tối ưu mò.
Bước 3 — Thử hạ cấp model. Chạy cùng bộ test với model rẻ hơn một bậc. Đo chất lượng bằng một tập đánh giá cố định (xem lại Bài 36 về prompt evaluation). Nếu chất lượng vẫn đạt ngưỡng chấp nhận, giữ model rẻ. Đây thường là khoản tiết kiệm lớn nhất.
Bước 4 — Cắt token đầu vào. Rà soát system prompt bỏ chữ thừa. Giảm few-shot example xuống mức tối thiểu còn giữ được chất lượng. Nếu có context dài, cân nhắc tóm tắt hoặc chỉ lấy phần liên quan.
Bước 5 — Kiểm soát token đầu ra. Đặt max_tokens hợp lý (không để mặc định quá cao). Yêu cầu format súc tích: JSON thay cho văn xuôi, "trả lời trong 2 câu", "chỉ trả về nhãn". Đây thường là đòn bẩy hiệu quả nhất vì output token đắt.
Bước 6 — Bật caching và cân nhắc batching/routing. Nếu phần đầu prompt lặp lại, bật prompt caching. Nếu task độc lập và đồng nhất, gộp batch. Nếu nhiều truy vấn có thể xử lý không cần LLM, đặt một router phía trước.
Bước 7 — Giám sát liên tục. Chi phí không phải việc làm một lần. Dựng dashboard theo dõi token và chi phí theo ngày, đặt cảnh báo (alert) khi vượt ngưỡng. Traffic tăng đột biến hoặc prompt bị chỉnh sửa có thể âm thầm thổi phồng hóa đơn.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng model flagship cho mọi thứ. Đây là lỗi phổ biến và tốn kém nhất. Mặc định chọn model mạnh nhất "cho chắc" là cách nhanh nhất đốt ngân sách. Hãy để model mạnh cho tác vụ khó, model nhỏ cho tác vụ đơn giản.
Lỗi 2 — Quên giới hạn max_tokens. Để mặc định, model có thể trả lời dài lê thê. Luôn đặt trần đầu ra phù hợp với nhu cầu thực tế.
Lỗi 3 — Nhồi cả kho tài liệu vào context. "Cứ đưa hết vào cho an toàn" là tư duy sai. Context dài không chỉ đắt mà còn có thể làm loãng sự chú ý của model, giảm chất lượng (xem Bài 12 về context window). Chỉ đưa phần liên quan.
Lỗi 4 — Tối ưu chi phí mà bỏ quên chất lượng. Cắt giảm mù quáng đến mức output kém sẽ khiến khách hàng bỏ đi — tốn kém hơn nhiều so với tiền token tiết kiệm được. Luôn giữ một tập đánh giá để đo chất lượng song song với chi phí.
Lỗi 5 — Quên chi phí tiếng Việt cao hơn. Khi ước lượng ngân sách cho sản phẩm phục vụ khách Việt, nhân hệ số token cao hơn. Nhiều dự án tính ngân sách theo con số tiếng Anh rồi vỡ kế hoạch.
Mẹo hay:
- Đặt "budget alert" theo ngày, không chỉ theo tháng — phát hiện sự cố sớm.
- Với hội thoại nhiều lượt, tóm tắt lịch sử cũ thay vì gửi nguyên văn.
- A/B test prompt ngắn với prompt dài: đôi khi prompt ngắn 40% cho chất lượng tương đương.
- Ghi log token của từng loại request để biết đâu là "kẻ ngốn token" cần xử lý trước.
Bài tập thực hành
Bài 1 — Tính chi phí baseline. Giả sử bạn vận hành một chatbot với: input 800 token/request, output 250 token/request, giá input 0,003 USD/1K token, giá output 0,015 USD/1K token, 20.000 request/ngày. Hãy tính chi phí mỗi ngày và mỗi tháng. Sau đó tính lại nếu bạn giảm output xuống 100 token và bật caching giúp giảm 50% input token. So sánh hai con số.
Bài 2 — Rà soát prompt của chính bạn. Lấy một prompt bạn đang dùng (hoặc một prompt từ các bài trước). Đếm token của nó. Viết lại phiên bản ngắn hơn 30% mà bạn tin vẫn giữ chất lượng. Chạy thử cả hai và tự đánh giá.
Bài 3 — Thiết kế router. Cho một chatbot ngân hàng, hãy liệt kê 5 loại câu hỏi có thể xử lý KHÔNG cần gọi LLM (bằng rule hoặc template) và 5 loại thực sự cần LLM. Giải thích tiêu chí phân loại của bạn.
Bài 4 — Quyết định batch size. Bạn cần phân loại 100.000 email. Hãy lập luận: nên chọn batch size bao nhiêu? Những rủi ro nào xuất hiện khi batch quá lớn? Bạn sẽ thử nghiệm thế nào để tìm điểm cân bằng?
Tóm tắt
Tối ưu chi phí token không phải là "keo kiệt" — đó là kỹ năng kỹ thuật giúp dự án AI của bạn tồn tại và có lãi khi lên quy mô lớn. Hãy ghi nhớ những điểm cốt lõi:
- Mọi thứ bắt đầu từ công thức:
Tổng chi phí = (input × giá_input + output × giá_output) × số_request. Bốn biến số này là bốn cần gạt của bạn. - Output đắt hơn input — kiểm soát độ dài câu trả lời thường mang lại hiệu quả lớn nhất.
- Ba tầng đòn bẩy theo thứ tự ưu tiên: chọn đúng model (lớn nhất), cắt giảm token, giảm số lần gọi (caching, batching, routing).
- Tiếng Việt tốn nhiều token hơn — luôn tính hệ số này vào ngân sách.
- Đo trước, tối ưu sau, giám sát liên tục — và không bao giờ hy sinh chất lượng đến mức mất khách.