Giá token theo từng lớp, giải thích
Vì sao input, cache read, cache write và output được tính giá riêng, mỗi model tính bao nhiêu credits cho một token mỗi lớp, và một request thật tính đủ.
Mỗi request bạn gửi tới đây được tính bằng credits, và số credits không phải là số token. Bốn lớp token được đo riêng — input chưa cache, cache read, cache write và output — vì chúng tốn những mức công khác nhau để phục vụ, và một mức giá gộp chung sẽ bắt workload rẻ của người này trả theo giá đắt của người khác. Dưới đây là toàn bộ phép tính theo từng lớp, trên chính những con số chúng tôi công bố, và cuối bài là một request thật được mổ ra từng phần.
Vì sao các lớp được tính giá riêng
Một token model phải đọc lần đầu, một token nó đọc lại từ phần prefix đã cache, một token nó ghi vào cache và một token nó sinh ra là bốn khối lượng công việc khác nhau. Sinh chữ là phần đắt nhất: một token output được tạo ra từng bước một, và model nào cũng tính nó cao hơn hẳn input của chính mình. Cache read là phần rẻ nhất, vì phần việc đằng sau nó đã làm và đã trả tiền ở một request trước đó. Cache write thì phía thượng nguồn không thu của chúng tôi đồng nào, và ở đây được niêm yết đúng bằng mức input của từng model — đó là nửa phần biên lợi nhuận được nói thẳng ra, thay vì giấu đi.
Một mức giá phẳng cho mọi token thì dễ quảng cáo hơn và tệ hơn khi mua. Nó thu quá tay với workload ăn cache, thu thiếu với workload sinh ra câu trả lời dài, và — phần quan trọng nhất — làm không còn ai đối chiếu hoá đơn với cái gì được nữa. Chính chỗ đó là bài kiểm tra chúng tôi đặt ra cho đồng hồ đo của mình: mọi khoản trừ đều phải tính lại được từ các mức giá lưu ngay trên dòng sổ bên cạnh nó, mà một mức giá trộn từ hai mức khác thì về bản chất là không thể — mức trộn ấy không nằm ở cột nào, nên không có gì trong bản ghi tính lại được. Vậy nên ở đây không có gì bị trộn. Mỗi lớp được đo theo đúng mức niêm yết cho nó, và mức đã niêm yết chính là mức bị trừ.
Một token giá bao nhiêu, theo từng lớp
Credits trên mỗi token, theo model và theo lớp, lấy thẳng từ catalogue mà mọi mức giá khác trên site này cũng lấy ra:
| MODEL | INPUT | CACHE READ | CACHE WRITE | OUTPUT + REASONING |
|---|---|---|---|---|
| astra | 2.5 | 0.25 | 2.5 | 12.5 |
| sol | 1 | 0.1 | 1 | 5 |
| terra | 0.5 | 0.05 | 0.5 | 3 |
| luna | 0.05 | 0.005 | 0.05 | 0.3 |
Một token input của sol là một credit. Đó là mốc neo mà cả bảng được viết dựa theo, và mọi ô còn lại là tỷ lệ của chính nó so với mốc đó: đọc ngang một dòng là có bốn mức giá của một model, đọc dọc cột input là thấy năng lực đắt tới đâu. Không con số nào trong bảng là số làm tròn cho đẹp mắt — đây đúng là các hệ số mà đồng hồ đo áp dụng, và portal của bạn liệt kê từng request theo đúng chúng.
Cache read tính bằng một phần mười
Một token đọc lại từ prefix đã cache được tính bằng một phần mười mức input của chính model đó — nói cách khác, cột cache read ở trên đúng bằng cột input chia mười, model nào theo model nấy. Khoản giảm này là một dòng riêng trên từng request trong portal chứ không phải một mức trung bình san đều cả tháng: một agent gửi đi gửi lại cùng một system prompt dài ở mỗi lượt phải nhìn thấy được phần tiết kiệm ấy tới nơi, từng request một, và kiểm được nó.
Một request thật, tính đủ
Phép tính dưới đây là một request trên astra: 303 token prompt, không có phần nào nằm trong cache, và 14 token trả lời. Các mức trong đó là mức của astra vào ngày viết bài — bảng ở trên mới là bảng sống, và nếu hai bên có lệch nhau thì bảng ở trên đúng.
POST /v1/chat/completions model: astra
lớp token mức credits
input 303 x 2.5 = 757.5
output 14 x 12.5 = 175.0
-------
bị trừ 932.5 -> 933
Hai điều về dòng cuối cùng đó. Tổng được làm tròn lên đúng một lần ở cuối chứ không làm tròn theo từng lớp: làm tròn từng lớp là làm tròn bốn lần, và bắt bạn trả tiền cho chính phép làm tròn. Và phép cộng chạy bằng số nguyên chính xác dựa trên chính các mức giá lưu trên dòng sổ, nên không có sai lệch dấu phẩy động giữa cái đồng hồ đo đã trừ và cái dòng sổ ghi là đã trừ — dòng đó tính lại bằng tay được, và đó chính là thứ làm nó kiểm toán được.
Phần giữ chỗ làm gì trước khi tính tiền
Trước khi request đi lên thượng nguồn, đồng hồ đo giữ chỗ một mức ước lượng trong hạn mức của bạn và ghi lại luôn các mức giá sẽ dùng khi quyết toán. Đó là thứ chặn một loạt request chạy song song cùng tiêu hai lần vào nắm credits cuối cùng: số dư trong portal đổi lúc request bắt đầu, không phải lúc nó kết thúc, nên con số bạn đang nhìn là con số không request nào khác tiêu được nữa.
Khi câu trả lời về, phần giữ chỗ được quyết toán theo đúng mức dùng mà nhà cung cấp báo lại, ở đúng các mức giá đã ghi lúc giữ chỗ — nên một lần đổi giá giữa chừng không thể tính lại giá cho một request đang chạy. Một lần quyết toán không bao giờ lớn hơn phần đã giữ: request nào có chi phí thật vượt quá phần đã giữ chỗ sẽ bị từ chối quyết toán và bị đánh dấu để đối soát, thay vì lặng lẽ trừ sâu thêm vào hạn mức của bạn. Phần giữ chỗ không dùng tới được trả lại ngay.
Xem tiếp ở đâu
Vẫn những hệ số đó, cả hai mức ngữ cảnh short và long, kèm mỗi model dùng vào việc gì: Model. Một gói giá bao nhiêu và một credit là gì: Gói và bảng giá. Base URL và một request bạn copy được: Bắt đầu nhanh.