Các Mô Hình Ngôn Ngữ Lớn (LLMs) đã cách mạng hóa cách mà chúng ta tương tác với trí tuệ nhân tạo, cho phép thực hiện các tác vụ phức tạp như tạo văn bản, dịch thuật, trả lời câu hỏi, và nhiều hơn nữa. Tuy nhiên, việc tương tác với những mô hình mạnh mẽ này, đặc biệt là với các câu lệnh tinh vi, có thể phát sinh chi phí tính toán và độ trễ đáng kể. Nhiều ứng dụng liên quan đến việc gửi những câu lệnh tương tự hoặc gần giống nhau lặp đi lặp lại. Hãy tưởng tượng một chatbot với một câu lệnh hệ thống cố định, một công cụ phân tích tài liệu xử lý các đoạn văn bản với cùng một hướng dẫn, hoặc một tác nhân sử dụng các định nghĩa công cụ nhất quán. Trong những kịch bản này, LLM liên tục xử lý cùng một thông tin ban đầu (tiền tố câu lệnh), lãng phí tài nguyên tính toán và làm tăng thời gian phản hồi.
Việc lưu trữ câu lệnh xuất hiện như một kỹ thuật tối ưu hóa mạnh mẽ để giải quyết tính không hiệu quả này. Nó cho phép các nhà cung cấp LLM lưu trữ trạng thái tính toán trung gian liên quan đến phần đầu tiên, tĩnh của một câu lệnh (tiền tố). Khi các yêu cầu tiếp theo sử dụng cùng một tiền tố, mô hình có thể tái sử dụng trạng thái đã được lưu trữ này, bỏ qua việc tính toán dư thừa và chỉ xử lý phần mới, động của câu lệnh (hậu tố). Điều này dẫn đến những cải thiện đáng kể cả về độ trễ và chi phí, giúp các ứng dụng LLM nhanh hơn và kinh tế hơn.
Hướng dẫn này cung cấp cái nhìn tổng quan toàn diện về việc lưu trữ câu lệnh, cách hoạt động của nó, các lợi ích của nó, chi tiết triển khai (tập trung vào API của Anthropic, cũng có liên quan đến các mô hình Claude trên AWS Bedrock), các cân nhắc về giá cả, những hạn chế và các thực tiễn tốt nhất.
Bạn muốn một nền tảng tích hợp, Tất cả trong Một để nhóm phát triển của bạn làm việc cùng nhau với năng suất tối đa?
Apidog đáp ứng tất cả các yêu cầu của bạn, và thay thế Postman với mức giá phải chăng hơn nhiều!

Cách Hoạt Động Của Việc Lưu Trữ Câu Lệnh: Cơ Chế
Tại cốt lõi, việc lưu trữ câu lệnh khai thác tính chất lặp đi lặp lại của nhiều tương tác LLM. Khi bạn gửi một câu lệnh đến một LLM, mô hình xử lý các token đầu vào theo trình tự để tạo ra một biểu diễn hoặc trạng thái nội bộ. Việc lưu trữ câu lệnh sẽ chặn quá trình này.
- Trượt Cache (Yêu Cầu Đầu Tiên / Tiền Tố Thay Đổi): Khi một yêu cầu đến với một tiền tố câu lệnh mà chưa được thấy gần đây hoặc không khớp với bất kỳ mục cache nào hiện có, LLM sẽ xử lý toàn bộ câu lệnh như thường lệ. Tuy nhiên, nếu việc lưu trữ được bật cho một ranh giới tiền tố cụ thể, hệ thống lưu trữ trạng thái nội bộ của mô hình tương ứng với tiền tố đó sau khi đã xử lý nó. Điều này thường được gọi là ghi cache. Một định danh duy nhất, thường là một hàm băm mật mã của nội dung tiền tố (bao gồm các câu lệnh hệ thống, định nghĩa công cụ và thông điệp cho đến điểm lưu cache), sẽ được liên kết với trạng thái đã lưu này, đóng vai trò như khóa cache.
- Gõ Cache (Yêu Cầu Tiếp Theo): Nếu một yêu cầu tiếp theo đến trong khoảng thời gian sống của cache (TTL) và tiền tố của nó hoàn toàn khớp với nội dung liên quan đến một khóa cache đã lưu, hệ thống sẽ truy xuất trạng thái nội bộ đã được lưu. LLM hiệu quả sẽ tiến nhanh đến cuối của tiền tố mà không cần xử lý lại. Nó sau đó chỉ cần xử lý phần mới của câu lệnh (hậu tố). Điều này được gọi là đọc cache hoặc gõ cache.
Tiền Tố Đã Lưu:
Cái gì cấu thành nên "tiền tố" sẽ phụ thuộc vào API và cách bạn cấu trúc yêu cầu của mình. Thông thường, nó bao gồm các phần tĩnh của câu lệnh mà bạn dự định sử dụng lại trong suốt các cuộc gọi. Ví dụ, sử dụng cấu trúc API của Anthropic làm tham chiếu:
- Các Công Cụ: Định nghĩa của các công cụ/chức năng có sẵn.
- Câu Lệnh Hệ Thống: Hướng dẫn hoặc ngữ cảnh ở mức cao cho mô hình.
- Thông Điệp: Các thông điệp ban đầu từ người dùng/trợ lý, chẳng hạn như các ví dụ few-shot hoặc lịch sử cuộc trò chuyện.
Thứ tự thường có ý nghĩa (ví dụ, Anthropic xử lý tools, rồi system, sau đó messages). Bạn chỉ định nơi kết thúc tiền tố có thể lưu cache bằng cách sử dụng các tham số API cụ thể.
Đặc Điểm Cache:
- Thời Gian Sống (TTL): Cache không phải là vĩnh viễn. Chúng có một TTL. Ví dụ, cache của Anthropic có TTL tối thiểu là 5 phút, được làm mới mỗi khi mục cache được truy xuất (một lần gõ cache). Nếu một mục cache không được sử dụng trong khoảng thời gian TTL của nó, nó sẽ hết hạn và sẽ cần được tái tạo trên yêu cầu liên quan tiếp theo. Hiện tại, hầu hết các triển khai cung cấp việc lưu cache "tạm thời" với các thời gian sống tương đối ngắn.
- Phạm Vi và Quyền Riêng Tư: Việc lưu cache được thiết kế với quyền riêng tư trong tâm trí. Cache thường được phân tách ở cấp độ tổ chức hoặc tài khoản. Ngay cả khi hai tổ chức khác nhau gửi cùng một tiền tố câu lệnh hoàn toàn giống nhau, họ sẽ không chia sẻ một mục cache. Trong một tổ chức, người dùng gửi các tiền tố giống hệt có thể có thể chia sẻ một mục cache, cải thiện hiệu quả cho các ứng dụng nhóm. Việc sử dụng hàm băm mật mã cho các khóa đảm bảo rằng chỉ các yêu cầu với các tiền tố giống hệt mới có thể truy cập một cache cụ thể.
- Sự Khớp Chính Xác: Việc lưu cache dựa vào các sự khớp chính xác của nội dung tiền tố. Bất kỳ thay đổi nào, dù nhỏ, trong tiền tố đã chỉ định sẽ dẫn đến việc trượt cache và cần một ghi cache mới.
Tại Sao Nên Sử Dụng Việc Lưu Trữ Câu Lệnh?
Triển khai việc lưu trữ câu lệnh mang lại những lợi ích đáng kể, chủ yếu tập trung vào hiệu suất và hiệu quả chi phí.
- Giảm Độ Trễ: Đây thường là lợi ích ngay lập tức nhất. Bằng cách bỏ qua việc xử lý lại hàng nghìn token tiền tố có thể có, LLM có thể bắt đầu xử lý thông tin mới liên quan (hậu tố câu lệnh) nhanh hơn rất nhiều. Điều này trực tiếp chuyển thành thời gian phản hồi nhanh hơn cho người dùng cuối. Đối với các ứng dụng yêu cầu tương tác theo thời gian thực, như các chatbot hoặc trợ lý lập trình, việc tăng tốc này là rất quan trọng. AWS Bedrock báo cáo rằng có thể giảm độ trễ lên đến 85% cho các mô hình hỗ trợ.
- Giảm Chi Phí: Các API LLM thường tính phí dựa trên số lượng token đầu vào và đầu ra được xử lý. Khi có một lần gõ cache, bạn thường bị tính phí với mức thấp hơn nhiều cho các token được đọc từ cache so với mức tiêu chuẩn cho token đầu vào. Bạn chỉ phải trả mức tiêu chuẩn cho các token mới trong hậu tố (và có thể có một mức giá hơi cao hơn cho ghi cache ban đầu). Qua nhiều cuộc gọi với các tiền tố lớn và tĩnh, điều này có thể dẫn đến tiết kiệm chi phí đáng kể. AWS Bedrock gợi ý rằng có thể có giảm chi phí lên đến 90%.
- Tối Ưu Hiệu Suất Đối Với Các Trường Hợp Sử Dụng Thông Thường: Việc lưu cache đặc biệt có tác động đối với các ứng dụng thường xuyên có sự lặp lại của câu lệnh:
- Tạo Nội Dung Tăng Cường Tìm Kiếm (RAG) / Câu Hỏi & Trả Lời Tài Liệu: Các tài liệu lớn hoặc đoạn ngữ cảnh thường được cung cấp lặp đi lặp lại như một phần của câu lệnh trong khi chỉ có câu hỏi của người dùng thay đổi. Việc lưu trữ ngữ cảnh tài liệu sẽ tăng tốc đáng kể việc hỏi & trả lời cho tài liệu đó.
- Nhắc Nhở Few-Shot: Cung cấp nhiều ví dụ trong câu lệnh (học few-shot) cải thiện hiệu suất của mô hình nhưng làm tăng độ dài câu lệnh. Việc lưu trữ những ví dụ tĩnh này tránh cần phải xử lý lại chúng cho mỗi truy vấn mới.
- Quy Trình Làm Việc Tác Nhân: Các tác nhân AI thường dựa vào các câu lệnh hệ thống phức tạp, hướng dẫn chi tiết và một tập hợp các định nghĩa công cụ cố định. Việc lưu trữ những yếu tố không thay đổi này đẩy nhanh quá trình thực hiện nhiệm vụ, đặc biệt là trong các quy trình nhiều bước.
- Chatbots / Cuộc Trò Chuyện Nhiều Lượt: Trong khi lịch sử cuộc trò chuyện mở rộng, câu lệnh hệ thống ban đầu và hướng dẫn thường không thay đổi. Việc lưu trữ câu lệnh hệ thống, và có thể dần dần lưu trữ các lượt cuộc trò chuyện, giữ cho tương tác diễn ra nhanh chóng ngay cả khi cửa sổ ngữ cảnh được lấp đầy.
- Trợ Lý Lập Trình: Ngữ cảnh mã tĩnh, tài liệu thư viện hoặc hướng dẫn mẫu có thể được lưu trữ, cho phép trợ lý tập trung tính toán vào truy vấn lập trình cụ thể của người dùng.
- Tích Hợp Liền Mạch: Việc lưu trữ câu lệnh được thiết kế để hoạt động song song với các tính năng LLM khác. Ví dụ, nó tích hợp với các tính năng của AWS Bedrock như Agents và Guardrails, cho phép bạn sử dụng các thiết lập phức tạp mà không phải chịu đầy đủ hình phạt độ trễ cho các thành phần lặp lại.
Cách Bật Lưu Trữ Câu Lệnh
Phương pháp chính xác để bật việc lưu trữ câu lệnh có chút khác biệt giữa các nhà cung cấp LLM và các API của họ. Ở đây, chúng tôi sẽ tập trung vào việc triển khai sử dụng API Thông Điệp của Anthropic, điều này áp dụng cho các mô hình Claude trực tiếp qua Anthropic hoặc thông qua các nền tảng như AWS Bedrock.
Nguyên Tắc Chung: Cấu Trúc Câu Lệnh Của Bạn
Điều quan trọng là cấu trúc các cuộc gọi API của bạn sao cho nội dung tĩnh, có thể sử dụng lại xuất hiện trước, sau đó là nội dung động.
+-------------------------+--------------------------+
| TIỀN TỐ TĨNH | HẬU TỐ ĐỘNG |
| (Câu lệnh hệ thống, Công cụ, | (Câu truy vấn người dùng mới, Lượt Cuộc cuộc Trò chuyện mới nhất, v.v.)|
| Ví dụ Few-Shot, | |
| Ngữ cảnh ban đầu) | |
+-------------------------+--------------------------+
^
|
Điểm Ngắt Cache Tại Đây
Triển Khai API Anthropic (cache_control)
Anthropic sử dụng tham số cache_control trong thân yêu cầu API Thông Điệp để bật và quản lý việc lưu trữ.
- Bật: Bao gồm một đối tượng
cache_controltrong một trong các khối mà bạn muốn đưa vào làm cuối tiền tố có thể lưu cache của bạn. Hiện tại, loại duy nhất được hỗ trợ là"tạm thời". - Vị Trí: Bạn có thể đặt khối
cache_controltrên: - Thông điệp câu lệnh
system. - Một đối tượng
messagecụ thể (lượt người dùng hoặc trợ lý). - Một khối định nghĩa
tool(ít phổ biến, nhưng có thể). - Thứ Tự Tạo Cache: Tiền tố cache được xây dựng dựa trên nội dung đến và bao gồm khối được đánh dấu bằng
cache_control, theo thứ tự tiêu chuẩn:tools->system->messages. - Nhiều Điểm Ngắt: Bạn có thể xác định tới 4 điểm ngắt cache trong một yêu cầu duy nhất bằng cách thêm
cache_controlvào nhiều khối. Hệ thống sẽ cố gắng tìm tiền tố cache khớp dài nhất dựa trên những điểm ngắt tiềm năng này.
Ví Dụ (SDK Python của Anthropic): Lưu Trữ Một Câu Lệnh Hệ Thống
import anthropic
client = anthropic.Anthropic(api_key="YOUR_API_KEY")
# Yêu Cầu Đầu Tiên (Ghi Cache)
response1 = client.messages.create(
model="claude-3-5-sonnet-20240620",
max_tokens=1024,
system=[
{
"type": "text",
# Câu lệnh hệ thống này là nội dung chúng ta muốn lưu
"text": "Bạn là một trợ lý hữu ích chuyên về vật lý thiên văn. Cơ sở kiến thức của bạn bao gồm nhiều thông tin chi tiết về sự tiến hóa của sao, vũ trụ học và khoa học hành tinh. Vui lòng phản hồi một cách chính xác và ngắn gọn.",
"cache_control": {"type": "ephemeral"} # Đánh dấu để lưu cache
}
],
messages=[
{
"role": "user",
# Đây là phần động, không được lưu trữ trong tiền tố
"content": "Giới hạn Chandrasekhar là gì?"
}
]
)
print("Phản hồi đầu tiên:", response1.content)
print("Sử Dụng (Ghi):", response1.usage)
# Đầu ra ví dụ có thể trông như thế này:
# Usage(Write): Usage(input_tokens=60, output_tokens=50, cache_creation_input_tokens=60, cache_read_input_tokens=0)
# Yêu Cầu Tiếp Theo (Gõ Cache - trong TTL, ví dụ: < 5 phút sau)
response2 = client.messages.create(
model="claude-3-5-sonnet-20240620",
max_tokens=1024,
system=[
{
"type": "text",
# HOÀN TOÀN giống hệt câu lệnh hệ thống trước đó
"text": "Bạn là một trợ lý hữu ích chuyên về vật lý thiên văn. Cơ sở kiến thức của bạn bao gồm nhiều thông tin chi tiết về sự tiến hóa của sao, vũ trụ học và khoa học hành tinh. Vui lòng phản hồi một cách chính xác và ngắn gọn.",
"cache_control": {"type": "ephemeral"} # Đánh dấu lại
}
],
messages=[
{
"role": "user",
# Truy vấn động mới
"content": "Giải thích khái niệm năng lượng tối."
}
]
)
print("\\\\nPhản hồi thứ hai:", response2.content)
print("Sử Dụng (Gõ):", response2.usage)
# Đầu ra ví dụ có thể trông như thế này:
# Usage(Hit): Usage(input_tokens=8, output_tokens=75, cache_creation_input_tokens=0, cache_read_input_tokens=60)
Trong ví dụ này:
- Cuộc gọi đầu tiên xử lý 60 token của câu lệnh hệ thống và 8 token của thông điệp người dùng. Nó lưu trữ câu lệnh hệ thống (
cache_creation_input_tokens: 60). - Cuộc gọi thứ hai tìm thấy một lần gõ cache cho câu lệnh hệ thống giống hệt (
cache_read_input_tokens: 60). Nó chỉ cần xử lý 8 token của thông điệp người dùng mới như là đầu vào tiêu chuẩn (input_tokens: 8).
Ví Dụ (Lưu Trữ Từng Phần Trong Cuộc Trò Chuyện):
Để lưu trữ lịch sử cuộc trò chuyện, bạn có thể đặt cache_control trên những thông điệp cuối cùng mà bạn muốn đưa vào cache cho lượt tiếp theo.
# Lượt 1 (Người dùng hỏi, Trợ lý phản hồi - Lưu Cache Hệ Thống + Lượt 1)
response_turn1 = client.messages.create(
model="claude-3-5-sonnet-20240620",
max_tokens=500,
system=[{"type": "text", "text": "Giữ một cá tính thân thiện."}], # Lưu cái này nữa
messages=[
{"role": "user", "content": "Xin chào Claude!"},
{"role": "assistant", "content": "Xin chào! Tôi có thể giúp gì cho bạn hôm nay?", "cache_control": {"type": "ephemeral"}} # Lưu đến đây
]
)
# Giả sử người dùng thêm một thông điệp khác cho Lượt 2
# Lượt 2 (Gõ Cache cho Hệ thống + Lượt 1, Ghi cache cho Lượt 2)
response_turn2 = client.messages.create(
model="claude-3-5-sonnet-20240620",
max_tokens=500,
system=[{"type": "text", "text": "Giữ một cá tính thân thiện."}], # Cùng câu lệnh hệ thống
messages=[
{"role": "user", "content": "Xin chào Claude!"}, # Phần đã lưu trong tiền tố
{"role": "assistant", "content": "Xin chào! Tôi có thể giúp gì cho bạn hôm nay?"}, # Phần đã lưu trong tiền tố
{"role": "user", "content": "Kể cho tôi một sự thật thú vị."}, # Nội dung động mới
{"role": "assistant", "content": "Bạn có biết rằng mật ong không bao giờ hỏng không?", "cache_control": {"type": "ephemeral"}} # Lưu đến cuối Lượt 2
]
)
# Sử dụng của Lượt 2 sẽ hiển thị cache_read_input_tokens cho Hệ thống+Lượt1
# và cache_creation_input_tokens cho các thông điệp người dùng/trợ lý mới của Lượt 2
Theo Dõi Hiệu Suất Cache:
Phản hồi API bao gồm các chỉ số sử dụng cho thấy cách mà cache đã được sử dụng:
input_tokens: Số token đầu vào không được lưu trữ đã xử lý (hậu tố động).output_tokens: Số token được tạo ra trong phản hồi.cache_creation_input_tokens: Số token đầu vào đã xử lý và được ghi vào cache trong yêu cầu này (xảy ra trên một lần trượt cache).cache_read_input_tokens: Số token đầu vào đã được tải từ cache trong yêu cầu này (xảy ra trên một lần gõ cache).
Giám sát các trường này rất quan trọng để hiểu xem chiến lược lưu cache của bạn có hiệu quả không. Số lượng cao cache_read_input_tokens tương đối với cache_creation_input_tokens theo thời gian cho thấy việc lưu cache thành công.
AWS Bedrock:
Đối với các mô hình như Anthropic Claude truy cập qua AWS Bedrock, cơ chế lưu cache thường được bật sử dụng tham số cache_control cùng trong thân yêu cầu kích hoạt mô hình (application/json định dạng được truyền vào InvokeModel hoặc InvokeModelWithResponseStream). Bạn sẽ cấu trúc thân JSON theo các yêu cầu cụ thể của mô hình (ví dụ, định dạng API Thông điệp của Anthropic) và bao gồm trường cache_control như đã chỉ ra ở trên. Kiểm tra tài liệu Bedrock cụ thể cho nhà cung cấp mô hình mà bạn đang sử dụng.
Giá Cả Cho Việc Lưu Trữ Câu Lệnh Là Gì?
Việc lưu trữ câu lệnh giới thiệu một cấu trúc giá phức tạp hơn so với chi phí token tiêu chuẩn. Mặc dù mang lại lợi ích tổng thể, điều quan trọng là phải hiểu các loại token khác nhau liên quan:
- Token Đầu Vào Cơ Bản: Đây là các token đầu vào tiêu chuẩn không phải là một phần của tiền tố được lưu trữ (tức là, hậu tố động trong một kịch bản gõ cache, hoặc toàn bộ câu lệnh nếu không có lưu cache hoặc gặp lỗi). Chúng được tính phí theo mức giá token đầu vào tiêu chuẩn của mô hình.
- Token Ghi Cache (
cache_creation_input_tokens): Khi một tiền tố được xử lý lần đầu tiên (hoặc sau khi trượt cache) và được ghi vào cache, các token liên quan đến tiền tố đó thường sẽ bị tính phí theo mức cao hơn khác. Ví dụ, Anthropic tính phí 25% nhiều hơn mức giá token đầu vào cơ bản cho các lần ghi cache. Điều này phản ánh chi phí của cả việc xử lý và lưu trữ mục cache. - Token Đọc Cache / Token Gõ Cache (
cache_read_input_tokens): Khi có một lần gõ cache xảy ra, các token tương ứng với tiền tố được tải từ cache sẽ bị tính phí theo mức giảm đáng kể. Ví dụ, Anthropic chỉ tính phí 10% của mức giá token đầu vào cơ bản (giảm giá 90%) cho các lần đọc cache. Điều này phản ánh mức tiết kiệm tính toán. - Token Đầu Ra: Các token do LLM tạo ra trong phản hồi sẽ bị tính phí theo mức giá token đầu ra tiêu chuẩn của mô hình, bất kể liệu việc lưu cache có được sử dụng cho đầu vào hay không.
Bảng Giá Ví Dụ (Các Mô Hình Claude của Anthropic - tỷ lệ minh họa):
| Mô Hình | Đầu Vào Cơ Bản (/MTok) | Ghi Cache (/MTok) (+25%) | Đọc Cache (/MTok) (-90%) | Đầu Ra (/MTok) |
|---|---|---|---|---|
| Claude 3.5 Sonnet | $3.00 | $3.75 | $0.30 | $15.00 |
| Claude 3 Haiku | $0.25 | $0.30 | $0.03 | $1.25 |
| Claude 3 Opus | $15.00 | $18.75 | $1.50 | $75.00 |
(Lưu ý: Luôn tham khảo các trang giá chính thức của Anthropic và AWS Bedrock để có được các mức giá hiện tại nhất.)
Hiệu quả chi phí phụ thuộc vào cách thức thường xuyên mà bạn có được các lần gõ cache so với lượt trượt cho một tiền tố nhất định. Nếu một tiền tố lớn được sử dụng lại nhiều lần, chi phí ban đầu cao hơn của việc ghi cache sẽ nhanh chóng được bù đắp bởi sự tiết kiệm đáng kể từ việc đọc cache sau đó.
Hạn Chế Của Việc Lưu Trữ Câu Lệnh
Mặc dù mạnh mẽ, việc lưu trữ câu lệnh có những hạn chế và các yếu tố cần xem xét:
Độ Dài Tối Thiểu Có Thể Lưu: Các mô hình thường có yêu cầu tối thiểu về token để một tiền tố đủ điều kiện lưu cache. Các câu lệnh ngắn hơn giới hạn này không thể được lưu trữ, ngay cả khi được đánh dấu với cache_control.
- Anthropic Claude 3.7/3.5 Sonnet & Opus: Tối thiểu 1024 token.
- Anthropic Claude 3.5/3 Haiku: Tối thiểu 2048 token.
Hủy Cache (Xóa Cache): Cache rất nhạy cảm với những thay đổi trong tiền tố. Bất kỳ sửa đổi nào cũng sẽ làm hỏng cache và buộc phải ghi lại:
- Thay đổi bất kỳ nội dung văn bản nào trong các khối
system,toolshoặcmessagesđược chỉ định là một phần của tiền tố. - Thay đổi thứ tự hoặc số lượng định nghĩa
tool. - Thay đổi tham số
tool_choice(ví dụ, chuyển đổi từautosang một công cụ cụ thể). - Thêm, xóa hoặc thay đổi hình ảnh trong câu lệnh (đối với các mô hình đa phương thức).
- Điều chỉnh các tham số mô hình khác ảnh hưởng đến xử lý ban đầu cũng có thể làm hỏng cache (ví dụ, các thiết lập tư duy mở rộng của Anthropic có thể làm vô hiệu hóa các cache thông điệp).
Thời Gian Sống Cache (TTL): Nhớ rằng cache là tạm thời (ví dụ: TTL tối thiểu 5 phút cho Anthropic, được làm mới khi sử dụng). Các tiền tố không được sử dụng lại trong TTL sẽ hết hạn. Hiện tại, không có cách nào để xóa hoặc kéo dài cache một cách thủ công ngoài hành vi tự động của nó.
Concurrency: Nếu bạn gửi nhiều yêu cầu giống hệt cùng một lúc nhắm vào một tiền tố trước khi yêu cầu đầu tiên hoàn thành và ghi mục vào cache, các yêu cầu tiếp theo có thể dẫn đến các trường hợp trượt cache cho đến khi lần ghi đầu tiên hoàn tất. Để đảm bảo gõ cache trong các tình huống song song, bạn có thể cần phải đợi phản hồi đầu tiên trước khi gửi thêm.
Các Mô Hình Hỗ Trợ: Việc lưu trữ câu lệnh không có sẵn cho tất cả các mô hình hoặc nhà cung cấp. Luôn kiểm tra tài liệu cho mô hình cụ thể mà bạn định sử dụng. (Hiện tại xác nhận cho nhiều mô hình Claude 3 và 3.5).
Debugging: Xác định những thay đổi tinh xảo khiến cache bị trượt đôi khi có thể rất khó khăn. Cần phải so sánh cẩn thận nội dung tiền tố chính xác giữa các cuộc gọi.
Các Thực Tiễn Tốt Nhất Để Lưu Trữ Hiệu Quả
Để tối đa hóa lợi ích của việc lưu trữ câu lệnh:
- Cấu Trúc Câu Lệnh Một Cách Thông Minh: Đặt thông tin ổn định, có thể sử dụng lại nhất (câu lệnh hệ thống, hướng dẫn, định nghĩa công cụ, tài liệu ngữ cảnh, ví dụ few-shot) ở đầu của chuỗi câu lệnh của bạn. Đặt thông tin động, thường xuyên thay đổi (câu truy vấn của người dùng, các lượt cuộc trò chuyện mới nhất) sau điểm ngắt cache.
- Xác Định Điểm Ngắt Tối Ưu: Sử dụng
cache_control(hoặc cơ chế tương đương) một cách có chủ đích. Đánh dấu kết thúc của khối nội dung tĩnh lớn nhất có thể. Nếu sử dụng nhiều điểm ngắt (như Anthropic cho phép), hãy xem xét các mức độ ổn định khác nhau trong cấu trúc câu lệnh của bạn. - Theo Dõi Sử Dụng Cache: Thường xuyên kiểm tra
cache_creation_input_tokensvàcache_read_input_tokenstrong phản hồi API của bạn. Hướng đến một tỷ lệ đọc cao so với ghi theo thời gian. Nếu bạn thấy chủ yếu ghi, các tiền tố của bạn có thể thay đổi quá thường xuyên hoặc có thể dưới độ dài tối thiểu có thể lưu cache. - Tránh Những Thay Đổi Không Cần Thiết: Cần chú ý rằng ngay cả những thay đổi nhỏ, có vẻ như không quan trọng đến nội dung tiền tố (chẳng hạn như thêm một khoảng trống hoặc thay đổi dấu câu) sẽ làm hỏng cache. Đảm bảo tính nhất quán trong cách tạo các tiền tố.
- Xem Xét Các Thương Vụ Chi Phí: Lưu trữ có hiệu quả nhất cho các tiền tố dài và thường xuyên được sử dụng lại. Đừng lưu trữ các tiền tố quá ngắn vì những tiết kiệm tiềm năng là không đáng kể và có thể không bù đắp cho sự phức tạp. Tránh lưu trữ những đầu vào của người dùng có biến đổi cao.
- Kiểm Tra và Lặp Lại: Thực hiện các thử nghiệm với các cấu trúc câu lệnh khác nhau và điểm ngắt cache để tìm ra chiến lược tối ưu cho khối lượng công việc và mẫu sử dụng cụ thể của ứng dụng của bạn.
Kết Luận
Việc lưu trữ câu lệnh là một kỹ thuật tối ưu hóa quan trọng cho bất kỳ ai xây dựng ứng dụng dựa trên các mô hình ngôn ngữ lớn. Bằng cách thông minh lưu trữ và tái sử dụng trạng thái tính toán của các tiền tố câu lệnh tĩnh, nó trực tiếp giải quyết các thách thức về độ trễ và chi phí liên quan đến các câu lệnh dài hoặc lặp lại. Hiểu cách thức hoạt động của việc lưu trữ, các chi tiết triển khai cụ thể cho nhà cung cấp LLM của bạn (như cache_control của Anthropic), các sắc thái về giá cả liên quan và những hạn chế của nó cho phép bạn thiết kế các ứng dụng AI hiệu quả, đáp ứng nhanh và tiết kiệm chi phí hơn. Khi việc sử dụng LLM phát triển về độ phức tạp và quy mô, việc tận dụng các tính năng như việc lưu trữ câu lệnh sẽ ngày càng trở nên quan trọng để xây dựng các giải pháp hiệu suất cao và bền vững.
Bạn muốn một nền tảng tích hợp, Tất cả trong Một để nhóm phát triển của bạn làm việc cùng nhau với năng suất tối đa?
Apidog đáp ứng tất cả các yêu cầu của bạn, và thay thế Postman với mức giá phải chăng hơn nhiều!

