Prompt Caching Nâng Cao: Kỹ Thuật Giảm Chi Phí LLM Cho Developer

Phần lớn developer đã nghe về prompt caching — nhưng đa số chỉ dừng ở mức "cache prefix để tiết kiệm token". Kỹ thuật nâng cao hơn mở ra nhiều khả năng thú vị.
Tóm tắt nhanh
Prompt caching cơ bản lưu kết quả tính toán của phần đầu prompt. Khi một request mới có cùng prefix → hệ thống bỏ qua bước tính toán lại, chỉ xử lý phần mới. Kết quả: giảm chi phí, giảm latency.
Nhưng đó chỉ là bề mặt. Kỹ thuật nâng cao mở ra nhiều khả năng hơn.
Kỹ thuật 1: Semantic Prompt Templates
Thay vì mã cứng từng prompt, tạo template với placeholder mang ý nghĩa ngữ nghĩa. Ví dụ:
System: {role_description}
Context: {dynamic_context}
User: {user_query}
Khi caching, phần system và context được cache riêng biệt. Request mới chỉ cần thay đổi user_query. Phương pháp này giúp cache hit rate tăng đáng kể.
Kỹ thuật 2: Multi-Tier Caching
Không phải mọi token đều có giá trị cache như nhau. Phân tầng cache:
- Tier 1 (hot): System prompt + hướng dẫn cứng — cache vĩnh viễn hoặc rất lâu
- Tier 2 (warm): Context tài liệu — cache theo session hoặc request group
- Tier 3 (cold): Query của người dùng — không cache
Chi phí cache mỗi tier khác nhau. Tier 1 có thể cache hàng giờ, tier 2 chỉ vài phút. Khi thiết kế tier cache, cân nhắc giữa chi phí lưu trữ và tần suất tái sử dụng.
Kỹ thuật 3: Cache-Aware Prompt Design
Thiết kế prompt có tính đến caching từ đầu. Nguyên tắc:
- Đặt phần cố định (system instructions) ở đầu prompt
- Phần thay đổi (user query) ở cuối
- Tránh chèn thông tin động vào giữa phần cố định
Điều này nghe đơn giản, nhưng nhiều developer vẫn viết prompt theo thói quen — đặt query ở giữa, thêm context ở cuối. Kết quả: cache miss liên tục.
Kỹ thuật 4: Partial Cache Reuse
Một số API hỗ trợ cache theo segment thay vì toàn bộ prefix. Ví dụ, nếu prompt có 3 phần A-B-C, và request mới thay đổi B → chỉ cần cache lại B, phần A và C vẫn được tái sử dụng.
Để khai thác tính năng này, cần hiểu rõ API caching hoạt động theo cơ chế nào. Không phải tất cả provider đều hỗ trợ partial cache.
Kỹ thuật 5: Cache Invalidation Strategies
Cache invalidate đúng lúc cũng quan trọng như cache đúng chỗ:
- Time-based: Cache hết hạn sau N phút
- Event-based: Invalidate khi dữ liệu thay đổi
- Usage-based: Invalidate sau N request
- Kết hợp: Đa chiến lược cùng lúc
Mỗi chiến lược có trade-off riêng. Time-based đơn giản nhưng có thể phục vụ dữ liệu cũ. Event-based chính xác hơn nhưng cần hệ thống event bus.
Ví dụ thực tế
Xây chatbot hỗ trợ khách hàng. Mỗi conversation có:
- System prompt cố định (vai trò, hướng dẫn)
- Knowledge base thay đổi theo sản phẩm
- Message của người dùng
Với multi-tier caching: system prompt cache vĩnh viễn, knowledge base cache theo giờ, message không cache. Chi phí giảm 40-60% so với phương án không dùng cache.
Kết thúc
Prompt caching nâng cao không phải mẹo nhỏ — nó là kiến trúc. Khi build ứng dụng AI với hàng nghìn request mỗi ngày, caching quyết định hệ thống có khả thi về mặt kinh tế hay không. Bắt đầu từ tier caching và cache-aware prompt design, sau đó mở rộng sang partial cache khi cần scale.