把代码渲染成图片发给Claude，API费用直降70%

一个反直觉的省钱思路

用AI写代码正变得越来越昂贵。每次让Claude修复一个bug，模型不仅要读你的代码，还要重新读一遍系统提示词、工具文档以及所有对话历史——就像每次问老板一个问题，都得先给他背一遍公司章程。结果是API账单像火箭般蹿升。

最近一个颇具争议的开源项目引发了广泛讨论：PXPipe。据B站UP主的深度拆解，开发者为了省钱想出了一个绝招——把符合条件的长上下文块（系统提示词、工具文档、旧历史、大段工具输出）渲染成图片，然后以截图形式发给Claude。

实测结果令人惊讶：输入Token减少约68%，按端到端账单计算节省59%~70%（取决于工作负载）。这究竟是Anthropic的计费漏洞，还是多模态模型隐藏的超能力？本文从工程视角深度拆解。

为什么图片比文本便宜

要理解这个套利机会，先得看两种计费方式的核心差异。

大语言模型的Token计费机制源于其底层的分词（Tokenization）设计。主流模型普遍采用BPE（Byte Pair Encoding）或类似的子词分词算法，将文本切分为若干子词单元。BPE最初由Philip Gage于1994年提出用于数据压缩，后被引入NLP领域，其核心思想是迭代地将最高频的字节对合并为单一符号。这一机制导致一个关键不对称：英文中function可能被编码为单个Token，而一个复杂的UUID如550e8400-e29b-41d4则可能被切分为10+个Token。英文中一个Token约对应3~4个字符，而中文、代码、JSON等高密度内容由于字符组合复杂，往往单个Token包含的字符数更少，导致同等信息量下Token消耗更多。这也是为什么代码和日志比普通英文散文更容易受益于图像压缩。

在LLM计费体系里，文本Token按字符数计算——大约一个单词或几个字母对应一个Token，字符越多，费用越高。图像Token的计费规则则完全不同：Claude按28×28的patch来计视觉Token。

这里的"patch"来自Vision Transformer（ViT）架构——图像首先被切分为固定大小的28×28像素块，每个块经线性投影变为固定维度向量后送入Transformer。ViT由Google Brain团队于2020年提出，核心创新在于将图像视为序列而非二维网格，使得自注意力机制得以在视觉领域直接应用。一张1568×728的图像会产生(1568/28)×(728/28)≈1456个视觉Token，这个数字相对固定，不随图像内容的信息密度变化——这正是图像计费具有"固定成本"特性的根本原因。无论图像中是空白背景还是密密麻麻的JSON，消耗的视觉Token数量几乎相同，这为信息密度极高的内容提供了天然的压缩优势。

一张1568×728的生产页，约需1400~1500个视觉Token。而如果同样一页塞满的是代码、JSON、日志这类高密度内容，作为文本可能消耗1.5万到3万个Token。一进一出，差价就出来了。

PXPipe抓住的正是这个信息密度的差价。README里展示过一个48000字符的示例：作为文本约25000 Token，作为图像仅约2700 Token。在真实的Claude Code流量上，PXPipe测得平均信息密度是1.91字符/Token——所以密集的代码、JSON、日志才有真正的套利空间，普通英文散文反而收益有限。

工程实现：像素级的抠门

极致的渲染压榨

打开 src/core/render.ts，你会发现作者在像素层面极度克制。他采用了一套紧凑的5×8像素点阵字体——这种字体起源于早期嵌入式显示器和LED点阵屏，每个字符仅占40个像素。选择这一字体的工程逻辑在于：视觉编码器的感受野（receptive field）足以覆盖完整字符，而无需高分辨率的抗锯齿渲染。过大的字体会减少单页信息量，破坏压缩比；过小则超出模型的识别极限，引发幻觉。5×8是当前模型能力下信息密度与识别准确率的帕累托最优点。页面严格限制在1568×728像素，使得单张图片能塞进整整28080个字符。

精准的分层记忆策略

不是所有内容都适合转成图片。在 transform.ts 里，作者设计了一套聪明的分层记忆机制：

• 最近的对话（刚提的问题、模型刚给的回答）必须保持纯文本，确保100%精确；
• 长期不变的系统提示词、工具定义转换为图片；
• 历史记录在工具调用结束后折叠、渲染成图片归档。

这套逻辑类似人类记忆：刚发生的事历历在目，昨天的事只记得大概。PXPipe用图像作为廉价的"大意存储器"，用文本作为昂贵的"精确工作区"。这一设计也与RAG（检索增强生成）系统的哲学深度相通——RAG由Meta AI于2020年提出，其核心洞察是：语义近似检索的结果已足够支撑大多数推理任务，无需字节完全精确的记忆。在认知科学中，人类的情节记忆本质上也是重构性的而非录像式回放，PXPipe将这一认知事实引入AI系统工程，在精确性与成本之间实现了分层平衡。

此外还有一个关键逃生口 KeepSharp：调用方可以显式指定哪些内容必须保持为文本。

生产环境中，必须把byte-exact内容——哈希值、ID、密钥——显式留在文本里，否则可能出严重问题。

缓存对齐的艺术

懂行的朋友可能会问：Anthropic不是有Prompt Caching吗？把文本转成图片，缓存不就失效了？

Prompt Caching是Anthropic于2024年推出的服务端优化机制，本质上是对KV Cache（Key-Value Cache）的持久化。在Transformer推理中，自注意力层会为每个Token计算Key和Value矩阵，这些中间计算结果通常在请求结束后丢弃。Prompt Caching将满足条件的前缀的KV Cache序列化存储，下次请求若前缀完全一致则直接复用，跳过重复计算，从而实现约90%的Token折扣和显著的延迟降低。缓存的核心要求是前缀内容必须字节完全一致（byte-exact）且达到最低长度阈值（约1024 Token）——这一严格要求源于KV Cache的确定性：任何一个Token的变化都会导致后续所有位置的注意力计算结果改变，使整个缓存失效。

PXPipe的处理相当巧妙：它会把调用方已有的cache_control标记挪到对应图像块的末尾，而不是新增缓存点。这样不会额外消耗缓存折扣，而是尽量不破坏Prompt Caching。在同样的缓存状态下，图片前缀本身需要的Token更少。

真实成本对比：在13709个请求的快照上，启用PXPipe的成本是41美元，不启用是100美元，节省59%。这不是单项压缩的数字，而是整个账单的真实对比。

关键洞察：VLM不是OCR

看到这里你可能觉得，这不过是个利用OCR识别的省钱插件。但关键在于——大模型的视觉系统根本不是OCR。

传统OCR会把图像切成一个个字母来识别，看不清就报"置信度低、识别失败"。多模态大模型（VLM）的工作方式完全不同：图像首先被切分为固定大小的patch（如Claude使用的28×28像素块），每个patch经过视觉编码器（通常基于ViT，即Vision Transformer架构）转换为连续的高维向量，再通过投影层对齐到语言模型的token embedding空间。ViT的自注意力机制使得每个patch能感知到全局上下文，而非孤立地识别局部像素——这与人类阅读时的语境补全机制高度类似。语言模型并不直接"看"像素，而是在这些视觉向量上进行注意力计算，结合语言先验来推断图像内容。这种机制天然具有鲁棒性，但也引入了"推断"而非"读取"的本质差异。

这解释了两个现象：

1. 当图片里的代码稍有模糊，模型依然能看懂逻辑——因为它根据上下文推导出来了；
2. 当你让它看一个毫无规律的12位十六进制哈希值时，它推导不出来，于是会一本正经地编造一个——它没有"置信度低"的概念，只会无声地产生幻觉。

这也是为什么早期在Opus模型上测试时，精确字符串识别率是15分之0，全军覆没。

模型进步改变了一切

转折点出现在新模型发布之后。据UP主分析，当Fable 5（视频中提及的新一代模型）发布后，同样的精确字符串识别测试变成了15分之13。一代模型的进步，把这个原本充满争议的思路推进到了作者愿意默认启用的程度。

为什么这类模型特别适合？因为它处在三个维度的交叉点上，ROI最优：

• 视觉能力足够强，能可靠读懂高密度文字图片；
• 视觉Token计费在密集文本场景下更划算；
• 输入价格高（约10美元/百万Token），砍掉60%输入Token会非常直观地体现在账单上。

这也解释了默认允许列表的选择逻辑：Opus等旧模型在5×8像素密度下精确读取率仅约10%，要达到95%就得把字型放大到10×16，单页只能装7000字符而非28080——完全破坏了成本优势，因此被列为opt-in。

更深层的启示：有损压缩是可以接受的

这个项目最有价值的认知是：在AI工程中，有损压缩完全可以接受，只要你清楚它损失在哪里。

有损压缩在多媒体领域早有成熟应用——JPEG、MP3、H.264都是通过丢弃人类感知阈值以下的信息来换取极高压缩率。值得注意的是，这些标准都有明确的"安全域"定义：JPEG提供quality参数让工程师显式控制权衡，MP3的心理声学模型精确定义了哪些频段可以被掩蔽。AI工程引入有损上下文压缩是一次范式迁移，但面临更复杂的挑战：模型的"感知阈值"难以形式化。一个哈希值的单字符错误在视觉上几乎不可察觉，但在系统语义上是灾难性的。这要求工程师必须对数据进行语义分类：结构化标识符（UUID、哈希、密钥、路径）属于必须无损保留的"关键域"，自然语言描述和历史日志属于可以有损压缩的"语义域"。软件工程讲究100%精确，但人类记忆本就是有损的——我们记不住昨天的每句原话，却记得核心意思。PXPipe用图像作为廉价的"大意存储器"，并通过KeepSharp机制提供了精确性兜底，实现了有损与无损的分层共存。

在GIST层面的测试中，模型对历史决策、路径名的理解准确率达到98%。

这意味着我们可以用极低成本的图像维持长期上下文感知，只在需要精确操作时才读取真实文本文件。但要清醒认识边界：精确字符串仍有误读风险，不能视为零影响。更安全的做法是用KeepSharp机制，把哈希、ID、路径这类byte-exact内容显式留在文本里，只对安全部分启用图像压缩。

这只是一个过渡阶段

文本到图像的上下文压缩，很可能只是一个过渡方案。学术界对视觉上下文压缩已有系统性探索：除DeepSeek专门训练的光学编码器用于长上下文压缩外，2023年以来还出现了多篇聚焦"视觉Token压缩"的论文，如LLaVA系列的Token Merging方案、以及GPT-4V的高分辨率tiling策略。Token Merging的核心思想是在ViT的自注意力层中识别语义相似的patch并将其合并，从而在不显著损失语义信息的前提下大幅减少Token数量——这与PXPipe在应用层面的压缩逻辑殊途同归。这些工作的共同出发点是：视觉编码在处理结构化、重复性强的内容时具有天然的隐式聚合优势。而PXPipe则是用现成的通用模型硬生生跑通了这条路——这说明视觉上下文压缩正在被业界认真探索，从学术研究向工程实践加速迁移。

未来我们很可能看到大模型原生支持记忆分级：精确的短期记忆用文本，模糊的长期记忆用高度压缩的视觉或向量特征。在官方方案到来之前，PXPipe是一个有效但仍需边界管理的实验性工具。

结语

PXPipe的真正创新不是压缩文本，而是发现了一个多模态模型的成本套利窗口——让大模型不再读transcript，而是读pixels。

但这个窗口只有在三个条件同时满足时才成立：模型视觉读小字足够强、图片Token计费足够便宜、任务不依赖逐字精确。所以它目前最适合新一代高价视觉模型，但不代表这项技术只属于某一个模型。随着各家视觉编码器持续升级，视觉上下文压缩很可能成为Agent系统里的标准中间层。