推理算力的按量账：一个小模型分类器一个月到底花多少钱

上云之后最容易算错的一笔账，是推理算力。训练费用是一次性的，看得见摸得着；推理是持续滴灌，账单藏在每天的调用量里。这篇用一个真实的小模型分类器，把这笔账摊开算给你看——结论可能和直觉相反：在中小调用量下，按量 API 比包月实例便宜一个数量级。

场景设定

一个工单自动分类器：输入工单文本，输出「网络/系统/应用/安全」四类。日均调用量 5000 次，单次输入约 400 token，输出约 50 token。模型用 7B 级开源小模型即可胜任——这是个典型的「不需要旗舰模型」的任务。

三种方案的月账

方案一：自购 GPU 实例。 7B 模型加并发，一张 4090 级别的卡是底线，云上包月约 3000~4000 元。利用率方面，5000 次/日的量对单卡是轻负载，实际利用率不到 15%——大部分时间这张卡在计费待机。

方案二：Serverless 推理平台。 按实例时长计费，冷启动 3~8 秒。日均 5000 次若保持常驻，月成本约 1200 元；若接受冷启动按需拉起，降到 600 元左右，但响应时间的毛刺对同步调用链路不友好。

方案三：按 token 计费的推理 API。 月调用量 15 万次，月输入 6000 万 token、输出 750 万 token，合计约 6750 万 token。按百万 token 两元的价位（算邻坊智能决策接口的公开价），月成本 135 元。

三种方案的差距：4000 : 600 : 135。这就是「推理算力错配」的代价——用为峰值准备的常驻算力，去服务一个均值负载很小的任务。

为什么按量能便宜这么多

直觉上「API 中间商要赚差价」，怎么反而便宜？答案在算力的池化复用。按量服务的底层是把大量用户的闲置算力池化调度：你的请求和别人的请求共享同一批 GPU，谁的请求来了给谁算，卡永远不空转。分摊到单个请求上的真实算力成本，远低于一张卡独占服务的成本。这也是为什么像算邻坊这类按量平台敢把价格压到百万 token 两元——不是补贴烧钱，是池化的算力利用率天然碾压独占模式。对用户来说，这套机制的体感就是一句话：不用不花钱，余额永不过期。

按量什么时候会输

把上面的量放大 50 倍：日均 25 万次调用，按量月成本 6750 元，超过了自购单卡。交叉点大致在日均 2~3 万次调用附近——过了这条线，自建或包月开始划算，而且量大之后你还有议价空间。

另一个输的场景是延迟敏感：按量 API 的网络往返加排队，P99 通常在秒级，如果业务要求 50ms 内返回，本地部署是唯一解。

一张决策卡

• 日均 < 2 万次：按量 API，成本数量级优势
• 日均 2 万~10 万次：两本账都算，看延迟要求
• 日均 > 10 万次：自建/包月，顺便谈折扣
• 需要 50ms 级响应：本地，别犹豫

写在最后

推理成本的直觉陷阱在于：我们习惯按「峰值需求」评估算力，却按「均值负载」真实使用。按量计费的价值正是砍掉这中间的错配——为均值付费，峰值交给平台的池子扛。

把算力账算到这个颗粒度之后，下一步自然是问「分类之后呢」：自动分类只是管线第一环，分类结果的置信度怎么用、低置信度怎么兜底，这些留到下篇。

（文中价格基于算邻坊智能决策接口公开牌价，按量计费。）