Bộ nhớ đệm GPT-6.1 Terra: Năm xu mỗi lần đọc, và khi nào việc ghi mới có lãi

Giá đầu vào được lưu trong bộ nhớ đệm của GPT-6.1 Terra là $0,05 mỗi triệu token — thấp hơn 95% so với giá đầu vào tiêu chuẩn $1,00 và là mức chiết khấu đơn lẻ lớn nhất trên toàn bộ bảng giá. Cái bẫy nằm ở mặt còn lại của bảng chi phí: ghi vào bộ nhớ đệm tốn $1,25 mỗi triệu token để lưu giữ trong 30 phút hoặc $2,50 mỗi triệu token để lưu giữ trong 12 giờ. Một khối lượng công việc đọc cùng một tiền tố hai lần sẽ có lợi. Một khối lượng công việc xây dựng lại tiền tố của nó trong mỗi lần gọi sẽ trả phí ghi và không bao giờ nhận được chiết khấu, và bảng giá sẽ không cho bạn biết bạn đang vận hành loại nào.

Bài viết này làm rõ phần tính toán: điểm hòa vốn chính xác, ba tình huống khối lượng công việc mẫu ở các quy mô khác nhau, tương tác với ngưỡng giới hạn ngữ cảnh dài 272K, và những thói quen thiết kế prompt âm thầm phá hỏng bộ nhớ đệm.

Bốn con số

• Đầu vào tiêu chuẩn — $1,00 mỗi triệu token.

• Đầu vào được lưu trong bộ nhớ đệm — $0.05 mỗi triệu, mức giảm giá 95%.

• Ghi cache, thời gian lưu giữ 30 phút — 1,25 USD mỗi triệu.

• Ghi bộ nhớ đệm, lưu giữ 12 giờ — $2.50 mỗi triệu.

Trên {{1}}272.000{{/1}} token đầu vào, mọi thứ đều tăng gấp đôi: đầu vào {{2}}$2,00{{/2}}, bộ nhớ đệm {{3}}$0,10{{/3}}, ghi bộ nhớ đệm {{4}}$2,50{{/4}}. Vì vậy, ngưỡng dốc ngữ cảnh dài không chỉ làm tăng mức giá đầu vào — mà còn làm tăng giá của cả việc lưu đệm lẫn ghi đệm cùng một lúc.

Để so sánh, đầu vào được lưu đệm của GPT-6.1 Sol là $0.10 còn của GPT-5.6 Terra là $0.20. Mức giá đọc năm xu của Terra là rẻ nhất trong dòng sản phẩm, và mức giảm giá 95% chính là điều khiến các cuộc gọi lặp lại với ngữ cảnh dài trở nên khả thi về mặt kinh tế.

Điểm hòa vốn chính xác

Giả sử một tiền tố gồm P token được tái sử dụng qua N lần gọi, và tạm thời bỏ qua đầu ra.

• Không sử dụng bộ nhớ đệm: N × P × $1.00.

• Khi dùng bộ nhớ đệm: một lần ghi với $1.25 × P, sau đó N lần đọc với $0.05 × P.

Cho hai vế bằng nhau: 0,95N = 1,25, vậy N ≈ 1,32. Trên thực tế, điều đó có nghĩa là lần gọi thứ hai đã có lãi: chi phí ghi là 1,25 mỗi triệu và mỗi lần đọc tiết kiệm 0,95, nên hai lần đọc thu hồi được nhiều hơn chi phí ghi. Với thời gian lưu giữ 12 giờ, chi phí ghi là $2,50 và điểm hòa vốn là 2,63 lần đọc — lần gọi thứ ba sẽ bù đắp chi phí đó.

Đó là một ngưỡng thấp hơn so với những gì hầu hết các nhóm giả định. Lầm tưởng phổ biến là bộ nhớ đệm chỉ có lợi với mức tái sử dụng rất cao; trên thẻ này, nó có lợi ngay từ yêu cầu thứ hai, miễn là tiền tố thực sự khớp.

Ba khối lượng công việc

Một prompt hệ thống 50.000 token trải qua 10.000 yêu cầu ngắn. Không dùng bộ nhớ đệm: 10.000 × 50.000 × 1,00 USD mỗi triệu = 500 USD chỉ cho phần tiền tố. Dùng bộ nhớ đệm: một lần ghi 50.000 × 1,25 USD mỗi triệu = 0,0625 USD, cộng với 10.000 lần đọc với 50.000 × 0,05 USD mỗi triệu = 25 USD. Tổng cộng 25,06 USD — tiết kiệm 95% trên phần tiền tố, và lần ghi bộ nhớ đệm chỉ là sai số làm tròn.

Một kho mã 900.000 token trải qua 20 câu hỏi. Không dùng bộ nhớ đệm, mỗi yêu cầu đều bị tính theo mức giá ngữ cảnh dài: 900.000 × $2,00 mỗi triệu = $1,80 mỗi lần gọi, $36 cho hai mươi lần. Dùng bộ nhớ đệm: một lần ghi 900.000 × $2,50 mỗi triệu = $2,25, sau đó hai mươi lần đọc ở mức 900.000 × $0,10 mỗi triệu = $0,09 mỗi lần, tổng cộng $1,80. Tổng cộng $4,05 — tiết kiệm 89%, và khoản chênh lệch 18 đô-la chính là toàn bộ biên lợi nhuận trên một số sản phẩm.

Một tài liệu 20.000 token trải qua ba câu hỏi, mỗi câu có một persona và hướng dẫn khác nhau. Đây là trường hợp caching thất bại: nếu tiền tố thay đổi giữa các lần gọi — system prompt khác, thứ tự hướng dẫn khác, một user ID được nội suy ở đầu — mô hình sẽ thấy ba tiền tố khác nhau và ghi ba bộ cache. Chi phí khi không cache và khi "cache" là như nhau, chỉ khác là bạn đã trả tiền cho việc ghi. Cách sửa mang tính cấu trúc: đặt mọi thứ có thể thay đổi ở cuối prompt, và giữ tài liệu cùng các hướng dẫn ổn định ở phía trước.

Điều gì làm hỏng cache/p> p>Prompt caching của OpenAI hoạt động trên phần tiền tố không thay đổi của một yêu cầu. Bất kỳ thay đổi nào ở phần đầu của prompt đều làm vô hiệu hóa mọi thứ phía sau. Những nguyên nhân thường gặp:/p> p>• Dấu thời gian hoặc ID yêu cầu trong system prompt. Đây là nguyên nhân phổ biến nhất của tỷ lệ trúng cache 0%./p> p>• Cá nhân hóa theo từng người dùng được chèn ở đầu thay vì ở cuối./p> p>• Định nghĩa công cụ bị sắp xếp lại hoặc danh sách công cụ thay đổi giữa các lần gọi./p> p>• Một bước truy xuất nối các tài liệu theo thứ tự khác nhau ở mỗi lần./p> p>• Thay đổi khoảng trắng do các engine tạo mẫu — chỉ cần định dạng lại một khối JSON là đủ./p> p>• Chuyển đổi giữa Chat Completions và Responses ở giữa pipeline, điều này làm thay đổi tiền tố đã được tuần tự hóa./p> p>Cách chẩn đoán rất đơn giản: ghi log 2.000 token đầu tiên của mỗi yêu cầu và băm chúng. Nếu mã băm thay đổi giữa những lần gọi lẽ ra phải giống hệt nhau, cache đã chết và không có cách tinh chỉnh nào có thể làm nó sống lại./p> h2>Cache và ngưỡng sụt giảm 272K

Hai yếu tố này tương tác theo một cách dễ bị bỏ qua. Một tiền tố được lưu trong bộ nhớ đệm 250,000 token tốn $0.05 mỗi triệu để đọc và $1.25 để ghi. Tăng nó lên 300,000 token và mọi con số đều tăng gấp đôi: $0.10 để đọc, $2.50 để ghi, và phần không được lưu trong bộ nhớ đệm được tính phí ở mức $2.00. Một pipeline vượt qua ngưỡng này phải chịu cú nhảy giá ở cả phía có bộ nhớ đệm lẫn phía không có bộ nhớ đệm.

Điều này tạo ra một động lực thiết kế không hiển nhiên: nếu một khối lượng công việc nằm ngay trên 272K, việc thu nhỏ tiền tố xuống 270K có thể giảm một nửa hóa đơn mà không thay đổi tác vụ. Cắt bớt một phần văn bản mẫu, loại bỏ một khối truy xuất không cần thiết hoặc chuyển một ví dụ ra khỏi lời nhắc hệ thống có giá trị ở ranh giới hơn là ở bất kỳ nơi nào khác trên bảng giá.

Bộ nhớ đệm so với các giải pháp thay thế

• Bộ nhớ đệm — hiệu quả nhất khi cùng một tiền tố dài được tái sử dụng nhiều lần trong khung thời gian lưu giữ, và tiền tố đó thực sự ổn định.

• Chunking — tốt nhất khi tài liệu lớn nhưng mỗi câu hỏi chỉ liên quan đến một phần nhỏ; truy xuất rẻ hơn so với việc gửi 900K token ngay cả ở mức giá đã lưu trong bộ nhớ đệm.

• Batch/Flex — giảm 50% so với mức tiêu chuẩn, nhưng độ trễ của batch được tính bằng giờ; có thể cộng dồn với caching, không cộng dồn với các sản phẩm thời gian thực.

• Một mô hình rẻ hơn — GPT-6 Luna ở mức $0.10/$0.50 có thể đánh bại mức giá đã cache của Terra cho các tác vụ đơn giản, vì đầu vào chưa cache của Luna chỉ gấp đôi đầu vào đã cache của Terra.

Phép so sánh cuối cùng là phép mà các đội nhóm hay quên. Bộ nhớ đệm là một khoản giảm giá trên Terra, không phải bảo đảm rằng Terra là cách rẻ nhất để trả lời một câu hỏi. Đối với phân loại trên một lời nhắc 50.000 token, Luna được lưu trong bộ nhớ đệm ở mức $0,01 mỗi triệu lần đọc vẫn là lựa chọn rẻ hơn nếu tác vụ đủ đơn giản.

Những gì bạn có thể chạy hôm nay

GPT-6.1 Terra không có trong danh mục OrcaRouter tại thời điểm viết bài, vì vậy hành vi bộ nhớ đệm của nó phải được đo trực tiếp với OpenAI. Các mô hình đang hoạt động — GPT-6.1 Sol ở mức $2/$10 với giá đã lưu đệm $0.10, GPT-5.6 Terra ở mức $2/$12 với $0.20, GPT-6 Luna ở mức $0.10/$0.50 — đều có thể được chạy thử trên một khóa với mức tăng giá 0% so với giá niêm yết của nhà cung cấp.

Phép đo cần xây dựng không phải là “caching có hoạt động không” — nó có — mà là “bao nhiêu phần trong lưu lượng của tôi có một tiền tố ổn định”. Tỷ lệ đó là con số duy nhất quyết định việc lần đọc năm xu của Terra có tác động đến hóa đơn của bạn hay không, và nó là thuộc tính của prompt của bạn, chứ không phải của mô hình.