租GPU还是调用API：算清推理成本临界点
通过GPU时租、API输入输出单价及流量比例，计算自托管推理的成本临界吞吐量，并进一步修正空闲时间的影响。提供32B模型量化部署示例和可代入实测数据的脚本。
原文暂未完整获取，基于公开信息的快读
租 GPU 跑大模型，什么时候比调用 API 便宜？dev.to 的一篇文章给出了成本临界点公式和可代入数据的 Python 脚本，并用 Qwen3 32B 量化部署举例。核心是把输入、输出比例和租用期间的空闲时间算进去：GPU 即使没有请求，也照样计费。
目前能确认什么
API 的输入与输出 token 通常分别定价，因此要先按实际流量比例，计算每个 token 的加权平均价格，再求临界点：
临界 token 数/小时 = GPU 时租 ÷ API 加权单 token 价格
这里统计的是输入与输出 token 的总量。若 GPU 只在租用时长的 40% 内处理请求，忙碌期间所需的平均吞吐量，还要在临界值基础上除以 0.4。
作者以单张 RTX 5090 32G 部署 Qwen3 32B 的 4-bit AWQ 版本为例。量化可以减少权重占用，但显存还要容纳保存上下文状态的 KV cache 和运行开销，不能只看模型文件大小。
文中的吞吐量是计算输入，不是这张卡的实测结果。
节选也明确说明，参与价格比较的 API 使用了其他模型，因此只能比较费用，不能据此认定效果相当。
我的判断
对请求零散、夜间流量少的应用，关键是整段租用时间里实际处理了多少 token。高峰期跑得快，未必能抵消长时间空闲的租金。
对已有稳定流量的团队，这个脚本可以帮助判断是否值得继续做部署验证。但需要测清自己的提示词长度、输出长度和并发组合：输入与输出的处理方式不同，总 token 数相同，实际吞吐也可能不同。
目前能算出成本门槛，还不能确认示例硬件能持续跨过门槛。
节选没有提供实测吞吐、完整价格表，也没有明确纳入运维等成本。模型质量是否满足业务要求、目标并发下延迟能否接受，仍需单独验证，公式无法代替这些结论。