开放模型能否省钱，要结合处理量、硬件使用率、模型规模和运维投入判断。自建虽然不按 token 向原厂付费，却仍有运行成本；调用规模小时，API 也可能更经济。适合比较的是每个业务合格结果的全部成本。

把账分成固定和变动两部分

API 主要按输入、输出、缓存和工具等项目计费，还可能有最低消费或套餐。自建主要承担机器或租赁、存储、网络和人力，但容量扩张、备用节点、故障处理和持续评测也会增加费用。两边都需业务集成，不应只给自建计入工程成本。

一个简单的预算例子

假设某项 API 输入每百万 token 2 元，输出每百万 token 8 元；每月一亿输入、两千万输出，模型费用为 200 加 160，共 360 元。这只是演算价格，不对应某家厂商的现行报价。若自建总固定费用每月 6000 元，小规模时很难仅靠节省 token 费用覆盖投入。

若相同结构的业务量扩大二十倍，示例 API 费用变为 7200 元，自建才开始有比较价值。但前提是那套机器确实能在响应时间要求内处理二十倍负载，且质量达标。不能假设硬件费用固定，吞吐却可无限增加。

显存够装权重，还不够

运行还需上下文缓存、计算过程和服务开销。并发用户增加、输入变长，显存需求会变化；为保证低延迟，实际利用率也可能无法始终跑满。把模型文件大小当成整套部署需求，容易低估机器数量。

量化能够减少资源占用，但需重新检查准确性、格式稳定性和特殊任务表现。MoE 模型每步激活参数较少，也并不意味着只需加载激活部分对应的容量。部署方式不同，内存、网络和多设备通信成本都会不同。

便宜的模型可能产生更贵的结果

若低价模型经常重试、生成更长内容或需人工返工，单次价格优势可能被抵消。比较时用同一批任务，统计最终被业务接受的结果数量，将运行、复核与失败处理一起计入。

同样，缓存和批处理也能改善 API 经济性。不能拿未使用折扣的接口，与自建满负载的理想状态比较。对流量波动明显的企业，托管开放模型或混合部署可能比两种极端方案更合适。

什么时候值得启动自建？

业务稳定、长期调用量高、团队具备运维能力，或有明确的数据与版本控制需求时，可开展容量验证。先用真实负载测吞吐和延迟，再核算备用容量与人力。成本优势应建立在可交付的服务上，而不是一张理论硬件清单。