Novita 最近更新了其 LLM 定价。对于通过该平台运行生产级推理的团队来说，这句话应该立即触发对当前支出的审计。API 费率的变化很少会在合适的时机出现，而且当它们涉及多个模型层级时，对每月消耗的影响可能比预期的更为剧烈。

为什么推理定价值得你关注

大多数现代 AI 应用并非构建在自管 GPU 集群之上。开发者将请求路由到像 Novita 这样的推理提供商，是因为另一种选择涉及获取硬件、管理 vLLM 或 TGI 部署，以及处理流量高峰期间的冷启动。这种便利性是有价值的，但也是按量计费的。生成的每一个 token 都会增加账单金额，并在用户会话、后台作业和内部工具中不断累积。

当提供商调整定价时，其影响会层层传递到你的技术栈中。一个每天处理一万次客户对话的聊天机器人，一周可能会消耗四千万个输入 token 和一千两百万个输出 token。即使每百万 token 的费率仅变动几美元，每月的差额也会迅速变得显著。对于自筹资金（bootstrapped）的产品或利润微薄的团队来说，这种差额可能会抹去盈利能力。无论是作为浏览器扩展运行的代码助手、在夜间处理的批量摘要流水线，还是在每次页面加载时查询模型的内部查找工具，都面临着同样的脆弱性。它们的单位经济效益取决于下一个 token 的确切价格。

Novita 发生了哪些变化

Novita 推出了影响其目录中不同模型的新成本。该公司并没有进行统一的百分比涨价或降价，而是根据模型进行调整，这意味着你的账单将取决于你具体调用的端点（endpoints）。

如果你的应用将所有流量都路由到单个大语言模型，那么计算就很简单：比较新旧费率，预测损失或节省。但大多数生产环境的配置要复杂得多。团队通常会维护路由逻辑，将简单查询发送给轻量级模型，而将重量级模型留给复杂的推理任务。还有一些团队会在多个模型之间进行 A/B 测试，以比较延迟和质量。在这些场景下，仅仅一两个模型的调价就可能扭曲你的整个成本结构。

Narevbot 在 Dev.to 上发布了一份详细的明细，列出了具体的每 token 和每请求费用。你可以在这里查看确切的费率表： https://dev.to/narevbot/changes-to-llm-pricing-novita-3plc

不要依赖记忆或埋藏在文档中的旧截图。在进行下一季度的预算建模之前，请直接从该来源获取最新数据。

如何审计你的风险敞口

从数据开始，而不是假设。登录你的 Novita 控制面板，导出过去两到三个月的用量历史记录。按模型和操作类型对数据进行细分。你需要知道哪些端点消耗了大部分预算，以及哪些端点在每次请求中生成的 token 最多。

寻找以下模式：

  • 集中度风险。 如果你 70% 的支出都流向一个模型，而该模型涨价了，那么紧迫性显而易见。如果你的支出分散在八个模型中，而其中三个发生了变动，虽然计算起来更费时，但风险依然真实存在。
  • Token 膨胀。 检查你的提示词（prompts）是否因不必要的上下文而变得臃肿。冗长的系统提示词、重复的 few-shot 示例以及繁琐的 XML 格式都会增加输入成本。定价更新是“瘦身”的绝佳借口。
  • 输出效率低下。 如果你的应用请求了长文本补全，但只使用了前几句话，那么你就在为丢弃的 token 付费。请调整你的 max_token 限制和停止序列（stop sequences）。
  • 闲置的后台作业。 生成报告或嵌入文档的定时任务运行频率可能高于实际需求。请核实 cron 调度计划和批处理大小。