--- title: "Pxpipe 评测：Claude Code 成本降低 60%？" canonical: https://wavect.io/zh/blog/text-as-image-token-savings/ language: zh description: "Pxpipe 的成本、SWE-bench 与精确召回测试，以及为什么 ID、哈希和精确数字必须保留为文本。" image: "https://wavect.io/img/blog/headers/header_text-as-image-token-savings.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 03 Jul 2026 最近审核 2026年8月7日 [**下一篇**](/zh/blog/cost-per-token-vs-cost-per-task/) # Pxpipe 评测：图像真能把 Claude Code 成本降低 60% 吗？ 要点速览 Pxpipe 是一个 MIT 许可的本地代理，把大量上下文作为图像发送给模型。项目报告端到端账单降低 59% 至 70%，SWE-bench 结果接近纯文本，但当前精确召回测试差异很大：Gemini 为 14/15，Fable 为 13/15，Opus 5 为 2/15，GPT-5.6 Sol 为 0/15。只应把它用于允许保留大意的上下文。ID、哈希、密钥、姓名和精确数字必须保留为文本。务必与正确缓存的基线比较，并在自己的模型和负载上验证。核查日期为 2026 年 8 月 7 日。 相关服务: [AI 赋能](/zh/services/ai-enablement/) 一个技巧正在流传：把请求中最沉重的部分，也就是系统提示词、工具文档、旧的对话历史和粘贴的代码，在请求到达模型之前先变成一张图像，从而让 Claude Fable 5 便宜大约 60% 运行。 这套逻辑听起来很荒诞，也正因如此才走红。一张图像对模型的花费是按它的像素尺寸算固定数量的 token，而不是按里面塞了多少文字。于是你可以把大量字符压进一张密集的图里，为像素买单，而不是为文字买单。 正在流传的工具是 [pxpipe](https://github.com/teamchong/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% 这个标题就是这么来的。 这就是模型实际收到的、用来替代你文本的东西： ![一堵密集的、去除空白后压缩的文字被渲染成单张图像，约 48k 个字符压进约 2.7k 个图像 token，顶部带有一条 OCR 指令横幅](/img/blog/text-as-image-what-the-model-sees_hu_75a279e2854fd825.webp)约 48k 个字符的系统提示词与工具文档，作为文本约 25k token，在一页里渲染成约 2.7k 个图像 token。来源： [pxpipe](https://github.com/teamchong/pxpipe) 仓库（MIT），仅作示意。 爆款版本略过的一个细节：因为每张图都被限制在接近 1,600 token，你无法把无限的上下文倒进一张巨大的画布。工具渲染的是许多页，而不是一张海报。节省是真的，但它来自把密集文本平铺到多张受限的图像上，而不是靠魔法。 ## 这不是奇技淫巧，而是一个研究方向 那个反直觉的部分，也就是文字的图像可能比文字本身更便宜，并不是某个代理工具的花招。它是一个活跃的研究领域。 2025 年 10 月，DeepSeek 发表了 [DeepSeek-OCR: Contexts Optical Compression](https://arxiv.org/abs/2510.18234) ，展示了一个视觉模型可以从一小组视觉 token 中解码文本，在压缩比低于 10 倍时以约 10 倍压缩保持约 97% 的 OCR 精度。Andrej Karpathy 借此提出，文本 token 或许是浪费的「历史包袱」，而给模型喂入文字的图像可能更高效。后续工作，例如 [Text or Pixels? It Takes Half](https://arxiv.org/html/2510.18279v1) ，也报告了视觉文本输入上类似的 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，所以诚实的比较应当针对一个正确缓存的基线，而不是一个天真的基线。 ## 什么时候值得，什么时候会把你烧到 这不是一个是或否的问题。它是一个路由决策，和我们在选择模型时用的是同一套纪律。让技术去匹配负载。 | 适合渲染成图像 | 不要渲染这些 | | --- | --- | | 庞大、静态的系统提示词和工具文档 | 任何逐字节的东西：ID、哈希、密钥 | | 只读的参考上下文和长文档 | 你要计算或引用的精确数字 | | 折叠起来的、较旧的对话历史 | 模型必须精确推理的近期对话轮次 | | Fable 5 或其他强图像阅读者 | 路由到 Opus 或视觉较弱的负载 | | 只需大意即可的大批量上下文 | 任何无声读错都不可接受的场景 | 如果你的负载是一大块庞大而稳定的指令，喂给一个大多只需要大意的 Fable 5 智能体，渲染可能是一次实打实的胜利。如果它是一个搬运精确数字和标识符的合规流程，同一个技巧就是一份无声的负债。 ## 它在真实的成本栈里处于什么位置 把上下文渲染成图像是一根杠杆，而且不是我们会先拉的那一根。在动用一个有损技巧之前，通常是那些无聊的杠杆取胜，而且它们不会让你的数据冒险： - **提示词缓存** 用于静态前缀，它是无损的，而且本就很大。 - **模型路由：** 便宜的模型做机械活，强的模型做判断。参见 [我们如何在 Fable、Opus、Sonnet 和 Haiku 之间路由工作](/zh/blog/coding-with-claude-fable-5/) 。 - **衡量每完成一个任务的成本，而不是每 token 的价格，** 因为那才是落在你账单上的数字。参见 [每 token 更便宜，每个答案更贵](/zh/blog/cost-per-token-vs-cost-per-task/) 。 - **一个网关** 用来集中管理回退、缓存和支出上限。参见我们的 [LLM 网关对比](/zh/blog/llm-gateway-router-comparison-2026/) 。 - **自托管或开放权重，** 当规模和数据驻留能够证明其合理时，详见 [在欧盟自托管 LLM 的真实成本](/zh/blog/self-hosting-llms-eu-cost/) 。 把上下文渲染成图像处在这份清单激进的一端：潜在节省高，正确性风险真实，在更安全的杠杆都就位之后，值得在合适的负载上做一次试点。 该拉哪个杠杆、按什么顺序拉，衡量标准是真实账单而不是基准分数，这正是我们 [AI 落地服务](/zh/services/ai-enablement/) 背后的工作：先把当前支出做上埋点，再把无损的杠杆用尽，最后把任何有损的手段放在一道真能抓出错值的评估之后。 [Twinsoft AI](/zh/case-studies/twinsoft-ai/) 就是把同样的顺序用在一套生产系统上，而我们的 [技术选型指南](/zh/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 写明了通用规则：按那些一旦选错就很难回头的约束来决定。 ![Kevin Riedl](/img/team/kevin.webp) "定价的物理是真的，研究也是认真的。但一个偶尔会编造哈希或名字的 60% 节省不是节省，而是被推迟的调试。渲染那些只需要大意的大批量上下文，把每一个精确的值都保持为文本，永远不要把它指向一个读不好图像的模型。" ## 常见问题 ### 在生产中把上下文渲染成图像安全吗？ 只对那些无声读错可以接受的上下文安全，比如庞大的静态指令，或送给擅长读图的模型的只读参考材料。它是有损的，所以把一切逐字节的东西（ID、哈希、密钥、精确数字）保持为文本。把它当作在合适负载上的定点优化，而不是默认设置。 ### 渲染上下文会破坏提示词缓存吗？ 它会和缓存争夺。你最大的静态上下文也正是提示词缓存的最佳对象，而缓存是无损的。在 GPT 路径上 pxpipe 放弃了原生缓存标记。所以要把渲染和一个正确缓存的基线比较，而不是和一个未缓存的比较，否则你会高估收益。 ### 为什么 Opus 读渲染文本比 Fable 差？ 这依赖模型。在 pxpipe 自己的十六进制回忆测试里，Fable 5 得了 15 中的 13，Opus 得了 15 中的 0，所以 pxpipe 默认用 Fable 5 和 GPT-5.6，把 Opus 设为手动开启。同一个在强图像阅读者上省钱的技巧，在较弱的模型上可能毁掉上下文。 ### 这和 DeepSeek-OCR 是一回事吗？ 底层想法相同，都是上下文的光学压缩，只是应用方式不同。DeepSeek-OCR 是一个被训练来从一小组视觉 token 中解码文本、达到约 10 倍压缩的模型。pxpipe 是一个代理，它为现有的、并非专门为此训练的商业 API 渲染你的上下文，损失也因此出现。 ### 它实际能省多少？ pxpipe 仓库声称在 Fable 5 上把端到端账单降低 59% 到 70%，并展示了一个演示任务：文本 42.21 美元，渲染后 6.06 美元。把它当作工具作者在自己负载上的数字，然后在你自己的负载上、针对一个已缓存的基线重新测量。 ## 最终思考 那么，天才还是荒诞？两者都是。机制是真的，图像 token 按像素计价，认真的研究也指向同一个方向。但把它硬套到没有为此训练过的模型上，是用金钱去换无声的错误，而无声的错误是最昂贵的一种。 像使用任何激进优化那样使用它：有意为之，用在合适的负载上，把精确的值保持为文本，并让更安全的杠杆，也就是缓存、路由、度量，先运转起来。这样做，渲染大批量上下文就是一把利器。到处开启它，它迟早会递给你一个你完全没料到的、信心十足的错误答案。 ## 你可能也喜欢.. [**每 token 更便宜。每个答案更贵。** 为什么每完成一个任务的成本，而不是每 token 的价格，才是落在你账单上的数字，以及如何在你自己的负载上衡量它。](/zh/blog/cost-per-token-vs-cost-per-task/) [**AI Enablement 对比一家通用 AI 咨询公司** 一家递给你一份战略幻灯片。另一家在你的基础设施上交付一套能跑的方案，你的团队拥有它，也能运维它。](/zh/compare/ai-enablement-vs-generic-ai-consultancy/) 模型与基础设施 ## 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [LiteLLM 生产级自托管指南：2026 架构与安全](/zh/blog/self-host-litellm-production-2026/) - [AI 就绪企业 Wiki：架构与实施指南](/zh/blog/ai-ready-company-wiki/) - [Claude 会给文本加水印吗？2026 API 实战解读](/zh/blog/claude-text-watermark-api-2026/) - [OpenKB 评测：知识编译器 vs RAG](/zh/blog/openkb-review-vs-rag/) - [Unsloth Desktop 评测：私有本地 AI 工作站？](/zh/blog/unsloth-desktop-local-ai-workstation-review/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 03 Jul 2026 最近审核 2026年8月7日 [**下一篇**](/zh/blog/cost-per-token-vs-cost-per-task/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/text-as-image-token-savings/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/zh/blog/text-as-image-token-savings/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Pxpipe 是一个 MIT 许可的本地代理，把大量上下文作为图像发送给模型。项目报告端到端账单降低 59% 至 70%，SWE-bench 结果接近纯文本，但当前精确召回测试差异很大：Gemini 为 14/15，Fable 为 13/15，Opus 5 为 2/15，GPT-5.6 Sol 为 0/15。只应把它用于允许保留大意的上下文。ID、哈希、密钥、姓名和精确数字必须保留为文本。务必与正确缓存的基线比较，并在自己的模型和负载上验证。核查日期为 2026 年 8 月 7 日。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 Pxpipe 评测：图像真能把 Claude Code 成本降低 60% 吗？ 要点速览 Pxpipe 是一个 MIT 许可的本地代理，把大量上下文作为图像发送给模型。项目报告端到端账单降低 59% 至 70%，SWE-bench 结果接近纯文本，但当前精确召回测试差异很大：Gemini 为 14/15，Fable 为 13/15，Opus 5 为 2/15，GPT-5.6 Sol 为 0/15。只应把它用于允许保留大意的上下文。ID、哈希、密钥、姓名和精确数字必须保留为文本。务必与正确缓存的基线比较，并在自己的模型和负载上验证。核查日期为 2026 年 8 月 7 日。 相关服务: AI 赋能 一个技巧正在流传：把请求中最沉重的部分，也就是系统提示词、工具文档、旧的对话历史和粘贴的代码，在请求到达模型之前先变成一张图像，从而让 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% 这个标题就是这么来的。 这就是模型实际收到的、用来替代你文本的东西： 约 48k 个字符的系统提示词与工具文档，作为文本约 25k token，在一页里渲染成约 2.7k 个图像 token。来源：pxpipe 仓库（MIT），仅作示意。 爆款版本略过的一个细节：因为每张图都被限制在接近 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，所以诚实的比较应当针对一个正确缓存的基线，而不是一个天真的基线。 什么时候值得，什么时候会把你烧到 这不是一个是或否的问题。它是一个路由决策，和我们在选择模型时用的是同一套纪律。让技术去匹配负载。 适合渲染成图像不要渲染这些 庞大、静态的系统提示词和工具文档任何逐字节的东西：ID、哈希、密钥 只读的参考上下文和长文档你要计算或引用的精确数字 折叠起来的、较旧的对话历史模型必须精确推理的近期对话轮次 Fable 5 或其他强图像阅读者路由到 Opus 或视觉较弱的负载 只需大意即可的大批量上下文任何无声读错都不可接受的场景 如果你的负载是一大块庞大而稳定的指令，喂给一个大多只需要大意的 Fable 5 智能体，渲染可能是一次实打实的胜利。如果它是一个搬运精确数字和标识符的合规流程，同一个技巧就是一份无声的负债。 它在真实的成本栈里处于什么位置 把上下文渲染成图像是一根杠杆，而且不是我们会先拉的那一根。在动用一个有损技巧之前，通常是那些无聊的杠杆取胜，而且它们不会让你的数据冒险： 提示词缓存用于静态前缀，它是无损的，而且本就很大。 模型路由：便宜的模型做机械活，强的模型做判断。参见我们如何在 Fable、Opus、Sonnet 和 Haiku 之间路由工作。 衡量每完成一个任务的成本，而不是每 token 的价格，因为那才是落在你账单上的数字。参见每 token 更便宜，每个答案更贵。 一个网关用来集中管理回退、缓存和支出上限。参见我们的LLM 网关对比。 自托管或开放权重，当规模和数据驻留能够证明其合理时，详见在欧盟自托管 LLM 的真实成本。 把上下文渲染成图像处在这份清单激进的一端：潜在节省高，正确性风险真实，在更安全的杠杆都就位之后，值得在合适的负载上做一次试点。 该拉哪个杠杆、按什么顺序拉，衡量标准是真实账单而不是基准分数，这正是我们AI 落地服务背后的工作：先把当前支出做上埋点，再把无损的杠杆用尽，最后把任何有损的手段放在一道真能抓出错值的评估之后。Twinsoft AI 就是把同样的顺序用在一套生产系统上，而我们的技术选型指南写明了通用规则：按那些一旦选错就很难回头的约束来决定。 \"定价的物理是真的，研究也是认真的。但一个偶尔会编造哈希或名字的 60% 节省不是节省，而是被推迟的调试。渲染那些只需要大意的大批量上下文，把每一个精确的值都保持为文本，永远不要把它指向一个读不好图像的模型。\" 常见问题 在生产中把上下文渲染成图像安全吗？ 只对那些无声读错可以接受的上下文安全，比如庞大的静态指令，或送给擅长读图的模型的只读参考材料。它是有损的，所以把一切逐字节的东西（ID、哈希、密钥、精确数字）保持为文本。把它当作在合适负载上的定点优化，而不是默认设置。 渲染上下文会破坏提示词缓存吗？ 它会和缓存争夺。你最大的静态上下文也正是提示词缓存的最佳对象，而缓存是无损的。在 GPT 路径上 pxpipe 放弃了原生缓存标记。所以要把渲染和一个正确缓存的基线比较，而不是和一个未缓存的比较，否则你会高估收益。 为什么 Opus 读渲染文本比 Fable 差？ 这依赖模型。在 pxpipe 自己的十六进制回忆测试里，Fable 5 得了 15 中的 13，Opus 得了 15 中的 0，所以 pxpipe 默认用 Fable 5 和 GPT-5.6，把 Opus 设为手动开启。同一个在强图像阅读者上省钱的技巧，在较弱的模型上可能毁掉上下文。 这和 DeepSeek-OCR 是一回事吗？ 底层想法相同，都是上下文的光学压缩，只是应用方式不同。DeepSeek-OCR 是一个被训练来从一小组视觉 token 中解码文本、达到约 10 倍压缩的模型。pxpipe 是一个代理，它为现有的、并非专门为此训练的商业 API 渲染你的上下文，损失也因此出现。 它实际能省多少？ pxpipe 仓库声称在 Fable 5 上把端到端账单降低 59% 到 70%，并展示了一个演示任务：文本 42.21 美元，渲染后 6.06 美元。把它当作工具作者在自己负载上的数字，然后在你自己的负载上、针对一个已缓存的基线重新测量。 最终思考 那么，天才还是荒诞？两者都是。机制是真的，图像 token 按像素计价，认真的研究也指向同一个方向。但把它硬套到没有为此训练过的模型上，是用金钱去换无声的错误，而无声的错误是最昂贵的一种。像使用任何激进优化那样使用它：有意为之，用在合适的负载上，把精确的值保持为文本，并让更安全的杠杆，也就是缓存、路由、度量，先运转起来。这样做，渲染大批量上下文就是一把利器。到处开启它，它迟早会递给你一个你完全没料到的、信心十足的错误答案。 你可能也喜欢.. 每 token 更便宜。每个答案更贵。 为什么每完成一个任务的成本，而不是每 token 的价格，才是落在你账单上的数字，以及如何在你自己的负载上衡量它。 AI Enablement 对比一家通用 AI 咨询公司 一家递给你一份战略幻灯片。另一家在你的基础设施上交付一套能跑的方案，你的团队拥有它，也能运维它。 模型与基础设施 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 从核心文章开始在欧盟自托管 LLM：开放权重模型何时才真正划算 LiteLLM 生产级自托管指南：2026 架构与安全 AI 就绪企业 Wiki：架构与实施指南 Claude 会给文本加水印吗？2026 API 实战解读 OpenKB 评测：知识编译器 vs RAG Unsloth Desktop 评测：私有本地 AI 工作站？ 集群中的上一篇2026 年 LLM 成本计算器：算任务，不算 Token集群中的下一篇每 token 更便宜。每个答案更贵。 查看相关服务： AI 咨询 RAG 与 AI 架构 Vibe Coding 救援 软件开发 Fractional CTO 看看生产环境中的应用: Twinsoft AI 先做决定: 如何为", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-07", "datePublished": "2026-07-03", "description": "Pxpipe 是一个 MIT 许可的本地代理，把大量上下文作为图像发送给模型。项目报告端到端账单降低 59% 至 70%，SWE-bench 结果接近纯文本，但当前精确召回测试差异很大：Gemini 为 14/15，Fable 为 13/15，Opus 5 为 2/15，GPT-5.6 Sol 为 0/15。只应把它用于允许保留大意的上下文。ID、哈希、密钥、姓名和精确数字必须保留为文本。务必与正确缓存的基线比较，并在自己的模型和负载上验证。核查日期为 2026 年 8 月 7 日。", "headline": "Pxpipe 评测：图像能把 Claude Code 成本降低 60% 吗？", "image": "https://wavect.io/img/blog/headers/header_text-as-image-token-savings.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/text-as-image-token-savings/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/text-as-image-token-savings/", "wordCount": 401 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/text-as-image-token-savings/", "name": "Pxpipe 评测：Claude Code 成本降低 60%？ | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "只对那些无声读错可以接受的上下文安全，比如庞大的静态指令，或送给擅长读图的模型的只读参考材料。它是有损的，所以把一切逐字节的东西（ID、哈希、密钥、精确数字）保持为文本。把它当作在合适负载上的定点优化，而不是默认设置。" }, "name": "在生产中把上下文渲染成图像安全吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它会和缓存争夺。你最大的静态上下文也正是提示词缓存的最佳对象，而缓存是无损的。在 GPT 路径上 pxpipe 放弃了原生缓存标记。所以要把渲染和一个正确缓存的基线比较，而不是和一个未缓存的比较，否则你会高估收益。" }, "name": "渲染上下文会破坏提示词缓存吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "这依赖模型。在 pxpipe 自己的十六进制回忆测试里，Fable 5 得了 15 中的 13，Opus 得了 15 中的 0，所以 pxpipe 默认用 Fable 5 和 GPT-5.6，把 Opus 设为手动开启。同一个在强图像阅读者上省钱的技巧，在较弱的模型上可能毁掉上下文。" }, "name": "为什么 Opus 读渲染文本比 Fable 差？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "底层想法相同，都是上下文的光学压缩，只是应用方式不同。DeepSeek-OCR 是一个被训练来从一小组视觉 token 中解码文本、达到约 10 倍压缩的模型。pxpipe 是一个代理，它为现有的、并非专门为此训练的商业 API 渲染你的上下文，损失也因此出现。" }, "name": "这和 DeepSeek-OCR 是一回事吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "pxpipe 仓库声称在 Fable 5 上把端到端账单降低 59% 到 70%，并展示了一个演示任务：文本 42.21 美元，渲染后 6.06 美元。把它当作工具作者在自己负载上的数字，然后在你自己的负载上、针对一个已缓存的基线重新测量。" }, "name": "它实际能省多少？" } ] } ```