机房与电力
核算机柜可用功率、配电冗余与制冷能力，确认承重与布线条件。高功耗机型常需单独回路，改造涉及审批与施工，应在采购前完成评估；否则设备到货后只能降功耗运行，吞吐达不到设计值，验收也无法通过。
网络与存储
模型加载与请求传输依赖内网带宽，本地盘或共享存储的读写速度影响启动与缓存命中。忽略存储，会出现模型加载慢、缓存频繁失效的问题，表现为延迟忽高忽低；排查时又容易误判为模型本身的问题。
运维能力
需要有人负责驱动与固件版本、卡故障排查、调度配置与容量规划。能力不足时可购买带运维的服务，但要明确响应时限与责任边界，否则故障时只能等厂商排期，业务侧无法给出恢复预期，责任边界要写进合同。
框架适配
推理框架对模型结构、量化方式与并行策略的支持程度决定能否跑起来。上线前应在目标环境完成适配与压测，不能等交付后再试；适配失败往往意味着换模型或换硬件，代价远高于前期验证，适配结论要留档。
监控与备件
需要 GPU 温度、功耗、显存、ECC 错误等指标采集，以及备件与维保安排。缺少备件时，单卡故障可能带来较长停机，尤其在供货周期不确定的时期；备件策略应与业务可接受的停机时间匹配，备件清单要与机型版本对应。
适用与不适用
适合谁
- 计划自建推理集群、能协调设施部门的企业
- 已有 GPU 但利用率与稳定性不佳的团队
- 需要评估机房改造范围与周期的 IT 负责人
不适合谁
- 没有机房条件、也不考虑托管的团队，也难以支撑长期运行。
- 用量小、按量实例即可满足的项目，也难以支撑运行。
典型场景
某高校实验室采购了推理服务器用于科研辅助，上架时发现机柜供电不足，只能降功耗运行，吞吐低于预期。后续通过调整配电与增加制冷，并补充显存与温度监控采集，才恢复正常。项目组把机房评估前置写入了下一次采购流程，避免同类问题重演。
可执行步骤
- 核算机柜功率、配电与制冷余量，确认承重与布线是否满足，确认余量是否满足目标机型
- 评估内网带宽与存储读写能力，用实际模型做一次加载测试，记录加载耗时与缓存命中情况
- 明确运维责任人与响应机制，写清值班安排与升级路径，落实到具体岗位
- 在目标环境完成框架适配与压测，记录版本与参数配置，形成适配说明供上线参考
- 落实监控采集、备件与维保，约定故障响应时限与备件范围，写入合同作为验收依据
常见坑
- 先采购后评估机房，设备到货无法满负荷运行，降功耗又影响业务体验。验收难以通过，返工又要重新排期。
- 忽略存储带宽，模型加载与缓存效率低下，延迟波动被误判为模型问题。排查方向一开始就错了，排查周期被拉长。
- 没有明确运维责任人，故障时相互推诿，恢复时间被无限拉长。业务方失去耐心，后续推广也会受阻。
- 备件与维保未落实，单卡故障导致长时间停机，业务连续性难以保障，损失也更难以向管理层交代。
- 框架适配留到交付后，发现不支持目标量化方式，只能换模型或换卡。上线时间被迫推迟，预算也要追加。
自检与验收清单
- 机柜功率与制冷余量是否核算并留档，是否形成书面结论
- 内网带宽与存储性能是否完成评估，是否留存记录
- 运维责任人与响应时限是否明确到岗，是否写入运维手册
- 框架适配与压测是否在目标环境完成，是否记录版本
- 备件与维保条款是否落实，响应时限是否明确，责任是否到人
常见问题
可以先小规模再扩容吗？
建议如此。先用少量设备验证框架、监控与运维流程，跑通后再按容量规划扩容。小规模阶段暴露的问题，修复成本远低于集群上线后，也便于分批申请预算并说明投入节奏。
机房改造要找谁评估？
通常由客户方设施或 IT 部门牵头，联合供配电与制冷服务商评估。我们可提供设备功耗与散热参数，但不替代机房安全与电气合规判定，最终结论应由客户方签认，我们不代签任何合规文件。
备件需要常备吗？
关键业务建议常备至少一套可替换部件，或选择承诺响应时限的维保服务。备件策略应与业务可接受的停机时间匹配，也要考虑供货周期的不确定性，不能只按价格决定。