把提示词渲染成图像，把 LLM 成本砍掉 60%：是天才，还是纯属荒诞？

一个技巧正在流传：把请求中最沉重的部分，也就是系统提示词、工具文档、旧的对话历史和粘贴的代码，在请求到达模型之前先变成一张图像，从而让 Claude Fable 5 便宜大约 60% 运行。

这套逻辑听起来很荒诞，也正因如此才走红。一张图像对模型的花费是按它的像素尺寸算固定数量的 token，而不是按里面塞了多少文字。于是你可以把大量字符压进一张密集的图里，为像素买单，而不是为文字买单。

正在流传的工具是 pxpipe，一个开源（MIT）的本地代理。它位于你的机器和 API 之间，在请求离开你的笔记本之前，把体积庞大、大多静态的上下文渲染成密集的 PNG「页面」。仓库自带的演示显示，同一个多步骤任务作为纯文本花费 42.21 美元，用 pxpipe 则是 6.06 美元。它声称在 Fable 5 上按当前挂牌价可把端到端账单降低 59% 到 70%。

那么，这到底是天才还是胡闹？诚实的答案是：其中的物理是真的，背后的研究是认真的，而失败模式糟糕到，对大多数生产工作你不应默认开启它。下面是完整的图景，连同那个爆款版本略去的种种前提。

它为什么真的有效：定价的物理

文本和图像按相同的每 token 费率计费，但计数方式非常不同。

文本按内容分词。字符越多，token 越多，成本越高。而图像，Anthropic 是按像素面积定价的，用一个大致的公式 (宽 x 高) / 750 个 token，并且对计数设了上限（图像会被缩放，让长边保持在约 1568px，这让上限接近每张图 1,600 个 token）。关键在于：这个数字并不在意图里是一片空白的矩形，还是一堵文字的墙。

在真实的 Claude Code 流量上，pxpipe 测得代码和 JSON 这类密集内容每个图像 token 能装约 3.1 个字符，而每个文本 token 约 1.9 个字符。一旦你的文本密度超过每 token 约 19 个字符，把它渲染成图像就开始划算。一段作为文本要花 25k token 的内容，渲染后回来约 2.7k 图像 token。60% 这个标题就是这么来的。

这就是模型实际收到的、用来替代你文本的东西：

爆款版本略过的一个细节：因为每张图都被限制在接近 1,600 token，你无法把无限的上下文倒进一张巨大的画布。工具渲染的是许多页，而不是一张海报。节省是真的，但它来自把密集文本平铺到多张受限的图像上，而不是靠魔法。

这不是奇技淫巧，而是一个研究方向

那个反直觉的部分，也就是文字的图像可能比文字本身更便宜，并不是某个代理工具的花招。它是一个活跃的研究领域。

2025 年 10 月，DeepSeek 发表了 DeepSeek-OCR: Contexts Optical Compression，展示了一个视觉模型可以从一小组视觉 token 中解码文本，在压缩比低于 10 倍时以约 10 倍压缩保持约 97% 的 OCR 精度。Andrej Karpathy 借此提出，文本 token 或许是浪费的「历史包袱」，而给模型喂入文字的图像可能更高效。后续工作，例如 Text or Pixels? It Takes Half，也报告了视觉文本输入上类似的 token 节省。

所以这个想法是站得住脚的，长上下文的经济学也确实有意思。pxpipe 只是一次早期而激进的尝试，想在今天的商业 API 上把它变现，而模型还没被训练得能把这件事做好。而「模型还没被训练得能把这件事做好」，恰恰是麻烦开始的地方。

让它对大多数工作都显得荒诞的那个坑

把文本渲染成图像是有损的，而且损失是无声的。

当模型看错一个被渲染的字符时，它不会抛出错误，也不会报告低置信度。它会信心十足地编一个出来。pxpipe 自己的 README 诚实地记录了这一点：在一个大海捞针测试里，要求模型从密集渲染内容中回忆精确的 12 位十六进制字符串，Fable 5 得了 15 中的 13，而 Opus 得了 15 中的 0。README 描述了一个真实案例：模型从渲染的聊天历史里回忆一个人的名字，并且信心十足地记错了。

这就是全部风险，一句话概括：任何你需要逐字节准确取回的东西，都必须保持为文本。ID、哈希、密钥、精确的数字、准确的名字。pxpipe 正是出于这个原因，把最近的对话轮次和精确标识符作为文本保留在图像旁边。

标题还跳过了这几点：

• 它依赖模型。pxpipe 默认用 Fable 5 和 GPT-5.6，这些是最擅长读取密集渲染文本的模型。Opus 4.8 和 GPT-5.5 只能手动开启，因为它们更容易读错渲染的上下文。在一个模型上帮你省 60% 的技巧，在另一个模型上可能悄悄毁掉上下文。
• 它增加延迟。把大请求编码成 PNG 需要时间，而这发生在请求离开你的机器之前。
• 它和提示词缓存相互影响。你最大、最静态的上下文，也就是系统提示词和工具文档，恰恰是提示词缓存的理想对象，而缓存本就对重复 token 大幅打折。在 GPT 路径上 pxpipe 放弃了原生缓存标记。渲染上下文和缓存上下文瞄准的是同一批 token，所以诚实的比较应当针对一个正确缓存的基线，而不是一个天真的基线。

什么时候值得，什么时候会把你烧到

这不是一个是或否的问题。它是一个路由决策，和我们在选择模型时用的是同一套纪律。让技术去匹配负载。

如果你的负载是一大块庞大而稳定的指令，喂给一个大多只需要大意的 Fable 5 智能体，渲染可能是一次实打实的胜利。如果它是一个搬运精确数字和标识符的合规流程，同一个技巧就是一份无声的负债。

它在真实的成本栈里处于什么位置

把上下文渲染成图像是一根杠杆，而且不是我们会先拉的那一根。在动用一个有损技巧之前，通常是那些无聊的杠杆取胜，而且它们不会让你的数据冒险：

• 提示词缓存用于静态前缀，它是无损的，而且本就很大。
• 模型路由：便宜的模型做机械活，强的模型做判断。参见我们如何在 Fable、Opus、Sonnet 和 Haiku 之间路由工作。
• 衡量每完成一个任务的成本，而不是每 token 的价格，因为那才是落在你账单上的数字。参见每 token 更便宜，每个答案更贵。
• 一个网关用来集中管理回退、缓存和支出上限。参见我们的LLM 网关对比。
• 自托管或开放权重，当规模和数据驻留能够证明其合理时，详见在欧盟自托管 LLM 的真实成本。

把上下文渲染成图像处在这份清单激进的一端：潜在节省高，正确性风险真实，在更安全的杠杆都就位之后，值得在合适的负载上做一次试点。

"定价的物理是真的，研究也是认真的。但一个偶尔会编造哈希或名字的 60% 节省不是节省，而是被推迟的调试。渲染那些只需要大意的大批量上下文，把每一个精确的值都保持为文本，永远不要把它指向一个读不好图像的模型。"