Khi triển khai LLM vào sản phẩm thực tế, một trong những câu hỏi đầu tiên tôi nhận được từ đội kỹ thuật không phải là 'làm sao để mô hình trả lời hay hơn' mà là 'làm sao để chi phí không giết chết dự án'. Rất nhiều bài viết hướng dẫn tối ưu bằng cách đổi mô hình nhỏ hơn hoặc lượng tử hóa, nhưng có một kỹ thuật đơn giản hơn nhiều, ít được khai thác đúng cách: prompt caching. Ý tưởng cốt lõi rất dễ hiểu. Khi bạn gửi một chuỗi hội thoại dài với cùng một system prompt, mỗi lượt trò chuyện mới lại phải tính toán lại toàn bộ phần đầu đó. Prompt caching cho phép lưu trữ phần prefix không đổi, và lần gọi sau chỉ phải xử lý phần mới thêm vào. Điều này giảm đáng kể số token đầu vào phải tính toán lại, kéo theo chi phí và độ trễ giảm mạnh. Một ví dụ thực tế: bạn xây dựng trợ lý hỗ trợ kỹ thuật cho phần mềm nội bộ, với system prompt dài mô tả quy trình, chính sách và định dạng phản hồi. Khi người dùng hỏi vài câu liên tiếp trong cùng một phiên, toàn bộ phần mô tả đó lặp lại ở mỗi lượt. Nếu không cache, bạn trả tiền cho việc xử lý lại hàng nghìn token giống hệt nhau mỗi lần. Khi có cache, chỉ phần tin nhắn mới được tính, phần còn lại đọc từ bộ nhớ tạm. Để áp dụng hiệu quả, tôi khuyên bạn nên sắp xếp prompt theo thứ tự ổn định: đặt system prompt và các tài liệu tham khảo ít thay đổi lên đầu, các câu hỏi và ngữ cảnh động xuống cuối. Điều này giúp prefix cache được tái sử dụng tối đa. Ngoài ra, hãy theo dõi thời gian tồn tại của cache trên nền tảng bạn dùng (thường vài phút đến vài giờ) và thiết kế phiên làm việc sao cho tận dụng được khoảng thời gian đó. Một lưu ý quan trọng: caching không phải là giải pháp cho mọi bài toán. Nếu prompt của bạn thay đổi liên tục, hoặc mỗi yêu cầu hoàn toàn độc lập, lợi ích sẽ rất nhỏ. Hãy đo lường trước khi tối ưu: ghi lại số token đầu vào trung bình, tỷ lệ prefix trùng lặp giữa các lượt gọi, rồi mới quyết định đầu tư. Thực tế triển khai cho thấy, với ứng dụng hội thoại dài hoặc hệ thống có system prompt phức tạp, prompt caching có thể giảm chi phí suy luận tới 90% mà không cần thay đổi chất lượng câu trả lời. Đây là bước tối ưu đầu tiên nên làm trước khi nghĩ đến việc đổi mô hình hay viết lại toàn bộ kiến trúc.