Fable giảm 60% chi phí: biến mã thành hình ảnh để mô hình tự OCR

 (github.com/teamchong)
4 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • pxpipe là một proxy cục bộ chuyển ngữ cảnh lớn của các yêu cầu Claude Code thành ảnh PNG để giảm token đầu vào, và cho biết có thể giảm khoảng 59~70% tổng chi phí end-to-end theo mức giá niêm yết hiện tại của Fable
  • Nguyên lý cốt lõi là chi phí token hình ảnh được tính theo kích thước pixel, không phải lượng văn bản bên trong; với văn bản dày đặc như mã, JSON, và đầu ra công cụ, trong lưu lượng Claude Code thực tế, mỗi token hình ảnh chứa khoảng 3.1 ký tự, còn mỗi token văn bản chỉ khoảng 1 ký tự
  • Mục tiêu nén là các tool_result lớn, lịch sử cũ đã được gập, prompt hệ thống tĩnh và tài liệu công cụ; còn các lượt gần đây, tin nhắn người dùng, đầu ra mô hình, văn xuôi thưa, và các mô hình ngoài danh sách cho phép thì vẫn được giữ nguyên dạng văn bản
  • Vì đây là phương pháp có mất mát, khả năng nhớ lại chính xác chuỗi hex 12 ký tự ở Fable 5 là 13/15 còn ở Opus là 0/15; các thiếu sót có thể xuất hiện không phải dưới dạng lỗi mà là đáp án sai nhưng nghe có vẻ hợp lý, nên các giá trị cần chính xác từng byte như ID, hash, hay secret phải được giữ ở dạng văn bản
  • Các mô hình mục tiêu mặc định là claude-fable-5,gpt-5.6; Opus 4.7/4.8 và GPT 5.5 chỉ dùng theo kiểu opt-in vì khả năng đọc ngữ cảnh hình ảnh kém hơn, và có thể kiểm tra việc áp dụng thực tế cùng mức tiết kiệm theo từng yêu cầu trong ~/.pxpipe/events.jsonl

Chi phí mà pxpipe muốn cắt giảm

  • pxpipe là một proxy cục bộ render ngữ cảnh lớn thành hình ảnh để giảm token đầu vào của Claude Code
  • Mục tiêu là các khối đầu vào chiếm nhiều dung lượng trong nội dung yêu cầu như prompt hệ thống, tài liệu công cụ, lịch sử trước đó, và đầu ra công cụ lớn
  • Đầu ra mô hình không bị nén, và stream phản hồi vẫn hoạt động bình thường
  • Chi phí token của hình ảnh được tính theo kích thước pixel, không phải số ký tự trong ảnh
    • Trong lưu lượng Claude Code thực tế, nội dung dày đặc chứa khoảng 3.1 ký tự mỗi token hình ảnh
    • Token văn bản được đo ở mức khoảng 1 ký tự
  • Ví dụ render đưa khoảng 48k ký tự prompt hệ thống và tài liệu công cụ vào một ảnh 1573×1248; nếu là văn bản sẽ cần khoảng 25k token, còn dưới dạng ảnh chỉ cần khoảng 2.7k token hình ảnh

Chạy và dashboard

npx pxpipe-proxy                                  # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # point Claude Code at it
  • Proxy chạy tại 127.0.0.1:47821
  • Dashboard có tại http://127.0.0.1:47821/
    • Số token đã tiết kiệm
    • So sánh trái/phải giữa văn bản→hình ảnh
    • Kill switch
    • Chip mô hình theo thời gian thực
  • Các lượt gần đây được giữ ở dạng văn bản, còn prompt hệ thống, tài liệu công cụ và lịch sử cũ dung lượng lớn sẽ được chuyển thành hình ảnh

Kết quả trong demo

  • Fable 5 là mặc định, và trong README được mô tả là mô hình đọc 100/100
    • Với 39 tệp filler đã được chuyển thành hình ảnh, mô hình đoán đúng số token chính xác 10/10
    • Kết quả khớp với grep và theo từng dòng
    • Giải đúng phép toán ledger nhiều bước
    • Chi phí phiên làm việc được nêu là $6.06 khi dùng pxpipe, so với $42.21 ở dạng văn bản thường
    • Bên pxpipe cần một lần nudging để khớp đúng định dạng đầu ra một dòng được yêu cầu
  • Opus 4.8 bị tắt theo mặc định
    • Text needle được đọc ở cả hai phía
    • Bài đếm cụm từ đã được chuyển thành hình ảnh không được Opus đọc ra, và pxpipe thể hiện thất bại thay vì bịa số
    • Vì tỷ lệ đọc sai này, Opus chỉ là đối tượng opt-in

Độ chính xác và tính mất mát

  • pxpipe là phương pháp nén có mất mát
  • Với nội dung hình ảnh dày đặc, kết quả nhớ lại chính xác chuỗi hex 12 ký tự khác biệt lớn giữa các mô hình
    • Fable 5: 13/15
    • Opus: 0/15
  • Thiếu sót có thể không xuất hiện như lỗi mà dưới dạng confabulation âm thầm
  • Các giá trị cần độ chính xác theo byte như ID, hash, và secret phải được giữ ở dạng văn bản
  • Hiện chưa có verbatim-risk guard chuyên dụng tích hợp sẵn
  • Subagent dùng mô hình ngoài danh sách cho phép có thể được chuyển qua ở dạng văn bản
    • CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6
    • model: sonnet trong frontmatter của agent

Benchmark và số đo

  • Benchmark dựa trên các bài toán số ngẫu nhiên mới sử dụng các bài toán mà khả năng mô hình đã ghi nhớ từ trước là thấp
Bài kiểm tra N Văn bản Ảnh pxpipe Token
novel arithmetic, claude-fable-5 100 100% 100% −38%
novel arithmetic, claude-opus-4-8 100 100% 93% −38%
gist recall A/B, Fable 5 98/arm 98/98 98/98 -
state tracking, Fable 5 18/arm 18/18 18/18 -
never-stated facts confabulation, Fable 5 16/arm 0/16 0/16 -
verbatim 12-char hex recall, dense render, Opus 15 15/15 0/15 -
verbatim 12-char hex recall, dense render, Fable 5 15 - 13/15 -
  • Pilot SWE-bench Lite đạt 10/10 ở cả hai phía, và kích thước yêu cầu giảm −65%
  • SWE-bench Pro là 14/19 khi ON, 15/19 khi OFF, và kích thước yêu cầu giảm −60%
    • Đánh giá trùng khớp ở 18/19 trường hợp
    • Một ca split được giải lại 3/3 trong các lần chạy tái tạo
    • README xem đây là biến động giữa các lần chạy chứ không phải vấn đề do nén
    • Có kèm lưu ý rằng cỡ mẫu còn nhỏ
  • GSM8K đạt 96% trong trạng thái đã chuyển thành hình ảnh, nhưng vì có thể nằm trong dữ liệu huấn luyện nên README ưu tiên đánh giá novel-number hơn

Cách hoạt động

tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]
  • Proxy chặn /v1/messages và viết lại các đầu vào lớn phù hợp thành image block
  • Các khối đã chuyển đổi được chèn lại theo cách thân thiện với cache, đồng thời tiền tố tĩnh được giữ nguyên để prompt caching tiếp tục hoạt động
  • Ảnh 1928×1928 dùng khoảng 4,761 vision token và chứa khoảng 92,000 ký tự
  • Để văn bản thắng, cần vượt khoảng 19 ký tự/token, trong khi lưu lượng Claude Code được đo là khoảng 1.91 với N=391
  • Bộ ước tính theo từng yêu cầu quyết định có chuyển thành ảnh hay không, còn văn xuôi thưa vẫn giữ ở dạng văn bản
  • Sự kiện được ghi vào ~/.pxpipe/events.jsonl

Nén gì và giữ nguyên gì

  • Có ba loại khối đầu vào được nén, tất cả đều nằm sau cổng kiểm tra lợi nhuận
    • Phần thân tool_result dày token từ khoảng 6k ký tự trở lên
    • Lịch sử cũ đã gập nằm phía sau live tail
    • Slab prompt hệ thống tĩnh và tài liệu công cụ
  • README cũng nêu rõ những mục được chuyển qua nguyên dạng
    • Tin nhắn người dùng
    • Các lượt gần đây
    • Đầu ra mô hình
    • Văn xuôi thưa
    • Các khối quá nhỏ nên không có lợi ích
    • Mô hình ngoài danh sách cho phép
  • Phạm vi mặc định là Fable 5 và GPT 5.6
  • Opus 4.8 và GPT 5.5 phải được bật rõ ràng qua dashboard hoặc PXPIPE_MODELS vì khả năng đọc nội dung hình ảnh kém
  • PXPIPE_MODELS=off sẽ tắt việc chuyển thành hình ảnh
  • Ở nhánh GPT, định nghĩa công cụ được giữ ở dạng native JSON và không dùng marker cache_control của Anthropic

Cách tính chi phí

  • Tỷ lệ tiết kiệm tiêu đề được tính theo tổng hóa đơn, không chỉ phần lát cắt đầu vào
  • Trên 13,709 snapshot yêu cầu, $100 giảm còn khoảng $41, tương đương 59% tiết kiệm
  • Sau đó, trên 8,904 trace yêu cầu đã nén, mức này được đo khoảng 70%
  • Nếu chỉ nhìn riêng các yêu cầu đã nén thì ở mức 72~74%, nhưng README không dùng con số này làm tiêu đề
  • Với mỗi lần POST tới /v1/messages, hệ thống chạy song song một phép đối chứng count_tokens miễn phí trên phần thân gốc chưa nén
  • Mức sử dụng tính phí thực tế được đọc từ khối usage trong phản hồi của Anthropic
  • Bản gốc và mức sử dụng thực tế được ghi cùng một dòng trong ~/.pxpipe/events.jsonl để tránh nhiễu do số lượt hay khác biệt giữa các lần chạy
  • Việc quy đổi sang USD dùng tỷ lệ giá niêm yết của Fable 5
    • input ×1.0
    • cache write ×1.25
    • cache read ×0.1
    • output ×5
  • Giá cache được áp dụng như nhau cho cả hai phía nên giảm giá cache không bị tính trùng thành phần tiết kiệm

Dùng như thư viện

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

const imgs = await renderTextToPngs(toolResultText);            // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
  body: requestBytes,
  model: "claude-fable-5",
});
  • Có thể dùng như thư viện mà không cần proxy
  • options.keepSharp(block) cố định một số khối ở dạng văn bản
  • options.emitRecoverable trả về bản gốc của các khối đã chuyển thành hình ảnh
  • Runtime là Pure JS và hỗ trợ Node cùng edge/Workers
  • @napi-rs/canvas chỉ được dùng ở thời điểm build
  • Toàn bộ API nằm trong src/core/index.ts

Các lỗi thực tế và giới hạn

  • Trong vài tuần sử dụng hằng ngày, đã có một lần mô hình nhớ sai nhưng rất tự tin tên người từ lịch sử chat đã chuyển thành hình ảnh
  • Các phiên coding chịu được kiểu lỗi này vì sẽ đọc lại tệp trước khi chỉnh sửa, nhưng việc nhớ lại trong chat thuần túy thì không có lớp kiểm chứng tương tự
  • Legibility audit đo khả năng nhớ lại chuỗi chính xác trên các trang render
    • Blind read với identifier dày đặc chỉ đạt tối đa 63%
    • Mọi miss đều được dự đoán bởi glyph-confusability matrix
    • Có áp dụng biện pháp giảm thiểu bằng cách giới hạn hình học trang theo API resample cap
    • Các identifier chính xác như SHA và số được chở kèm ở dạng văn bản
  • README cũng nêu các giới hạn
    • Việc nhớ lại nguyên văn dựa trên hình ảnh là khó đáng tin cậy
    • Yêu cầu lớn sẽ có thêm độ trễ mã hóa PNG trước khi gửi
    • ASCII/Latin-1 đã được kiểm thử tốt
    • CJK hoạt động nhưng được xử lý thận trọng

Phát triển và lộ trình

pnpm install && pnpm test
pnpm run build                # regenerates dist/
  • Các lệnh phát triển gồm cài đặt, kiểm thử và build
  • Giấy phép là MIT
  • Lộ trình chỉ được nêu như giả thuyết, và nếu không có số liệu cùng cỡ mẫu thì không được xem là claim
    • Render glyph sắc nét hơn
    • Liệu phần bulk đã chuyển thành hình ảnh có thể tăng ngữ cảnh hữu dụng lên khoảng 2 lần trong cùng cửa sổ 1M hay không
    • Liệu active context nhỏ hơn có giúp tăng độ chính xác cho các tác vụ dài hay không

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Chỉ nhìn Gemini thôi thì tôi hiểu là khi xử lý PDF, nó thực hiện OCR rồi đưa cả văn bản lẫn hình ảnh vào mô hình, và không tính phí token văn bản.
    Nếu backend của Claude cũng làm điều tương tự, mẹo này gần giống một lỗ hổng trong cách tính phí token; và nếu Claude hoạt động như Gemini thì khả năng cao sau này sẽ bị chặn.

    • Điểm này thật sự thú vị. Ban đầu tôi nghĩ “dù sao nội bộ rồi cũng sẽ chuyển thành token văn bản, nên với Claude chi phí thực thi thực tế không thể rẻ hơn được”.
      Nhưng ở bình luận bên dưới có nói DeepSeek đã cải thiện mạnh tỷ lệ nén bằng token thị giác: https://news.ycombinator.com/item?id=48777848
      Tôi không hiểu hết chi tiết kỹ thuật bên trong, nên vẫn chưa thật sự hiểu vì sao tuyến OCR có thể dẫn tới giảm tổng điện năng hay chi phí tính toán.
    • Không hẳn vậy. Hãy xem bài báo DeepSeek-OCR: Contexts Optical Compression: https://arxiv.org/abs/2510.18234
      Một cách để đưa hình ảnh vào LLM là chia ảnh thành các tile, cho các tile đó đi qua mạng nơ-ron bộ mã hóa thị giác để tạo ra token thị giác, rồi đưa vào LLM như token văn bản. Tất nhiên phải huấn luyện để bộ mã hóa thị giác và LLM hiểu nhau. Cách này được gọi là mô hình OCR đầu-cuối.
      Khi đã có một mô hình được huấn luyện như vậy, ta có thể phóng to hoặc thu nhỏ ảnh tài liệu để thay đổi số token thị giác dùng để biểu diễn cùng một tài liệu văn bản, đồng thời cũng có thể điều chỉnh các tham số như kích thước patch hay độ phức tạp của bộ mã hóa thị giác.
      Kết quả khá tốt; trong một số thử nghiệm, số token đầu vào giảm 90% trong khi hiệu năng đầu ra vẫn giữ được 97%.
    • Claude Science có công cụ trích xuất PDF, nhưng tôi không rõ nó có thực sự làm OCR hay không.

  • Năm ngoái tôi đã thử làm điều tương tự với mô hình OpenAI; khi đó nó có tác dụng giảm token prompt, nhưng lại cần nhiều token hoàn thành hơn hẳn nên cuối cùng vừa đắt hơn vừa chậm hơn.
    https://pagewatch.ai/blog/post/llm-text-as-image-tokens/

  • Ôi, đau mắt quá. Trông như một README được vibe code vậy.

    • Phần mô tả do LLM nén lại đọc quá khổ sở. Khó chỉ ra chính xác là vì sao, nhưng nhìn là nhận ra ngay, và để hiểu được thì đúng nghĩa phải tốn gấp đôi công sức.
      Ví dụ:

      Honest caveat, visible in the clip: the pxpipe arm answered the count first and needed one follow-up nudge to also print the ledger balance in the requested one-line format; the plain arm followed the format on the first try. Legibility is solved on Fable — single-reply format compliance is the remaining rough edge.
      Đọc lại bốn lần thì có thể suy đoán đại khái chuyện gì đã xảy ra, nhưng phần lớn là thông tin thừa và gây rối.
      Mọi mô hình đều viết kiểu này ở một mức độ nào đó, nhưng Claude có vẻ đặc biệt nặng. GPT 5.5 cho cảm giác súc tích hơn và nén được nhiều thông tin có giá trị hơn.

    • Khi ai đó chia sẻ thứ họ làm ra mà tôi thấy một README vibe coding, tôi coi đó là tín hiệu mạnh rằng họ không hiểu đủ thứ mình tạo ra để có thể giải thích một cách có thẩm quyền.
      Hoàn toàn có thể tạo ra thứ thật sự hữu ích bằng AI, nhất là trong lĩnh vực mà bạn vốn đã có chuyên môn. Nhưng khi đó cần 1) nói rõ đã dùng sự trợ giúp của AI và 2) giải thích bằng lời của chính mình rốt cuộc bạn đã làm gì. Nếu còn nói được cả các giới hạn khi làm việc với AI thì càng tốt.
      Như vậy mới tạo được niềm tin rằng “thứ người này làm đáng để thử, họ hiểu rõ thứ họ đã tạo ra”.
      99% những thứ xuất hiện gần đây là kết quả của việc người ta làm trong các lĩnh vực họ hoàn toàn không hiểu, nên hễ thấy README kiểu đó là tôi đóng tab luôn.

  • Cái này trông như một mẹo khai thác cách định giá bằng cách đốt tài nguyên. Nếu lỗ hổng bị bịt thì chẳng phải giá OCR phải tăng lên sao?

    • Không phải lỗ hổng; đúng hơn là mã hóa thông tin thành token quang học hiệu quả hơn văn bản rất nhiều.
    • Không hẳn. Cách này không nhất thiết dùng nhiều tài nguyên hơn. Trái lại, có thể nó đang loại bỏ một sự kém hiệu quả căn bản.
      Nghĩ kỹ thì cũng hợp lý. Con người cũng đọc code theo từng từ, nhưng thường là lướt qua và dùng nhận dạng mẫu để nắm đại khái nó làm gì. Chỉ khi cần trả lời một câu hỏi cụ thể mới tập trung vào một phần cụ thể.
      Có thể xem con người cũng tự nhiên thực hiện một kiểu tối ưu hóa đường vòng tương tự.

  • Bài liên quan: https://blog.can.ac/2026/06/10/snapcompact/

  • Cần cẩn thận với cách này. Lý do chi phí giảm có thể là vì thực ra nó chuyển sang một mô hình khác có hiệu năng thấp hơn.
    Bề ngoài trông như Fable nhưng thực tế có thể không phải. Khi đó bạn chỉ đang làm thêm việc vô ích, và có khi tốt hơn là quay lại mô hình opus 4.8.

  • Có vẻ Oh-My-Pi (OMP.sh) dùng hình ảnh để nén ngữ cảnh. OMP được xây dựng trên Pi coding agent.

  • Cũng có một white paper của DeepSeek về kỹ thuật này: https://www.seangoedecke.com/text-tokens-as-image-tokens

  • Trước đây tôi từng thấy một tweet của ai đó, có lẽ là Carmack, Geohot hoặc Karpathy, nói rằng hình ảnh có thể là lựa chọn tốt hơn.
    Từ đó tôi đã dùng hình ảnh kèm các prompt câu rất đơn giản để cho agent biết chuyện gì đang diễn ra, và đôi khi thậm chí không đưa văn bản nào vào prompt.
    Hiệu quả rất tốt.
    Tuy nhiên điều này không hoàn toàn giống điều Karpathy nói. Dù vậy, ý tưởng đó đã dẫn tôi tới một workflow tốt hơn.

  • Xin lỗi nhưng chuyện này thật vô lý. Nó hoạt động và khá thông minh, nhưng rõ ràng là một cách lách qua thất bại trong định giá.
    Giống như chuyện tiền thưởng rắn độc khiến người ta bắt đầu nuôi rắn, việc này lợi dụng và khuyến khích lãng phí.
    Tôi cho rằng trách nhiệm cuối cùng nằm ở cơ chế định giá tệ của Anthropic, thứ đã tạo điều kiện cho kiểu arbitrage này. Nhưng cho đến khi nó được sửa, sẽ có nhiều người lao vào khai thác, và điều đáng ghê tởm là sẽ có thêm một đống rác số hoàn toàn không cần thiết.