数据能否出域
涉及敏感数据的推理必须留在本地或专属环境，这一条通常直接决定形态，其余讨论都以此为前提。若业务允许脱敏后出域，云上按量实例可作为起步选择，但脱敏规则要由业务与安全共同确认，技术方不能单方判断，也不能用抽样代替全量核查。
负载是否平稳
全年利用率高的场景，自购的边际成本更低；波动大或存在明显峰谷时，按量实例能避免为闲置付费。用近半年利用率曲线判断，而不是按峰值配置，否则设备大部分时间在等任务，折旧却照常计提，账面数据很难看。
机房与交付
自购需要机柜、配电、制冷与网络，交付周期还受供货影响。机房条件不足时，托管或云上专属更现实；改造周期往往长于设备采购，审批与施工还可能跨部门，必须提前排进整体计划，否则设备到货只能长期堆放。
谁来运维
驱动、固件、调度与故障处置都需要专职或明确兼职人员。缺少这类能力时，选择带运维服务的形态，比自己招人更快，但要在合同里写清响应时限与责任边界，避免故障时双方互相等待，也避免把问题都推给供应商。
组合而非二选一
常见做法是本地承担稳定主业、云上承接峰值与试验，用统一调度与镜像管理降低两套环境的差异。组合的代价是复杂度，需要明确的责任分工与变更流程，否则两侧配置会逐渐分叉，排障时间成倍增加。
适用与不适用
适合谁
- 有本地机房、正在考虑自购推理设备的企业
- 负载波动大、犹豫是否包年包月的技术团队
- 需要在数据合规与成本之间取平衡的负责人
不适合谁
- 没有机房条件、也不接受托管服务的团队
- 负载极低、按量实例即可满足的项目
典型场景
某医院信息中心要部署病历质控辅助，数据不能出内网。团队先评估机房配电余量，确认可支撑两台整机；再用近半年门诊量曲线判断峰值集中在上午，决定本地部署两台，同时保留云上专属通道用于科研试验，两侧镜像与监控统一管理，按月核对使用情况。
可执行步骤
- 明确数据边界，列出不可出内网的业务场景，请安全部门书面确认后归档，形成一页清单
- 取近半年利用率数据判断峰谷特征，标出峰值出现的时间段与持续时长，作为容量判断依据
- 评估机房供电、制冷、承重与网络条件，估算改造范围、周期与审批链路，明确责任人
- 确定运维责任人与响应机制，写清值班安排、升级路径与故障处置时限，落到岗位
- 对候选形态做小规模试用，用真实请求验证吞吐与稳定性，再签采购合同与维保条款
常见坑
- 按峰值一次性采购，全年大部分时间算力闲置，单位任务成本远高于按量方案。更稳的做法是基线自购、峰值补充。
- 忽略机房改造成本与周期，设备到货后长期堆放，项目进度整体后延，预算也被动追加，最终压缩的是业务验证时间。
- 采购时未约定维保与备件，故障后等待周期不可控，关键业务只能降级运行，客户侧感知明显，恢复时间也无法承诺。
- 本地与云上两套环境各自演进，镜像与配置逐渐分叉，同一问题在两处表现不同，排障成本翻倍，版本回滚也更复杂。
自检与验收清单
- 数据边界是否明确，并形成书面结论与系统清单
- 是否用历史利用率而非峰值做容量判断，依据是否留档
- 机房供电与制冷条件是否完成实地评估，结论由谁签字
- 运维责任人与响应时限是否落实到具体岗位，并签字
- 维保条款与备件安排是否写入合同并约定响应时限
常见问题
自购和租用哪个更合适？
看利用率与使用周期。长期稳定高负载，自购的单位成本通常更低；短期项目或波动大，租用更灵活。决策时应把机房、电力与人力一并计入，而不是只比设备价格，否则容易低估自建的真实投入。
云上 GPU 实例能满足合规要求吗？
要看数据分级与云平台的安全评估情况。部分行业要求数据留在本地或通过特定评估，需由安全与法务确认，技术方案不能替代合规结论，也不能仅凭供应商的资质说明就下判断。
边缘部署适合什么场景？
适合低延迟、数据不宜回传、单点算力需求不大的场景，例如现场质检与门禁识别。模型规模受限，复杂任务仍需回中心处理，边缘与中心的分工要提前设计好，避免两类任务互相挤占资源。