我最近在帮几个团队做多模态大模型API的选型咨询，聊下来发现一个挺有意思的现象：大家嘴上都在说“成本很重要”，可真到动手算账的时候，十个人里能拿出八套不同的算法。有人只看每百万token的标价，有人把图片按张数乘以单价就完事，还有人干脆拿上个月的账单总额除以调用次数，得出一个“平均每次几分钱”的模糊结论。这些算法放在一起比，结论能一样才怪。我自己就踩过这样的坑，早期做横向评估时，把某家厂商的图片输入按“一张图等于固定token数”粗略折算，结果实际账单下来差了将近四成。那次之后我才老老实实去翻各家的计费文档，把输入成本的构成边界重新捋了一遍。
这件事让我意识到，多模态输入成本对比这件事，难的不是拿到价格表，而是先把“到底在比什么”说清楚。文本、图像、音频、视频这四种模态，计费逻辑各走各的路，有的按token，有的按秒，有的按分辨率切片，有的还叠加转写费用。你拿一个按token计价的价格去跟一个按分钟计价的方案比，数字上能算出一个比值，但这个比值背后的假设往往经不起推敲。所以我在这第一章里想做的，不是急着抛结论，而是把研究的背景和评估口径先摊开来讲明白，后面几章的对比才有共同语言。
1.1 多模态大模型API输入成本的构成与边界
我习惯把输入成本拆成三层来看。最外面一层是账面价格，也就是厂商定价页上写的那个数字，按token、按张、按秒标得清清楚楚。中间一层是计量规则，同样一段内容，不同厂商折算成多少计价单位，这里头的差异比价格本身的差异还要大。最里面一层是隐性成本，比如图片预处理、音频转写、格式转换这些环节，有的厂商打包在输入价格里，有的单独计费，有的干脆不告诉你它悄悄做了。三层叠在一起，才是你真正掏出去的钱。
边界这件事也得说清楚。我见过不少对比文章，把输出成本、微调成本、存储成本全混进来算一个“综合单价”，读起来很热闹，实际参考价值有限。输入成本就该老老实实界定在“把内容送进模型”这个动作上，输出侧的费用、调用失败的消耗、并发限流带来的重试开销，严格来说都不该算进来。我自己的做法是，做对比时先把边界画死，只比输入侧的计费，其他部分单独列出来做备注。这样比出来的数字干净，别人拿去复现也容易。
还有一个容易被忽略的边界问题：同样的模态，输入形态不同，成本构成就不一样。文本输入就是纯token，简单直接。图像输入可以是原图直传，也可以是先做OCR再传文本，这两条路径的成本结构完全不同。音频输入可以走原生音频token，也可以先转写成文本再喂给模型，后者往往更便宜但会损失语调信息。把这些路径差异纳入成本构成的讨论里，对比才不至于停留在表面。
1.2 文本、图像、音频、视频输入的计费差异
文本输入的计费是最透明的，基本就是按token算，输入输出分开计价，长上下文还有阶梯定价。我对比过多家厂商的文本单价，差距主要体现在长上下文区间，短文本的价差其实没那么夸张。文本这块的坑主要在于分词器的差异，同样一段中文，不同厂商切出来的token数能差出百分之二三十，光看单价不看分词效率，比出来的结论会偏。
图像输入的计费就热闹多了。有的厂商按图片数量收，一张图一个固定价；有的按分辨率分档，低清一个价高清另一个价；有的走切片逻辑，把图片切成若干块，每块折算成token。我实测过同一张1080p的截图，走按张计费的方案和走切片计费的方案，成本能差出一倍多。这里头的关键变量是分辨率和图片内容复杂度，一张纯色图和一张满是文字的图表，在切片逻辑下消耗的token数天差地别。
音频和视频的计费逻辑又是另一套。音频普遍按时长计价，但采样率、声道数、是否包含转写服务，都会影响最终价格。视频更复杂，本质上是抽帧加音频轨的组合，有的厂商按视频时长乘一个系数折算，有的按抽帧数量加音频时长分别计费。我见过一个团队做短视频内容审核，一开始按“视频时长乘以文本单价”估算，实际跑下来发现抽帧密度才是成本大头，估算和实际差了将近三倍。这种差异不是谁故意坑人，而是计费维度压根不在一个平面上。
1.3 成本对比的统一口径与指标设计
要把这些不同维度的计费拉到一张表里比，我得先定几个口径。第一个口径是“单位内容成本”，也就是处理同样一段内容要花多少钱。文本按千token算，图像按张算，音频按分钟算，视频按分钟算，各自用最贴近业务实际的单位。第二个口径是“等效token成本”，把非文本模态按厂商的折算规则统一换算成token，这样能横向比单价，但这个口径的假设比较强，我只在需要跨模态比价的时候用，平时不拿它当主指标。
指标设计上我偏好三个数：单次调用平均输入成本、单位内容输入成本、以及一个我管它叫“成本弹性”的指标。前两个好理解，第三个说的是内容规模翻倍时成本怎么变。有的方案是线性的，内容翻倍成本翻倍；有的方案有阶梯折扣，规模上去单价下来；还有的方案因为切片逻辑存在阈值效应，内容稍微超一点就跳档。成本弹性这个指标在选型时特别有用，业务量增长快的团队不看这个，很容易在半年后被账单吓一跳。
口径统一还有个现实难题：厂商文档的更新频率不一样。我上个月整理的一份对比表，这周再去核对，已经有两家调整了图片计费的切片规则。所以我在做对比时会明确标注数据采集日期，并且把“文档口径”和“实测口径”分开列。文档口径用于快速筛选，实测口径用于最终决策。两者有出入的时候，以实测为准，并且把出入点记下来，这本身就是很有价值的选型信息。
1.4 相关搜索词与用户关注点拆解
我翻了不少搜索数据，发现用户在这块的关注点大致分三类。第一类是比价型，搜的是“多模态API价格对比”“图像输入token怎么算”这种，需求很直接，就是要一张能看懂的表。第二类是避坑型，搜的是“多模态计费坑”“音频输入隐性成本”这类，背后往往是被账单教育过的团队。第三类是选型型，搜的是“多模态大模型选哪家”“输入成本优化”，这类用户已经不满足于看价格，想要的是结合业务场景的判断依据。
从搜索词的分布看，“图像输入token计费”和“音频输入成本”这两个方向的搜索量明显高于文本，这跟我的观察一致。文本计费太成熟了，大家心里都有数，反倒是图像和音频这两块，计费规则不透明、折算逻辑复杂，用户的不确定感最强。我在后面章节里会把图像和音频单独拎出来做专题，原因就在这里。
用户关注点的另一个共性是对“实际账单”的执念。几乎每个来咨询的团队都会问一句“你有没有实测数据”。这说明单纯的价格表已经不够用了，大家要的是能对上账的经验值。我在这一章里把评估口径讲透，也是为后面的实测对比做铺垫。口径清楚了，实测数据才有说服力，不然又是一笔糊涂账换一笔糊涂账。
聊完评估口径，接下来得把计费机制本身掰开来看。我这几年对接过不少厂商的API文档，越看越觉得这套机制像俄罗斯套娃，你以为看懂了最外层，拆开还有一层，再拆还有一层。文本时代好歹还有个“token单价乘以用量”的简单公式，到了多模态这里，光一个图像输入就能给你整出分辨率分档、切片数量、单图token上限三套规则叠加。我有个做电商的朋友，给商品图做自动描述，一开始按张数估成本，上线两周后账单直接翻倍，查了半天才发现高清图和低清图走的不是同一个计费档。这种事儿不是个例，机制不摸透，预算根本没法做。
我写这一章的目的很明确：把文本、图像、音频、视频这几类输入的计费逻辑一个个拆开讲清楚。不追求面面俱到，重点讲那些实际会咬人的细节。比如音频的采样率怎么影响token数，视频的抽帧逻辑怎么折算，缓存命中到底能省多少。这些东西厂商文档里大多有写，但写得比较技术化，我把它翻译成大白话，再配上我自己踩过的坑，读起来应该能省点力气。
2.1 输入token的计量方式与计价单位
token这个词大家都熟，可真要问一句“多模态里的token到底怎么数”，能答清楚的人不多。文本的token是分词器切出来的，这个没什么争议，中文一个字通常算一到两个token，英文一个词算一到两个，各家分词器略有差异但量级一致。图像和音频就麻烦了，它们本身不是离散的符号序列，厂商得自己定义一套折算规则，把连续信号变成token。这个折算规则每家都不一样，有的按图像块算，有的按特征向量算，有的干脆给你一个公式让你自己套。
计价单位这块，我观察到市场上主要有三种玩法。第一种是纯token计价，所有模态统一折算成token，按每百万token多少钱来收。第二种是分模态计价，文本按token，图像按张，音频按分钟，各算各的账，最后加总。第三种是混合计价，基础费用按token算，某些模态额外加收处理费。这三种玩法没有绝对的好坏，关键是你在做对比的时候得先搞清楚对面这家用的是哪一套，不然比出来的数字没有意义。我见过有人拿纯token方案的单价去乘按张方案的图片数量，算完还纳闷为什么实际账单对不上，这就是典型的计量单位没对齐。
还有一个容易忽视的细节：输入token和输出token的计价单位虽然都叫token，但价格通常不一样，而且有些厂商对输入token做了更细的划分。比如图像输入折算出来的token，跟你直接发文本产生的token，在计费系统里可能被归到不同的价格档。我核对过一家厂商的账单明细，同样的token数量，走图像通道和走文本通道，单价差了大概百分之十五。这种差异文档里往往不会明说，得自己从账单结构里反推。所以我建议做成本测算的团队，别只看定价页的总表，一定要拉一份真实的账单明细出来，看看token到底被分成了几类来计价。
2.2 图像输入token计费：分辨率、切片与数量
图像计费这块，我总结下来就三个变量在起作用：分辨率、切片数量和单图token上限。分辨率决定图像信息量的上限，切片数量决定这张图实际被拆成多少块来算，单图token上限则是一道保险，防止一张超大图把token数撑爆。这三个变量组合起来，就是你为一张图付的钱。
切片逻辑是最值得细说的。现在主流厂商基本都用类似ViT的架构，把图像切成固定大小的patch，每个patch折算成固定数量的token。一张1024乘1024的图，切成16乘16的patch，就是4096个patch，每个patch算多少token，乘一下就出来了。问题在于不同厂商的patch大小不一样，有的用14乘14，有的用16乘16，有的还会做多尺度切分，同一张图切出来的patch数量能差出两三成。我拿一张标准测试图做过对比，A厂商算出850个token，B厂商算出1200个token，单价再一乘，成本差了将近一半。
分辨率分档是另一层。很多厂商会把图像按长短边分成几档，低清档一个折算系数，高清档另一个系数，超过某个阈值还可能触发额外的处理费。我见过一个做文档扫描识别的团队，原始扫描件是3000乘4000的，直接传进去token数直接顶到单图上限，每张图成本是压缩到1080p之后的四倍多。他们后来加了一步预处理，把图片缩到模型推荐的分辨率再传，识别准确率几乎没降，成本砍下来一大截。这个案例说明一个道理：图像计费里的分辨率变量，是用户自己可以控制的，别傻乎乎地把原图直接往里灌。
单图token上限这个设计我觉得挺有意思。它的本意是保护用户，避免一张巨图产生天价账单，但也带来一个副作用：当你的图像信息密度很高时，上限会把细节截断，模型看不到的部分等于白传。我遇到过做工业质检的客户，缺陷区域只占整图很小一块，按标准切片逻辑，那块区域分到的token太少，模型根本分辨不出来。后来他们的做法是先做区域裁剪，把缺陷区域单独切出来放大再传，token用得更少，效果反而更好。这个思路值得借鉴，图像计费不是越省越好，关键是把token花在信息密度高的地方。
2.3 音频输入token计费：时长、采样与转写
音频计费比图像要直观一些，主流是按秒或按分钟计价，但里面的门道一点不少。最核心的变量是时长，这个没什么好说的，一分钟就是一分钟。真正的差异藏在采样率和编码格式里。同样是六十秒的音频，16kHz单声道和44.1kHz立体声，折算出来的token数能差好几倍。有的厂商会在文档里写清楚采样率怎么影响token数，有的只字不提，你传什么它就按什么算，账单出来才知道疼。
我拿一段会议录音做过实测。原始文件是48kHz立体声，时长半小时，直接传进去按某厂商的折算规则算下来，token数高得离谱。后来我用工具转成16kHz单声道，时长没变，内容也没损失多少，token数直接降了六成多。这个操作的成本几乎为零，效果立竿见影。所以我的建议是，上传音频之前先看一眼厂商推荐的采样率参数，不按推荐值来，多花的钱纯属冤枉。
转写这块要单独拎出来说。很多团队处理音频的实际路径是“先转写成文本，再把文本喂给大模型”，而不是直接传原生音频。这两种路径的成本结构完全不同。转写路径的成本等于转写服务的费用加上文本token的费用，原生音频路径的成本等于音频token的费用。哪个便宜取决于具体场景。我算过一笔账，一段十分钟的清晰语音，转写费用加上文本token，总成本比原生音频token低大概三到四成。但如果音频里有大量非语音信息，比如音乐、环境音、多人重叠说话，转写会丢掉这些信息，原生音频反而更合适。
转写服务本身的计费也有讲究。有的按音频时长收费，有的按转写出来的字数收费，有的对静音片段做特殊处理。我见过一个做播客内容分析的团队，他们的音频里静音片段占比很高，按时长计费的方案让他们为大量空白付了钱。后来换成按有效语音时长计费的方案，成本降了将近一半。这种细节不看账单根本发现不了，所以音频这块我特别强调要做实测，别光看标价。
2.4 视频与文档等复合输入的折算规则
视频是复合输入里最复杂的，因为它本质上至少包含两条轨道：画面和声音。厂商处理视频的方式大致分两种。一种是分别处理，抽帧算图像的token，音频轨算音频的token，两者相加。另一种是整体折算，按视频时长乘一个综合系数，系数里打包了抽帧和音频的成本。第一种方式透明，你能看清楚钱花在哪；第二种方式省事，但系数怎么定的你不清楚，优化起来无从下手。
抽帧密度是视频计费的核心变量。一秒钟抽一帧和两秒钟抽一帧，token数差一倍。我做过一个短视频内容审核的项目，一开始用默认抽帧密度，一分钟的视频大概产生几十帧，成本还能接受。后来业务方要求提高审核精度，抽帧密度调高之后，成本直接翻了三倍。这个案例让我明白一件事：视频计费里的抽帧密度，是一个需要用业务需求来反推的参数。精度要求不高的场景，低密度抽帧完全够用，没必要为用不上的精度买单。
文档输入的情况有点特殊。PDF、Word这些格式，厂商通常会在入口处做一层解析，把文档拆成文本、表格、图片三部分分别计费。文本部分按token算，表格可能按单元格数或者按解析难度折算，图片部分走图像计费逻辑。这里面最容易被低估的是扫描版PDF，整页都是图片，走的是图像token计费，一页的成本可能是一页纯文本的几十倍。我接触过一个做合同审查的团队，他们的合同全是扫描件，一开始按文本量估算成本，实际账单出来高了二十多倍，原因就在这里。
复合输入的计费还有一个隐藏变量：解析质量。同样一份PDF，不同厂商的解析器提取出来的内容量不一样。解析得细的，表格结构还原得完整，图片提取得到位，token用得多但信息全；解析得粗的，表格变成一堆乱码文本，token用得少但模型看不懂。这个权衡在选型时特别重要，不能光看单价，得看单位token能换来多少有效信息。我一般会拿几份有代表性的文档做解析质量对比，把解析结果和原始文档逐项核对，这比看价格表有用得多。
2.5 缓存、批处理与最低计费对输入成本的影响
缓存这个机制，用好了能省一大笔钱，用不好就是个摆设。原理很简单：同样的输入内容重复发送时，厂商可以把第一次处理的结果缓存起来，后续调用直接复用，只收很低的缓存读取费。问题在于什么算“同样”。文本的缓存命中相对容易判断，前缀相同就能命中。图像和音频的缓存命中就麻烦了，文件要做哈希比对，稍有改动就命不中。我见过一个团队做固定知识库的问答，每次调用都把同一份长文档作为上下文传进去，开了缓存之后这部分成本降了九成多。这个场景太适合缓存了，内容固定、调用频繁。
批处理的逻辑是用时间换钱。把多个请求攒成一批发过去，厂商在非高峰时段集中处理，单价能打个折扣。折扣力度各家不一样，我看到过五折的，也看到过八折的。批处理适合那些对实时性要求不高的场景，比如离线内容分析、批量文档处理。有个做舆情监测的客户，把夜间采集的新闻批量送进去做摘要，走批处理通道，成本比实时调用低了将近四成。这个策略的代价是延迟，从提交到拿到结果可能要等几分钟到几十分钟，能不能接受取决于业务。
最低计费这个条款，文档里通常写在不起眼的角落，但实际影响不小。很多厂商对单次调用设了一个最低计费单位，比如最少按一百个token收，哪怕你实际只用了十个。短请求密集的场景，这个条款会让实际单价远高于标价。我算过一个做短消息分类的案例，每条消息平均二十个token，按最低一百token计费，实际成本是标价的五倍。这种场景要么把请求攒起来批量发，要么选一家最低计费门槛低的厂商，光盯着单价看会掉坑里。
缓存和批处理可以叠加使用，效果更明显。固定不变的长上下文走缓存，变动部分走批处理，两条腿走路。我帮一个团队做过这样的配置，他们的场景是给每篇长文生成结构化摘要，模板部分走缓存，文章正文走批处理，综合成本比原始方案降了七成左右。这种优化不需要改代码架构，纯粹是调用策略的调整，投入产出比很高。我的经验是，做完成本测算之后，先别急着换厂商，把缓存和批处理这两个开关打开试试，很多时候省下来的钱比换一家厂商还多。
计费机制摸清楚之后，我以为比价就是个体力活，把各家单价拉个表一填就完事。真动手做了才发现，这张表根本填不平。文本、图像、音频、视频四类输入，各家用的计量单位不一样，分档逻辑不一样，长上下文的溢价曲线也不一样。我第一版对比表做出来，横着看竖着看都觉得不对劲，后来重新设计了对比框架，又拿真实数据跑了三遍，才算得出几个能站得住脚的结论。
这一章我把对比的过程和结果摊开来讲。价格数字会变，我调研时点的报价到你看的时候可能已经调过两轮了，所以我更想讲的是对比框架怎么搭、哪些变量会让结论翻转、综合场景下怎么算总账。数字部分给的是区间和量级，具体签约还得看各家官网和商务谈判，这点先说在前面。
3.1 主流厂商API输入价格对比框架
搭对比框架这件事，我踩过的最大坑是拿标价直接比。标价是厂商想让你看到的那一面，真正的成本藏在分档细则、最低计费、长上下文溢价这些角落里。我后来的做法是分三层来搭框架：第一层比标价，把各家公开的输入单价列出来；第二层比有效单价，按我实际业务的输入特征换算；第三层比账单口径，拿真实调用量跑一个月看实际扣费。三层比下来，排名经常和第一层完全不一样。
厂商分类也得先做。我把市面上的玩家分成三档：国际大厂、国内大厂、垂直专精型。国际大厂的定价普遍偏高，但多模态能力齐全，文档规范，账单明细清楚。国内大厂这两年价格战打得厉害，文本输入单价压到了国际厂商的几分之一甚至几十分之一，多模态部分也在快速跟进。垂直专精型的厂商往往在某一类模态上有价格优势，比如专做语音识别的、专做图像理解的，单看某一项可能最便宜，但组合场景下未必划算。这个分类的意义在于，你得先想清楚自己的业务是单模态为主还是多模态混合，再决定往哪个方向比。
口径统一是框架里最费劲的部分。文本按每百万token计价是通行做法，这个好统一。图像有的按张，有的按token，有的按像素面积折算，我得拿同一张测试图分别跑一遍各家API，看账单实际扣了多少，反推折算规则。音频有的按秒，有的按分钟，有的按转写后的字符数，也得实测。视频更麻烦，抽帧密度的默认值不一样，不设统一参数跑出来的数字完全没有可比性。我花了大概两周时间就干这一件事，把四类输入的统一测试集建起来，后面所有对比都基于这套测试集，结论才靠谱。
3.2 文本输入token单价与长上下文成本
文本单价的差距是所有模态里最悬殊的。我调研时的价格区间，国际头部厂商的主流模型输入单价大概在每百万token一到五美元这个范围，轻量版模型能压到零点几美元。国内厂商的主流模型输入单价普遍在每百万token几毛到几块钱人民币，部分厂商的轻量模型甚至低到几分钱。这个差距有汇率因素，更多是市场竞争策略不同。单看文本，国内厂商的性价比优势非常明显。
长上下文是文本计费里最容易被低估的变量。多数厂商对超过某个阈值的上下文做溢价，常见的是128k或者200k分界，超过之后单价翻倍甚至更高。我做过一个长文档问答的测算，单次输入十万token，用某国际厂商的标准档模型，成本大概是零点几美元一次。如果文档涨到三十万token，触发长上下文溢价档，单次成本可能翻两三倍。同样这个场景换国内厂商，绝对成本低很多，但溢价曲线的形状也得单独确认，不能想当然地认为便宜的地方长上下文也便宜。
还有一类隐性成本是文本计费里特有的：重试和冗余。文本生成任务里，调用失败重试、多轮对话里反复传历史上下文，这些都会推高实际输入量。我见过一个客服机器人项目，单轮对话的输入token是设计值的三倍多，查下来是历史消息没做裁剪，每轮都把完整对话历史传进去。这个问题的解法很直接，做滑动窗口或者摘要压缩，成本立刻降下来。文本这块的优化空间其实比图像音频大，因为文本输入的结构完全由你控制，裁剪、压缩、摘要都是成熟手段。
3.3 图像输入token计费价格对比
图像对比的难度比文本高一个量级，核心问题是计费单位不统一。我拿一张1024乘1024的标准测试图跑了一遍各家API，结果很有意思。有厂商按固定token数计，一张图折下来大概几百个token；有厂商按切片算，同样这张图切出上千个token；还有厂商按面积换算，短边和长边各有一个系数，算下来又是另一个数。折算成同一张图的成本，最贵的和最便宜的差了将近五倍。
分辨率分档的影响在图像这块体现得最明显。不少厂商对高清图单独定价，或者对超过某个像素阈值的图触发额外计费。我拿3000乘4000的扫描件测过，直接上传和压缩到1080p再上传，同一家厂商的成本差了四倍左右。这个变量的可控性很强，预处理做得好，图像成本能压下来一大截。我的建议是图像输入前统一加一道压缩工序，把长边缩到模型推荐尺寸，肉眼几乎看不出差别，账单差别很大。
多图输入的阶梯效应也值得提一句。单张图的成本好算，一次传十张、二十张图的成本不是简单相乘。有的厂商对多图请求有打包折扣，有的没有，有的按总token数走统一的阶梯价。我做过一个相册内容分析的场景测算，每次传二十张图，不同厂商的总成本差异比单图对比时还要大，原因就在于打包规则不一样。做图像密集型业务的团队，多图批量调用的计费规则一定要单独拉出来测，别拿单图单价去乘张数。
3.4 音频输入token计费价格对比
音频的计费单位比图像还乱。按分钟计价的、按秒计价的、按音频token折算的、按转写字符数计价的，四种玩法我都见过。要横向对比，第一步是把所有单位换算成每分钟成本。换算过程中采样率的变量会跳出来，同一段音频，16kHz单声道和44.1kHz立体声在按token计价的厂商那里，成本可能差好几倍。我在测试集里统一用16kHz单声道，尽量把变量控住。
换算完之后的价格分布挺分散的。国际厂商的原生音频输入，每分钟成本大概在几分美元这个量级。国内厂商的音频输入单价普遍更低，部分厂商能压到国际厂商的三分之一甚至更低。但是，转写路径的存在让这个对比变得复杂。很多业务实际走的是先转写再喂文本，转写服务的单价加上文本token的单价，合计起来可能比原生音频token便宜，也可能更贵，取决于音频质量和时长。我测过一段十分钟的清晰会议录音，转写路径的总成本比原生音频路径低三成左右，换成带背景音乐的音频，转写质量下降，原生音频反而更省心。
长音频的阶梯计费也得单独看。有的厂商对超过一定时长的音频按更高单价计费，有的对静音片段做扣除，有的对多声道音频按声道数乘算。我遇到过一个播客处理的案例，一小时节目里静音和片头片尾占了将近两成时长，按总时长计费的方案多付了这部分钱，换成按有效语音时长计费的方案，成本降了将近两成。音频这块的细节特别多，光看定价页根本看不出来，必须拿真实音频文件去跑账单。
3.5 综合场景下的输入成本对比结论
绕了一圈，回到最实际的问题：综合场景下到底该选谁。我的结论是没有通吃的赢家，答案取决于你的模态组合和调用特征。纯文本为主的场景，国内厂商的价格优势太明显，除非有特定的能力要求必须用国际大厂，否则从成本角度没什么好犹豫的。文本加图像的混合场景，要重点看图像折算规则和你自己的图像预处理能力，预处理做得好的团队，选按token计费的厂商更可控；预处理环节薄弱的团队，选按张计费的厂商账单更可预测。
音频密集型场景的判断逻辑又不一样。转写路径成熟、音频质量稳定的业务，选转写加文本的组合往往最便宜。音频里信息密度高、非语音成分多的业务，原生音频输入更合适，这时候要重点比原生音频的token折算规则。视频场景我建议先做业务精度反推，把抽帧密度定下来再比价，不然比出来的数字没有意义。
我拿一个典型的混合场景做过完整测算：一个客服系统，输入包含文本对话历史、用户上传的截图、偶尔的语音留言。按每月一百万次调用估算，不同厂商组合的总成本能差出三四倍。最便宜的组合不一定是单项最便宜的厂商拼起来的，因为跨厂商的工程成本和调用路由的复杂度也是成本。我的经验是，综合成本要算上集成和维护的隐性投入，两三家厂商差距在百分之二十以内的时候，选工程上最省事的那家，长期看更划算。
上一章横向比完，我脑子里一直有两个疙瘩没解开。一个是图像，同样的图传给不同厂商，账单能差出五倍，这五倍到底差在哪个环节。另一个是音频，按分钟、按秒、按token、按字符四种玩法混在一起，换算出来的数字我自己都不太敢信。横向对比解决的是"哪家贵哪家便宜"，解决不了"为什么贵、贵在哪一步"。这两个问题不拆开，选型就是拍脑袋。
这一章我把图像和音频单独拎出来做专题。做法很简单：拿真实文件、真实账单，把每一分钱花在哪里拆开看。拆完之后我发现，这两类输入的成本结构比文本复杂得多，定价页上那行单价顶多占全部成本的六成，剩下四成藏在预处理、格式转换和阶梯规则里。
4.1 图像输入：按张、按分辨率、按token的计费方案对比
图像计费的主流玩法我数出三种，每一种背后的商业逻辑不一样，适合的业务也不一样。
按张计费最直观，传一张图扣一笔钱或者固定折算若干token，跟图多大、多复杂没关系。这种方案对高清图特别友好，一张四千万像素的扫描件和一张缩略图一个价。账单完全可预测，财务做预算的时候最喜欢。对厂商来说，这是在赌平均图尺寸，用户传的都是小图它就赚，都是大图它就亏。
按分辨率分档是折中方案，短边小于某个值一个价，超过一档上调。我见过按像素面积阶梯的，也见过按长宽比判断的。这种方案的问题在边界上，一张图刚好卡在分档线上，稍微裁几个像素，价格就跳一档。我测过一组图，把长边从一千缩到九百九，同一家厂商的扣费降了将近四成。这种灵敏度用户基本感知不到，账单出来才发现。
按token计费是现在的主流方向，原理是把图切成小块，每块折算固定token数。折算规则各家不一样，patch尺寸有十四乘十四的，也有十六乘十六的，每patch给的token数也不一样。同一张1024的图，我实测下来，不同厂商折算出的token数从几百到上千都有。这个方案对预处理的要求最高，你的图尺寸控制得好，成本完全可控。控制不好，一张原图进去，token数翻几倍。
三种方案放一起比，谁便宜完全取决于你的图长什么样。我拿同一张标准测试图跑了一圈，最贵和最便宜差了将近五倍。换一张低分辨率的小图再跑，排名又变了。这就是为什么单看定价页做图像选型特别容易翻车。我的做法是拿自己业务里最有代表性的二十张图做成固定测试集，每季度跑一次账单，看实际扣费，而不是看标价。
4.2 音频输入：按秒、按分钟、按token的计费方案对比
音频这边的乱，比图像更胜一筹。
按分钟计费是传统语音服务的老玩法，一分钟多少钱，向上取整到分钟。三十一秒的语音按一分钟收，这个取整规则对短语音特别不友好。我算过一个语音留言的场景，平均每条语音二十二秒，按分钟向上取整等于每条都付了一分钟的钱，实际多付了将近一半。
按秒计费公平一些，但要看它怎么处理静音和尾部空白。有的厂商按文件总时长算，有的按检测到的有效语音时长算。这个差别在长录音上能放大到两成以上。
按token计费是跟着大模型起来的玩法，音频先被编码成token序列，token数跟采样率、声道数、编码格式强相关。我做过一组对照测试，同一段内容，16kHz单声道和44.1kHz立体声，按token计费的厂商那边成本差了三倍左右。这个倍数放在一小时的长音频上，就是真金白银。
按转写字符数计费本质上是把音频问题转成了文本问题。先做语音识别，再按识别出的字数收钱。这种方案的单价看起来往往最低，但你得把转写准确率考虑进去。嘈杂环境里识别出来的字可能比实际说的多，也可能漏字，账单和语义对不上。我测过一段带背景音的访谈，转写字符数比人工核对的实际字数多了将近一成五。
换算成统一的每分钟成本之后，价格分布挺散。国际厂商原生音频输入大概在每分钟几分美元这个量级，国内厂商能压到三分之一甚至更低。转写路径和原生音频路径谁便宜，前面章节说过，取决于音频质量，这里补一句：还取决于你的用途。如果你本来就要文本，转写路径一举两得；如果你要的是语调情绪这类非文本信息，转写路径等于先把信息扔了再花钱买回来。
4.3 多图与长音频输入的阶梯成本分析
单张图、单段音频的成本好算，批量场景下规则完全变了。
多图输入的阶梯效应我踩过坑。有厂商对一次请求里的多张图按总token走统一阶梯价，图越多单价越低。也有厂商每张图独立计价，传二十张就是单价的二十倍，一点折扣没有。还有厂商设了单次请求的图数上限，超过上限得分批请求，分批又带来额外的请求开销。我做过一个相册内容分析的测算，每次传二十张图，两家厂商的总成本差了一倍多，差的就是打包规则。
长音频的阶梯更隐蔽。超过某个时长门槛单价上调，这个门槛有设三十分钟的，有设一小时的。分段上传看起来能绕开门槛，实际上分段会带来重复的请求头和尾部静音，每段都有一点固定开销。我算过一条九十分钟的播客，整段上传触发了溢价档，切成三段上传反而便宜了将近两成，代价是工程上要多写一点拼接逻辑。
阶梯规则里还有一个容易忽略的点：并发和限流。长音频处理慢，批量任务排队，如果你的业务有时效要求，得用更高价位的加速档，这部分溢价在定价页上通常写得很小。
4.4 预处理器、转写与格式转换带来的隐性成本
这一节是我最想写的，因为这是账单上最不显眼、占比又最高的部分。
图像预处理器是个典型。很多厂商的API内置了缩放、裁剪、增强、去噪这些处理步骤，这些步骤有的单独计费，有的已经打包进token折算里，定价页上根本看不到单独一行。我拿一张手机直出的照片测过，关掉服务端的自动增强，同样的图token数少了将近两成。自动增强对识别效果有帮助，值不值这个钱，得按业务精度要求来算。
转写服务是另一层。走转写路径的业务，实际上付了两次钱：一次给语音识别，一次给文本token。很多团队做预算的时候只算了后者，前者漏掉了。我见过一个项目，预算按文本token做的，上线第一个月账单超了一倍，查下来是转写调用量没算进去。
格式转换的成本更隐形。音频的wav转mp3、m4a转opus，图像的heic转jpg、png转webp，这些转换如果放在客户端做，省的是API的钱，花的是客户端算力和开发工时。如果放在服务端做，有的厂商收转码费，有的不收但会限制支持的格式。我遇到过一家厂商只支持wav和mp3，业务里的m4a全得先转，转码服务单独买，这笔钱在选型对比表里压根没有这一栏。
还有失败重试。图像识别的失败率比文本高，网络抖动、格式不兼容、内容审核拦截，都会触发重传。音频长传超时更常见。重试一次的隐性成本就是双倍。我在一个票据识别项目里统计过，实际扣费比理论值高了将近三成，其中大部分是重试和格式不兼容导致的失败重传。
4.5 典型业务场景的图像音频输入成本测算
讲完机制，拿几个真实场景算账。
电商商品图审核，每天几万张，图源是手机拍的，分辨率参差。这个场景按token计费最可控，前提是上传前统一压缩到长边一千二左右。不压缩直接传，成本能差三四倍。按张计费的厂商在这个场景下反而没优势，因为平均图尺寸偏小，等于替大图用户分摊了成本。
票据和文档OCR，图源是扫描件，分辨率高，细节不能丢。这个场景压缩空间有限，压缩过头识别率掉得厉害。我的做法是分层处理，先传压缩版做初筛，初筛不确定的再传原图。这样平均成本能压下来四成左右，精度基本不受影响。按分辨率分档的厂商在这个场景要特别小心，扫描件的尺寸经常刚好卡在档位边界上。
语音客服，短语音留言，每条几秒到几十秒。这个场景按秒计费比按分钟友好得多，向上取整到分钟的方案在这里亏得最狠。转写路径和原生音频路径的取舍要看后续处理，如果只是要做意图分类，转写加文本完全够用，成本也低。
播客和会议转写，长音频，一小时起步。这个场景的关键是静音扣除和分段策略。我把一条一小时的节目做过完整测算，扣掉片头片尾和中间静音，有效语音只占八成出头。按有效语音计费的方案比按总时长计费的方案便宜了将近两成。分段上传配合并发处理，还能再省一点工程等待时间。
这几个场景算下来，我心里有个大概的判断框架：图源可控、预处理能力强的团队，优先选按token计费的方案，成本上限高但下限也低。图源杂乱、团队工程资源紧的，选按张计费求个账单稳定。音频短、批量大的，按秒计费最实在。音频长、后续要文本的，转写路径通常更经济。这些结论都有前提条件，换个业务参数可能就翻转，所以我更希望读者带走的是测算方法，而不是这几个具体结论。
前面四章把账本翻了底朝天，横向比了价，纵向拆了计费机制，图像和音频的专题也单独过了一遍。这一章我想换个角度，不讲"贵不贵"，讲"怎么省"和"怎么选"。
省钱的招数我试过不少，有些立竿见影，有些看着省实际亏。选型的坑更多，光看定价页做的决策，我踩过的不少于五次。这一章把我压箱底的那点经验掏出来，按可操作的程度从高到低排。
5.1 基于输入模态组合的成本优化策略
模态组合这件事，很多人默认"信息越全越好"，文本不够就加图，图不够再加音频。我一开始也这么想，直到有次做商品详情页的自动摘要，把商品图也塞进去，成本翻了四倍，摘要质量只提升了一点点。那次之后我养成一个习惯：每加一种模态，先做一轮AB测试，看效果提升能不能覆盖成本增幅。
纯文本够用的场景，硬加图像和音频是最大的浪费。我做客服意图识别的时候对比过，纯文本路径和"文本加语音原声"路径的准确率差不到三个点，成本差了将近五倍。那三个点确实存在，语音里的情绪信息有时候能帮上忙，但八成以上的工单根本不需要情绪判断。我的做法是分层路由，先用文本走一遍，置信度低的再升级到多模态。这样整体成本降了六成多，准确率基本没掉。
反过来也有场景是文本不够的。工业质检、医疗影像这类业务，图像是主力模态，文本只是辅助说明。这种场景别在文本上抠成本，把预算留给图像预处理和更高分辨率的输入，收益更大。模态组合的优化核心是找到那个"信息瓶颈"在哪，把预算花在瓶颈模态上，非瓶颈模态能砍就砍。
5.2 图像压缩、抽帧与音频分段对token成本的影响
图像压缩是最直接的省钱手段，但压缩参数怎么定有讲究。我做过一组对照实验，长边从两千压到一千二，token成本降了将近一半，识别准确率只掉了零点几个百分点。继续往下压到八百，成本又降了两成，准确率开始明显下滑。拐点在一千到一千二之间，具体位置看你业务的图像内容复杂度。票据、文档这类细节密集的图，拐点偏高；商品图、场景图这类轮廓为主的，拐点偏低。
我现在的做法是给每类图像建一个压缩档位表，上线前跑一轮标注数据验证，找到准确率掉到可接受下限的那个压缩比，就定在那里。工程上写个简单的压缩脚本，上传前自动处理，省下来的账单每个月能看见。
视频抽帧的逻辑类似，但参数更多。帧率抽多少、关键帧怎么选、要不要做场景切换检测，每一个都影响token量。我做过监控视频的分析，一秒一帧和两秒一帧的成本差一倍，事件检出率只差一个多点。后来我改成动态抽帧，画面变化大的时候加密，静止画面稀疏采样，整体成本压到了固定抽帧的三成左右。
音频分段的关键是静音检测。长录音里静音占比经常超过两成，有些会议录音能到四成。把静音段切掉再上传，token数直接少一截。分段长度也要试，太短了请求开销占比高，太长了单次处理慢、失败重传代价大。我试下来五到十分钟一段比较平衡，配合并发上传，工程上不算复杂。
5.3 缓存、批处理与调用路由的成本收益
缓存这块的收益被很多人低估了。多模态输入里有大量重复内容，电商场景同一张商品图可能被不同请求反复传，客服场景同一段语音留言模板反复出现。我把请求内容的哈希值做键，缓存命中的直接返回结果，不重复调用API。上线一个月，缓存命中率做到了三成多，这部分成本直接归零。
缓存的设计要注意粒度。按单张图缓存和按整个请求缓存，命中率差很多。我一开始按请求缓存，命中率只有一成出头，改成按图像和音频片段分别缓存，命中率翻了三倍。代价是要维护一个片段级的缓存索引，工程上多写百来行代码，值。
批处理是另一条路。很多厂商对批量请求给折扣，幅度从一成到三成不等。适合离线场景，比如夜间批量跑第二天的商品图审核。实时业务用不上批处理折扣，但可以用请求合并，把多个小请求打包成一个大批次提交，减少请求开销。我做过一个测算，请求合并能把固定开销摊薄四成左右。
调用路由是我最近半年才认真做的。同一件事不同厂商价格差好几倍，质量差不了太多。我按内容复杂度做路由，简单的图走便宜的小模型，复杂的走贵的大模型。路由规则写了几条：按图像分辨率、按文本长度、按业务类型。上线后整体成本降了三成多，返工率没涨。路由的维护成本在于规则要定期复核，业务变了规则得跟着调。
5.4 多模态大模型API选型决策清单
选型这件事我吃过亏，早期光比单价，上线后发现隐性成本一堆。后来我整理了一份自己的检查清单，每次选型照着过一遍，能避开大部分坑。
第一层看模态覆盖。你的业务需要哪几种输入，厂商是不是原生支持，还是要走预处理转换。原生支持的贵一点也值，转换环节的隐性成本和失败率经常把差价吃回去。第二层看计费粒度。按token、按张、按秒、按分钟，哪种跟你业务的输入特征最匹配。短音频别选按分钟取整的，高清图别选按张一刀切的。第三层看阶梯规则和上限。单次请求有没有图数上限、时长上限，超了怎么算，这些细则在定价页角落，但影响很大。
第四层看预处理能力。服务端有没有自动压缩、去噪、格式转换，这些功能收不收费，关掉之后token量差多少。第五层看缓存和批处理支持。有没有官方缓存机制，批处理折扣多少，接入复杂度如何。第六层看失败率和重试成本。这个只能实测，拿自己业务的真实文件跑一周，统计实际扣费和理论值的偏差。偏差超过两成的，要么是格式兼容问题，要么是内容审核拦截，都得提前摸清楚。
最后一层看锁定风险。多模态输入的格式标准化程度比文本低，换厂商的迁移成本不低。我倾向选支持标准格式（JPEG、PNG、WAV、MP3）的厂商，私有格式用多了，迁移的时候得重写预处理链路。这一条在选型表里经常排最后，但我见过迁移时被私有格式卡住的项目，代价远大于省下来的那点单价差。
5.5 成本对比结论与未来计费趋势
把五章的内容收一收，成本对比的核心结论其实不复杂。多模态输入的成本差异主要不在标价，在计费机制和预处理环节。同样一张图、同一段音频，走不同厂商的账单能差几倍，差的是token折算规则、预处理策略和阶梯设计。选型的时候拿自己业务的真实文件做测试集，比看任何对比表都靠谱。
未来计费趋势我看三个方向。一个是计费粒度越来越细，按token、按patch、按有效时长，粗放的一口价会越来越少。这对用户是好事，成本更可控，对选型的要求也更高，得看懂计费细则。另一个是缓存和批处理会成为标配，厂商之间的竞争从单价转向整体拥有成本，谁能帮用户把重复计算省掉，谁就有优势。
第三个方向是多模态打包计费的出现。现在文本、图像、音频分开计价，未来可能出现按"信息量"统一折算的计费方式，把不同模态折算到同一个计量单位上。这个趋势对用户来说意味着比价更简单，对厂商来说意味着定价权更强。我的建议是保持关注，别急着押注某一种计费模式，业务侧把预处理和路由做扎实，计费模式怎么变都能接得住。
说到底，成本优化的天花板不在厂商的定价页上，在你自己的工程能力上。预处理做得好、路由分得细、缓存命中率高，同样的API能跑出别人一半的账单。这部分能力是攒出来的，不是选出来的。
