Kết quả đo chi phí tokenizer của Claude 4.7

• Claude 4.7 tạo ra số token nhiều hơn trung bình 1,3~1,45 lần so với phiên bản trước, dẫn đến chi phí mỗi phiên tăng 20~30% trong cùng một cơ chế giá
• Mức tăng token đặc biệt rõ ở nội dung tiếng Anh và mã nguồn, trong khi nội dung CJK (tiếng Trung, tiếng Nhật, tiếng Hàn) gần như không thay đổi
• Nhờ tokenization chi tiết hơn, độ tuân thủ chỉ thị (Instruction Following) tăng khoảng 5 điểm phần trăm, đặc biệt là giảm lỗi định dạng
• Số token của cache prefix và lịch sử hội thoại tăng lên, khiến chi phí cache và tốc độ tiêu hao rate limit cũng tăng theo
• Kết quả cho thấy Claude 4.7 được đánh giá là đánh đổi chi phí token bổ sung để đổi lấy độ chính xác cao hơn và khả năng thực hiện chỉ thị chi tiết hơn

---

Kết quả đo tokenizer của Claude 4.7

• Claude Opus 4.7 của Anthropic được công bố là dùng nhiều token hơn 1,0~1,35 lần so với phiên bản trước là 4.6, nhưng trong đo đạc thực tế con số được xác nhận ở mức 1,45~1,47 lần
• Với cùng mức giá và quota, việc số token tăng lên kéo theo các tác động như tăng tốc độ tiêu hao max window, chi phí cache prefix cao hơn, và chạm rate limit sớm hơn
• Thử nghiệm gồm hai phần: đo chi phí và đo độ tuân thủ chỉ thị

Phương pháp đo chi phí

• Sử dụng endpoint POST /v1/messages/count_tokens của Anthropic API để đưa cùng một nội dung vào các model 4.6 và 4.7, từ đó chỉ so sánh chênh lệch tokenizer thuần túy
• Sử dụng hai bộ mẫu
  • 7 mẫu sử dụng thực tế do người dùng Claude Code gửi
  • 12 mẫu nhân tạo gồm tiếng Anh, mã nguồn, dữ liệu có cấu trúc, CJK, emoji, ký hiệu toán học, v.v.

• Kết quả với nội dung Claude Code thực tế

  • Tỷ lệ trung bình có trọng số là 1,325 lần trên 7 mẫu thực tế (8.254 → 10.937 token)
  • Ví dụ chính
  • Tệp CLAUDE.md: 1,445 lần
  • Prompt người dùng: 1,373 lần
  • Bài đăng blog: 1,368 lần
  • Code diff: 1,212 lần

• Kết quả theo loại nội dung (12 mẫu nhân tạo)

  • Trung bình nội dung tiếng Anh và mã nguồn: 1,345 lần
  • Trung bình nội dung CJK (tiếng Trung, tiếng Nhật, tiếng Hàn): 1,01 lần
  • Ví dụ chi tiết
  • Tài liệu kỹ thuật: 1,47 lần
  • Shell script: 1,39 lần
  • Mã TypeScript: 1,36 lần
  • Văn xuôi tiếng Anh: 1,20 lần
  • JSON: 1,13 lần
  • Văn xuôi tiếng Nhật và tiếng Trung: 1,01 lần

Mô hình thay đổi của tokenizer

• Nội dung CJK, emoji và ký hiệu chỉ ở mức 1,005~1,07 lần, tức gần như không thay đổi
  • Có vẻ từ vựng phi Latin không thay đổi nhiều
• Nội dung tiếng Anh và mã nguồn tăng 1,20~1,47 lần, trong đó mã nguồn bị ảnh hưởng nhiều hơn văn xuôi
  • Các chuỗi lặp trong mã (keyword, import, identifier, v.v.) bị tách nhỏ hơn và chia thành nhiều token hơn
• Tỷ lệ token trên mỗi ký tự trong tiếng Anh giảm từ 4,33→3,60, còn TypeScript giảm từ 3,66→2,69
  • Cùng một văn bản được biểu diễn bằng các đơn vị nhỏ hơn

Vì sao lại dùng nhiều token hơn

• Anthropic nhấn mạnh rằng ở 4.7, model có xu hướng “tuân theo chỉ thị theo nghĩa đen hơn”
• Đơn vị token nhỏ hơn giúp tăng cường word-level attention, góp phần cải thiện thực hiện chỉ thị chính xác, tác vụ ở mức ký tự, và độ chính xác khi gọi công cụ
• Các đối tác như Notion, Warp và Factory báo cáo giảm lỗi khi thực thi công cụ
• Tuy vậy, ngoài tokenization thì trọng số mô hình và hậu huấn luyện (post-training) cũng đã thay đổi, nên không thể tách riêng nguyên nhân

Bài test độ tuân thủ chỉ thị

• Sử dụng benchmark IFEval (2023, Google): lấy mẫu 20 prompt trong tổng số 541 prompt như “trả lời chính xác N từ”, “viết không có dấu phẩy”, v.v.
• Kết quả
  • Ở strict mode theo đơn vị prompt: 4.6 → 85%, 4.7 → 90% (+5 điểm phần trăm)
  • Ở strict mode theo đơn vị chỉ thị: 86% → 90% (+4 điểm phần trăm)
  • Ở loose mode không có khác biệt
• Cải thiện chủ yếu đến từ giảm lỗi liên quan đến định dạng
• Chỉ có một prompt đơn lẻ (change_case:english_capital) cho thấy khác biệt rõ ràng
• Do cỡ mẫu nhỏ nên mức tăng +5 điểm phần trăm còn chưa chắc chắn về mặt thống kê, nhưng được đánh giá là cải thiện nhỏ nhưng nhất quán

Tính chi phí theo phiên của Claude Code

• Giả định một phiên hội thoại 80 lượt qua lại
  • Static prefix: 6K token (CLAUDE.md 2K + định nghĩa công cụ 4K)
  • Lịch sử hội thoại: tăng 2K mỗi lượt, đạt 160K ở lượt 80
  • Input/output: 500 / 1.500 token mỗi lượt
  • Tỷ lệ cache hit: 95%

• Chi phí phiên theo chuẩn 4.6

  • | Hạng mục | Cách tính | Chi phí |
  • | --- | --- | --- |
  • | Ghi cache lần đầu | 8K × $6.25/MTok | $0.05 |
  • | Đọc cache (79 lần) | 79 × 86K × $0.50/MTok | $3.40 |
  • | Input mới | 79 × 500 × $5/MTok | $0.20 |
  • | Output | 80 × 1.500 × $25/MTok | $3.00 |
  • | Tổng | | khoảng $6.65 |

• Chi phí phiên theo chuẩn 4.7

  • CLAUDE.md: 1,445 lần → 2K → 2,9K
  • Định nghĩa công cụ: 1,12 lần → 4K → 4,5K
  • Lịch sử hội thoại: 1,325 lần → 160K → 212K
  • Input người dùng: 1,325 lần → 500 → 660
  • Cache prefix trung bình: khoảng 115K token
  • | Hạng mục | Cách tính | Chi phí |
  • | --- | --- | --- |
  • | Ghi cache lần đầu | 10K × $6.25/MTok | $0.06 |
  • | Đọc cache (79 lần) | 79 × 115K × $0.50/MTok | $4.54 |
  • | Input mới | 79 × 660 × $5/MTok | $0.26 |
  • | Output | 80 × 1.500–1.950 × $25/MTok | $3.00–$3.90 |
  • | Tổng | | khoảng $7.86–$8.76 |
  • Chi phí mỗi phiên tăng 20~30%, dù đơn giá token không đổi
  • Người dùng gói Max sẽ kết thúc phiên sớm hơn trong cùng một khung thời gian

Ảnh hưởng tới prompt cache

1. Cache được tách riêng theo từng model, nên khi chuyển sang 4.7 thì cache cũ của 4.6 bị vô hiệu
   • Phiên đầu bắt đầu trong trạng thái không có cache, làm chi phí prefix lớn hơn
2. Bản thân dung lượng cache tăng 1,3~1,45 lần, nên cả chi phí đọc và ghi đều tăng theo cùng tỷ lệ
3. Ngay cả cùng một log hội thoại, số token cũng thay đổi, gây ra sự đứt quãng so với trước đây trong số liệu billing và monitoring

Phản biện và cách diễn giải

• “Phần lớn input là đọc cache nên tác động không đáng kể”

  • Khi tỷ lệ cache hit cao thì tác động chi phí có thể nhỏ, nhưng khi TTL hết hạn, cache bị vô hiệu, hoặc chuyển model, chi phí sẽ tăng theo tỷ lệ đầy đủ

• “1,35 lần không phải trần mà là một khoảng”

  • Giá trị đo thực tế tập trung gần mức trần (1,325 lần), thậm chí một số tệp còn vượt mức này
  • Khi sử dụng thực tế, lập kế hoạch theo mức trần sẽ an toàn hơn

Kết luận

• Với các tác vụ chủ yếu là tiếng Anh và mã nguồn, mức sử dụng token tăng 1,3~1,45 lần
• Độ tuân thủ chỉ thị cải thiện khoảng +5 điểm phần trăm, nhỏ nhưng có ý nghĩa thực tế
• Chi phí mỗi phiên tăng 20~30%, trong khi đơn giá token giữ nguyên
• Kết quả là đây được xem như cấu trúc trả thêm chi phí để đổi lấy độ chính xác cao hơn và khả năng thực hiện chỉ thị chi tiết hơn

[kaydash]

Không phải Claude 4.7 mà là Opus 4.7

[GN⁺]

Ý kiến Hacker News

• Với giả định đường cong hiệu năng/chi phí của LLM có dạng log, vẫn chưa rõ liệu Opus 4.5+ là một điểm mới trên đường cong đó, hay chỉ đơn thuần nằm ở đoạn chi phí tăng vọt để đổi lấy hiệu năng cao hơn
  Việc Anthropic tăng giá nhanh có thể là tín hiệu phản ánh chi phí vận hành tăng mạnh
  Tôi cho rằng thông lệ hiển thị trục x dưới dạng log chi phí trong các biểu đồ đánh giá mô hình đang che khuất thực tế này

  • Đã tham khảo phân tích chi phí theo giờ của AI agent của Toby Ord. Khái niệm biên hiệu năng/chi phí của ông ấy đáng được chú ý nhiều hơn
  • Tôi nghĩ đã đến lúc các nhà phát triển cần right-sizing mức độ mô hình và nỗ lực cho phù hợp với từng tác vụ
    Thời đại cứ mặc định dùng model mạnh nhất đã kết thúc. Cần có các lựa chọn cho phép chọn nhiều điểm khác nhau tùy theo công việc
    Với tác vụ phức tạp, tôi thấy dùng model lớn hơn và tiêu hết 5 giờ token trong một lần cũng không sao
    Tuy vậy, nhiều người sẽ ghét sự phức tạp của kiểu lựa chọn này, và tôi đoán sắp tới sẽ có nhiều nỗ lực smart routing hơn
  • Anthropic đang tiến gần IPO nên chịu áp lực lớn về tăng doanh thu trên mỗi người dùng. Rốt cuộc họ đang chuyển dần sang cấu trúc giá phản ánh đúng chi phí vận hành mô hình thực tế
  • Nếu mô hình được triển khai trực tiếp trên silicon, chi phí sẽ giảm và tốc độ sẽ tăng. Có thể tham khảo các hướng đi như Taalas
  • Nếu khách hàng sẵn sàng chấp nhận chi phí cao hơn, tôi nghĩ hoàn toàn có thể cung cấp những mô hình mạnh hơn rất nhiều
    Ví dụ như Apple luôn có một tệp khách hàng muốn các tùy chọn siêu đắt đỏ, nên thị trường LLM siêu hiệu năng cao cũng có khả năng tồn tại

• Nhiều người tập trung vào chi phí của model AI, nhưng trên thực tế, thời gian con người bỏ ra để điều phối và rà soát AI coding agent còn đắt hơn nhiều
  $200/tháng thì đắt với dân dùng cho vui, nhưng ở góc độ kinh doanh lại là mức không đáng kể
  Điều quan trọng là model làm việc tốt đến đâu, và ở mặt bằng giá hiện tại thì hiệu quả theo thời gian mới là yếu tố cốt lõi

  • Đội của chúng tôi đã ra mắt ba sản phẩm bằng Claude trong năm nay. Đặc biệt có dự án vốn dự kiến 9 người làm trong 6 tháng nhưng đã hoàn thành với 2 người trong 2 tháng
    Tôi nghĩ giá trị kinh tế của gói Claude rơi vào khoảng 10.000~40.000 euro.
    Giá có tăng gấp 100 tôi vẫn mua. Chỉ khi lên mức 20.000 euro/tháng thì mới cân nhắc phương án khác, còn hiện tại mức tăng năng suất là áp đảo
  • $200 gần như không đáng kể với doanh nghiệp, nhưng rất khó biện minh nếu chỉ là thú vui cá nhân
  • Instance Openclaw của tôi từng bị tính $200/ngày do dùng Opus. Tối ưu routing mới là vấn đề lớn hơn. Khi còn ở mức $1/giờ thì ổn, nhưng $15/giờ thì mất sức cạnh tranh

• Tôi nghĩ việc cải thiện chất lượng model rồi cũng sẽ chạm đến vùng lợi suất giảm dần
  Giống như màn hình 8K so với 16K, đa số người dùng không cảm nhận được khác biệt
  Nếu chi phí tăng 20~30% thì phải có mức giá trị tăng thêm nhìn thấy rõ tương ứng

  • Vì vậy tôi cho rằng phần lớn nghiên cứu đang tập trung vào lĩnh vực coding. Mức độ khó tiếp tục tăng và giá trị kinh tế cũng vẫn được giữ
    Ngược lại, các truy vấn hội thoại thông thường đã gần như bão hòa, rất khó tạo khác biệt giữa các model
  • Trông có vẻ 99% chính xác, nhưng khi phải đưa ra 100.000 quyết định mỗi ngày thì sai số nhỏ cũng sẽ tích lũy thành vấn đề lớn
  • Nếu xuất hiện model 4K có thể chạy cục bộ, các phòng lab lớn sẽ gặp khó. Dù vậy Google có doanh thu quảng cáo nên chắc vẫn trụ được
  • Còn tùy loại công việc. Ví dụ trong thiết kế thuốc mới, chênh lệch giữa mức hoàn thành 95% và 100% có thể tạo ra khác biệt giá trị gấp hàng chục lần
  • Với tìm kiếm web hay tóm tắt thì có lẽ đã chạm trần, nhưng độ phức tạp của coding thì có thể mở rộng vô hạn

• Hệ số nhân model (multiplier) của GitHub Copilot đã tăng từ 3 lên 7,5
  Có vẻ Microsoft đang cố giảm lỗ
  Tham khảo tài liệu chính thức

  • Vì vậy chúng tôi đã khuyến nghị trong tổ chức rằng “tuyệt đối đừng bật Opus 4.7”. 4.6 (3x) và 4.5 (3x) thì ổn, nhưng 4.7 (7,5x) thì hoàn toàn không có hiệu quả chi phí
  • Gần đây Opus 4.6 cho thấy chất lượng suy luận suy giảm. Nó vội kết luận và bỏ qua logic. Nếu không có đột phá lớn thì tôi nghĩ sẽ sớm có sự xuống cấp chất lượng(en**)** rất mạnh

• Tiêu đề bài viết dễ gây hiểu nhầm. Số token có tăng nhưng chi phí trên mỗi tác vụ có thể khác
  Giả sử Opus 4.7 không dùng cùng một đường suy luận như Opus 4.6
  Cần chờ kết quả từ Intelligence Index của Artificial Analysis

  • Trong benchmark nội bộ, Opus 4.7 rẻ hơn 50% và điểm hiệu năng là 80% (so với 60%)
  • Tôi đã sửa tiêu đề bài viết từ “Claude Opus 4.7 costs 20–30% more per session” sang cách diễn đạt trung tính hơn
  • Theo thử nghiệm so sánh 28 tác vụ, 4.7 có chi phí tương đương bản 4.6 cũ và đắt hơn khoảng 20% so với bản 4.6 mới
  • Theo dữ liệu cá nhân của tôi, 4.7 tốn chi phí hơn 4.6, còn mức cải thiện hiệu năng thì không rõ ràng
  • Ngay cả trên biểu đồ công bố chính thức tôi cũng thấy được cơ sở cho tuyên bố “strictly better”

• Hôm qua dùng Opus thì tốt đến mức đáng kinh ngạc, nhưng hôm nay nó lại liên tục mắc lỗi ngay cả với việc đơn giản
  Tôi phải chỉ ra cùng một vấn đề đến lần thứ ba, phiên làm việc cũng hay bị ngắt và xảy ra compaction quá mức
  Cuối cùng tôi quyết định quay lại Sonnet

  • Đây không phải bug mà là chính sách cắt giảm lượng tính toán. Sau này sẽ còn nặng hơn
  • LLM không phải nhân cách. Khi lấy mẫu từ phân phối xác suất thì khả năng xuất hiện phiên làm việc tệ sớm muộn cũng là 100%. Phải reset context rồi thử lại
  • Gần đây tôi cũng thường thấy kết quả rất tệ khi dùng Opus 4.7. Nhìn model tự thừa nhận sai rồi thử lại khiến tôi thấy hơi chua chát

• Dạo này tôi thường nghĩ: “Liệu có thật sự cần model mạnh hơn nữa không?”
  Cả ngành đang quá ám ảnh với cuộc đua hiệu năng mà bỏ quên hiệu quả và tính bền vững
  Tôi cho rằng sắp tới hướng đi quan trọng sẽ là tối ưu hóa các model 0.5B~1B tham số cho từng tác vụ cụ thể

  • Nếu có thể chạy Sonnet 4.6 ở local thì tôi cũng đã rất hài lòng
    Như trong bài CPUs Aren’t Dead, model Gemma 4 E2B của Google có thể chạy cả trên điện thoại và vượt GPT-3.5-turbo
    Theo Intelligence Index của Artificial Analysis, các model 2B mới nhất cho hiệu năng tương đương model 175B của 3~4 năm trước
    Gemma 4 E4B thậm chí còn vượt GPT-4o
    Nếu xu hướng này tiếp diễn, chẳng bao lâu nữa ta sẽ có thể chạy model đẳng cấp hàng đầu ngay trên laptop
  • Nhiều người kỳ vọng Sonnet 4.6 sẽ có hiệu năng ngang Opus 4.5, nhưng thực tế không phải vậy
  • Hiệu quả thì không kiếm ra tiền. Các công ty LLM lớn có lợi khi giữ chi phí suy luận ở mức cao
    Kiểu quảng bá “model mới điên thật” rốt cuộc cũng chỉ là marketing FOMO
  • Không phải ai cũng cần máy tính cầm tay cao cấp. Điều quan trọng là chọn công cụ đúng với nhu cầu
  • Nhưng cũng không thể hài lòng với “model lười và thiếu chính xác”. Lab nào giải được bài toán này sẽ giành lợi thế quyết định

• Những người bán đồ ăn vặt ở Kolkata, Ấn Độ, khi không thể tăng giá dù nguyên liệu đầu vào tăng, đã chọn cách giảm kích thước sản phẩm
  Sự thích nghi tâm lý của con người vận hành theo kiểu như vậy

  • Hiện tượng này có ở khắp nơi trên thế giới. Bao bì đồ ăn vặt vẫn vậy nhưng lượng bên trong giảm đi. Ngay cả ống Pringles cũng mỏng hơn và ngắn hơn
  • Hiện tượng này được gọi là Shrinkflation

• Anthropic đã giới thiệu chế độ xhigh mới trong 4.7
  Chế độ max dùng nhiều token và có thể gây suy luận quá mức, nên trong đa số trường hợp họ khuyến nghị xhigh
  Tham khảo tài liệu chính thức

  • Việc thêm mức xhigh và đẩy max ra xa hơn tạo cảm giác kiểu “cái này có thể vặn lên tới 11”

• Dựa trên code thực tế, Opus 4.7 cho thấy mức tăng token khoảng 30%
  Điều quan trọng là “4.7 mang lại năng lực mới nào so với 4.6”
  Vẫn còn quá sớm để kết luận, và nếu giá trị đủ lớn thì tôi sẵn sàng chấp nhận chi phí tăng

  • Điểm thú vị trong các cuộc thảo luận là rất nhiều người chạy theo model mới, nhưng thực ra chỉ Sonnet 4.6 thôi cũng đã đủ hiệu quả
    Nếu thu hẹp phạm vi công việc thì việc review và quản lý sẽ dễ hơn, có thể sửa nhanh với diff nhỏ
    Nếu Copilot tiêu thụ token gấp 7 lần thì ngược lại có lẽ sẽ gây đứt gãy workflow
  • Gần đây có nhiều phàn nàn rằng 4.6 đã bị giảm chất lượng
  • Tôi không biết 4.6 sẽ còn được duy trì bao lâu. Bản cho doanh nghiệp có thể còn tồn tại thêm, nhưng người dùng cá nhân có lẽ sớm sẽ không còn quyền lựa chọn nữa