Fable 5被网友薅出省钱神招！pxpipe最高让token减70%！

没想到，人类当年靠微缩打印做小抄的土办法，在大模型身上也照样管用。

这两天，有位机智的老哥发现，只要把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、哈希、密钥、精确数字和最近几轮对话，只压缩系统提示词、工具文档、较早历史记录、大型工具输出这些“又长又密”的内容。

最后，如果想自己试一下也很简单，作者给的启动方式只有两行：

npx pxpipe-proxy # proxy on 127.0.0.1:47821ANTHROPIC_BASE_URL=
http://127.0.0.1:47821 claude # point Claude Code at it

启动后，本地还有一个dashboard：

http://127.0.0.1:47821/

里面可以看到节省了多少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这代模型，则让普通用户第一次在真实生产工具里，摸到了这个套利空间。

话说，用图像作文本输入，有没有搞头？

参考链接

[1]https://github.com/teamchong/pxpipe

[2]https://arxiv.org/pdf/2212.08045

文章来自于微信公众号 “量子位”，作者 “量子位”