henry 发自凹非寺
量子位 | 公众号 QbitAI
没想到，人类当年靠微缩打印做小抄的土办法，在大模型身上也照样管用。
这两天，有位机智的老哥发现，只要把 Fable 5 的上下文转换成一张张密密麻麻写满文字的图片，再让模型通过 OCR 读回来，token 输入成本最多能省下 70%。
更离谱的是，不只是普通对话，系统提示、工具文档、历史记录，全都能一股脑塞进图里。
空说无凭，老哥还真给了一个例子：
大约 4.8 万字符的系统提示词和工具文档，如果直接按文本输入，大约需要 2.5 万 token；
但把它们渲染成一张上面 1573×1248 的图片后，只需要约 2700 个 image token。
按 Fable 5 现在的价格计算，实测端到端账单下降了 59% 到 70%。
这一图胜过千言万语，还真有以前考试微缩、写小字的味儿了。
真·压缩即智能。
网友看完直接表示：这招可千万别让 Dario 知道了。
（你也不想你的 Fable 5 限制上传图片吧）
把上下文做成小抄，账单直接砍七成
开头提到的这个邪修 Fable 5 的方法，名叫 pxpipe，目前在 GitHub 已经收获 3000+ STAR。
在说明里，作者也是直抒胸臆的表示：
这玩意就是把 Fable 5 的文本上下文，渲染成图片，以降低的 token 用量。
之所以能这么“邪修”，关键在于一个计价差异：
图片的 token 成本，主要由像素尺寸决定，而不是由图片里塞了多少文字决定。
也就是说，只要模型还能读清图片里的字，那么同样一段内容，压成一张密密麻麻的 PNG，可能就比直接作为文本输入更便宜。
尤其是代码、JSON、工具输出、系统提示词、工具文档这类内容，本身就非常 token 密集。
按照 pxpipe 作者的测算，在真实 Claude Code 流量中，这类内容如果作为图片输入，大约可以做到每个 image token 容纳 3.1 个字符；
但如果作为文本输入，约等于每个 text token 只能容纳 1 个字符。
而这，就给了 pxpipe 操作空间。
pxpipe 本质上是一个本地代理：拦截 Claude Code 发出的请求，在请求离开本机之前，先把其中比较臃肿、适合压缩的上下文，重新排版成一张张紧凑的 PNG 图片，再塞回请求里发给模型。
模型读这些图片，走的则是同一个视觉通道——也就是 Anthropic 的 computer use 功能读取屏幕截图时依赖的那条通道。
换句话说，pxpipe 并不是让模型“真正 OCR”文本，而是利用模型本来就具备的看图能力，把大段上下文伪装成截图喂进去。
说白了，就是一个自动的微缩“打印机”。
后面，为了证明这招不是纯脑洞，作者也放了一个对比 demo。
同样一组任务，原始文本版本跑到最后，账单是 42. 21 美元，上下文窗口已经占满 96%；而 pxpipe 版本只花了 6. 06 美元，上下文还只用了 73. 5k/1M
也就在省钱的同时，任务也照样完成了，Fable 5 依然能从图片化上下文中读出关键信息，完成计数和多步账本运算。
不过，这也不是一招鲜吃遍天。作者用 Opus 4.8 跑了同样的实验，普通文本 needle 没问题，但一到图片化内容里的词频统计，Opus 就读不出来了。
与此同时，这也意味着，这是一种有损压缩，非常吃模型的视觉读取能力。
密集图片里的精确字符串，Fable 5 还能勉强读，Opus 就很容易翻车；更危险的是，错了也未必报错，而是自信编出一个看似合理的结果。
（注：这组 benchmark 证明：在 Fable 5 上，把高密度上下文渲染成图片，基本不影响语义理解和状态追踪，还能显著省 token；但一旦涉及逐字读取精确字符串，就会暴露有损压缩的风险）
所以 pxpipe 也没有把所有内容都图片化，而是保留 ID、哈希、密钥、精确数字和最近几轮对话，只压缩系统提示词、工具文档、较早历史记录、大型工具输出这些“又长又密”的内容。
最后，如果想自己试一下也很简单，作者给的启动方式只有两行：
npxpxpipe-proxy# proxy on 127.0.0.1:47821ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude# point Claude Code at it
启动后，本地还有一个 dashboard：
里面可以看到节省了多少 token、每一次文本转图片的前后对比、kill switch，以及当前启用的模型标签。
需要注意的是，pxpipe 只压缩请求，不压缩模型输出。也就是说，响应还是正常流式返回；它动的只是输入侧那些大块上下文。
谷歌 2022 年老论文早已证明
这项目一经发出后，也是一石激起千层浪，谁叫 fable 5 这么贵。
有网友表示，这招我早就在用了。
还有学者翻出了谷歌 2022 年的老论文，CLIPPO。
简单来说，跟 pxpipe 的做的差不多，CLIPPO 的核心思想就是把文字也当成图片处理
传统 CLIP 通常是两套编码器：一套看图，一套读文本。
CLIPPO 则直接把文本渲染成 RGB 图片，让同一个 Vision Transformer 同时处理真实图片和文字图片，连图片 + 问题也可以拼成一张图一起喂进去。
这样一来，模型不再需要 tokenizer、文本 tower 和 word embedding，但在图像分类、图文检索上依然接近 CLIP 风格模型，只差1-2 个点。
也就是说，文字不一定非得以 token 的形式进入模型，也可以先变成像素。
此外，评论区里，还有不少网友提到了 DeepSeek-OCR。
在 DeepSeek OCR 中，主打的就是把长上下文做成视觉压缩。pxpipe 文档里也专门拿它解释这条路线，低于 10x 压缩时能有约 97% 解码精度，接近 20x 时降到约 60%。
所以，这次 pxpipe 的热闹可能不只是一个“省钱小工具”引发的。
它更像是把过去几年几条线突然接上了：CLIPPO 证明，文字可以当图看；DeepSeek-OCR 证明，上下文可以做光学压缩；
而 Fable 5 这代模型，则让普通用户第一次在真实生产工具里，摸到了这个套利空间。
话说，用图像作文本输入，有没有搞头？
