Lợi nhuận:
- Giải thích logic khớp tiền tố của bộ nhớ đệm nhắc nhở
- Tăng số lần truy cập bộ đệm bằng cách đặt bối cảnh cố định trước và bối cảnh thay đổi sau
- Có thể tính toán tính kinh tế ghi/đọc bộ đệm và điểm hòa vốn
Một sản phẩm LLM có vẻ rẻ tiền ở nguyên mẫu; Khi bạn bước lên bàn cân, hóa đơn sẽ gây ngạc nhiên. Trong hầu hết các khối lượng công việc, hầu hết hóa đơn đều xuất phát từ cùng một ngữ cảnh cố định được gửi đi gửi lại với mỗi yêu cầu: lời nhắc hệ thống dài, sách quy tắc, tài liệu tham khảo. Bộ nhớ đệm nhanh chóng loại bỏ chính xác sự lãng phí này. Trong phần này, bạn sẽ tìm hiểu cách hoạt động của bộ đệm, cách sắp xếp lời nhắc truy cập và cách tính điểm hòa vốn của nền kinh tế bộ đệm. Khi được lắp đặt đúng cách, chỉ riêng nó có thể cắt giảm một nửa hóa đơn của bạn hoặc thậm chí thấp hơn.
Bộ nhớ đệm hoạt động như thế nào? Quy tắc bất biến duy nhất
Bộ nhớ đệm nhắc nhở là một kết hợp tiền tố. Nhà cung cấp tạm thời lưu trữ các mã thông báo mà họ đã xử lý kể từ khi bắt đầu lời nhắc của bạn. Nếu lời nhắc bắt đầu với cùng một tiền tố trong yêu cầu tiếp theo, phần chung này sẽ không được tính toán lại; Đọc nó rẻ hơn nhiều so với bộ nhớ đệm.
Một quy tắc bất biến tuân theo điều này: Nếu một byte đơn thay đổi ở bất kỳ vị trí nào trong tiền tố, toàn bộ bộ đệm sẽ không hợp lệ kể từ thời điểm đó trở đi. Nghĩa là, nội dung cố định phải ở đầu và nội dung thay đổi nên ở cuối. Nếu bạn đặt một dòng ở đầu lời nhắc hệ thống, dòng này sẽ thay đổi theo từng yêu cầu, chẳng hạn như "Ngày hôm nay: 18.07.2026", mọi thứ đằng sau nó sẽ không thể vào bộ đệm.
Thứ tự xử lý thường là: công cụ → dấu nhắc hệ thống → tin nhắn. Bạn đặt điểm cache (breakpoint) ở cuối phần cố định.
Tiết kiệm bộ nhớ đệm
Cache có ba mức giá:
- Ghi vào bộ đệm: Lưu trữ lần đầu tiên. ~1,25 lần giá đầu vào thông thường (cho 5 phút lưu trữ).
- Đọc bộ đệm: Đọc các yêu cầu tiếp theo. ~0,1 lần giá đầu vào thông thường — tức là bằng 1/10.
- Đầu vào thông thường: Phần không vào bộ đệm và được xử lý với toàn bộ chi phí mỗi lần.
Điểm hòa vốn: Yêu cầu đầu tiên trả phí ghi (1,25×). Từ yêu cầu thứ hai, việc đọc (0,1×) sẽ có hiệu lực. Đại khái, bạn sẽ phải đối mặt với hai yêu cầu; Sau đó, đó là tiết kiệm ròng. Bối cảnh cố định càng lớn và càng có nhiều yêu cầu được sử dụng lại thì mức tăng càng lớn.
Kịch bản
Bộ nhớ đệm có hoạt động không?
Lời nhắc hệ thống cố định lớn, hàng ngàn yêu cầu
Có - thu nhập cao nhất
Nhiều câu hỏi trên cùng một tài liệu tham khảo
Có
Văn bản ngắn hoàn toàn khác nhau cho mỗi yêu cầu
Không — tiền thưởng viết bị lãng phí
Yêu cầu một lần
Không - không đọc chút nào
Ngày/ID thay đổi theo từng yêu cầu tại dấu nhắc hệ thống
Không - tiền tố bị hỏng, lượt truy cập bằng 0
Từng bước: Làm thế nào để thiết lập lời nhắc truy cập?
- Phân biệt hằng và biến. Nội dung nào không bao giờ thay đổi (lời nhắc hệ thống, sách quy tắc, tài liệu)? Những thay đổi nào với mỗi yêu cầu (câu hỏi của người dùng, ngày, ID)?
- Đặt hằng số ở đầu. Trong quá trình xử lý, phần đến trước (công cụ, hệ thống) phải ổn định.
- Đặt biến ở cuối. Câu hỏi hiện tại của người dùng, cuối cùng.
- Đặt biển báo ở cuối đường viền. Đặt điểm đệm vào khối cuối cùng của phần cố định.
- Xác nhận lượt truy cập. Kiểm tra xem cache_read_input_tokens có lớn hơn 0 trong trường sử dụng trong phản hồi hay không. Nếu bằng 0 thì có một bộ gây rối ẩn trong tiền tố.
{ "system": [ { "type": "text", "text": "{{large_constant_system_promptu_and_rules}}", "cache_control": { "type": "phù du" } } ], "messages": [ { "role": "user", "content": "{{user_current_question}}" } ]}
Mẹo: Đừng đoán số lần truy cập bộ đệm, hãy đo lường chúng. Nếu mức sử dụng.cache_read_input_tokens vẫn bằng 0 đối với các yêu cầu liên tiếp thì bộ ngắt im lặng (datetime.now() tại dấu nhắc hệ thống, JSON không có thứ tự, danh sách các công cụ thay đổi theo từng yêu cầu) đang chạy. So sánh lời nhắc thô của hai byte yêu cầu theo từng byte và tìm sự khác biệt.
Kẻ gây rối thầm lặng
Các mẫu điển hình vô tình làm hỏng bộ đệm:
# BREAKER: nhúng thông tin vào lời nhắc hệ thống thay đổi theo từng yêu cầu "Ngày hôm nay: {{now}}. Bạn là trợ lý..." ← tiền tố thay đổi theo mỗi yêu cầu, số lần nhấn là 0# TRUE: chuyển biến sang hệ thống thông báo: "Bạn là trợ lý..." ← hằng nhập vào bộ nhớ đệm: [{role: user, content: "Hôm nay là {{bây giờ}}. Câu hỏi: ..."}] ← biến ở cuối
Các bộ ngắt khác: JSON được sắp xếp khác nhau theo từng yêu cầu (giữ các khóa theo thứ tự cố định), danh sách các công cụ khác nhau tùy theo người dùng (các công cụ được xử lý trước; không có gì đi vào bộ đệm nếu chúng thay đổi), thay đổi mô hình giữa cuộc hội thoại (bộ đệm là mô hình cụ thể).
Lời nhắc yếu / Lời nhắc mạnh (cấu trúc thân thiện với bộ đệm)
# Hệ thống WEAK (xây dựng phá bộ đệm): "Ngày: 18.07.2026 14:32. Người dùng: Ahmet (id 8842). Bạn là bot hỗ trợ. Quy tắc: ...(2000 token)..."
# Hệ thống MẠNH (cấu trúc thân thiện với bộ đệm): "Bạn là bot hỗ trợ. Quy tắc: ...(2000 mã thông báo, không bao giờ thay đổi)..." [dấu hiệu bộ đệm]tin nhắn: [ { role: user, content: "Date: 18.07.2026 14:32. User id: 8842. Câu hỏi: làm cách nào để bắt đầu hoàn lại tiền?" }]
Trong phiên bản yếu, khối quy tắc 2000 mã thông báo được xử lý với toàn bộ chi phí cho mỗi yêu cầu. Trong phiên bản mạnh, cùng một khối được viết một lần và đọc tất cả các yêu cầu tiếp theo với mức giá bằng 1/10.
Ba hộp nhỏ
Trường hợp 1 - Lưu vào bộ nhớ đệm cuốn sách quy tắc. Tự động hóa kế toán đã thêm sổ quy tắc 12.000 mã thông báo vào mỗi hóa đơn; 5.000 yêu cầu mỗi ngày. Chi phí đầu vào không cần bộ nhớ đệm ~$180 mỗi ngày. Họ giữ nguyên sổ quy tắc và lưu vào bộ nhớ đệm: yêu cầu đầu tiên trả phí ghi, các lần đọc tiếp theo là 0,1×. Chi phí đầu vào giảm ~90% xuống còn ~$18 mỗi ngày.
Trường hợp 2 - Chi phí của dòng ngày ẩn. Một nhóm đã thiết lập bộ nhớ đệm nhưng không nhận được kết quả nào; cache_read_input_tokens luôn bằng 0. Lý do: Có datetime.now() trong dòng đầu tiên của lời nhắc hệ thống, tiền tố thay đổi theo từng yêu cầu. Khi chúng tôi chuyển ngày sang tin nhắn của người dùng, tỷ lệ trúng đột ngột tăng từ 0% lên 94%.
Trường hợp 3 - Bộ đệm bị đặt sai vị trí. Một ứng dụng tìm kiếm đang gửi các truy vấn ngắn hoàn toàn khác nhau với mỗi yêu cầu; Họ háo hức thêm một dấu hiệu bộ nhớ cache. Không có tiền tố chung, mỗi yêu cầu chỉ trả phí ghi, không đọc — làm tăng chi phí. Họ đã gỡ bỏ tấm biển. Bài học: bộ đệm chỉ trả tiền nếu có tiền tố lớn và không đổi được sử dụng lại.
Những lỗi thường gặp
- Trộn hằng số và biến: Khi nội dung biến nằm ở tiền tố, lần truy cập được đặt lại.
- Nhúng ngày/ID vào lời nhắc hệ thống: Kẻ gây rối thầm lặng phổ biến nhất.
- Không đo lường lượt truy cập: Nếu không kiểm tra cache_read_input_tokens, chất thải sẽ không được chú ý.
- Thêm bộ đệm khi không có tiền tố công khai: Bạn chỉ phải trả phí ghi, chi phí sẽ tăng lên.
- Thay đổi danh sách hoặc mẫu xe: Tiền tố bị hỏng ngay từ đầu; mọi thứ đều được viết lại.
- Quên kích thước bộ đệm tối thiểu: Bộ đệm rất ngắn (dưới ~1–4k mã thông báo tùy thuộc vào kiểu máy) sẽ không âm thầm vào bộ đệm.
Tìm hiểu sâu hơn: Thiết kế bộ đệm theo loại khối lượng công việc
Lợi ích thực tế của bộ nhớ đệm thay đổi tùy thuộc vào tính chất khối lượng công việc của bạn; vì vậy hãy tìm hiểu lưu lượng truy cập của bạn trước tiên. Ba mẫu điển hình và cài đặt chính xác:
Lời nhắc hệ thống chung, các câu hỏi khác nhau. Mẫu doanh nghiệp phổ biến nhất: lời nhắc hệ thống lớn (vai trò, quy tắc, có thể là tài liệu tham khảo) với hàng trăm câu hỏi khác nhau của người dùng. Ở đây phần cố định (hệ thống) ban đầu được lưu vào bộ đệm; mỗi câu hỏi mới chỉ trả giá đầy đủ cho phần nhỏ của chính nó. Mức tăng rất cao vì phần lớn được đọc đi đọc lại nhiều lần với giá chỉ bằng 1/10.
Độc thoại nhiều vòng. Khi cuộc trò chuyện kéo dài, mỗi vòng mới sẽ được xây dựng dựa trên tất cả lịch sử trước đó. Nếu bạn đặt cờ bộ đệm vào cuối vòng cuối cùng, mỗi yêu cầu sẽ sử dụng lại tiền tố cuộc trò chuyện trước đó; lượt truy cập tích lũy khi cuộc trò chuyện phát triển. Điều này giúp giảm đáng kể chi phí cho các phiên trợ lý kéo dài.
Tiền tố được chia sẻ là bit cuối cùng cần thay đổi. Nhiều yêu cầu chia sẻ một tập hợp lớn các mục trước cố định (bộ mẫu, hướng dẫn) nhưng được phân tách bằng một câu hỏi duy nhất ở cuối. Bạn đặt con trỏ bộ đệm ở cuối phần được chia sẻ; Nếu không, mỗi yêu cầu sẽ ghi bộ nhớ đệm riêng và không yêu cầu nào trong số đó sẽ được đọc.
Một lưu ý: bộ đệm phụ thuộc vào kiểu máy và kích thước tối thiểu nhất định. Các tiền tố rất nhỏ (dưới vài nghìn mã thông báo, tùy thuộc vào kiểu máy) sẽ không âm thầm vào bộ đệm ngay cả khi bạn gắn cờ chúng - cache_creation_input_tokens vẫn bằng 0. Ngoài ra, việc thay đổi mô hình giữa cuộc trò chuyện sẽ làm mất hiệu lực toàn bộ bộ đệm; Nếu một nhiệm vụ khác yêu cầu một mô hình giá rẻ, hãy giữ luồng chính trong một mô hình và đặt công việc phụ vào một lệnh gọi riêng.
Tóm lại
Bộ nhớ đệm nhắc nhở là một kết hợp tiền tố: nội dung cố định phải ở đầu, nội dung biến đổi phải ở cuối. Đối với một bối cảnh lớn, được sử dụng lại, chi phí đọc là một phần mười của toàn bộ giá, gần như hòa vốn trong hai yêu cầu. Lỗi phổ biến nhất là làm hỏng tiền tố bằng cách nhúng dữ liệu biến đổi vào dấu nhắc hệ thống; Bạn xác minh lần truy cập bằng cách đo lường lần truy cập đó trong trường sử dụng.
Nhiệm vụ ứng dụng
Chọn khối lượng công việc. (1) Chia nội dung thành 2 cột: “không bao giờ thay đổi” và “thay đổi theo mọi yêu cầu”. (2) Vẽ lại cấu trúc gợi ý, đặt phần cố định ở đầu và phần biến đổi ở cuối. (3) Ước tính kích thước mã thông báo của phần cố định và so sánh chi phí hàng tháng có/không có bộ đệm. (4) Lưu ý trường nào (cache_read_input_tokens) mà bạn sẽ xác minh lần truy cập từ đó.
danh sách kiểm tra
- [ ] Tôi có thể giải thích rằng bộ đệm là khớp tiền tố và là quy tắc bất biến duy nhất.
- [ ] Tôi có thể tăng độ chính xác bằng cách đặt nội dung cố định ở đầu và biến ở cuối.
- [ ] Tôi biết kinh tế viết/đọc và điểm hòa vốn hai yêu cầu.
- [ ] Tôi có thể nhận ra những yếu tố gây rối thầm lặng (ngày tháng, JSON không có thứ tự, thay đổi danh sách phương tiện).
- [ ] Tôi có thể xác minh lần truy cập bằng cách sử dụng.cache_read_input_tokens.