国产GPU PoC怎么做？模型适配、性能与验收清单

先给结论

国产GPU/AI加速卡PoC的目标不是证明某张卡“理论性能够高”，而是确认目标模型、目标软件、目标业务在指定国产平台上能否正确运行、性能是否达到业务SLA、迁移成本是否可接受、并且具备长期运维条件。

不同国产芯片的软件栈、迁移工具、算子库和多卡通信体系不同，不应套用一张统一的CUDA兼容表，也不应直接用理论FLOPS与另一平台推导生产性能。

国产GPU PoC先确定4个公平原则

1. 同任务：用同一批真实业务样例、模型版本和质量指标，不用不同Demo互相比较。
2. 同服务目标：推理比较应固定输入/输出长度分布、并发/到达率和TTFT/TPOT等SLA；训练比较应固定目标质量与训练配置。
3. 允许平台原生优化：不同芯片可以使用各自官方推荐的运行时、算子和框架，但必须完整记录精度、量化、版本与参数。
4. 同时记录迁移成本：能够运行不等于可以生产，代码修改、自定义算子、镜像、运维和人员学习成本都应计入结论。

因此，国产GPU PoC更像“完整平台可交付性验证”，而不是单卡跑分。

国产GPU项目建议按七层验收

层级	验证内容	输出
1. 硬件健康	设备枚举、显存、温度/功耗、错误、PCIe/互联	健康基线
2. 驱动/运行时	驱动、固件、运行时、容器、版本匹配	可复现软件栈
3. 框架/算子	PyTorch/其他框架、关键算子、自定义扩展	兼容/缺口清单
4. 模型功能	加载、推理/训练、精度、量化、长上下文/多模态	功能与质量回归
5. 性能容量	TTFT、TPOT、吞吐、并发、训练step、扩展效率	SLA下容量边界
6. 稳定与恢复	长稳、OOM/异常请求、进程/节点恢复、Checkpoint	可靠性结果
7. 运维交付	监控、日志、镜像、升级、备件、文档与支持	生产交付清单

模型与算子适配：不要只看“框架支持PyTorch”

• 模型级：目标模型是否有官方或社区明确适配路径；模型commit、Tokenizer和配置是否一致。
• 精度级：BF16/FP16/FP8/INT8/INT4等目标精度是否有硬件和算子实现，量化格式是否需要转换。
• 算子级：Attention、MoE、RMSNorm、RoPE、自定义CUDA扩展等是否需要替换或重新编译。
• 框架级：训练/推理框架版本是否在厂商支持矩阵内，模型服务API和所需功能是否完整。
• 多卡级：通信库、张量/数据/专家并行是否可用，并在目标拓扑下验证实际扩展效率。

以昇腾为例，官方CANN承担AI处理器与上层框架之间的软件平台角色，官方文档还分别管理驱动、固件和MindIE等组件。这说明“国产GPU软件栈”应按具体厂商逐套建立兼容矩阵，不能笼统处理。

性能怎么比较才不失真

任务	建议主指标	必须固定/记录
交互式LLM推理	TTFT、TPOT/ITL、P95/P99、SLA内吞吐	模型、精度、输入/输出长度、并发、框架
批量推理	总吞吐、单位任务完成时间、质量	Batch、数据集、预处理、精度
训练/微调	达到目标质量的时间、step时间、扩展效率	数据、Batch、精度、优化器、并行方式
多卡/多节点	扩展效率、通信占比、稳定性	节点/GPU数、互联、网络、通信库
端到端应用	任务成功率、时延、成本/资源占用	RAG/Agent完整链路与业务数据

可以用厂商提供的带宽、算力和功耗测试工具检查硬件是否达到应有基线。例如昇腾Ascend-DMI官方文档公开了总线/内存带宽、计算能力、功耗和设备状态等测试功能。但这类微基准只能用于分层诊断，不能替代目标模型端到端性能。

迁移成本应该如何量化

迁移项	建议记录
代码改动	修改文件/模块、替代API、自定义算子数量
模型转换	权重格式、量化、算子图转换、额外校准
依赖替换	CUDA专有库/插件的替代方案及功能差异
容器与部署	基础镜像、驱动挂载、编排插件、启动参数
性能调优	从“能跑”到“达标”所需的调优项和工时
运维学习	监控、故障定位、升级、日志工具和人员培训
回退路径	原平台/旧版本能否保留，回退需要多长时间

如果方案A性能略高但需要大量专有代码重写，方案B性能略低但迁移与运维成本显著更低，两者的项目价值可能完全不同。因此PoC结论应包含工程工时和不可替代依赖，而不只是一张性能表。

生产可运维性：国产算力PoC最容易漏掉的一层

• 是否有稳定的驱动/固件/运行时版本组合与清晰升级路径。
• 容器镜像、模型文件、编译缓存和依赖能否离线保存并重复部署。
• GPU/加速卡利用率、显存、温度、功耗、错误和服务指标能否进入现有监控。
• 多卡/多节点异常能否定位到设备、链路、通信库或模型服务层。
• 关键组件发生升级时，是否有回归测试、灰度和回滚机制。
• 备件、RMA、技术支持响应与问题升级渠道是否满足项目要求。

国产GPU项目PoC验收表

验收项	通过条件怎么写	不建议怎么写
模型功能	指定模型/版本的目标任务通过，失败项有清单	“支持主流大模型”
质量	同任务集达到项目约定质量边界	“效果差不多”
性能	指定长度/并发/SLA下TTFT、TPOT、吞吐达标	只写单次tokens/s
多卡扩展	从1卡到N卡/节点的目标任务扩展效率与稳定性达标	只看理论互联带宽
长稳	在约定负载和时长内错误/资源漂移满足标准	“连续跑过一次”
迁移	代码/算子/镜像改动和工时在项目预算内	“兼容PyTorch所以无需迁移”
运维	监控、日志、升级、回滚、备件流程完成演练	只确认驱动可安装
复现	保存软硬件版本、镜像、配置、脚本和报告	依赖人工口头配置

赋创可以在项目中提供哪些支持

赋创可结合客户的目标模型、业务任务、现有软硬件环境和机房条件，协助梳理需求、形成候选AI服务器/集群方案，并在目标环境中完成软硬件适配、PoC基线、容量与稳定性验证。涉及性能与资源数量时，以明确测试条件和实测结果为依据，不把单一理论峰值或厂商公开样例直接等同于客户生产配置。

FAQ｜常见问题

国产GPU PoC最应该先测什么？

先确认目标模型和业务任务能否在可支持的软件栈上正确运行，再建立质量基线；随后才有意义比较性能、并发、多卡扩展和稳定性。

国产GPU能直接拿理论FLOPS和NVIDIA GPU比较吗？

不适合作为生产结论。理论峰值不包含算子效率、显存、通信、框架和模型结构差异。应在同一业务任务与明确测试条件下比较端到端结果。

支持PyTorch就等于现有模型不用改吗？

不等于。模型可能依赖自定义CUDA扩展、特定FlashAttention/MoE算子、量化格式或第三方插件，需要逐项验证和替代。

国产GPU验收可以只看单机性能吗？

如果生产计划包含多卡/多节点，不能只测单机。还要验证通信库、拓扑、网络、分布式框架、扩展效率和节点故障恢复。

国产GPU PoC要不要评估运维和售后？

要。生产可用性不仅是模型性能，还包括版本升级、监控、故障定位、备件/RMA、回滚和技术支持，尤其应在长期项目中提前验证。

方案咨询

需要把方案落到实际配置？

联系赋创获取算力、软件栈和交付路径建议。

咨询方案浏览指南