title: "AI 编程最贵的不是模型，是上下文——有人把 42 刀的账单压到了 6 刀" description: "pxpipe把文本渲染成PNG图片压缩多模态模型上下文，token成本降低59-70%，但精确字符串召回率Opus仅0/15，Fable 13/15——省钱还是挖坑，取决于你压的是什么" tags: ["AI编程", "pxpipe", "token压缩", "Fable 5", "Claude Code"]
42.21 美元 vs 6.06 美元。
同一个任务，同一个模型，同一个会话。左边是普通文本输入，右边是接入 pxpipe 之后的请求。
7 倍价差，不是换了个便宜模型，不是砍了功能，只是换了一种方式把上下文"喂"给 AI。
这就是 pxpipe 正在做的事——把大段文本渲染成 PNG 图片，让多模态模型"看"而不是"读"，从而把 input token 成本砍掉 59-70%。
但天下没有免费的压缩。在你冲上去装之前，先搞清楚这笔账到底怎么算。
一个反直觉的定价漏洞
要理解 pxpipe 为什么能省钱，得先理解多模态模型的计价方式。
文本 token 的成本，大致是 1 个字符 = 1 个 token。一段 48000 字符的系统提示和工具文档，大约需要 25000 个 text token。
但图片 token 的计算方式完全不同——它取决于像素尺寸，而不是图片里有多少文字。一张排版紧凑的 PNG 图片，里面塞了 48000 字符，模型只需要约 2700 个 image token 就能"看完"。
3.1 个字符 per image token vs 1 个字符 per text token。
这就是 pxpipe 利用的定价差：同样的信息密度，图片通道比文本通道便宜 3 倍。
它是一个本地代理，拦截你发给 Claude Code 的请求，把系统提示、工具文档、旧对话历史、大型工具输出这些"臃肿"部分在本地渲染成 PNG，然后把图片塞进请求替代原始文本。当前用户输入、最近几轮对话、关键实时内容仍然保留为文本，降低模型误读当前任务的风险。
数据说话：省了多少，丢了什么
pxpipe 官方给出的核心数据：
| 指标 | 数值 |
|---|---|
| 端到端成本降低 | 59-70% |
| 压缩部分 token 降低 | 72-74% |
| 4.8 万字符系统提示 | 25k text token → 2.7k image token |
| Demo 会话成本 | $42.21 → $6.06 |
| 上下文余量 | 接近打满 → 仍有很大余量 |
看起来很美。但问题藏在精确度数据里。
pxpipe 做了一个关键测试：在密集的图片化内容中嵌入 12 位十六进制字符串，测试模型的精确召回率。
| 模型 | 精确召回率 | 失败模式 |
|---|---|---|
| Fable 5 | 13/15（86.7%） | 静默编造——给出一个看起来合理但实际错误的值 |
| Opus 4.6 | 0/15（0%） | 完全无法精确复现 |
这个数据至关重要。
Fable 5 的视觉理解能力足够强，86.7% 的精确召回率在大多数场景下可以接受。但 Opus 直接归零——这意味着如果你用的是 Opus，pxpipe 对精确内容基本无效。
而且失败模式不是报错，是静默编造（silent confabulation）。模型不会告诉你"我看不清这个字符串"，而是自信地给出一个看起来合理但完全错误的值。这在生产环境中是最危险的失败模式——错误不会被捕获，会沿着调用链继续传播。
不是所有内容都该压缩
pxpipe 不会粗暴地把整段请求全部图片化，它有自动判断机制：
适合压缩的： 系统提示词、工具说明文档、较老的对话历史、大型工具输出（长日志、代码片段、JSON、文件读取结果）。这些内容信息密度高，模型只需"大概知道"就够了，不需要逐字精确。
不该压缩的： 当前用户输入、最近几轮对话、精确标识符（变量名、API Key、hash 值、版本号）。pxpipe 为此设计了 fact sheet 机制，把高风险标识符额外以文本形式保留。
但 fact sheet 不是万能的。你需要自己判断哪些内容属于"高风险标识符"——如果你漏掉了一个关键的 commit hash 或配置值，模型可能用编造的值继续推理，而你浑然不知。
学术路线 vs 工程路线
pxpipe 不是第一个用"视觉方式处理文本"的思路。
DeepSeek-OCR 走的是学术路线：专门训练了一个视觉编码器 DeepEncoder，在 10x 压缩比下 OCR 精度达 97%，用 100 个视觉 token 就超越了 GOT-OCR2.0（256 token）。这是真正的"有损但可控"压缩。
VIST 框架（南理工/中南大学/南林大，NeurIPS 2025）提出"快-慢阅读通路"：远处的上下文渲染为图像由视觉编码器快速提取，近处关键文本直接输入 LLM 深层推理。视觉 token 比传统文本 token 少 56%，显存减半。
pxpipe 走的是工程路线——不改模型、不训练编码器、不改架构，只在请求出口加一层代理，把文本渲染成 PNG 塞回去。简单粗暴，立竿见影，但精度上限受限于模型本身的视觉理解能力。
| 维度 | pxpipe | DeepSeek-OCR | VIST |
|---|---|---|---|
| 路线 | 工程hack | 学术训练 | 学术框架 |
| 压缩比 | ~3x | ~10x（97%精度） | ~2.3x |
| 需要训练 | ❌ | ✅ | ✅ |
| 精确召回 | 依赖模型 | 97%（10x） | 未公布 |
| 部署门槛 | 极低（本地代理） | 高（需部署编码器） | 高（需集成框架） |
| 通用性 | Fable 5/GPT 5.6 | 通用 | 通用 |
pxpipe 的优势是零门槛、零改动、即插即用。劣势是精度完全绑死在模型的视觉能力上——换了个弱视觉模型，压缩效果可能从"省钱"变成"烧钱返工"。
代价清醒：什么时候不该用
1. 精确字符串是刚需的场景——别用。
如果模型需要精确匹配 commit hash、配置值、API 端点、密钥片段等，图片化会导致静默编造。fact sheet 机制可以缓解但不能根除这个问题。Opus 用户尤其要谨慎——0/15 的召回率意味着精确内容基本全丢。
2. 非多模态模型——没法用。
pxpipe 默认面向 Fable 5 和 GPT 5.6，因为它们的视觉理解能力最稳定。纯文本模型根本不支持图片输入。对于视觉能力弱的模型，可以选择关闭或手动开启，但关闭了就没省钱效果了。
3. 样本量有限——别太乐观。
官方数据基于 10-19 个任务的测试。生产环境的工作负载千差万别，59-70% 的成本降低是理想值，不是保证值。
4. 计价可能变——这不是结构性优势。
pxpipe 利用的是当前多模态模型的定价差。如果 Anthropic 调整图片 token 的计价方式（比如按信息密度而非像素尺寸），这个漏洞可能随时被堵上。pxpipe 自己也承认："prices move and workloads differ, so the durable number is the token cut itself."
谁该装，谁该等等
该装的：
- 重度 Claude Code / Fable 5 用户，月账单三位数以上
- 长任务、多轮迭代场景，上下文经常打满
- 上下文中以"参考性内容"为主（文档、日志、历史），精确字符串需求少
- 愿意花时间调 fact sheet 配置的团队
该等等的：
- Opus 用户（0/15 召回率，压缩基本无效）
- 精确代码补全、配置生成等对精确度有硬要求的场景
- 团队协作环境，错误传播风险高
- 等 DeepSeek-OCR 类方案成熟后，可能有更可控的压缩路径
省钱的本质是选对压缩对象
pxpipe 的核心洞见不是"图片比文本便宜"，而是不是所有上下文都值得逐字传输。
系统提示词、工具文档、旧对话历史——这些内容模型只需要"知道大概"，不需要"逐字记住"。把它们压成图片，就像把参考书放在桌上而不是逐字抄进笔记本——需要的时候翻一眼就够了。
但精确的标识符、当前任务的输入、关键参数值——这些必须逐字无误。把它们也压成图片，就像把密码写在纸上然后用传真发出去——看起来传到了，但每一个字都可能被看错。
有损压缩不是问题，不知道哪里有损才是问题。
pxpipe 的 fact sheet 机制是在正确的方向上迈步，但目前还不够成熟。真正安全的上下文压缩，需要模型和工具的协同设计——不是在出口加一层代理，而是从架构层面区分"哪些信息需要逐字保真，哪些可以模糊处理"。
在那一天到来之前，pxpipe 是一个值得尝试的工程方案——但请把精确内容留在文本里。
暂无评论。