OpenRouter ra mắt Prompt Caching và Sticky Routing: Tối ưu chi phí cho Agent AI

Agent của bạn gửi cùng một system prompt, định nghĩa công cụ (tool definitions), schema và hướng dẫn chính sách trong mỗi lượt phản hồi. Trong một phiên làm việc 6 lượt, bạn có thể bị tính phí cho cùng một khối nội dung mở đầu đó 6 lần, mặc dù thứ duy nhất thay đổi chỉ là tin nhắn mới nhất của người dùng hoặc kết quả công cụ mới nhất của agent.

Prompt caching giải quyết vấn đề này. Nhà cung cấp sẽ đọc phần lặp lại trong prompt của bạn từ bộ nhớ đệm thay vì tính phí toàn bộ giá cho mỗi lần gửi. Sticky routing (định tuyến cố định) giúp duy trì điều này xuyên suốt các lượt bằng cách gửi phiên làm việc trở lại đúng nhà cung cấp đang lưu giữ bộ nhớ đệm đó.

Bài viết này đề cập đến khía cạnh tài chính: chi phí cho các token được lưu trong bộ nhớ đệm, lý do tại sao việc đọc và ghi vào bộ nhớ đệm có mức giá khác nhau, cách session_id giữ cho phiên làm việc của agent luôn "nóng" từ lượt đầu tiên và cách kiểm tra xem tính năng caching có thực sự hoạt động hay không.

Tóm tắt (Tl;dr)

Prompt caching giúp cắt giảm chi phí token của bạn bao nhiêu?

Việc đọc từ bộ nhớ đệm có chi phí bằng 0,1x đến 0,5x so với giá input thông thường, tùy thuộc vào nhà cung cấp. Phạm vi này chính là lý do tại sao caching có thể giúp các vòng lặp agent trở nên rẻ hơn nhiều.

Phần lặp lại thường là phần đắt đỏ nhất: một system prompt dài, các định nghĩa công cụ, JSON schema, các bộ lọc an toàn (guardrails), tài liệu được truy xuất hoặc các ví dụ giúp mô hình duy trì tính nhất quán. Nếu không có caching, mỗi lượt đều phải trả toàn bộ chi phí cho tất cả những nội dung đó. Với caching, yêu cầu đầu tiên sẽ ghi nội dung vào bộ nhớ đệm, và các yêu cầu sau đó sẽ đọc lại với mức giá rẻ hơn.

Dưới đây là cái nhìn ở cấp độ nhà cung cấp:

Tài liệu về prompt caching có bảng phân tích đầy đủ. Số tiền chính xác vẫn phụ thuộc vào mô hình và lộ trình của nhà cung cấp; hệ số nhân cho bạn biết input được lưu trong bộ nhớ đệm so sánh thế nào với input thông thường của nhà cung cấp đó.

Đối với những người xây dựng agent, mô hình rất đơn giản: lượt đầu tiên có thể phải trả phí để thiết lập bộ nhớ đệm, nhưng mọi lượt sau đó sẽ rẻ hơn nhiều miễn là khối nội dung mở đầu đó được tái sử dụng.

Chi phí đi về đâu: ghi vào bộ nhớ đệm so với đọc từ bộ nhớ đệm?

Prompt caching có hai loại chi phí: ghi và đọc.

Việc ghi xảy ra khi nhà cung cấp lưu trữ phần có thể tái sử dụng của prompt. Việc đọc xảy ra khi một yêu cầu sau đó sử dụng lại nội dung đã lưu trữ đó. Bạn sẽ có lợi khi cùng một nội dung được đọc đủ số lần để bù đắp cho chi phí ghi.

Ở một số nhà cung cấp, chi phí ghi đắt hơn input thông thường. Chi phí ghi vào bộ nhớ đệm của Anthropic là 1,25x giá input cho TTL (thời gian tồn tại) mặc định 5 phút và 2,0x giá input cho TTL 1 giờ. Một lần ghi vào bộ nhớ đệm Anthropic mà không bao giờ được sử dụng lại sẽ tốn kém hơn so với việc gửi cùng một prompt mà không dùng caching.

Đối với một yêu cầu dùng một lần, caching có thể không giúp ích gì. Đối với một agent đa lượt, sự lặp lại là mặc định: agent mang theo cùng các hướng dẫn, công cụ, schema và ngữ cảnh chính sách trong suốt cả phiên. Vì vậy, chi phí ghi sẽ tự bù đắp sau một vài lượt.

Hãy sử dụng thời gian tồn tại bộ nhớ đệm (TTL) 5 phút cho các đợt hoạt động ngắn khi lượt tiếp theo đến nhanh chóng. Sử dụng loại 1 giờ khi phiên làm việc có thể tạm dừng đủ lâu để bộ nhớ đệm mặc định hết hạn, nhưng nội dung vẫn đáng để giữ lại.

Tại sao bộ nhớ đệm "nóng" không phải lúc nào cũng giúp ích cho yêu cầu tiếp theo?

Bộ nhớ đệm "nóng" chỉ hữu ích nếu yêu cầu tiếp theo rơi vào đúng endpoint của nhà cung cấp đang lưu giữ nó.

Khi các yêu cầu có thể được định tuyến đến nhiều nhà cung cấp, lượt một có thể ghi vào bộ nhớ đệm ở một nhà cung cấp trong khi lượt hai lại rơi vào nơi khác. Nhà cung cấp thứ hai không có bộ nhớ đệm "nóng" để đọc. Yêu cầu vẫn hoạt động, nhưng bạn phải trả toàn bộ giá và cached_tokens vẫn ở mức thấp hoặc bằng không.

Đó là lý do tại sao chúng tôi kết hợp sticky routing với prompt caching. Sau một yêu cầu đã được lưu vào bộ nhớ đệm, chúng tôi định tuyến các yêu cầu tiếp theo cho cùng một mô hình trở lại đúng endpoint của nhà cung cấp đó khi giá đọc bộ nhớ đệm của họ rẻ hơn input thông thường. Nếu nhà cung cấp "dính" đó không khả dụng, OpenRouter sẽ chuyển sang nhà cung cấp khả dụng tiếp theo thay vì làm thất bại yêu cầu.

Theo mặc định, OpenRouter nhận diện một cuộc hội thoại bằng cách băm (hash) tin nhắn hệ thống hoặc tin nhắn nhà phát triển đầu tiên và tin nhắn không phải hệ thống đầu tiên của nó. Điều đó hoạt động khi các tin nhắn mở đầu đó không thay đổi.

Các agent thường làm hỏng điều này. Một số viết lại tin nhắn đầu tiên của chúng khi chúng tóm tắt trạng thái, sắp xếp lại ngữ cảnh công cụ hoặc thêm metadata cho lượt chạy mới. Khi các tin nhắn mở đầu thay đổi, mã băm thay đổi và cuộc hội thoại có thể rơi vào một nhà cung cấp khác. Giải pháp là sử dụng một session_id rõ ràng.

Ép buộc bộ nhớ đệm "nóng" từ lượt đầu tiên với session_id

Đối với các vòng lặp agent, hãy thiết lập session_id. Khi bạn truyền nó vào, OpenRouter sử dụng trực tiếp nó làm khóa định tuyến cố định thay vì suy ra khóa từ các tin nhắn mở đầu.

Với session_id, sticky routing bắt đầu hoạt động sau yêu cầu thành công đầu tiên, trước khi bất kỳ lần cache hit nào xảy ra. Nếu không có nó, tính "dính" chỉ bắt đầu sau khi phát hiện cache hit. Đối với các agent đa lượt, đó là sự khác biệt giữa một bộ nhớ đệm đáng tin cậy từ lượt đầu tiên và một bộ nhớ đệm chỉ đôi khi mới "nóng".

Bạn có thể gửi session_id dưới dạng trường cấp cao nhất trong body của yêu cầu hoặc thông qua header x-session-id. Hãy giữ nó ổn định cho cuộc hội thoại hoặc lượt chạy của agent và giữ nó dưới 256 ký tự.

Sử dụng một giá trị khớp với đơn vị công việc: một luồng chat, ticket, lượt chạy quy trình hoặc tác vụ của agent. Đừng tạo một session_id mới cho mỗi lượt, nếu không các yêu cầu sẽ ngừng rơi vào nhà cung cấp đang giữ bộ nhớ đệm.

Nếu bạn sử dụng các mô hình router như Auto Router hoặc Pareto Router, tính năng session stickiness cũng sẽ ghim mô hình mà router đã chọn, không chỉ nhà cung cấp. Điều đó giúp cuộc hội thoại không bị chuyển đổi mô hình giữa chừng, nhờ đó hành vi vẫn nhất quán và bộ nhớ đệm vẫn "nóng".

Làm thế nào để tôi xác nhận prompt caching thực sự đang hoạt động?

Cách nhanh nhất để kiểm tra là xem xét phần usage (sử dụng).

Trong phản hồi, usage.prompt_tokens_details.cached_tokens hiển thị số lượng token đã được đọc từ bộ nhớ đệm. Nếu nó lớn hơn không, yêu cầu đã truy cập vào bộ nhớ đệm. cache_write_tokens hiển thị số lượng token đã được ghi trong một yêu cầu ghi vào bộ nhớ đệm.

Trong ví dụ này, hầu hết các token của prompt đến từ bộ nhớ đệm và lượt này không ghi một mục bộ nhớ đệm mới.

Bạn có thể kiểm tra hành vi của bộ nhớ đệm ở ba nơi: chế độ xem chi tiết trên trang Activity, API /api/v1/generation và đối tượng usage.prompt_tokens_details được trả về cùng với các phản hồi API.

Sử dụng cache_discount để xem một lần tạo (generation) đã tiết kiệm được bao nhiêu. Trên các nhà cung cấp có tính phí ghi, bạn có thể thấy mức chiết khấu âm ở lượt ghi vì chi phí ghi vào bộ nhớ đệm đắt hơn input thông thường. Ở các lượt đọc bộ nhớ đệm sau đó, mức chiết khấu sẽ chuyển sang dương.

Tại sao bộ nhớ đệm của bạn bị miss (trượt) và làm thế nào để ngăn chặn điều đó?

Khi caching có vẻ bị hỏng, thường là do một trong 4 nguyên nhân: prompt quá ngắn, bộ nhớ đệm đã hết hạn, nội dung mở đầu đã thay đổi hoặc yêu cầu đã chuyển sang nhà cung cấp khác.

Prompt nằm dưới mức tối thiểu của nhà cung cấp

Mọi nhà cung cấp đều có kích thước prompt tối thiểu, và dưới mức đó thì không có gì được lưu vào bộ nhớ đệm. Trên Anthropic, Claude Opus 4.5 đến 4.8 và Claude Haiku 4.5 cần 4.096 token; Claude Haiku 3.5 cần 2.048; Claude Sonnet 4, 4.5 và 4.6 (và Opus 4 / 4.1) cần 1.024. OpenAI cần 1.024. Gemini 2.5 Pro cần 4.096; Gemini 2.5 Flash cần 1.024.

Nếu nội dung có thể tái sử dụng của bạn nằm dưới mức tối thiểu đó, caching sẽ không bắt đầu. Đừng thêm văn bản rác vào yêu cầu chỉ để ép buộc nó. Hãy sử dụng caching ở nơi bạn đã có sẵn nhiều nội dung có thể tái sử dụng: công cụ, schema, tài liệu được truy xuất, ví dụ hoặc văn bản chính sách.