Source: https://aiprimetech.io/vi/blog/prompt-caching-explained/ Tháng Sáu 17, 2026 · 6 phút · API # Giải thích về bộ nhớ đệm prompt: Khi nào tiết kiệm chi phí và khi nào không A Tác giả [AI Prime Tech](https://aiprimetech.io/vi/) · Có AI hỗ trợ Vào lúc 9:12 sáng thứ Hai, một trong các tác nhân hỗ trợ của chúng tôi bắt đầu phát sinh chi phí cao hơn dự kiến 4x. Mô hình không tạo thông tin bịa đặt, biểu đồ lưu lượng không sai, và không ai vô tình chuyển từ Haiku sang Opus. Vấn đề đơn giản hơn: mỗi yêu cầu đều chứa cùng một tài liệu chính sách dài 42,000 token, nhưng tỷ lệ trúng bộ nhớ đệm prompt của chúng tôi gần như bằng không vì chúng tôi chèn dấu thời gian mới và siêu dữ liệu riêng của người dùng trước tài liệu đó. Cùng nội dung. Cùng mô hình. Cùng ứng dụng. Không tiết kiệm được gì từ bộ nhớ đệm. Lưu bộ nhớ đệm cho prompt là một trong những tính năng nghe có vẻ tự động cho đến khi bạn cố giảm hóa đơn. Trên thực tế, tính năng này mang lại lợi ích cho một cấu trúc prompt rất cụ thể: một phần tiền tố lớn, ổn định, được tái sử dụng trong nhiều yêu cầu. Nếu hiểu câu đó, bạn thường có thể dự đoán liệu bộ nhớ đệm có giúp tiết kiệm chi phí hay âm thầm không mang lại tác dụng gì. ## Bộ nhớ đệm prompt thực sự lưu những gì Bộ nhớ đệm prompt không phải là bộ nhớ ngữ nghĩa. Nhà cung cấp không nói: “Nội dung này có vẻ giống thứ bạn đã gửi trước đây.” Cách hoạt động gần với điều sau hơn: “Phần đầu của yêu cầu này khớp với một chuỗi token trước đó ở mức đủ đáp ứng yêu cầu của mô hình và chính sách bộ nhớ đệm này, nên chúng tôi có thể tái sử dụng phần tính toán nội bộ cho tiền tố đó.” Sự phân biệt đó rất quan trọng. Bộ nhớ đệm prompt thường hữu ích khi bạn liên tục gửi cùng một tiền tố dài: - Chỉ dẫn hệ thống - Lược đồ công cụ - Các bộ tài liệu dài - Danh mục sản phẩm - Ngữ cảnh mã nguồn - Tài liệu pháp lý hoặc chính sách - Ví dụ few-shot - Kết quả truy xuất tĩnh được tái sử dụng trong nhiều yêu cầu Bộ nhớ đệm thường không giúp ích nhiều khi mỗi yêu cầu có phần đầu khác nhau: - Dấu thời gian động ở đầu - Dữ liệu riêng của người dùng đặt trước nội dung dùng chung - Thứ tự ví dụ được xáo trộn ngẫu nhiên - UUID riêng cho từng yêu cầu nằm trong phần có thể lưu vào bộ nhớ đệm - Các đoạn truy xuất thay đổi thứ tự hoặc định dạng - Lịch sử trò chuyện đặt trước các chỉ dẫn ổn định Biện pháp kỹ thuật cốt lõi là đặt ngữ cảnh ổn định, tốn nhiều chi phí ở đầu và ngữ cảnh hay thay đổi ở phía sau. ## Anthropic và OpenAI: Mục tiêu tương tự, cách kiểm soát khác nhau Anthropic và OpenAI đều hỗ trợ bộ nhớ đệm prompt, nhưng trải nghiệm sử dụng của nhà phát triển khác nhau. Anthropic cung cấp khả năng kiểm soát bộ nhớ đệm prompt rõ ràng hơn. Bạn có thể đánh dấu các khối nội dung bằng các thiết lập kiểm soát bộ nhớ đệm, rồi kiểm tra các trường thông tin sử dụng như cache_creation_input_tokens và cache_read_input_tokens. Điều này giúp bạn dễ xác định hơn liệu mình đang tạo mục bộ nhớ đệm hay đọc từ chúng. Bộ nhớ đệm prompt của OpenAI hoạt động tự động hơn trên các mô hình được hỗ trợ. Khi một tiền tố prompt được tái sử dụng, các token đầu vào được lưu trong bộ nhớ đệm có thể được tính phí theo cách khác và hiển thị trong siêu dữ liệu sử dụng. Bạn thường không đặt các điểm ngắt bộ nhớ đệm tường minh theo cùng cách; thay vào đó, bạn cấu trúc yêu cầu sao cho tiền tố có thể tái sử dụng giữ nguyên ở cấp byte/token. Khác biệt thực tế nằm ở khả năng kiểm soát so với sự tiện lợi. | Tiêu chí | Bộ nhớ đệm tường minh theo cách của Anthropic | Bộ nhớ đệm tự động theo cách của OpenAI | Khả năng kiểm soát của nhà phát triển | Cao hơn; bạn có thể đánh dấu các khối có thể lưu vào bộ nhớ đệm | Thấp hơn; nhà cung cấp phát hiện các tiền tố có thể tái sử dụng | Khả năng gỡ lỗi | Thường rõ ràng hơn nhờ các bộ đếm tạo/đọc bộ nhớ đệm | Phụ thuộc vào siêu dữ liệu sử dụng mà mô hình/API cung cấp | Tầm quan trọng của cấu trúc prompt | Rất cao | Rất cao | Phù hợp nhất với | Các khối tĩnh lớn, công cụ, tài liệu, ví dụ | Các tiền tố dài được tái sử dụng qua nhiều lần gọi | Lỗi thường gặp | Điểm ngắt bộ nhớ đệm đặt sau nội dung động | Tiền tố thay đổi trước khi bộ nhớ đệm có thể khớp | Cách hình dung | “Tôi đang ghi và đọc một tiền tố gần như có tên riêng” | “Nhà cung cấp nhận ra tiền tố lặp lại này” Chi tiết triển khai khác nhau tùy mô hình và nhà cung cấp, đồng thời vẫn tiếp tục thay đổi. Nhưng nguyên tắc kiến trúc vẫn ổn định: bộ nhớ đệm dựa trên các tiền tố lặp lại, không phải các prompt tương tự nhau. ## Mô hình định giá: Tạo và đọc Một cách hữu ích để hiểu bộ nhớ đệm prompt là chia token đầu vào thành ba nhóm: - Token đầu vào thông thường: được tính phí theo giá đầu vào thông thường. - Token tạo bộ nhớ đệm: các token dùng để tạo một mục bộ nhớ đệm, thường được tính phí cao hơn hoặc theo mức giá ghi riêng. - Token đọc bộ nhớ đệm: các token được đọc từ một mục bộ nhớ đệm hiện có, thường được tính phí theo mức giá giảm. Anthropic thể hiện trực tiếp sự phân biệt này qua các trường thông tin sử dụng như: ``` { "usage": { "input_tokens": 812, "cache_creation_input_tokens": 42000, "cache_read_input_tokens": 0, "output_tokens": 684 } } ``` Trong một yêu cầu sau đó, nếu tiền tố trúng bộ nhớ đệm, bạn sẽ muốn thấy kết quả gần với dạng sau: ``` { "usage": { "input_tokens": 936, "cache_creation_input_tokens": 0, "cache_read_input_tokens": 42000, "output_tokens": 711 } } ``` Lần gọi đầu tiên tạo bộ nhớ đệm. Các lần gọi sau đọc từ đó. Hiệu quả kinh tế phụ thuộc vào mức giá hiện tại của nhà cung cấp, TTL của bộ nhớ đệm và mô hình. Vì giá thay đổi, tôi thích mô hình hóa điều này bằng các biến trong mã hơn là ghi cố định các con số vào tài liệu thiết kế. Đây là một hàm Python nhỏ tôi dùng khi quyết định liệu có đáng triển khai bộ nhớ đệm cho một tuyến xử lý hay không: ``` def cache_savings( cached_tokens: int, normal_input_per_mtok: float, cache_write_per_mtok: float, cache_read_per_mtok: float, requests: int, ) -> dict: mtok = cached_tokens / 1_000_000 no_cache = requests * mtok * normal_input_per_mtok with_cache = ( mtok * cache_write_per_mtok + (requests - 1) * mtok * cache_read_per_mtok ) return { "no_cache": round(no_cache, 6), "with_cache": round(with_cache, 6), "savings": round(no_cache - with_cache, 6), "savings_pct": round((1 - with_cache / no_cache) * 100, 2), } print(cache_savings( cached_tokens=42_000, normal_input_per_mtok=3.00, cache_write_per_mtok=3.75, cache_read_per_mtok=0.30, requests=100, )) ``` Đoạn này chỉ dùng giá minh họa. Cấu trúc mới là điều quan trọng. Với một tiền tố có thể tái sử dụng dài 42,000 token và 100 yêu cầu, bộ nhớ đệm thường mang lại hiệu quả rất tốt. Với cùng tiền tố đó nhưng chỉ có một yêu cầu, bộ nhớ đệm có thể tốn kém hơn nếu giá ghi cao hơn giá đầu vào thông thường. Đó là điểm dễ vấp đầu tiên: bộ nhớ đệm prompt là cơ chế phân bổ chi phí. Nếu không tái sử dụng tiền tố đã lưu trong bộ nhớ đệm, bạn sẽ không nhận được lợi ích. ## Công thức hòa vốn Bạn có thể ước tính điểm hòa vốn bằng: ``` no_cache_cost = N * T * normal_price cache_cost = T * write_price + (N - 1) * T * read_price ``` Trong đó: - N là số yêu cầu sử dụng cùng một tiền tố - T là số token có thể lưu vào bộ nhớ đệm - normal_price là giá token đầu vào thông thường - write_price là giá tạo bộ nhớ đệm - read_price là giá đọc bộ nhớ đệm Bộ nhớ đệm giúp tiết kiệm chi phí khi: ``` T * write_price + (N - 1) * T * read_price < N * T * normal_price ``` Thư mục T được triệt tiêu khi chỉ xét điểm hòa vốn về chi phí, nghĩa là số lần tái sử dụng và tương quan giá quyết định lựa chọn. Nhưng số lượng token vẫn quan trọng trong vận hành: tiết kiệm 80% trên 500 token là không đáng kể; tiết kiệm mức đó trên 80,000 token là một khoản đáng ghi nhận. Một cách tính nhẩm hữu ích: ``` break_even_requests = (write_price - read_price) / (normal_price - read_price) ``` Nếu việc ghi bộ nhớ đệm chỉ đắt hơn một chút so với đầu vào thông thường và việc đọc rẻ hơn nhiều, điểm hòa vốn có thể rất thấp. Nếu việc ghi bộ nhớ đệm tốn kém hoặc tiền tố hiếm khi lặp lại, hiệu quả của bộ nhớ đệm rất dễ mất đi. ## Cách cấu trúc prompt để có tiền tố ổn định Cách tối ưu bộ nhớ đệm prompt tốt nhất không phải là một cờ API. Đó là cách bố trí prompt. Cách bố trí kém: ``` Request ID: req_8f19a Current time: 2026-02-14T09:12:33Z User: customer_4812 Locale: en-US SYSTEM INSTRUCTIONS: ... POLICY MANUAL: [42,000 tokens of stable text] USER QUESTION: Can I get a refund after 45 days? ``` Cách này làm mất tác dụng của bộ nhớ đệm tiền tố vì prompt đã khác nhau ngay từ đầu. Cách bố trí tốt hơn: ``` SYSTEM INSTRUCTIONS: ... POLICY MANUAL: [42,000 tokens of stable text] DYNAMIC REQUEST METADATA: Request ID: req_8f19a Current time: 2026-02-14T09:12:33Z User: customer_4812 Locale: en-US USER QUESTION: Can I get a refund after 45 days? ``` Khối ổn định nằm trước. Khối động nằm sau. Với bộ nhớ đệm tường minh theo cách của Anthropic, về mặt khái niệm, cấu trúc có thể như sau: ``` { "model": "claude-sonnet-4-6", "max_tokens": 800, "system": [ { "type": "text", "text": "You are a support policy assistant..." }, { "type": "text", "text": "Refund policy manual v2026-02-01:\n\n...", "cache_control": { "type": "ephemeral" } } ], "messages": [ { "role": "user", "content": "Can I get a refund after 45 days?" } ] } ``` Lược đồ yêu cầu chính xác thay đổi tùy phiên bản API và SDK, vì vậy hãy xem đây là cấu trúc minh họa thay vì mã để sao chép và dán. Điều quan trọng là khối ổn định lớn được đánh dấu rõ ràng là có thể lưu vào bộ nhớ đệm và không thay đổi giữa các lần gọi. Với bộ nhớ đệm tự động theo cách của OpenAI, cấu trúc prompt cũng quan trọng như vậy ngay cả khi bạn không đánh dấu khối theo cách thủ công: ``` { "model": "gpt-5.5", "messages": [ { "role": "system", "content": "You are a support policy assistant...\n\nRefund policy manual v2026-02-01:\n\n..." }, { "role": "user", "content": "Can I get a refund after 45 days?" } ] } ``` Nếu thông điệp hệ thống thay đổi ở mỗi yêu cầu, bạn không nên kỳ vọng việc đọc bộ nhớ đệm diễn ra ổn định. ## Một mẫu kiến trúc thực tế Đối với hệ thống production, tôi thích biểu diễn rõ ràng các tiền tố prompt được lưu trong bộ nhớ đệm ngay trong mã ứng dụng. Một mẫu đơn giản: ``` prompt_prefix/ support_policy_v17.txt tool_schema_v4.json examples_v9.md runtime_request/ user_question user_profile retrieved_recent_orders ``` Sau đó, ghép các yêu cầu như sau: ``` from pathlib import Path POLICY_PREFIX = Path("prompt_prefix/support_policy_v17.txt").read_text() TOOL_SCHEMA = Path("prompt_prefix/tool_schema_v4.json").read_text() EXAMPLES = Path("prompt_prefix/examples_v9.md").read_text() def build_prompt(user_question: str, user_profile: dict) -> str: stable_prefix = f""" You are a support policy assistant. TOOLS: {TOOL_SCHEMA} POLICY: {POLICY_PREFIX} EXAMPLES: {EXAMPLES} """.strip() dynamic_suffix = f""" USER PROFILE: {user_profile} USER QUESTION: {user_question} """.strip() return stable_prefix + "\n\n--- DYNAMIC REQUEST ---\n\n" + dynamic_suffix ``` Trong thực tế, tôi cũng quản lý phiên bản của tiền tố. Nếu tài liệu chính sách thay đổi, tôi muốn việc vô hiệu hóa bộ nhớ đệm diễn ra có chủ đích: ``` sha256sum prompt_prefix/support_policy_v17.txt ``` Giá trị băm đó được ghi vào nhật ký cùng với tên mô hình, số token tạo bộ nhớ đệm, số token đọc bộ nhớ đệm và tuyến xử lý yêu cầu. Nếu thiếu khả năng quan sát này, lỗi bộ nhớ đệm rất khó xử lý vì phản hồi vẫn hoạt động; chỉ là tốn kém hơn. Một dòng nhật ký hữu ích có dạng: ``` { "route": "support.answer", "model": "claude-sonnet-4-6", "prefix_hash": "9d3a4a...", "input_tokens": 932, "cache_creation_input_tokens": 0, "cache_read_input_tokens": 42000, "output_tokens": 688, "latency_ms": 1840 } ``` Đừng tối ưu chỉ dựa trên hóa đơn. Hãy ghi nhật ký hành vi của bộ nhớ đệm theo từng tuyến xử lý. ## Độ trễ: Thường tốt hơn, nhưng không phải phép màu Bộ nhớ đệm prompt có thể giảm độ trễ vì nhà cung cấp mô hình có thể tái sử dụng phần tính toán cho tiền tố đã lưu trong bộ nhớ đệm. Nhưng tôi sẽ không thiết kế SLA dựa trên giả định về một mức giảm độ trễ cố định nếu chưa đo lường trên khối lượng công việc của chính mình. Những gì thực sự diễn ra trong production phức tạp hơn: - Các prompt ngắn có thể không cho thấy thay đổi đáng kể về độ trễ. - Các tiền tố dài được lưu trong bộ nhớ đệm thường cải thiện thời gian đến token đầu tiên. - Độ dài đầu ra vẫn chi phối nhiều yêu cầu. - Các lệnh gọi công cụ, độ trễ mạng và thời gian chờ trong hàng đợi có thể che khuất lợi ích của bộ nhớ đệm. - Các lần không trúng bộ nhớ đệm tạo ra những đợt tăng vọt ở phần đuôi của phân bố độ trễ nếu thao tác ghi chậm hơn thao tác đọc. Một thiết lập đo kiểm thực tế khá đơn giản: ``` # warm cache python run_eval.py --case support_refund --repeat 1 # measure cache reads python run_eval.py --case support_refund --repeat 50 --jsonl out.jsonl # inspect p50/p95 by cache_read_input_tokens > 0 python analyze_latency.py out.jsonl ``` Đo riêng các yêu cầu trúng và không trúng bộ nhớ đệm. Gộp chúng lại sẽ cho bạn một con số không giải thích được trường hợp nào. ## Những vấn đề dễ mắc phải mà tôi thấy trong các hệ thống thực tế ### 1. Nội dung động đứng trước nội dung ổn định Đây là lỗi phổ biến nhất. Dấu thời gian, ID yêu cầu, bản liệt kê cờ tính năng, thiết lập ngôn ngữ và khu vực của người dùng hoặc thông tin phân nhóm thử nghiệm được đặt ở đầu prompt hệ thống. Hãy chuyển chúng xuống dưới. ### 2. JSON “tương đương” không thực sự tương đương Hai đoạn sau giống nhau về ngữ nghĩa nhưng chưa chắc giống nhau đối với bộ nhớ đệm: ``` {"name":"refund_lookup","timeout":3,"strict":true} ``` ``` { "strict": true, "timeout": 3, "name": "refund_lookup" } ``` Nếu đưa lược đồ công cụ hoặc cấu hình vào tiền tố được lưu trong bộ nhớ đệm, hãy tuần tự hóa chúng theo cách xác định: ``` import json def stable_json(data: dict) -> str: return json.dumps(data, sort_keys=True, separators=(",", ":")) ``` Điều này tránh các lần không trúng bộ nhớ đệm ngoài ý muốn do thay đổi thứ tự khóa hoặc khoảng trắng. ### 3. Truy xuất có thể phá hỏng khả năng lưu vào bộ nhớ đệm Các hệ thống RAG thường xây dựng prompt như sau: ``` Retrieved documents: [doc A] [doc B] [doc C] Instructions: ... ``` Nếu kết quả truy xuất khác nhau theo từng truy vấn, tiền tố cũng khác nhau theo từng truy vấn. Điều đó không có vấn đề gì nếu ngữ cảnh truy xuất thực sự mang tính động, nhưng đừng đặt các chỉ dẫn ổn định sau phần đó. Cách tốt hơn: ``` Instructions: ... Long-lived product documentation: [stable docs] Query-specific retrieved documents: [doc A] [doc B] [doc C] ``` Với các hệ thống có lưu lượng lớn, hãy cân nhắc chia ngữ cảnh thành: - Chỉ dẫn ổn định trên toàn hệ thống - Tài liệu ổn định theo từng tenant - Nội dung truy xuất riêng cho từng người dùng hoặc truy vấn Mỗi lớp có hành vi bộ nhớ đệm khác nhau. ### 4. Thời gian sống của bộ nhớ đệm rất quan trọng Một số mục trong bộ nhớ đệm sẽ hết hạn. Nếu lưu lượng của bạn đến theo từng đợt, một tiền tố có thể được tái sử dụng rất nhiều trong mười phút rồi không còn được dùng nữa. Thời gian sống dài hơn của bộ nhớ đệm có thể hữu ích, nhưng mức giá hoặc khả năng cung cấp có thể khác nhau tùy nhà cung cấp và mô hình. Đây là lúc phân bố yêu cầu trở nên quan trọng. “Chúng tôi nhận 10,000 yêu cầu mỗi ngày” ít hữu ích hơn “chúng tôi nhận 200 yêu cầu mỗi phút cho chính tiền tố này trong khoảng từ 9 giờ sáng đến 10 giờ sáng”. ### 5. Thay đổi mô hình làm mất hiệu lực của các giả định Không nên cho rằng tiền tố được lưu trong bộ nhớ đệm cho một mô hình có thể tái sử dụng cho mô hình khác. Nếu bạn định tuyến giữa Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3 hoặc các mô hình mở như Llama, Qwen, DeepSeek, MiniMax hay Kimi, hãy theo dõi hành vi bộ nhớ đệm theo từng mô hình. Định tuyến giữa nhiều mô hình hữu ích, nhưng khiến việc phân bổ chi phí trở nên phức tạp hơn. Nếu lưu lượng được chia theo năm hướng, mỗi mô hình có thể nhận được ít tiền tố lặp lại hơn. ### 6. Cá nhân hóa prompt có thể phản tác dụng Các nhóm thường cá nhân hóa prompt hệ thống: ``` You are helping {{customer_name}}, who is on plan {{plan_name}}. ``` Việc đó có vẻ vô hại, nhưng nếu phần này xuất hiện trước nội dung được lưu trong bộ nhớ đệm, mỗi khách hàng sẽ có một tiền tố khác nhau. Hãy đặt phần cá nhân hóa phía sau, trừ khi nó thực sự thay đổi cách mô hình diễn giải khối nội dung ổn định. ## Khi nào việc lưu prompt vào bộ nhớ đệm giúp tiết kiệm chi phí Việc lưu vào bộ nhớ đệm thường rất phù hợp khi: - Tiền tố có thể lưu vào bộ nhớ đệm có kích thước lớn, thường là hàng nghìn hoặc hàng chục nghìn token. - Chính xác cùng một tiền tố được tái sử dụng nhiều lần. - Tiền tố giữ nguyên qua các yêu cầu. - Lưu lượng đến trong thời gian sống của bộ nhớ đệm. - Bạn có thể quan sát số token tạo bộ nhớ đệm và số token đọc từ bộ nhớ đệm. - Tuyến xử lý có cách cấu thành prompt có thể dự đoán được. Ví dụ cụ thể: - Một trợ lý lập trình liên tục đưa vào cùng một bản đồ kho mã và hướng dẫn về phong cách lập trình. - Một bot hỗ trợ đưa vào cùng một sổ tay chính sách cho mọi câu hỏi về hoàn tiền. - Một tác tử sử dụng một lược đồ công cụ tĩnh lớn trong mọi yêu cầu. - Một trợ lý nghiên cứu nội bộ đưa vào cùng một phần tổng quan về tập tài liệu cho một nhóm. Với những khối lượng công việc này, việc lưu prompt vào bộ nhớ đệm có thể là một trong những cách tối ưu chi phí hiệu quả nhất vì không đòi hỏi giảm chất lượng ngữ cảnh. Bạn vẫn giữ prompt dài; chỉ là không còn phải trả đủ giá đầu vào mỗi lần. ## Khi nào việc lưu prompt vào bộ nhớ đệm không hữu ích Việc lưu vào bộ nhớ đệm kém hiệu quả hoặc gây bất lợi khi: - Prompt ngắn. - Các tiền tố hiếm khi được tái sử dụng. - Phần lớn ngữ cảnh là nội dung truy xuất riêng cho từng truy vấn. - Dữ liệu động xuất hiện trước dữ liệu ổn định. - Bạn liên tục sửa đổi chỉ dẫn trong quá trình thử nghiệm. - Lưu lượng bị phân tán quá mỏng trên nhiều mô hình, tenant hoặc biến thể prompt. - Chi phí ghi vào bộ nhớ đệm cao hơn và các lần đọc quá ít để bù đắp chi phí đó. Một vấn đề thường gặp khi đánh giá: việc lưu prompt vào bộ nhớ đệm trông có vẻ kém hiệu quả trong notebook vì bạn chỉ chạy mỗi trường hợp một lần. Sau đó, nó lại tỏ ra rất hiệu quả trong môi trường vận hành thực tế vì hàng nghìn người dùng dùng chung một tiền tố ổn định. Điều ngược lại cũng xảy ra: một bản demo lặp lại cùng một prompt 100 lần và cho thấy mức tiết kiệm lớn, nhưng môi trường vận hành thực tế có tùy chỉnh theo từng tenant khiến không thể tái sử dụng. Hãy kiểm thử với phân bố yêu cầu thực tế. ## Danh sách kiểm tra đơn giản về mức độ sẵn sàng sử dụng bộ nhớ đệm Trước khi bật hoặc dựa vào việc lưu prompt vào bộ nhớ đệm, tôi kiểm tra: - Có ít nhất một tiền tố ổn định dài hơn vài nghìn token không? - Nó có xuất hiện trước mọi nội dung động không? - Việc tuần tự hóa có mang tính xác định không? - Tiền tố có được quản lý phiên bản và băm không? - Tôi có thể ghi nhật ký số token tạo bộ nhớ đệm và số token đọc từ bộ nhớ đệm không? - Tôi có biết số lần tái sử dụng dự kiến trong thời gian sống của bộ nhớ đệm không? - Tôi đã đo riêng độ trễ cho các lần trúng và không trúng bộ nhớ đệm chưa? Nếu có từ ba câu trả lời “không” trở lên, việc lưu vào bộ nhớ đệm vẫn có thể hoạt động, nhưng bạn đang phỏng đoán. ## Những điểm thực tiễn cần ghi nhớ Lưu prompt vào bộ nhớ đệm không phải là một phép nén thần kỳ. Đó là việc tái sử dụng một tiền tố token ổn định, và lợi ích kinh tế đến từ việc trả chi phí tạo một lần cùng chi phí đọc thấp hơn nhiều lần. Cách triển khai về mặt kỹ thuật khá rõ ràng: - Đặt nội dung ổn định có kích thước lớn lên đầu: chỉ dẫn, công cụ, tài liệu, ví dụ. - Chuyển dấu thời gian, siêu dữ liệu người dùng, kết quả truy xuất và ID yêu cầu xuống sau tiền tố có thể lưu vào bộ nhớ đệm. - Theo dõi cache_creation so với cache_read token theo từng tuyến xử lý và mô hình. - Sử dụng cách tuần tự hóa xác định cho lược đồ công cụ và cấu hình JSON. - Lập mô hình điểm hòa vốn dựa trên giá thực tế của nhà cung cấp và phân bố lưu lượng của bạn. - Hãy thận trọng với việc định tuyến giữa nhiều mô hình, tùy chỉnh theo từng tenant và các prompt ngắn. - Đo riêng độ trễ cho các lần trúng và không trúng bộ nhớ đệm thay vì tin vào giá trị trung bình. Cách tối ưu bộ nhớ đệm prompt tốt nhất mà tôi từng thấy chẳng hề phức tạp: chúng tôi chuyển 42,000 token ổn định lên trước 12 token động. Hành vi của mô hình không thay đổi. Hóa đơn thì có. [Suy luận](/vi/blog/tag/inference/)[Prompt](/vi/blog/tag/prompts/)[RAG](/vi/blog/tag/rag/)[API](/vi/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/vi/) AI Prime Tech xuất bản blog này. Các bài viết được soạn với sự hỗ trợ của AI; hãy đối chiếu những chi tiết phụ thuộc vào phiên bản như ID mô hình, giá và giới hạn với tài liệu chính thức trước khi dựa vào chúng. Truy cập Claude API với chi phí thấp hơn Một khóa API cho Claude Opus 5.5, Sonnet 5, Haiku 4.5 và Fable 5.1, cùng GPT-6 mô hình. Thanh toán theo mức sử dụng, không cần đăng ký thuê bao. [Nhận khóa API của bạn →](/register) AI Prime Tech là cổng API bên thứ ba độc lập. Claude™ và Anthropic® là các nhãn hiệu của Anthropic, PBC. Không hàm ý có sự liên kết hay chứng thực.