Cùng một đoạn văn bản, ném cho hai mô hình, một cái cắt thành 766 token, cái kia cắt thành 1170.
Đưa ra con số này là Tibo, người phụ trách OpenAI Codex.
Nguyên văn của anh ấy là: Một token của OpenAI, không bằng một token của mô hình khác. Giá mỗi token thấp hơn, không nhất định có nghĩa là hóa đơn thấp hơn.
Mọi người đều dùng "bao nhiêu đô la cho một triệu token" để so giá, như thể token là một đơn vị tiêu chuẩn như gram, kilowatt giờ, nhưng nó không phải.
Để mọi người dễ hiểu hơn, anh ấy còn kể một câu chuyện về pizza.
Hai chiếc pizza giống hệt nhau.
Cửa hàng thứ nhất cắt 8 miếng, mỗi miếng 2 đô la. Cửa hàng thứ hai cắt 16 miếng, mỗi miếng 1.25 đô la. Cửa hàng thứ hai treo biển ghi giá rẻ hơn, nhưng ăn cả chiếc phải trả 20 đô la, cửa hàng thứ nhất chỉ cần 16 đô la.
Anh ấy bổ sung một câu: Dạ dày của bạn không quan tâm bạn vừa ăn bao nhiêu miếng.
Mỗi miếng rẻ hơn, cả chiếc lại đắt hơn. Cách cắt khác nhau, đơn giá mất đi tính so sánh.
Token là đơn vị nhỏ nhất để tính phí mô hình, bạn có thể hiểu nó là "cách cắt" văn bản của mô hình.
Cùng một câu nói, cách cắt khác nhau, số lượng miếng cắt ra sẽ khác nhau. Cắt ra bao nhiêu miếng, tính tiền bấy nhiêu miếng. Số miếng càng nhiều, hóa đơn càng đắt.
Lần so sánh này bao phủ tiếng Anh, văn bản kỹ thuật, đa ngôn ngữ và nội dung số.
Bộ phân tách từ của GPT-5.6 Sol dùng 766 token, kết quả ước tính của Claude Opus 5 là 1170.
Cùng một đoạn văn bản, cách cắt của GPT-5.6 Sol cắt ít hơn 34,5% số miếng.
Và giá đầu vào của hai bên, đều là 5 đô la cho mỗi triệu token.
Đơn giá giống hệt nhau, số miếng ít hơn ba phần mười, chi phí đầu vào cũng ít hơn ba phần mười.
Rắc rối cũng nằm ở đây.
Nếu ngay cả việc "một token lớn bao nhiêu" hai bên còn không thống nhất được, vậy bảng so sánh giá API mà mọi người chuyền tay nhau hàng ngày, cuối cùng có còn đáng tin không?
Cùng một đoạn văn bản, tại sao đếm ra hai con số?
Đó là bởi vì đơn vị token này, căn bản không có đơn vị đo lường thống nhất.
Mỗi nhà cung cấp tự huấn luyện bộ phân tách từ (tokenizer), tự quyết định cắt văn bản thành những mảnh lớn bao nhiêu.
Từ thông dụng, bộ phân tách từ nuốt trọn cả từ, từ hiếm gặp, một từ có thể bị tách thành ba bốn mảnh.
Lấy tiếng Anh làm ví dụ là dễ thấy nhất. Những từ như the, and, is xuất hiện hàng ngày, bộ phân tách từ dành cho chúng một mã số riêng, một từ là một token.
Đổi sang từ dài như unbelievable, phải tách thành un, believ, able mấy mảnh, một từ đã chiếm ba token.
Lý do rất đơn giản: Bộ phân tách từ được thống kê từ kho ngữ liệu huấn luyện, tổ hợp nào xuất hiện thường xuyên, tổ hợp đó sẽ chiếm một vị trí riêng. Phần còn lại, chỉ có thể dùng mảnh vụn ghép lại.
Vì vậy "một đoạn văn có bao nhiêu token", về bản chất là đang hỏi "những thứ trong đoạn văn này, trong kho ngữ liệu của nhà này có thường gặp không".
Mà văn xuôi tiếng Anh, lại chính là loại nội dung có sự khác biệt nhỏ nhất trong tất cả. Mã nguồn, JSON, chuỗi số dài, kết quả cắt ra của hai bên chỉ còn chênh lệch xa hơn.
Ngay cả mô hình mới cũ của cùng một nhà, việc đếm cũng không thể dùng chung
Đây không phải là vấn đề của riêng một nhà nào.
Tài liệu của chính Anthropic viết rất rõ: Việc đếm token là giá trị ước tính, số lượng token đầu vào thực tế được sử dụng khi tạo tin nhắn có thể có sai lệch nhỏ.
Và đưa ra một con số cụ thể.
Mô hình Claude 4.7 trở về sau đổi sang bộ phân tách từ mới, cùng văn bản đầu vào, số lượng token tạo ra nhiều hơn khoảng 30% so với các mô hình đời đầu, mức tăng cụ thể tùy thuộc vào nội dung và hình thái khối lượng công việc.
Tài liệu chính thức của Anthropic: Mô hình Claude 4.7 trở về sau đổi sang bộ phân tách từ mới, số token của cùng văn bản nhiều hơn khoảng ba phần mười, đừng tái sử dụng số đếm đo được từ mô hình cũ.
Cùng một công ty, cùng một đoạn văn bản, sau khi đổi đời tăng thêm ba phần mười.
Vì vậy lời khuyên chính thức đưa ra là, muốn biết khối lượng công việc của mình chênh bao nhiêu, hãy đếm cùng một yêu cầu theo hai mô hình, so sánh input_tokens được trả về.
Đừng lấy số đo được trên mô hình đời đầu để ước tính chi phí.
Giữa hai đời mô hình của cùng một nhà, việc đếm còn không thể dùng chung. So sánh trực tiếp "đơn giá mỗi triệu token" giữa các nhà cung cấp, càng không thể nói đến tiêu chuẩn hóa.
Cùng 5 đô la, hóa đơn chênh ở bốn chỗ
Cùng đơn giá, cùng đầu vào, hóa đơn cuối cùng chênh ở đâu?
Thứ nhất, hiệu suất phân tách từ vừa nói. Cùng một đoạn văn bản, số lượng token cắt ra khác nhau, nhân với cùng đơn giá, số tiền phải trả tự nhiên khác nhau.
Thứ hai, bộ nhớ đệm (cache).
Giá đầu vào bộ nhớ đệm của GPT-5.6 Sol là 0,50 đô la mỗi triệu token, chỉ bằng một phần mười giá đầu vào tiêu chuẩn. Khối lượng công việc có nhiều tiền tố lặp lại, mục này có thể viết lại toàn bộ cấu trúc hóa đơn.
Thứ ba, đầu ra (output).
GPT-5.6 Sol đầu ra 30 USD/triệu token, Claude Opus 5 là 25 USD trở lên.
Mà trong quy trình công việc tác nhân (agent) thực tế, trọng lượng của token đầu ra thường khắc nghiệt hơn cả đầu vào.
Cũng có nghĩa là, 34,5% tiết kiệm được ở phía trước, rất có thể bị trả lại ở đây.
Thứ tư, dễ bị bỏ qua nhất, nó được viết ngay trên trang mô hình của chính OpenAI. Khi đầu vào của GPT-5.6 Sol vượt quá 272K token, toàn bộ yêu cầu đó, đầu vào sẽ tính giá gấp 2 lần, đầu ra tính giá gấp 1,5 lần.
Trang mô hình chính thức GPT-5.6 Sol: Đầu vào 5 USD, đầu vào bộ nhớ đệm 0,50 USD, đầu ra 30 USD, dòng chữ nhỏ phía dưới ghi quy tắc tăng giá khi vượt quá 272K.
Không phải phần vượt quá tăng giá, mà là toàn bộ yêu cầu đó áp dụng tỷ lệ cao hơn.
Cùng một đoạn mã, bạn hỏi nó trong ngữ cảnh 27 vạn token, và trong ngữ cảnh 28 vạn token, đơn giá đã đổi một bậc.
Hạn chế này đến từ trang định giá của chính hãng, ngữ cảnh càng dài, chi phí chú ý (attention) và bộ nhớ (VRAM) tăng càng nhanh, cửa sổ dài chưa bao giờ miễn phí.
Cửa sổ triệu token mở ra, tiền từ từ chảy đi
Tibo sau đó đăng dòng thứ hai, hướng dẫn mọi người cách mở đầy cửa sổ ngữ cảnh trong Codex.
Mở file ~/.codex/config.toml, thêm ba dòng trước tất cả tiêu đề section:
model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000
Dòng đầu chọn mô hình, dòng thứ hai kéo ngân sách ngữ cảnh lên 1 triệu token, dòng thứ ba để tự động nén kích hoạt ở khoảng 90 vạn token, chừa một chút dư.
Lưu, khởi động lại client, mở một phiên (session) mới, cấu hình mới có hiệu lực.
Không muốn động đến giá trị mặc định, cũng có thể chỉ ghi đè tạm thời trong một phiên CLI đơn lần:
codex -m gpt-5.6-sol
-c model_context_window=1000000
-c model_auto_compact_token_limit=900000
Hai khóa (key) này đều có thể tra được trong tài liệu tham khảo cấu hình Codex chính thức, tác dụng nhất quán với những gì anh ấy viết.
model_context_window, số token cửa sổ ngữ cảnh khả dụng của mô hình hiện tại.
model_auto_compact_token_limit, ngưỡng kích hoạt nén lịch sử tự động.
Nhưng tài liệu chỉ định nghĩa ý nghĩa của khóa, không liệt kê nhóm giá trị "1 triệu/90 vạn" này thành giá trị đề xuất chung.
Bản thân Tibo ở cuối bài cũng bổ sung một câu: Giá trị mặc định là họ đã điều chỉnh cẩn thận.
Vậy tại sao nhiều người lại muốn tự sửa?
Một báo cáo thực nghiệm từ người dùng trên GitHub đã giải thích lý do.
Báo cáo thực nghiệm trong kho openai/codex này: Thư mục Codex chặn cửa sổ ở 372K, hiệu dụng 353.4K, trong khi thông số kỹ thuật mô hình ghi là 1.05M
Trong phiên bản client Codex và tài khoản ChatGPT Pro cụ thể, thư mục mô hình gán nhãn cửa sổ cho gpt-5.6-sol là 372K, tính theo 95%, thực tế dùng được 353.4K. Trong khi trang mô hình chính thức ghi nhãn là 1.05M.
Mua cửa sổ triệu token, dùng chỉ còn một phần ba.
Báo cáo này có giới hạn phiên bản và tài khoản rõ ràng, không thể coi là hiện trạng của mọi người dùng, bài cấu hình của Tibo thời gian đăng còn muộn hơn.
Còn cần làm rõ một việc: Sửa cấu hình lên 1 triệu, sẽ không ngay lập tức phát sinh chi phí 1 triệu token. Tính phí luôn là dựa trên lượng xử lý thực tế.
Nhưng ngưỡng nén đẩy lên 90 vạn, có nghĩa là một phiên dài sẽ mang theo lịch sử ngày càng dài đi tiếp, mỗi lượt yêu cầu đều phải xử lý lại đoạn lịch sử này.
Cửa sổ càng lớn, nén càng muộn, yêu cầu càng dễ va vào ngưỡng 272K vừa nói.
Trong hội thoại ngắn, sự khác biệt nhỏ nhoi của bộ phân tách từ chỉ là chuyện sau dấu thập phân. Khi phiên kéo dài đến vài chục vạn token, bản ghi lịch sử mang đi mang lại, nhân với một bậc tỷ lệ cao hơn, dấu thập phân khác biệt đã biến thành vị trí nguyên số.
Tiền không phải tiêu một lúc, mà tăng lên từng lượt, từng lượt.
Đơn vị tiếp theo, là "mỗi lần thành công"
Trong dòng bài của Tibo còn có một câu, bị những con số che lấp: Điều thực sự quan trọng là chi phí cho mỗi kết quả thành công (price per successful outcome).
Anh ấy còn đưa ra cách. Kiểm tra chuẩn (benchmark) có thể làm điểm khởi đầu, nhưng thực sự muốn biết đắt rẻ, phải lấy công việc của chính mình chạy một lượt.
Câu này đã thay đổi điểm neo so sánh giá. Từ "bao nhiêu tiền mỗi triệu token", đổi thành "tổng cộng tốn bao nhiêu tiền để chạy xong cùng một nhiệm vụ".
Muốn biết hai bên trên tay bạn cuối cùng ai rẻ hơn, tự mình kiểm tra một lượt là được.
Lấy cùng một đoạn văn bản gốc, cùng tỷ lệ phối ngôn ngữ, cùng định nghĩa công cụ, lần lượt gọi giao diện đếm chính thức của hai bên để lấy số token thực tế, sau đó tính thêm tỷ lệ trúng bộ nhớ đệm, độ dài đầu ra, độ dài suy luận và tỷ lệ ngữ cảnh dài, cuối cùng so xem ai hoàn thành việc này với chi phí ít hơn.
Hiệu suất phân tách từ chỉ là mắt xích đầu tiên trên chuỗi này. Một mô hình phân tách từ tiết kiệm hơn, nếu suy luận dài dòng, số lần làm lại nhiều, hóa đơn vẫn có thể đảo ngược vượt lại.
Sau này nên hỏi không phải một triệu token bao nhiêu tiền, mà là sửa lỗi này tốn bao nhiêu tiền.
Tài liệu tham khảo:
https://x.com/thsottiaux/status/2089082893804896524?s=20
https://x.com/thsottiaux/status/2088866513008873560?s=20 https://github.com/openai/codex/issues/31860
Bài viết từ tài khoản công chúng WeChat "Tân Trí Nguyên", tác giả: ASI Khải Thị Lục
