CUDA 应用在一台开发机编译成功，不代表同一二进制能在所有 GPU 上以相同方式运行。nvcc 的架构选项决定代码对象中包含哪些目标架构的本机代码，以及是否保留某个虚拟架构的 PTX。部署时，运行时可能直接选择匹配的本机代码，也可能由驱动对 PTX 即时编译；若没有可用目标，则会在加载阶段失败。兼容策略必须从实际 GPU 清单和软件生命周期出发，而不是复制网上的一串 gencode 参数。
sm 与 compute 表达不同层次
通常可把 compute 理解为虚拟架构目标，把 sm 理解为特定 GPU 架构的本机代码目标，但具体支持值要以所用 CUDA Toolkit 文档为准。只生成当前开发 GPU 的 sm 代码，制品较集中，却可能无法覆盖其他部署节点；只保留 PTX 可以给未来驱动留出即时编译机会，却会增加首次加载的不确定性，也不保证新架构上的性能等同于针对性编译。企业制品应明确支持哪些架构、哪些只是回退路径。
目标越多，制品与构建成本越高
为大量架构同时生成本机代码会增大 Fatbin、链接时间、镜像体积和分发成本。包含第三方 CUDA 扩展的框架尤其容易让每个插件重复携带多个目标。不能为了“兼容所有”无限增加目标，而应根据生产资产、退役计划和扩容路线建立支持集合。对边缘、工作站和数据中心不同产品，可拆分制品或构建渠道，避免一个包承担完全不同的硬件范围。
即时编译会影响冷启动与缓存
当运行时从 PTX 生成本机代码，首次加载可能产生额外时间，并依赖驱动编译器和缓存目录。只在已经预热的节点测试，会漏掉新节点、缓存清理或只读文件系统下的行为。验收应清理相关缓存后执行冷启动，记录编译耗时、缓存权限和磁盘占用，再测后续启动。容器平台还要确认缓存位于容器层、宿主机还是临时卷，以及升级后何时失效。
框架扩展可能绕过主项目设置
主程序的架构目标正确，运行时编译的自定义算子、Python 扩展或独立共享库仍可能使用另一套默认值。构建清单要覆盖所有含设备代码的产物，并在 CI 中检查其架构段。若插件由客户现场编译，还要固定编译器、Toolkit、主机工具链和环境变量。不能看到镜像标签相同就假设内部每个扩展都兼容。
性能与正确性都要跨目标验证
制品能加载只是最低门槛。不同架构可能选择不同指令、资源分配或库实现，仍需执行数值正确性、性能和稳定性回归。使用 PTX 回退时，应把实际选择路径和驱动版本写入报告。若新 GPU 尚未纳入正式验证，可以标记为待评估，不能因为驱动完成了 JIT 就声称获得完整支持。
建议的发布门禁
- 从 CMDB 导出生产 GPU 架构与数量，定义必需、过渡和计划退役集合。
- 为必需集合生成并检查本机代码，对未来兼容是否保留 PTX 作出明确决定。
- 统计制品体积和构建时间，检查所有自定义算子与共享库的目标架构。
- 在每类目标节点执行冷缓存加载、功能、数值和性能回归。
- 在发布说明中写明支持范围、回退路径和未验证架构，变更 GPU 清单时重新构建。
nvcc 对 GPU 代码生成、虚拟架构与目标架构的参数说明可查阅 NVIDIA CUDA Compiler Driver NVCC 文档。可用目标会随 Toolkit 变化，旧工具链也未必认识新架构；因此编译参数、驱动与生产 GPU 必须作为一个版本组合管理。
WeChat
Profile