生产环境中的多模态大模型：没人会预先计算的成本账

大多数团队在向现有的 LLM 流水线添加多模态能力时，往往没有先计算成本。他们用几张测试图片做了原型，运行良好，然后就上线了——直到收到第一张账单。根据调用量的大小，账单上的数字往往介于“令人尴尬”和“灾难性”之间。

问题不在于多模态 AI 在原则上有多贵，而在于每种模态都有独特的 Token 计算逻辑，它们会以一种你凭纯文本直觉无法预料的方式复合叠加。只需一个配置参数——比如视频帧率、图像分辨率模式，或者你是否在每一轮对话中重复发送系统提示词（System Prompt）——都可能在你不经意间，让你的推理费用翻上 10 倍甚至更多。

图像 Token 计算逻辑

图像并非免费的上下文。在模型处理之前，它们会被转换为 Token，而 Token 的数量取决于图像的尺寸，而非文件的大小。

GPT-4o 的公式最为透明：85 + (切片数量 × 170) 个 Token。这里的切片（Tiles）是指图像缩放后被划分为 512×512 像素的部分。一张 512×512 的图像消耗 255 个 Token；一张 1024×1024 的图像消耗 765 个 Token；而一张 4000×6000 像素的高分辨率文档扫描件可能消耗超过 16,000 个 Token——按照目前的输入价格计算，单张图片约需 0.041 美元，而这还没算你生成的任何输出内容。

Claude 使用不同的公式——大约是 (宽 × 高) / 750 个 Token——并且如果长边超过 1568 像素或 Token 数超过约 1,600 个，它会自动缩放图像。这意味着大多数“大”图会被限制，但上限依然昂贵：一张处于最大尺寸限制的典型图像大约消耗 1,333–1,600 个 Token。按 Haiku 的价格计算，每张图约 0.0016 美元；按 Opus 计算，则约 0.008 美元。

Gemini 的公式没有以同样的方式公开记录——不同供应商披露的信息各异——但从经验上看，标准图像大约在 560 个 Token 左右。

如果不计算调用量，这些数字看起来都并不可怕。每天 10,000 次图像查询，按 GPT-4o 的高详情价格（假设每张图平均 765 个 Token）计算 = 每月 76.5 亿个输入 Token = 每月仅图像输入的费用就高达约 19,125 美元，这还没算输出、文本上下文和系统提示词的费用。而且这还只是假设每次查询仅包含一张图片。处理发票、产品照片或批量文档的团队通常每次请求会发送 3–10 张图片。

对于图像来说，最立竿见影且零成本的优化方案是：将简单的分类或存在检测任务切换到低详情模式（Low-detail mode，固定 85 个 Token，无论图像尺寸如何）。对于任何不需要精细视觉细节的任务，这能带来 9 倍的 Token 缩减。团队通常是在收到第一张超乎预期的账单后才发现这一优化方案的，很少有人能在这之前想到。

另一个杠杆是分辨率门控。在提交之前，将图像的长边缩放到最大 512 像素，可以显著减少切片数量。将 JPEG 压缩质量设为 85，可以在不明显影响 AI 任务准确率的情况下，减小传输的数据负载。这两者都不需要修改模型。

音频：看似便宜，实则不然

音频计费表面上看很简单：大多数供应商按处理的音频分钟数收费。Whisper 和 GPT-4o Transcribe：0.006 美元/分钟；Deepgram：约 0.0077 美元/分钟。即使在大规模调用下，这个成本计算看起来也是可控的。

陷阱在于实时音频 API。当你从批量转录转向对话式语音界面（即 LLM 逐轮响应音频）时，计费模式会发生翻天覆地的变化。实时 API 按音频 Token 计费：输入音频 Token 约为每百万个 40 美元，输出音频 Token 约为每百万个 80 美元。在实时对话中，这大约相当于音频输入每分钟 0.06 美元，音频输出每分钟 0.24 美元。

这已经比批量转录贵了 10 倍。再加上系统提示词的成本：在实时会话中，大多数实现方式会在每一轮对话中重新发送完整的系统提示词。一个 1,000 词的系统提示词如果每轮对话都重发一次，每分钟会增加约 1.63 美元的成本——这甚至超过了音频本身的费用。一个带有合理尺寸系统提示词的完整语音代理，单是推理成本就很容易达到每分钟 2 美元以上，这还没算平台费、通话费或 TTS（语音合成）费用。

降低系统提示词成本的方法是积极使用上下文缓存并截断对话历史。降低整体语音流水线成本的方法通常是架构层面的：尽早决定你是否真的需要实时音频理解（模型直接听音频），还是“批量 STT → 文本 → LLM”的方案就足够了。对于大多数用例来说，后者的成本要低得多。一个完整的批量语音流水线（STT + LLM + TTS）总成本约为每分钟 0.07–0.22 美元。而实时 LLM 音频的费用在每分钟 0.30 美元到 2 美元以上不等，具体取决于提示词的大小。

音频质量也会以团队往往低估的方式直接影响成本和准确率。当信噪比（SNR）从 15 dB 降至 5 dB 时，词错率（WER）大约会翻倍。在呼叫中心、车间、户外等真实环境中，SNR 经常掉到 5–10 dB 范围内。在清晰音频数据集上能达到 95% 准确率的模型，在高噪声环境下准确率会崩塌到 70% 以下。

语音识别研究中有一个反直觉的发现：旨在消除噪声的预处理流水线往往会让情况变得更糟。谱减法（Spectral subtraction）虽然能将测得的 SNR 提高约 8 dB，但由于它在去除噪声的同时也剥离了语音谐波，可能会导致 WER 增加 15%。更好的方法是使用在噪声数据上训练过的端到端模型——它们直接处理原始音频，避免了那些原本想帮忙却引入了误差的预处理步骤。

视频：倍数效应变得危险的地方

视频是多模态成本计算真正变得危险的地方，因为它包含了一个大多数从业者从未触及的默认配置参数：帧采样率。

Gemini 的视频理解 API 默认为每秒 1 帧。默认设置下，一段 60 秒的视频 = 60 帧。每帧大约为 258 个视觉 token。每秒再增加 32 个音频 token。总计：一分钟视频约 17,400 个 token。这仍是在可控范围内的。

现在考虑一下，如果有人为了在高速运动内容上获得更高的准确性，将默认设置改为 24 FPS 会发生什么。60 秒、24 FPS = 1,440 帧 = 大约 374,400 个 token。成本差异：21.5 倍，仅仅源于一个参数的更改。如果每天处理 100 个视频，这相当于每天 ~104 美元与 ~2,235 美元的区别。按年计算，错误的 FPS 设置会导致每年多支出约 78 万美元。

正确的帧率完全取决于内容类型。对于讲座录像、产品演示或任何摄像机固定且内容移动缓慢的场景，0.1 FPS 通常就能捕获所有语义上唯一的帧。对于手术视频或体育分析，1 FPS 确实不够。成本最优的架构会在提交前应用内容感知帧选择：按基础速率提取，应用感知哈希（perceptual hashing）去重近乎相同的帧，应用场景检测来识别唯一的片段，然后仅提交关键帧。这种方法根据视频类型的不同，可减少 13–45% 的 token 使用量；在内容密集的演示视频中，结合去重和场景检测可将成本降低高达 83%。

上下文缓存（Context caching）为视频提供了另一个重要杠杆。Gemini 的隐式缓存（自 2025 年年中起默认启用）对重复分析同一视频的缓存 token 提供 90% 的折扣。一段 5 分钟的视频，首次分析费用约为 0.18 美元；随后对同一缓存视频的查询费用约为 0.018 美元。对于需要重复分析同一视频的工作流——如质量保证 QA、医疗复核、内容审核——这彻底改变了经济模型。

基准测试中未体现的失效模式

除了成本之外，每种模态都有标准基准测试（benchmarks）难以捕捉的退化模式。

对于图像：“分辨率诅咒”是一个已知但未受到足够重视的失效模式。大多数模型中的视觉编码器在处理之前会降采样到固定的内部分辨率——通常是 384×384 像素。具有精细细节（手写体、微小文本、密集标签）的高分辨率源图像可能会在编码步骤中完全丢失这些细节。这意味着发送更高分辨率的图像并不总能产生更好的结果；它可能会以显著更高的 token 成本产生相同甚至更差的结果。准确率达到平台期（plateaus）的实际分辨率因模型和任务而异，且极少有文档记录。

多图请求的效果下降，原则上并不是因为模型处理多图的能力差，而是因为它们将总 token 数推到了上下文注意力质量下降的范围。关于“上下文腐烂”（context rot）的研究表明，性能下降在 2,500 个 token 左右开始显现，在 5,000–10,000 个 token 以上会出现普遍退化。一组 10 张高细节图像，每张 765 个 token = 在添加任何文本之前就有 7,650 个图像 token。这不是一个理论上的担忧；处理多页文档包的生产团队经常会遇到这个瓶颈。

对于音频：关键的失效模式是对预处理栈的过度工程化。预处理链中的每一个降噪、归一化或 VAD 过滤器都是剥离模型所需信息的机会。在干净的基准数据集上看起来像是改进的预处理步骤，往往会损害真实世界长尾输入的准确性。实际建议：投资于在噪点数据上训练的模型，而不是预处理流水线，并在不同的信噪比（SNR）范围内测量字错率（WER），而不仅仅是在干净的测试集上。

对于视频：时序推理方面在当前模型中仍然非常薄弱。它们无法准确解释因果序列，在移动场景中混淆空间方向（左与右），并会错过虽然细微但语义重要的帧间变化。帧采样降低了成本，但加剧了这些失效——对 30 FPS 的动作序列进行 1 FPS 采样仅捕获了 3.3% 的帧。在视频基准测试中表现最好的模型通常是在 1 FPS 就足够的视频类型上进行测试的；而生产环境的工作负载并不总是如此配合。

真正行之有效的生产架构

在大规模运行稳定多模态流水线的团队，通常会收敛于同一套架构模式。

LLM 调用前的输入验证。 图像质量门控（模糊检测、最小分辨率检查、格式验证）在消耗 token 并返回垃圾结果之前拦截不良输入。音频 VAD（语音活动检测）在计费前去除静音，对于停顿频繁的真实通话录音，可将音频成本降低 30–40%。

模态感知的模型路由。 并不是每种模态在每个模型上都能得到同样好的处理。GPT-4o 在文本和图像混合推理任务中表现良好。Gemini 2.5 在原生视频和音频理解方面领先。Claude Sonnet 在文档提取基准测试中展现出应对图像质量退化的最佳韧性。根据模态和任务类型进行路由——而不是将所有内容发送到同一个模型——可以在控制成本的同时发挥各自的相对优势。

针对结构化文档区分 OCR 与原生视觉。 LLM 视觉处理成本为每份文档 0.20–1.00 美元。专用 OCR API 的成本为每页 0.01–0.05 美元。对于大批量的结构化提取（发票、表格、收据），先进行专用 OCR 处理，再由 LLM 进行后处理，通常能以单份文档低 10–20 倍的成本达到相同的准确率。将原生 LLM 视觉保留给需要布局推理、表格解读或复杂视觉上下文的任务。

带有健康状态追踪的级联降级（Cascade fallback）。 多模态 API 调用的失败率高于纯文本调用，且退化通常是无声的——模型返回了答案，只是质量较差。生产流水线受益于显式的健康状态追踪（健康 → 错误率达 2%+ 时降级 → 错误率达 5%+ 时失败 → 恢复中）以及回退链：主模型 → 更便宜的替代方案 → 缓存响应 → 优雅报错。语义缓存（Semantic caching）消除了重复查询对供应商的依赖。

明确每种模态的成本归因。 跟踪每个查询 token（并按模态细分）的可观测性技术栈，能及时发现导致盈利工作负载转为亏损的配置偏移。在未受监控的流水线中，只要一名工程师将视频采样从 0.1 FPS 切换到 1 FPS，或将低细节图像切换为高细节图像，就可能产生 10 倍的账单增长，且需要数周时间才能发现。

在交付前算好账

控制多模态成本的模式已经存在，且并非秘而不宣。大多数团队在规划时所缺失的，是在首次生产部署之前就养成核算成本的习惯，而不是等到收到第一张令人大吃一惊的账单之后。

对于图像：计算（每日图像查询量 × 每张图像的平均 token 数 × 输入 token 单价）。然后使用低细节模式（low-detail mode）进行同样的计算并对比。两者的差距通常超过 5 倍，而计算过程只需大约十分钟。

对于音频：将批量转录工作负载与实时对话工作负载区分开，并分别定价。这两者不属于同一种成本模型。

对于视频：在接受默认的 FPS 设置之前，先确定你的实际内容类型和帧变化率。在真实内容的样本上测试感知哈希（perceptual hashing）去重，以获得经验性的帧缩减评估。

那些避免了账单冲击的团队并没有做任何奇特的事情。他们只是在编写集成代码之前，先在电子表格里算好了这笔账。