用训练思路买推理
训练看重算力与卡间互联，推理更看重显存容量、带宽与能效。按训练卡的思路配置，可能出现算力富余但显存吃紧、解码速度不理想的情况，模型加载与长上下文都会受限，最后只能缩短输入。这类返工通常在压测阶段才暴露。
按峰值一次性买满
峰值只占全年少部分时间，为它付全价会让单位成本高企。更稳的做法是基线自购、峰值为按量或专属补充，用调度把两类资源统一管理，既保住峰值体验，也避免全年为闲置容量付费，容量一旦买定，后续调整空间很小。
忽略机房改造
高功耗机型的配电、制冷与承重常需改造，周期以月计。设备先到、机房未就绪的情况并不少见，项目进度因此整体后延，预算也被动追加，采购合同里的交付节点跟着失效。采购节点与上架计划都会被打乱。
轻视互联与存储
多卡并行与模型加载都依赖互联和本地盘带宽。只算卡数不看互联拓扑与存储性能，实际吞吐可能远低于预期，扩容时加卡也提不了速，排查往往要花上数周时间，扩容方案也要重做，容量规划也要同步调整。
不做真实负载测试
用标准基准跑分代替业务测试，长短请求比例、上下文长度与并发模式都与真实场景不同。没有实测数据，容量规划只能靠猜，上线后要么频繁超时，要么长期闲置，两种结果都难以向管理层解释，因此测试必须贴近真实请求分布。
适用与不适用
适合谁
- 正在做推理服务器选型的技术团队
- 集群上线后吞吐不达预期的运维负责人
- 要向评审说明配置合理性的架构师
不适合谁
- 用量很小、直接用云上实例的项目，也拿不出可用的测试结论。
- 没有模型与负载信息、无法测试的团队
典型场景
某制造企业按训练经验采购了高算力机型，上线后发现长文档场景显存不足，只能缩短上下文，回答质量受影响。团队重新按显存与带宽评估，调整为显存更大的配置，并把部分离线任务迁到原有设备，才让整体吞吐与体验回到预期，采购流程也补上了实测环节。
可执行步骤
- 明确推理任务的长短请求比例、上下文长度与并发要求，写成测试说明，并注明测试数据来源
- 按显存需求反推配置，再核对带宽与互联是否匹配并行策略，最后由架构师签字确认
- 用真实请求在候选机型上实测加载、吞吐与延迟分布，记录原始输出与延迟分布
- 评估机房改造范围与周期，把改造排进整体交付计划，并预留审批与施工时间
- 设计基线自购加峰值补充的组合，写明扩容触发条件与责任人，纳入预算评审
常见坑
- 只对比算力参数，忽略显存与带宽，长上下文直接不可用，只能靠截断输入勉强上线。体验明显受损。
- 未评估机房改造，设备到位却无法上架运行，租金与折旧同时在发生，项目却停摆，工期也随之延后。
- 忽略互联拓扑，多卡并行效率低下，加卡不提速，容量规划与预算都要重做，扩容前缺少验证，只能边跑边改。
- 用基准跑分替代业务测试，容量规划失真，上线后不是频繁超时就是长期闲置，两类问题都会直接反映在投诉上。
- 采购合同只写型号不写验收标准，性能不达标时缺少依据，沟通成本与返工成本都很高，验收条款缺失时性能争议很难有结论。
自检与验收清单
- 是否按显存与带宽反推配置，而不是只看算力数字
- 是否用真实请求分布完成实测并留档，并保留测试记录
- 机房改造范围与周期是否确认，是否已排入计划
- 峰值是否有按量补充方案与触发条件，触发条件是否写明
- 互联与存储带宽是否满足并行需求，扩容收益是否测算
常见问题
基准跑分还有参考价值吗？
可用于横向初筛，但不能直接换算成业务吞吐。业务请求的长短比例、上下文长度与并发模型差异很大，最终仍需用自己的负载实测，否则容易被理想条件误导，测试资源也容易浪费在无关指标上。
一张卡能跑多大模型？
取决于模型参数量、量化精度、上下文长度与并发数，没有固定答案。做法是先估算权重占用与缓存需求，再留出余量，用目标模型在实际机型上实测确认，配置最终由双方书面确认。
机房改造一般要多久？
视配电容量、制冷方式与审批流程而定，差异较大。建议在采购决策阶段同步启动评估，把改造周期纳入整体计划，避免设备到货后长期等待，也避免与上架计划冲突，减少后期返工。