Nick Saraev · 06:44 · 发布 2026-07-07 · 9470次观看(截至抓取) · 观看原视频
主旨
把 Fable 5 调用里本该作为文本 token 喂入的大段上下文先渲染成图片,经 vision 通道送入,利用”vision 计费按像素面积而非字符数”的规则,让同一信息在 大海捞针 类查询上能省下 30-59% 的输入成本。
核心论点
- Vision 计费按图像像素面积固定,与图中字符数量无关——这是把”等量文本→压缩图片”路径变成可套利桶的前提,本片核心机制。(→ 详解1)
- 同一 prompt 走文本路径 vs 图像路径的两路实测,文本 59,822 tokens、图像 38,142 tokens,实测成本从 $1.03 降到 $0.69——视觉通道确实把同语义的 token 数砍掉约 36%。(→ 详解2)
- 整条管道可由 Fable 5 自己根据一条语音 prompt 现场搭建,本质是在 forward-goal 风格下让模型把”把 prompt 渲成图再喂回给我”封装为一个一次性的最小脚本,人退到只下需求。(→ 详解3)
- 省 token 的力度与查询类型强相关:在大海捞针型知识查询上,本片 head-to-head 测出 68.7% 输入 token 削减、最终账单降 59%,远超普通对话的 30% 基线。(→ 详解6)
- 不主张对每次调用都用,只对”巨型 prompt、需要被反复复用、长期跑业务工作流”的场景才划算;作者亦认为厂商会很快打补丁,时间窗有限。(→ 详解1、详解7)
知识点详解
1. 套利的前提:Vision 与文本走两条计费通道 00:05
视频开场就点明本片的可套利机制:“an images token cost is fixed by its pixel dimensions, not how much text is inside of it”(00:33)。换言之,1928×1928 的图不管里面塞了一个字还是塞满正文,账单几乎一样。
只要图里的字仍然经 OCR 可读,模型对图片内容的识别就与读等量文本等价。这条规则一旦被意识到,就在文本路径与 vision 路径之间留下一个”单位字符成本”差,作者称之为”arbitrage”(套利)。
但作者明确不推荐对每次调用都用这套:“am I going to use this on every single query that I’m running? Probably not”(00:55);真正的适用面是”really massive queries that are hundreds of thousands of tokens”(01:00)、“this is a quick and easy way you can immediately save 30%“(01:09)这两句所定义的——巨量、需要被长期复用、被反复调用的工作流。本片的核心取舍是”批量、复用、长跑”的工作流才值得”渲染→送入”这一步的额外开销。
2. 双路实测:同一 prompt 文本 vs 图像 01:39
作者在终端里把同一段 prompt 分别以文本形态和图像形态喂给模型,报告两条结果:“the text version of this prompt cost $1.3, whereas the images version of the prompt cost 69. Mathematically, that’s a little over a 30% reduction in token usage”(01:39)。口径换算到 token 时,数字是 59,822 vs 38,142(01:53)。
更关键的是 token 数差异背后是否有质量损失:作者明说”zero difference in the model’s ability to recall various components of the text which I know”(01:55),换言之,在该基准 prompt 的内容上,模型从压缩图片里读出来的语义与读原文本等价。这意味着”信息密度”这条警示线,在这条 vision 通道上没有被击穿。
作者把这种”Fable 模型对极小可读字体的识别基本是世界级”的现象归到 OCR 能力上:“the OCR, the optical character recognition and like Fable’s ability to understand text even if it’s really tiny um is essentially probably the best in the world right now”(02:08)。
3. 一条语音 prompt,让 Fable 自己把管道搭好 02:28
实操层作者没写一行手动代码,而是用本地语音转文字(自由开源的 hex,跑在 parakeet 上),“把一句话丢给 Fable 让它把整个流水线搭建出来”。具体的那句话含义是:“build a simple system that every time I feed in a prompt, converts it to an image first, presumably using a cheaper model, and then takes that and then feeds that into Fable”(02:44),并以”I want to be able to pass off extremely long prompts to Fable in order to arbitrage on tokens”(02:59)作为完成判据。
这正是 forward-goal 范式的一次教科书使用:目标(把超长 prompt 用图形式喂入)+ 完成判据(可以批量套利)+ 自治阈值(模型自己用更便宜的模型完成图片渲染),一次说清楚就让 Fable 启动长任务。
Fable 实际产出的最终产物是一个名为 pxpipe.py 的脚本——后续只要把任意 prompt 文件丢进去,它就自动渲染成图后喂回 Fable,触发”人类对话一次→长期套利”的复用形态。视频把这段脚本归到了免费的 Skool 资源(Maker Zero 社群)中,作为本片最后的”Get the script”章节交付。
4. 1928×1928 这个像素桶为什么能装下全量 prompt 04:12
作者把成像的算术摊到屏上解释:“A 1928 by 1928 image costs approximately this many vision tokens and holds that many characters”(04:12);既然”a real cloud code traffic averages that many characters a token”,像素桶的字符密度就远超等值文本 token 桶——这就是”that’s how you make imaging profitable”(04:19)的几何算术。
关键观察点:1928×1928 这块”像素桶”虽然按面积价是固定的,但能容纳的字符数远远高于同等价位的文本 token 能表示的字符数。两者的”每美元字符密度”在 vision 通道那里更高,这就是套利空间的几何来源。
作者同时警告:“they’re probably going to patch this pretty quick”(04:26);他个人已经”feeding in every single one of my prompts like this for the foreseeable future”,并提醒受众但凡有值得长期复用的 prompt,现在就该用——他认为此种套利是基于厂商当前的 billing glitch,时间窗口有限,越早用越划算。
5. Mega Prompt 实战:knowledge base 任务现场跑 04:37
在拿到 pxpipe.py 之后,作者现场演示 mega prompt 的用法:把所有历史视频上传记录及对应表现数据存在一个巨型文本文件里,既作为 text 又作为同义 image 备一份,然后在 Fable 5 上用 API 定价跑 head-to-head。
这一步的关键设计是把”会反复喂入 Fable 的巨型参考资料”与”会反复被查询的小问题”分开。文本文件写得再长都被一次预先渲染收掉,日后每次提问只生成图像送入,模型拿到的已经是压缩后的 token 流。作者明确点出这是”knowledgebased task”——里面是真实的引用、合并、组合,不是重复推理。
6. Head-to-head 结果:68.7% 输入 token 削减、59% 成本下降 06:13
实测数字:“there’s a 68.7% reduction in input tokens. With all that in mind, the cost didn’t decrease by 25 to 30% like I showed you before in the example. It’s actually 59%“(06:13)。
这个数字相比详解 2 的 30% 基线显著放大,作者解释这是查询类型的功劳——属于 大海捞针 一类:“if you have these sort of needle in a hay stack type queries, obviously you have significantly higher quality or rather larger alpha in using a strategy like this”(06:20)。
换言之:在需要从超长上下文里精确召回某个片段的场景,文本路径下”超长上下文”对每条 query 都要重新计费,而图像路径下”上下文”已经被一次性收掉了成本。这意味着套利的边际收益随着”上下文被复用的次数”线性放大。
7. 收尾:脚本免费发,但要快用 06:26
视频收尾非常短:“this announcement doesn’t really need to be more in-depth than that”(06:32)——作者认为该机制直白不绕,视频到此刚好。脚本被挂在描述区的 Skool 链接里(Maker Zero 社区为本片贡献的 100% 免费资源仓),顺手推了一下 Maker School 90 天 accountability 计划,作为本片的附赠销售收尾。
可执行步骤
- 评估你当前 Fable / Claude 调用里哪些 prompt 是”巨型 + 长期 + 高频复用”的(详解体量几十万 token 起步),把候选清单列出来。
- 从 description 区
Maker Zero链接拿到pxpipe.py(或自建同等脚本),准备一个 CLI 调用方式:python pxpipe.py /path/to/prompt.txt,返回图像文件给 Fable。 - 把脚本与 Fable session/工具绑定,设计为每次”大 prompt 引用”时统一走图像通道,避免与”小 prompt 实时对话”路径混淆。
- 对每条巨型 prompt 提前烤一份压缩图备用(reusable cache),不复用就不要走这条路。
- 设计 A/B 监控:同一查询分别走文本与图像两条路径,记录各自的 token、wall-clock、答案质量评分(回查 + 人工 spot check),基于真实数据判断是否启用。
- 为打补丁预留撤退路径:把”图像缓存+回退到文本”做成可配置项,模型厂商计费规则一改就一键切回。
关联
- 互补:前作:Fable 1486 美元实测的 7 条技巧——那条片主要在文本侧动手(工具调用输出瘦身、语义压缩、礼貌性铺垫剥离等),本片改走”文本→图像→vision 通道”的另一条轴,两者在”给 Fable 减负”这件事上不重叠。先读哪条:文本侧技巧零额外算力开销、对所有模型都通用,先实施;当遇到”prompt 必填且无法压缩”的硬性场景(参考语料、知识库条目),再叠本片的图像渲染路径。
术语
- Vision token(视觉 token)计费:主流多模态模型对图像输入按”分块数”计费,与图像里实际字符数无关,本片套利机制成立的物理前提。
- 图像套利(image arbitrage):把本应作为文本 token 喂给模型的提示词或参考资料先渲成图送入,在 vision 通道实现单位字符成本更低的工程手段。
- OCR(optical character recognition,光学字符识别):模型从图片中提取并识别其中的文字内容,Fable 在视频中被声称具备世界级小字体识别能力;本片把”vision 通道不损信息密度”完全建立在 OCR 鲁棒性上。
- 大海捞针(needle in a haystack):从超长上下文里精确召回某个片段的查询类型,本片 head-to-head 测试所用任务的主要形式。
- Forward-goal(目标导向完成):一种 prompt 风格,只设目标与完成判据、不规定中间步骤,使模型自主决定长任务的执行路径。
金句
“We’re basically just arbitrageing the cost of an image right now versus the cost of tokens.” — 一句话点明本片的”单位字符成本套利”本质。(04:25)
“this announcement doesn’t really need to be more in-depth than that.” — 作者认为该机制直白不绕,刻意保持视频简短。(06:32)
立场与利益
- 与利益同向(待印证):本片关键主张——“渲染文本到图能省 30-59% input token,且召回质量无差异”——直接帮 Maker School(
https://skool.com/makerschool/about,位于 description 区)和 Maker Zero(https://skool.com/maker-zero/about)做内容营销:用一台免费脚本留住关注者、把对 token 价格敏感的开发者引流进 Skool 社群,继而推销 90 天 accountability 计划。采信前需独立复现:30% baseline 实测在视频里有数字,但 59% 极致数字只在一次”大海捞针型”任务里跑出,无统一统计口径,采纳前要在自己的 workload 上做 A/B。 - 利益中性:把 vision 计费按像素面积而非字符数固定这件事作为套利前提——这是当前主流多模态 API 的公开计费规则(Anthropic / OpenAI 文档皆可查),无需博主演示即可独立验证。
- 与利益反向(可信度最高):“they’re probably going to patch this pretty quick”——作者主动戳破该套利可能很快被堵死,不利于自己的”让你们持续向我学怎么省 token”叙事仍说出口,反而劝观众”趁能用赶紧用”——这反而是对受众真正有利的忠告。
价值定位
适合谁:已经在用 Fable 5 / Claude 类 API、且能让 agent 反复触发同一套长 prompt 的开发者或业务运营者(例:把全量参考语料挂回会话、做大批量知识抽取的工程师、做长期 RAG 系统或定制 agent 的从业者)。
解决什么:把”巨型且稳定”的 prompt 上下文从每次 token 计费搬移到一次性图像渲染缓存,以单位字符成本显著的差距降低长期账单。
认知 vs 实操:本片同时给认知(为什么 vision 计费能套利、为什么大海捞针型收益更大)与实操(从 pxpipe.py 脚本到与 session 集成的端到端管道),但因为脚本未在 description 区显式给出开源 URL(只在视频内口头指向 Skool),实际操作上需要先进入 Maker Zero 社群领取,该获客路径是视频作者的设计;若你不愿意入社群,完全可以基于详情 3 的 prompt 让 Fable 现场复现同样脚本。
自检问题
-
视频中把同一 prompt 的两种形态分别喂给模型,文本版的 token 数和图像版的 token 数分别是多少?实测成本下降了多少? 答案:文本 59,822 tokens、图像 38,142 tokens;同一 prompt 实测成本由 $1.03 降到 $0.69(详解 2)。01:53
-
为什么把文本塞进图片能省钱,模型读图时为什么不会丢信息? 答案:vision 计费按像素面积固定,与图片里字符数无关;Fable 的 OCR 能识别极小可读字体,字符密度足够容下原 prompt(详解 1、详解 2、详解 4)。00:33
-
视频在”大海捞针型”知识查询的 head-to-head 中,报告的输入 token 削减与最终成本降幅分别是多少? 答案:输入 token 减 68.7%,账单降 59%(详解 6)。06:13
-
作者认为应该对每次 Fable 调用都使用这套技巧吗?适合什么场景? 答案:不建议每次都用;只对”巨型 prompt、需长期复用、被反复调用的业务工作流”才划算(详解 1 末尾)。01:02
-
作者对这套套利的可持续性如何判断? 答案:认为厂商会很快打补丁,建议尽早用(详解 1、详解 4、详解 7)。04:25