GPU 算力

这个类别解决什么问题

提供运行自有模型或微调任务所需的并行算力。

什么时候需要

只有当模型 API 无法满足你的成本、延迟、数据或定制需求时才需要。多数 AI 产品在早期并不需要这一层。

选择时看哪些指标

这些是评估这类服务时通用的判断维度，不针对任何具体厂商。

• GPU 型号是否匹配你的任务类型
• 按秒还是按小时计费，空闲时是否仍然收费
• 冷启动时间
• 存储与模型加载方式
• 从零到可用的工程复杂度

中国开发者特别需要考虑什么

自托管意味着你要自己处理容量规划、排队与故障恢复。在评估「自托管更便宜」之前，先把工程人力算进去。

这一层的成本结构

GPU 算力的支出有三块：算力时长、存储，以及冷启动和镜像拉取带来的额外时长。算力按秒或按小时计费；存储按容量乘以时间计费，模型权重和数据集通常在你不用 GPU 时也继续收钱，这一项最容易被忘掉。无服务器形态把闲置成本换成了冷启动成本：请求稀疏时便宜，但每次冷启动可能要几秒到几十秒。自建长期实例则相反，是彻底的固定成本，开不开都在付。计费粒度与起停规则以官方页面为准。

常见误区

• 拿 API 单价乘以用量，直接对比自托管。漏掉了工程人力、存储、冷启动浪费和可靠性投入。正确算法是：自托管的月总成本加上你投入的小时数，除以实际处理的请求量，得到单次成本，再和 API 比。
• 把训练或微调和在线推理放在同一套资源上。训练占满卡，线上请求排队超时，用户看到的是你的产品挂了。分开环境，推理留可预测的容量，训练用可中断的按需实例。
• 没有并发上限和队列。突发流量把并发打满，请求互相拖慢，费用还是照时长付。做法是设并发上限，把超出的请求排队，并给用户一个可见的等待提示，而不是让它静默超时。

从零开始的上手顺序

1. 先回答「为什么 API 不够」，把理由落到成本、延迟、数据、定制四项之一并写下来。如果答案只是感觉便宜，先把用量数据跑出来。
2. 选一个最小任务，比如用开源模型跑一次推理，在按需实例上确认环境和显存占用，暂时不要碰训练。
3. 把模型权重放在独立存储上，让实例可以随时销毁重建。别往实例本地盘放不可复现的数据，否则这台机器就再也不敢关。
4. 用脚本固化启动流程：拉镜像、加载模型、健康检查、暴露端口。跑通之后你才有可测量的冷启动时间，而不是靠感觉估计。
5. 先只放一个真实用户或一小部分流量进来，记录单次成本、错误率和冷启动分布，再决定要不要换成长期实例。

在不同业务模式中的作用

常见问题