“每百万Token成本”不是单纯查看模型标价，而是把一次请求涉及的输入、输出、缓存、算力和运维支出统一折算。若只比较单价，容易忽略长上下文、低并发闲置和输出过长造成的真实成本差异。核算前首先要明确口径：计算的是API调用成本、模型服务成本，还是包含设备与机房在内的全生命周期成本。
基础核算方法
如果输入Token和输出Token采用不同单价，可使用：
单次成本 = 输入Token数 × 输入单价 + 输出Token数 × 输出单价
再按业务样本统计平均值：
每百万Token成本 = 单位周期总成本 ÷ 同期有效处理Token数 × 1,000,000
这里的“有效处理Token”必须提前定义。若统计模型服务的处理能力，可把输入和输出Token分别记录，再合并为总处理量；若评估交付价值，也可以只把最终有效输出作为分母。两种口径都可以使用，但不能混用，否则不同方案之间的比较会失真。
对于自建推理服务，分子不能只填芯片采购价。更完整的模型应包括设备折旧、服务器与网络、存储、电力、机房、软件适配、运维人力以及故障和迁移成本。设备成本还应结合实际利用率计算：低峰期大量资源闲置时，理论吞吐越高，并不代表每百万Token成本越低。
不要忽略请求结构
输入与输出的比例会显著影响结果。长上下文会增加Prefill阶段的计算和显存压力，长输出则会持续占用Decode资源。多轮对话、检索增强、工具调用和模型串联，还可能让一次用户请求对应多次模型调用。因此，核算时应按真实业务统计短请求、长上下文、高并发和峰值流量，而不是只用一条理想测试样本。
缓存也要单独标注。Prompt缓存、KV Cache复用或结果缓存可能减少重复计算，但缓存占用的显存、存储和管理成本仍然存在。应同时记录“计费Token”“实际计算Token”和“有效业务Token”，避免把缓存命中后的低成本误判为所有请求都能达到的成本。
最终，采购决策应同时观察每百万Token成本、首Token延迟、每Token生成延迟、稳定并发、显存占用和故障恢复能力。通用GPU可能带来更高复用性，专用加速器则可能在稳定大规模推理中降低单位成本；真正可靠的结论，必须建立在统一口径和真实负载测试之上。