先说结论：先算单价，再算区间，最后才算自部署
大模型推理的成本决策，卡住很多团队的地方不是算不出来，而是算错了对象。最常见的错误是拿”API 每百万 token 的价格”直接和”显卡每小时的价格”对比——这两个数字不在同一个维度上，前者是产出单位，后者是投入单位，中间差着吞吐、并发率、利用率和运维成本四层折算。把它们直接相减，得出的结论通常会把团队带偏。
正确的顺序是三步：第一步，搞清楚 API 计价口径，知道自己每个月的 token 消耗对应多少钱；第二步，算清自部署的真实成本结构，把卡时、并发率与运维一起折算成”每百万 token 的等效成本”；第三步，再拿两个数字做区间对比，并叠加数据敏感性、定制需求、波动容忍度这些非价格因素。2026 年的公开报价里，DeepSeek 一类模型的 API 价格量级在每百万 token 输入 0.27 美元、输出 1.1 美元附近，而 GPT-4 级别的模型报价在每百万 token 5 到 15 美元的量级，两者相差一个数量级。这个差距本身不足以决定你要不要自部署，但它决定了你该从哪个方向开始算账。
一句话版本：低量级、需求波动大、不想养运维的团队，API 几乎总是更划算；高量级、数据敏感、有定制需求且负载平稳的团队，自部署才可能算得过账，而且通常要先做完量化与批处理优化才能算平。
API 计价口径：输入和输出不是一个价
读 API 价目表的第一件事，是分清输入 token 和输出 token。几乎所有主流厂商都对这两者分别定价，而且输出价格明显更高——常见倍率是输入的数倍。原因在于计算特性不同：输入阶段可以并行处理，显卡利用率高；输出阶段是自回归逐 token 生成，每一步都依赖上一步，显卡利用率天然偏低。所以输出贵不是定价策略，而是成本结构的直接反映。
第二件事是分清缓存命中与未命中。很多厂商对重复出现的上下文（比如固定的系统提示词、长文档前缀）提供缓存折扣，命中缓存的那部分输入价格可以低一个量级。如果你们的应用有稳定的长前缀——例如固定的角色设定、知识库前言、代码规范——把前缀设计成可缓存的形式，能直接砍掉一大部分输入成本，这是投入产出比最高的一项优化。
第三件事是注意阶梯计价与批量折扣。部分厂商对夜间时段、批量推理任务提供折扣，或者按月消耗量分档降价。这些条款不写在首页最显眼的位置，但对你实际的账单影响很大，尤其是消耗量已经上到一定规模之后。
| 计费维度 | 口径说明 | 对成本的影响 |
|---|---|---|
| 输入 token | 按每百万 token 计价，通常较低 | 长上下文、长提示词会快速放大 |
| 输出 token | 按每百万 token 计价，通常是输入的数倍 | 长回复、链式思考会显著放大 |
| 缓存命中 | 重复前缀命中缓存时折扣计价 | 可缓存前缀是降本首选 |
| 批量/错峰 | 批量任务或非高峰时段折扣 | 适合离线处理类负载 |
| 量级档位 | 月消耗达到档位后单价下移 | 需要主动与商务确认 |
把这几条合起来看，你会得到一个反直觉的结论：API 的”标价”往往是你能拿到的最高价。缓存、批量、错峰、档位四层折扣叠加上去，实际单价可能比标价低不少。所以在做 API 与自部署对比时，请用”你的实际混合单价”，而不是价目表首页那个数字。
自部署的成本结构：卡时只是一半
自部署的成本由三部分构成，很多人只算第一部分。
第一部分是卡时成本。这是最直观的一项：租几张卡、每小时多少钱、跑多少小时。国内 A100 40G 时租约 2.4-2.9 元，H100/H800 约 9.6-12 元，24G 的 4090 约 1.2-2.5 元。如果按推理场景算，多数 7B 到 13B 模型的部署落在 24G 卡上，成本相对可控。
第二部分是并发率与利用率折算。这是最容易被忽略、也最能改变结论的一层。你租了一张卡，但它的实际吞吐取决于模型大小、量化精度、批处理策略和你的请求模式。同样一张卡，做单请求低并发服务时可能每秒只产出几十个 token，开启连续批处理后吞吐可以提升数倍。也就是说，”每百万 token 的等效成本”不是一个固定值，它随着你的优化程度上下浮动几倍。跳过这一层直接拿卡价除以 token 数，结论必然失真。
第三部分是运维与人力。自部署意味着你要有人管服务健康、处理 OOM、升级推理框架、做灰度发布、应对流量高峰、处理故障。这部分成本在小团队里经常以”某个工程师一半的时间”的形式存在，很容易被记成零，但它真实存在。如果这个服务是核心业务，还要额外考虑高可用与多副本带来的冗余成本——为了保证可用性，你往往要付出比理论峰值需求更多的算力。
| 成本项 | 计入方式 | 常见漏算 |
|---|---|---|
| 卡时 | 卡型单价 × 运行小时 | 低负载时段的空转成本 |
| 并发折算 | 实际吞吐决定等效每百万 token 成本 | 用理论峰值而非实测吞吐 |
| 运维人力 | 服务维护、升级、故障处理的工时 | 常被记为 0 |
| 高可用冗余 | 为可用性多部署的副本 | 按峰值需求而非冗余需求算 |
| 存储与网络 | 模型存储、日志、出网带宽 | 大模型权重存储与拉取开销 |
优化四件套：原理比数字重要
自部署能不能算得过账，很大程度上取决于你做到了哪一层优化。下面四项是推理优化的核心手段，理解原理比记住任何具体数字都重要，因为具体收益高度依赖你的模型与负载特征。
一、量化：用精度换显存与速度
量化把模型权重从 FP16 压到 INT8 或 4-bit，权重体积相应减少到大约二分之一或四分之一。收益是双重的：一方面显存占用下降，同样的卡能装下更大的模型或更大的批；另一方面显存带宽的压力减轻，而推理常常受限于带宽而非算力，所以吞吐往往同步提升。代价是精度损失，通常量化在通用任务上损失可控，但在需要精确数值推理或长链推理的任务上更容易被察觉。评估量化必须用自己的任务集跑对比，不能只看论文数字。
二、KV cache 管理：长上下文的隐形开关
自回归生成时，每个已生成的 token 都要缓存注意力键值对，上下文越长、并发越高，KV cache 越大，长上下文场景下它甚至超过权重成为显存第一大户。对应的优化有几种：把 KV cache 量化到更低精度，几乎不损失质量就把上下文容量翻倍；使用分页式的显存管理减少碎片、提高复用；对超出必要范围的上下文做截断或摘要，从根本上减少需要缓存的长度。对以长文档问答为主的应用，这一项的收益往往超过其他所有优化。
三、批处理：把显卡喂饱
单请求推理的显卡利用率往往很低，因为每生成一个 token 都要把权重读一遍，而算力大部分时间在等带宽。批处理把多个请求合并成一批一起算，权重的读取开销被多个请求分摊，吞吐可以成倍提升。更进一步的连续批处理（continuous batching）允许请求在生成过程中动态加入和退出批次，避免了整批等待最慢那条的问题，是当前高吞吐推理服务的事实标准。这项优化不改模型、不改精度，纯粹靠调度提升效率，是性价比最高的一招。
四、投机解码：用小模型加速大模型
投机解码的思路是让一个小而快的模型先草拟若干个 token，再由大模型一次性并行验证。如果草稿被接受，就等于用一次大模型前向传播产出了多个 token；被拒绝的部分则回退重算。它的收益取决于草稿模型的命中率，在文本连贯、可预测性强的场景下加速明显，在高度随机或专业化的输出上收益有限。实现复杂度高于前三项，适合已经做完量化和批处理、还想继续压延迟的场景。
API 还是自部署：分流决策表
| 判断维度 | 倾向 API | 倾向自部署 |
|---|---|---|
| 调用量级 | 低到中等，月消耗有限 | 高量级且持续稳定 |
| 负载波动 | 波动大、有明显峰值 | 平稳可预测 |
| 数据敏感性 | 可接受数据出域 | 数据不可出域或合规要求严格 |
| 定制需求 | 通用能力足够 | 需要微调专属模型或私有知识注入 |
| 运维能力 | 没有专职人力的团队 | 有工程团队能承担服务维护 |
| 延迟要求 | 可接受公网往返与排队 | 需要极致延迟控制或本地部署 |
| 模型更新频率 | 希望自动跟上最新模型 | 模型版本需要自己锁定 |
这张表的使用方式是数数：如果大多数维度落在”倾向 API”一侧，就先踏实把 API 用好，把缓存和批量折扣吃满；只有当”高量级 + 平稳 + 数据敏感 + 有运维人力”这几条同时成立时，自部署的账才基本算得平。中间状态最常见的解法是混合架构：核心敏感链路自部署小模型，长尾与突发请求走 API，用同一个网关做路由。这样既保住了数据边界，也不用为峰值流量准备冗余算力。
常见问题
为什么输出 token 比输入 token 贵这么多？
因为两者的计算模式不同。输入阶段所有 token 可以并行处理，显卡能跑满；输出阶段是自回归逐 token 生成，每一步都依赖上一步的结果，显卡大部分时间在等显存带宽而不是算力，利用率天然偏低。成本结构差异直接反映在定价上，这不是厂商的定价策略问题。理解这一点，也能解释为什么”让模型少说废话”是真的能省钱的优化。
自部署一定比 API 便宜吗？
不一定，而且在小量级场景下通常更贵。自部署的固定成本——卡时、运维、冗余——不管你用不用都要付，只有把调用量堆到足够高，这些固定成本才能被摊薄到低于 API 单价。经验上，只有当负载持续稳定、量级足够大、并且你已经做完量化和批处理优化之后，自部署才可能算得过账。反过来，如果你的负载有明显波峰波谷，API 的按量付费反而是更优的财务结构。
缓存命中能省多少？
取决于你的提示词里有多少是重复的。如果应用有固定的长系统提示词、固定的知识库前言或固定的输出格式说明，这部分重复前缀命中缓存后，输入价格可以低一个量级。做这件事的方法很直接：把提示词中固定不变的部分放在最前面，把变化的部分放在后面，让缓存机制能够命中。这是改造成本最低、见效最快的一项优化。
量化会不会影响业务效果？
会有影响，但通常可控，关键是要验证。通用对话、检索问答、摘要类任务对量化的容忍度较高；精确数值计算、复杂代码生成、多步推理类任务更敏感。建议的做法是先在自己的真实任务集上对比量化前后的关键指标，如果差距在可接受范围内再上线，同时保留一个高精度版本的降级开关。
混合架构会不会很复杂？
复杂度主要在于路由与一致性。你需要一个统一网关把请求分发给自部署集群或 API，还要保证两条链路的输出风格、格式与错误处理保持一致。好处是灵活性极高：既保住了敏感数据不出域，又不用为峰值流量准备冗余算力，而且可以在 API 与自部署之间持续对比成本与效果，动态调整分流比例。对大多数有工程能力的团队，这是长期最优的结构。
避坑清单
- 拿卡价直接除以 token 数。缺少并发率与利用率折算是自部署成本误判的头号原因，实测吞吐才是分母。
- 忽略运维人力。服务健康、框架升级、故障处理都是真实成本，不记入就会高估自部署的收益。
- 用理论峰值吞吐做规划。生产环境的实际吞吐远低于压测峰值，按峰值规划会导致长期空转浪费。
- 不做缓存与批量优化就用 API。标价不是你的实际价，四层折扣不主动吃满等于白付钱。
- 为峰值流量自建全部容量。波峰波谷明显的负载应该用混合架构或弹性租用，而不是把冗余成本长期背在身上。
- 只比价格不比效果。推理成本的分母是有效产出，质量下降带来的返工与重试会悄悄推高真实成本。
按画像给建议
- 个人开发者与小团队：直接用 API，把精力放在提示词缓存设计和输出长度控制上。这两项优化不需要任何基础设施投入，见效却最直接。只有当某个模型的调用量稳定到成为固定大额支出时，才值得评估租卡自部署。
- 有工程能力的初创团队：按负载特征分流。把稳定的核心链路放到自部署集群（优先用 24G 卡的 7B 到 13B 模型，单卡成本可控），把长尾与突发请求交给 API，用统一网关管理。同步建设量化与批处理能力，这两项的收益最快兑现。
- 企业与受合规约束的团队：数据边界先行，能用自部署解决的场景尽量自部署，优先评估国产算力方案以满足信创要求。在做经济性评估时，把所有成本项——卡时、并发折算、运维、冗余、存储与网络——完整列出再对比，避免被”看起来更便宜”的单价误导。
回到方法论：推理成本这道题的分母永远是”有效产出”，而不是”服务器数量”或”卡时数”。无论你选择 API 还是自部署，把输入输出口径、缓存与批量折扣、量化与批处理优化这几件事做实，成本曲线自然就会向下走。所有价格请以厂商官方渠道披露的实时价目为准，本文引用的区间仅用于建立量级感；涉及 GPU 平台与云服务的选型，可参考 阿里云 等官方文档中关于实例规格与计费的说明。
Leave a Reply