显存容量与带宽
容量决定能装下多大的模型与多长的上下文缓存，带宽决定解码速度。参数规模相同的模型，量化后占用差别明显；只报卡数不看单卡显存，往往在加载阶段就失败，更谈不上稳定服务与容量规划。
精度与算子支持
推理常用半精度与低比特量化，需要确认目标框架对相应精度和算子的支持程度。标称算力若缺少对应算子，实际吞吐会大幅低于预期，选型时应以框架实测为准，而不是只看参数表与厂商标称值。
真实吞吐与延迟
关注每秒生成 token 数、首字延迟与并发下的 P95。厂商标称的多为理想批处理场景，实际业务长短请求混合，必须在自己的请求分布下测；否则上线后延迟与容量都会与预期不符，扩容也找不到依据，因此压测必须用真实样本。
互联与扩展能力
单机多卡看卡间互联带宽，多机扩展看网络与拓扑。张量并行对互联敏感，互联不足会让增加卡数带来的收益迅速衰减；规划扩容时要把这一层算进去，而不是只算卡数，否则加卡未必提速，扩容前先做小规模验证。
机房与能效条件
整机功耗、散热方式、机架承重与供电冗余决定能不能落地。高功耗机型常需改造配电与制冷，这部分投入与周期容易被漏算；评估时应与设施部门一起核算，而不是只看设备参数与报价。不能只看参数表。
适用与不适用
适合谁
- 准备采购推理服务器、需要对比方案的企业
- 自建推理服务、遇到吞吐瓶颈的团队
- 要给采购评审提供技术依据的架构师
不适合谁
- 只做小规模试点、用云上按量实例即可的项目
- 尚无明确模型与负载、无法实测的团队
典型场景
某设计院要为本地方案审阅部署推理服务，初选两款整机。团队用同一模型与同一批长文档做对比，发现其中一款在多并发下首字延迟明显偏高，进一步排查是卡间互联带宽不足。最终按实测结果调整配置，避免上线后返工。
可执行步骤
- 确定目标模型、量化方式与上下文长度，写成测试说明并冻结版本号，并留存说明
- 用真实请求分布构造测试集，含长短混合与高峰并发，并覆盖边界情况，含异常输入
- 在候选机型上测加载、吞吐与 P95 延迟，记录原始数据并保存测试日志，作为基线
- 核对框架对精度与算子的支持情况，做一次端到端验证并记录异常，记录异常项
- 评估机房供电、制冷与承重条件，形成改造清单并明确责任部门与周期，并留存记录
常见坑
- 只看标称算力，忽略显存带宽，解码速度达不到预期，长上下文直接不可用，结论需要重做，采购前很难发现。
- 用短请求压测，长上下文场景下显存与延迟双双吃紧，容量规划失真。上线后频繁超时。用户体验明显下降。
- 忽略机房配电与散热改造，设备到货后无法上架，项目整体延后，折旧却已开始计提，预算只能追加。
- 未核对推理框架的算子支持，量化后精度或速度不达预期，只能临时换型，预算被动追加，测试才能发现。
自检与验收清单
- 单卡显存与带宽是否满足目标模型，是否留有余量
- 是否在自有模型与真实分布下实测吞吐，数据是否留档
- 互联拓扑是否匹配并行策略，扩展是否还有收益
- 机房供电与制冷是否完成评估，改造是否排期，是否明确周期
- 推理框架的精度支持是否验证，是否有替代方案
常见问题
显存越大越好吗？
在预算与功耗允许时，大显存能支持更长上下文与更大模型，但也要看带宽与算力是否匹配。显存大而带宽低的配置，解码速度未必理想，选型时应以实测吞吐为准，而不是只看容量数字。
消费级卡能做企业推理吗？
小规模、低并发、非关键场景可以尝试，但要注意显存、散热、驱动稳定性与维保。对外服务或长稳运行场景，建议选择有服务保障的机型，否则一次故障就可能影响业务，恢复时间也不可控。
需要为峰值预留多少余量？
取决于业务对延迟的容忍度与扩容速度，常见做法是保留一定水位并配合限流。具体比例应结合历史峰值与扩容周期确定，不宜照搬他人配置，也不要把余量当成越多越安全。