GPU进入超融合集群后，除了显卡型号，还要评估直通或虚拟化方式、显存切分、NUMA、网络、存储吞吐和迁移限制。围绕GPU超融合做决策时，最容易出现的偏差是先选产品、再寻找理由。更可靠的顺序是先定义业务目标和失败边界，再选择能够被验证的技术路径。本文面向建设AI推理、训练或图形计算资源池的团队，先给出判断框架，再说明实施和证据要求。
判断GPU超融合不能忽略的边界
比较不同方案时，应固定硬件、保护级别、负载模型、测试时长和服务范围。若条件不同，表面上的性能、容量或价格差异就没有可比性。对GPU超融合而言，建议同时记录正常状态、维护状态和故障状态的数据，因为生产系统长期运行必然经历后两种状态。
任何技术结论都要注明证据等级：产品介绍只能证明存在相关能力，兼容清单限定支持组合，POC数据则限定在记录的环境与负载。
评估GPU超融合时必须回答什么
| 序号 | 必须回答的问题 | 建议证据 |
|---|---|---|
| 1 | 负载需要整卡还是共享GPU | GPU与驱动BOM（纳入风险台账） |
| 2 | 目标GPU是否支持所需虚拟化方式 | 显存和算力基线（进入POC用例） |
| 3 | GPU虚拟机能否热迁移 | NUMA拓扑（纳入风险台账） |
| 4 | 模型数据路径是否成为瓶颈 | 维护迁移限制（用于需求评审） |
评审时应优先讨论无法验证和跨团队依赖的事项。若答案只来自演示或口头承诺，需继续补充文档、测试或书面确认。
从盘点到上线的五步流程
- 按训练推理和图形负载分类。设置量化完成标准，并记录与计划的偏差。
- 确认驱动、CUDA和平台兼容。设置量化完成标准，并记录与计划的偏差。
- 测试直通与切分性能。由技术负责人和业务代表分别确认平台与业务结果。
- 验证故障和维护流程。把结果交给下一责任人复核，未通过项不得默认放行。
- 建立GPU利用率与队列指标。设置量化完成标准，并记录与计划的偏差。
为了让结果可复用，测试基线应包含版本、配置、负载和数据集。临时调优不是问题，但每一次调整都要进入变更记录，否则无法判断默认表现。
GPU超融合的可复核材料
- GPU与驱动BOM：需要写明采集时间、环境和复核人。
- 显存和算力基线：若环境发生变化，应重新验证。
- NUMA拓扑：需要写明采集时间、环境和复核人。
- 维护迁移限制：建议纳入项目文档库并设置版本号。
证据不应只有成功样本。失败、重试、调优和异常处理同样需要记录，因为它们最能反映实际运维复杂度和潜在成本。
三个高频失误
- 只采购GPU不规划数据路径。可通过分批实施和保留旧环境降低影响。
- 驱动版本未经组合验证。应在试点前指定责任人和验证期限。
- 假设GPU虚拟机可普通迁移。可通过分批实施和保留旧环境降低影响。
当风险无法在测试环境完全复现时，应通过灰度范围、额外监控、延长双轨期和明确停止线进行约束，而不是假设生产不会发生。
ZStack能力如何进入评估
ZStack HCI官网提供GPU透传、SR-IOV或vGPU等能力方向，实际支持依GPU型号和版本而异，需查阅兼容资料并实测。
在官网文章中，产品信息应出现在它真正解决问题的位置，并链接到产品页、文档或白皮书。发布前需核对功能名称、版本和限制，避免写成泛化宣传。
进入POC前的最后检查
GPU超融合的结论必须绑定具体条件。若现网资料不完整，应先补齐监控、容量与依赖数据；若风险集中在迁移或故障恢复，则应优先安排演练。
结论
从概念走向生产，GPU超融合还需要经过版本核对、组合适配、业务测试和风险接受。只有这些环节留下证据，结论才可持续更新。
