BÍ QUYẾT TỐI ƯU TOKEN KHI SỬ DỤNG AI
Lưu ý: Nội dung bài viết không dựa trên một sự việc xảy ra trong dự án phát triển thực tế...
Câu chuyện bắt đầu từ một request rất bình thường!!!
“Một request tưởng chừng bình thường đã khiến cả team phát hiện ra nguyên nhân làm chi phí AI API tăng gần gấp đôi.”
Khoan đã, có gì đó không đúng...
Một sáng thứ Hai, như thường lệ tôi mở dashboard để kiểm tra chi phí AI API của dự án. Có một con số khiến tôi phải mở to mắt nhìn lại lần thứ hai “chi phí tăng gần gấp đôi” ư! Điều kỳ lạ là trong tuần đó không có thêm người dùng, không đổi model AI và cũng không triển khai thêm tính năng mới.
Phản ứng đầu tiên của cả team là đưa ra giả thuyết rằng Prompt có thể là nguyên nhân, vì đây là thành phần được cập nhật nhiều nhất trong quá trình phát triển.
Tuy nhiên, trong các hệ thống AI vận hành thực tế, chi phí API thường chịu ảnh hưởng bởi nhiều thành phần khác nhau của request. Thay vì kết luận dựa trên cảm tính, chúng tôi mở log của một request thực tế để phân tích và xác minh giả thuyết này.
📊 Log của request
System Prompt : 612 tokens
Conversation History : 4,382 tokens
RAG Documents : 1,756 tokens
User Question : 48 tokensTôi nhìn lại một lần nữa thì prompt chỉ tiêu hao hơn 600 token, trong khi lịch sử hội thoại đã vượt 4.000 token. Kết quả phân tích log cho thấy giả thuyết ban đầu chưa chính xác. Prompt chỉ chiếm khoảng 600 token, trong khi Conversation History đã vượt 4.000 token và trở thành thành phần cần ưu tiên phân tích.
Để xác định chính xác thành phần nào đang làm chi phí API tăng lên, trước tiên cần hiểu cách AI tính chi phí cho mỗi request:
Khác với nhiều API thông thường tính phí theo số lần gọi, hầu hết các mô hình AI hiện nay tính phí theo tổng số token mà chúng phải xử lý. Nói cách khác, cùng gọi API một lần nhưng request chứa nhiều Prompt, lịch sử hội thoại hoặc tài liệu sẽ tiêu tốn nhiều token hơn và có chi phí cao hơn.
Ví dụ, hai ứng dụng đều gọi AI API một lần:
• Ứng dụng A gửi khoảng 500 token.
• Ứng dụng B gửi khoảng 5.000 token.
Mặc dù đều chỉ gọi API một lần, ứng dụng B vẫn có chi phí cao hơn vì AI phải đọc và xử lý nhiều dữ liệu hơn.
Vì vậy, muốn tối ưu chi phí AI, điều quan trọng không phải là giảm số lần gọi API, mà là giảm lượng token thực sự cần thiết trong mỗi request.
Vì sao token lại ảnh hưởng đến chi phí?
Một request thực tế thường không chỉ có câu hỏi của người dùng. Nó còn bao gồm Prompt hệ thống, lịch sử hội thoại, tài liệu từ RAG và nhiều dữ liệu ngữ cảnh khác.
Những thành phần nào làm AI tiêu tốn nhiều token?
Dựa trên cấu trúc của một request AI, chúng tôi bắt đầu phân tích từng thành phần để xác định đâu là nguyên nhân chính làm số lượng token tăng lên.
Bắt đầu khoanh vùng nguyên nhân: Giống như khi debug một hệ thống, thay vì đoán mò, tôi bắt đầu khoanh vùng từng thành phần trong request để xem đâu là nơi tiêu tốn nhiều token nhất.
Danh sách khoanh vùng:
• Prompt
• Conversation History
• RAG Documents
• Tool Calling
• Output Token
Kết quả phân tích các thành phần trong request
*Lưu ý: Bài viết chỉ giới thiệu tổng quan các hướng tối ưu. Phần triển khai chi tiết như Summary Conversation History, Top-K Retrieval hay chiến lược chia chunk cho RAG sẽ được phân tích trong bài viết tiếp theo.
Kết luận:
Từ kết quả phân tích log và đối chiếu với cấu trúc của request AI, chúng tôi xác định Conversation History và RAG Documents là hai nguyên nhân chính làm số lượng token tăng cao. Conversation History tiêu tốn nhiều token do hệ thống gửi lại toàn bộ lịch sử hội thoại ở mỗi request, trong khi RAG Documents đưa vào quá nhiều tài liệu và chunk không liên quan đến câu hỏi hiện tại.
Bên cạnh đó, Tool Calling và Output Token cũng góp phần làm chi phí tăng khi Tool trả về quá nhiều field không cần thiết hoặc AI tạo câu trả lời dài hơn nhu cầu thực tế. Ngược lại, Prompt không phải nguyên nhân chính trong trường hợp này, vì chỉ chiếm một phần nhỏ trong tổng số token của request.
Như vậy, thay vì chỉ tập trung rút gọn Prompt, cần ưu tiên tối ưu Conversation History, giới hạn tài liệu RAG được retrieve, thu gọn dữ liệu từ Tool Calling và kiểm soát độ dài Output.
Tuy nhiên, xác định được nguyên nhân mới chỉ là bước đầu. Phần tiếp theo sẽ minh họa cách áp dụng các biện pháp tối ưu này vào một chatbot chăm sóc khách hàng cụ thể.
Tối ưu token cho chatbot chăm sóc khách hàng
💡 Ngữ cảnh
Bạn xây dựng chatbot hỗ trợ khách hàng cho một website bán điện thoại. Người dùng hỏi: “iPhone 16 Pro có được bảo hành 24 tháng không?”
📤 Request trước khi tối ưu
✓ System Prompt
(600 tokens)
✓ Conversation History
35 lượt hội thoại trước đó:
- Màu sắc
- Giá bán
- Trả góp
- Địa chỉ cửa hàng
- Chính sách đổi trả
(4.200 tokens)
✓ RAG Documents
- Chính sách bảo hành (18 trang)
- Hướng dẫn mua hàng (25 trang)
- Giới thiệu công ty (12 trang)
- Catalog sản phẩm (80 trang)
(2.300 tokens)
✓ Tool Calling
customerName
phone
email
address
orderHistory
rewardPoint
favoriteProducts
...
(800 tokens)
✓ User Question
iPhone 16 Pro có được bảo hành 24 tháng không?
(18 tokens)Tổng cộng AI phải xử lý gần 8.000 token chỉ để trả lời một câu hỏi rất đơn giản.
🔍 Sau khi kiểm tra log: Khi tách request thành từng phần, chúng tôi nhận ra phần lớn token không đến từ câu hỏi của người dùng. Lịch sử hội thoại cũ, tài liệu không liên quan và dữ liệu dư thừa từ Tool Calling mới là những phần cần được xử lý. Thay vì giảm dữ liệu một cách tùy ý, chúng tôi tối ưu từng thành phần theo bốn bước dưới đây:
Bước 1 - Rút gọn Conversation History: Hệ thống không còn gửi toàn bộ 35 lượt hội thoại ở mỗi request. Các cuộc hội thoại cũ được tóm tắt thành một đoạn ngắn, sau đó chỉ giữ lại 8 message gần nhất để AI vẫn hiểu được ngữ cảnh hiện tại.
4.200 tokens → 650 tokens
Bước 2 - Chỉ lấy tài liệu RAG thực sự liên quan: Tài liệu được chia thành các chunk nhỏ. Khi người dùng hỏi về bảo hành, hệ thống tìm kiếm theo nội dung câu hỏi và chỉ gửi Top 3 chunk có độ liên quan cao nhất, thay vì đưa cả hướng dẫn mua hàng, giới thiệu công ty và catalog sản phẩm vào request.
2.300 tokens → 350 tokens
Bước 3 - Thu gọn dữ liệu từ Tool Calling: Tool trước đây trả về toàn bộ hồ sơ khách hàng. Với câu hỏi về thời gian bảo hành, AI thực tế chỉ cần tên sản phẩm và thời hạn bảo hành.
- Trước tối ưu: { customerName, phone, email, address, orderHistory, rewardPoint, favoriteProducts, ... }
- Sau tối ưu: { productName, warrantyPeriod }800 tokens → 40 tokens
Bước 4 - Giới hạn độ dài câu trả lời: Vì người dùng chỉ cần biết thời hạn bảo hành, Prompt bổ sung yêu cầu trả lời trực tiếp trong 2-3 câu và giới hạn Output Token ở mức phù hợp. Việc này tránh trường hợp AI giải thích dài hơn nhu cầu nhưng không làm thay đổi nội dung chính của câu trả lời.
📤 Request sau khi tối ưu
✓ System Prompt
(600 tokens)
✓ Conversation History
Summary các cuộc hội thoại cũ + 8 message gần nhất
(650 tokens)
✓ RAG Documents
Top 3 chunk liên quan đến bảo hành
(350 tokens)
✓ Tool Calling
productName
warrantyPeriod
(40 tokens)
✓ User Question
iPhone 16 Pro có được bảo hành 24 tháng không?
(18 tokens)Kiểm tra chất lượng phản hồi sau tối ưu: Giảm token chỉ có ý nghĩa khi câu trả lời sau tối ưu vẫn đáp ứng đúng nhu cầu của người dùng. Vì vậy, chúng tôi chạy lại cùng một tập câu hỏi trước và sau khi thay đổi request, sau đó so sánh theo ba tiêu chí:
• Câu trả lời có đúng với nội dung trong chính sách bảo hành hay không.
• Có cung cấp đủ thông tin trực tiếp để giải quyết câu hỏi của người dùng hay không.
• Có xuất hiện thông tin sai, thiếu ngữ cảnh hoặc không liên quan hay không.
Với câu hỏi “iPhone 16 Pro có được bảo hành 24 tháng không?”, cả hai phiên bản đều trả về đúng thời hạn bảo hành và điều kiện áp dụng. Phiên bản sau tối ưu ngắn gọn hơn nhưng không làm mất thông tin cần thiết.
🎯 Kết quả
Sau khi tối ưu Conversation History, RAG Documents và Tool Calling, tổng số token của mỗi request giảm từ khoảng 8.000 xuống còn 1.600 token, tương đương giảm khoảng 80%.
💬 So sánh câu trả lời trước và sau tối ưu
Để kiểm tra việc giảm token có làm ảnh hưởng đến chất lượng phản hồi hay không, chúng tôi chạy lại cùng một câu hỏi trước và sau khi tối ưu request.
Câu hỏi: "iPhone 16 Pro có được bảo hành 24 tháng không?"
Nhận xét:
• Thông tin về thời hạn bảo hành được giữ nguyên.
• Điều kiện áp dụng không thay đổi.
• Phiên bản sau tối ưu ngắn gọn hơn nhưng vẫn trả lời đầy đủ câu hỏi của người dùng.
💡 Bài học rút ra
Điều quan trọng không phải là làm cho Prompt ngắn hơn mà là đừng bắt AI đọc những gì nó không cần. Khi số lượng request tăng lên mỗi ngày, việc giảm từ khoảng 8.000 xuống còn 1.600 token mỗi request sẽ tạo ra sự khác biệt rất lớn về chi phí vận hành trong khi chất lượng phản hồi gần như không thay đổi.
🏁 Kết bài
Sau khi áp dụng những thay đổi trên, điều đầu tiên tôi kiểm tra không phải là chất lượng câu trả lời mà là dashboard theo dõi chi phí AI API. Những con số bắt đầu giảm xuống rõ rệt, trong khi người dùng gần như không nhận ra bất kỳ thay đổi nào trong trải nghiệm sử dụng.
Điều thú vị là chúng tôi không đổi sang model rẻ hơn, không cắt giảm tính năng và cũng không viết lại toàn bộ Prompt. Chúng tôi chỉ thay đổi cách hệ thống cung cấp ngữ cảnh cho AI: gửi ít hơn nhưng đúng hơn. AI chỉ nhận những thông tin thực sự cần để trả lời câu hỏi, thay vì phải đọc toàn bộ lịch sử hội thoại, tài liệu hay dữ liệu không liên quan.
Nhìn lại toàn bộ quá trình điều tra, tôi nhận ra chi phí AI hiếm khi tăng vì một nguyên nhân duy nhất. Một chút Conversation History không còn giá trị, vài tài liệu RAG được retrieve quá nhiều, một JSON từ Tool Calling quá lớn hay một câu trả lời dài hơn mức cần thiết. Mỗi thứ riêng lẻ có vẻ không đáng kể, nhưng khi cộng lại qua hàng nghìn request mỗi ngày, chúng trở thành một khoản chi phí rất đáng quan tâm.
Trước đây, mỗi khi chi phí AI API tăng, tôi thường tự hỏi: ‘Prompt của mình đã tối ưu chưa?’. Sau cuộc điều tra này, tôi nghĩ câu hỏi đúng hơn là ‘AI có thực sự cần tất cả dữ liệu mà mình đang gửi hay không?’.
Chỉ cần thay đổi góc nhìn này, chúng ta sẽ dễ dàng phát hiện ra nhiều cơ hội tối ưu hơn.
Hy vọng những kinh nghiệm trong bài viết sẽ giúp bạn có thêm một góc nhìn khi xây dựng các ứng dụng tích hợp AI. Lần tới, trước khi nghĩ đến việc đổi model hoặc cắt giảm tính năng để tiết kiệm chi phí, hãy thử mở log của một request bất kỳ.
Trong nhiều dự án AI, chi phí không tăng vì model quá đắt, mà vì chúng ta đang gửi cho AI nhiều dữ liệu hơn mức cần thiết. Chỉ cần thay đổi góc nhìn này, bạn có thể tiết kiệm một khoản chi phí đáng kể mà không phải đánh đổi chất lượng phản hồi.
Nguồn tham khảo
[1] OpenAI - What are tokens and how to count them?
[2] Anthropic - Context windows
[3] Liu et al. - Lost in the Middle: How Language Models Use Long Contexts
[4] OpenAI - Controlling the length of model responses
[5] OpenAI - Prompt Caching
[6] Anthropic - Prompt caching
[7] Google AI for Developers - Context caching
[8] OpenAI - How to check token usage
[9] OpenAI API Pricing
Đừng để ý tưởng chỉ nằm trên giấy. Với tốc độ và sự linh hoạt đã được chứng minh qua 1.000+ dự án, chúng tôi sẽ giúp doanh nghiệp của bạn bứt phá.
Nhận tư vấn miễn phí ngayBài viết liên quan về "Generative AI & ML"
Thử biến Google Colab thành máy chủ API để chạy hội thoại giọng nói S2S
PoC này biến Google Colab thành máy chủ WebSocket tạm thời cho AI hội thoại giọng nói. Hệ thống kết hợp faster-whisper large-v3, Gemini 2.5 Flash-Lite, VOICEVOX và Silero VAD, đồng thời giảm độ trễ bằng phản hồi streaming, chia câu và tổng hợp giọng nói song song.
Sản xuất nội dung giọng nói AI: 5 cách làm
Nội dung giọng nói AI được tạo qua hai bước: AI viết kịch bản và TTS tổng hợp giọng nói. Bài viết giới thiệu 5 cách giúp ổn định chất lượng: bắt đầu với giọng có sẵn, cụ thể hóa phản hồi, quản lý yêu cầu và phiên bản, ưu tiên các đánh đổi, tổ chức buổi nghe chung và sử dụng hậu kỳ khi cần.
Sự khác biệt lớn giữa PoC và dịch vụ thương mại mà chúng tôi nhận ra khi phát triển AI hội thoại bằng Gemini
PoC AI hội thoại bằng Gemini Live API có thể được xây dựng nhanh, nhưng thương mại hóa làm phát sinh vấn đề về kết nối đồng thời, quota, giám sát, vòng đời model và âm thanh trên từng thiết bị. Bài viết chia sẻ quá trình chuyển từ kết nối trực tiếp trên trình duyệt sang LiveKit và Vertex AI.
