Thuế cache đa ngôn ngữ

Hai ghi chú trên blog này, một về cái sàn cache mà tiếng Anh chạm tới sau cùng và một về chuyện độn prompt để vượt qua nó, hóa ra là hai mặt của cùng một bất đẳng thức. Để nguyên ở dạng bài blog thì phí, nên chúng tôi dành cả tháng Tám làm cho tử tế: mười hai ngôn ngữ, bốn họ tokenizer, đối chiếu hóa đơn thật, một thí nghiệm chất lượng có đối chứng, và một bản preprint kèm mọi thứ cần để tái lập.

The Multilingual Cache Tax, INTFRAME Research, DOI 10.5281/zenodo.22081426. Bài báo theo CC BY 4.0, mã nguồn theo MIT, kèm gói tái lập.

Luận điểm gói trong một dòng

Một cái sàn cache tính bằng token biến sự phình token giữa các ngôn ngữ thành chênh lệch chi phí chẳng liên quan gì tới dịch vụ thực sự được cung cấp. Ở đoạn prompt đủ dài, cache giữ nguyên khoảng cách phình vốn có, vì ưu đãi nhân mọi ngôn ngữ với cùng một hệ số. Ở gần sàn, dấu bị đảo: ngôn ngữ phình ít nhất, thường là tiếng Anh, lại là bên phải trả giá đầy đủ. Bạn nộp mặt nào của thứ thuế này chỉ phụ thuộc vào prefix của bạn nằm trên hay dưới một con số trong bảng giá.

Điều khiến nó thành một bài báo

Gọi i là độ phình của một cặp ngôn ngữ và r là hệ số giá cache. Khoản phạt gần sàn chỉ tồn tại khi r · i < 1. Và việc độn để thoát khỏi nó có lợi đúng theo cùng điều kiện ấy. Cái bẫy và lối thoát là cùng một bất đẳng thức, nghĩa là khả năng thoát ra không phải may mắn của một bộ tham số mà là một tính chất cấu trúc.

Trong đó có cả một mẩu lịch sử: ở mức giá cache 0.5× của năm 2024, một cặp phình mạnh như tiếng Thái với tokenizer cũ (4.4×) có r · i = 2.2 và hoàn toàn không có khoản phạt gần sàn nào. Chính việc cả ngành hạ xuống 0.1× đã tạo ra hiện tượng này, và cũng chính nó bảo đảm luôn đường thoát.

Đo các đầu vào ở đúng nơi chúng tồn tại

Văn bản benchmark thổi phồng cái giá mà một dịch vụ thật phải trả. System prompt trong production phần lớn là khung sườn trung lập ngôn ngữ: JSON schema, thẻ, quy tắc định dạng, và chẳng ai đi dịch những thứ đó. Trong kho ngữ liệu của chúng tôi, khung sườn chiếm 32% đến 66% số token tiếng Anh, trung vị 54%. Chỉ bản địa hóa phần lõi chỉ dẫn, đúng như các hệ thống thật vẫn làm, thì độ phình hữu hiệu tụt hẳn.

Mọi con số tiền trong bài báo đều dùng giá trị thận trọng của prompt thật, không dùng giá trị benchmark. Hãy hình dung một dịch vụ tái sử dụng một system prompt qua một triệu request mỗi tháng, trên bảng giá model tầm trung. Prompt tiếng Anh 900 token nằm dưới sàn, không được cache, tốn khoảng 1,880 đô một tháng. Bản tiếng Hàn 1,134 token được cache, tốn khoảng 505 đô. Nghĩa là một hệ thống tiếng Anh triển khai trong vô thức trả gấp khoảng 3.7 lần cho cùng một prefix. Độn prompt tiếng Anh lên tới sàn thì còn khoảng 285 đô, rẻ nhất trong cả ba. Ở đoạn sâu hơn, nơi cả hai đều được cache, khoảng cách còn lại chừng 1,960 đô mỗi năm, và độn bao nhiêu cũng không xóa được.

Chỗ chúng tôi đã sai

Bản thảo đầu tiên lập luận rằng khoản phạt gần sàn là một chi phí mang tính cấu trúc. Không phải vậy, và chính thí nghiệm độn mà chúng tôi chạy để bảo vệ luận điểm đó đã bác bỏ nó. Chúng tôi rút lại phiên bản mạnh, phát hành lại, và ghi thẳng việc rút lại vào hồ sơ thay vì lặng lẽ sửa đi.

Chúng tôi còn cắt trọn một mục kết quả. Có một trục về độ trễ, và thời gian tới token đầu tiên đo từ một máy khách duy nhất quá nhiễu để đỡ nổi luận điểm theo ngôn ngữ mà chúng tôi muốn nêu. Script đo vẫn nằm trong gói tái lập, dán nhãn là thăm dò và không đưa vào bài báo. Xóa đi phát hiện mình tâm đắc nhất bao giờ cũng rẻ hơn trước khi công bố.

Phạm vi cũng hẹp hơn cái tiêu đề. Việc đối chiếu hóa đơn thật chỉ làm trên OpenAI, các con số cho nhà cung cấp khác là mô hình hóa từ mức sàn đã công bố và tokenizer công khai. Phụ phí ghi cache và hạn TTL nằm ngoài mô hình chi phí, còn kết quả về độn chỉ giới hạn trong bốn nhóm bài ngắn chấm được bằng máy. Tất cả đều nằm ở mục đe dọa tính hợp lệ, vì một bài báo chỉ liệt kê ưu điểm của mình thì là tài liệu quảng cáo.

Cách sửa gọn trong một dòng chính sách giá

Cái sàn tồn tại có lý do. Mỗi prefix được cache chiếm bộ nhớ KV cache, và cái sàn giữ cho bộ nhớ đó khỏi đầy ứ những mẩu nhỏ, thay đổi liên tục, tái sử dụng chẳng được bao nhiêu. Lý do ấy tính bằng token vì phần lưu trữ cũng tính bằng token, và chính điều đó xếp hạng luôn các phương án sửa. Sạch nhất là cache cả những khối đã căn thẳng nằm dưới sàn, giữ nguyên đơn vị mà phần lưu trữ vốn đã dùng. Kế đó là co giãn mức sàn theo từng tokenizer để nó mang cùng một lượng nội dung ở mọi ngôn ngữ. Tính sàn bằng số ký tự, phương án nghe có vẻ đơn giản nhất, lại là phương án yếu nhất, vì nó tách quy tắc xét điều kiện ra khỏi chính thứ đang được đo đếm.

Chừng nào chưa có phương án nào thành hiện thực, phiên bản dành cho người vận hành gói trong ba dòng của bảng kiểm trước khi triển khai: biết mức sàn của mình, đo tỷ lệ cache hit theo từng ngôn ngữ, và đừng bỏ mặc prompt nằm trong dải giữa sàn và một phần mười của sàn.