适配国产GPU这件事，听起来像是“改个驱动跑通就行”，但真正动手做过的人都知道，这里面的水比想象中深得多。最近我们团队刚把水獭大模型安全卫士完整跑上海光GPU，从模型算子对齐、推理框架适配到多卡通信调优，前前后后踩了大大小小几十个坑。这篇文就把整个过程中最关键的技术判断、实操步骤和排错经验整理出来，希望能给正打算做国产化适配的朋友一些参考。
水獭大模型安全卫士是什么？通俗讲，它就是一个专门给大模型应用做“安检”的中间层：在模型对外提供服务之前，对输入和输出做内容安全检测，拦截恶意指令、有害内容，同时还能对模型自身的响应做脱敏和合规校验。它本身重度依赖大模型推理能力，所以对底层算力平台非常敏感。这次完成海光GPU适配，意味着这套安全能力可以在纯国产化硬件链路上完整跑通，对金融、政务、能源这类对自主可控有硬性要求的行业来说，价值很直接。
这篇内容主要写给三类人：一类是正在做国产化AI平台替换的架构师，需要了解适配的真实工作量和技术难点；一类是算法工程师，想知道模型迁移到海光GPU后如何保证精度和性能；还有一类是运维和平台工程师，面临ROCm环境部署、多卡通信、故障排查等实际问题。我会按真实的项目推进顺序来讲，从方案选型一直讲到问题排查。
1. 项目背景与适配目标拆解
1.1 为什么“能跑”和“跑好”是两回事
先说个很多人容易忽略的点：大模型应用适配国产GPU，最难的往往不是让它“能跑起来”，而是让它“稳定地、高效地、精度无损地跑好”。Pytorch和HuggingFace生态天然对CUDA友好，但换到海光GPU的ROCm生态，就像把一套为Windows优化的软件搬到Linux上，基础功能可能兼容，但性能、精度、显存行为全都不一样。
水獭大模型安全卫士的核心工作负载有两块：一块是嵌入向量化，也就是把用户输入文本变成向量，这需要跑BERT或中文RoBERTa这类相对轻量的模型；另一块是内容判定与生成式安全分析，这块会用到7B到13B参数规模的大模型做推理，用来判断复杂场景下的内容风险。两种负载对算力的需求差异很大，适配策略也必须分开考虑。
我们最初在x86加NVIDIA A100的环境上做开发，功能已经稳定。迁移到海光GPU之后，第一轮实测结果非常打脸：小模型的推理时延从原来的30毫秒涨到了90毫秒左右，大模型的Token生成速度也从50 tokens/s掉到了不到20 tokens/s。功能倒是能跑通，但这样的性能完全没办法支撑生产环境的实时安全检测需求。这也就引出了适配的核心目标：在保证检测精度不下降的前提下，把性能压回可用的区间。
1.2 海光GPU与ROCm生态的基本格局
海光GPU的架构脱胎于AMD的CDNA设计，在软件栈上走的是ROCm路线，这一点和NVIDIA的CUDA是完全平行的两套体系。ROCm里对应的库有这些：hipBLAS对应cuBLAS，rocBLAS承担基础矩阵运算，MIOpen对应cuDNN负责卷积和部分算子优化，RCCL对应NCCL做多卡集合通信。
对于只做推理的应用来说，好消息是Pytorch官方对ROCm已经有比较完善的支持，2.x版本开始提供ROCm构建的发行包。坏消息是，模型里一旦出现某些算子走不到MIOpen或hipBLAS的优化路径，就会掉回一个很慢的通用实现，甚至在某些极端情况下报错说算子不支持。水獭大模型安全卫士里恰好就有这么几个容易踩坑的算子，比如GELU的精确实现、RoPE位置编码的某些变体、以及FlashAttention的自定义实现，这些在CUDA生态都很成熟，但在ROCm上未必都有对应的高性能内核。
还有一个绕不开的现实问题：生态成熟度。NVIDIA的TensorRT、Triton Inference Server这些工具链，对模型做了非常深度的优化，直接可用。但海光这边更现实的做法是直接用Pytorch的torch.compile配合Inductor做图优化，再手动处理那些编译不过去或者编译出来性能很差的算子。
2. 适配方案设计与核心改造点
2.1 分层适配策略：避开“一步到位”的坑
项目启动时我们讨论过两套方案。方案一是直接换用海光官方推荐的推理引擎，比如triton加上ROCm后端；方案二是保留原有Pytorch推理代码，通过HIP迁移和算子替换来做最小化改动。
最终选了方案二。原因很直接：水獭大模型安全卫士的推理链路里有不少自定义的逻辑，包括前置的文本改写、多轮对话状态拼接、敏感信息实体遮蔽，这些和模型本身耦合很深，如果整个换推理引擎，相当于把应用层全部重写一遍，周期和风险都不可控。方案二虽然牺牲了一部分极致性能，但可以先把业务链路跑通，再用性能剖析工具逐段优化，风险是可控的。
拆分下来，整个适配工作分成三条线并行：
- 算子层：梳理模型中所有PyTorch算子，逐个在ROCm环境下验证正确性和性能
- 框架层：确认Pytorch版本、TorchVision等依赖库与ROCm版本的兼容矩阵，调整推理脚本的加速配置
- 通信层：多卡部署时把NCCL替换为RCCL，调整集合通信的超参和拓扑感知策略
这三条线对应的问题完全不同，混在一起查会非常崩溃。强烈建议分开推进、分别验收。
2.2 算子兼容性验证：用“输出对齐”找出隐藏炸弹
算子验证是整个适配里最枯燥但最重要的一环。我们的做法是：固定一组有代表性的输入样本，包含短文本、长文本、带特殊字符的对抗样本、多语言混合文本，跑一遍模型前向，对比CUDA环境下和ROCm环境下的输出差异。
这里有个关键细节：不能只看最终输出的精确相等。浮点运算在不同硬件上的累加顺序、近似算法都可能导致最后几位小数的差异，直接比较完全相等会得到一堆假阳性。我们用两个指标综合判断：一是最大绝对误差，二是余弦相似度。经验阈值是最大绝对误差小于1e-2且余弦相似度大于0.9999，就认为算子对齐通过。如果某层误差明显偏大，就用二分法定位：把模型从中间截断，分别对比前半段和后半段的中间张量，逐层逼近出问题的算子。
我们实际遇到的典型问题是LayerNorm的方差计算路径在ROCm上走了不同实现，导致fp16精度下的误差比CUDA大一个数量级。解决方案也很“土”：在该算子上临时强制使用fp32计算，代价是性能损失约2%，但精度完全对齐，属于用空间换正确的经典操作。
2.3 半精度推理的取舍：不能无脑用FP16
大模型推理几乎都绕不开混合精度。水獭卫士在CUDA环境下用的是FP16混合精度，显存占用低且速度快。迁移到海光GPU后，同样的设置出现了两个问题：一是部分算子在FP16下的数值稳定性变差，表现为长文本场景下检测置信度偶尔跳动；二是MIOpen对某些卷积/矩阵乘算子的FP16支持路径性能不佳，实际速度反而不如FP32。
面对这个问题，我们的处理原则是“按算子分区精度，而不是全模型一刀切”。具体来说，把计算密集且数值敏感的算子（比如QKV投影、注意力分数计算）固定在FP32，其余部分保持FP16。经过这一轮调整，精度完全恢复，性能损失大概3%到5%。不要小看这个“土办法”，它在大模型国产化适配里是保精度最有效的手段之一。
3. 实操过程与关键配置实录
3.1 运行环境与版本选型
这套内容是我们在实际项目里验证过的组合，不同版本之间有细微行为差异，但整体思路是一致的：
| 组件 | 版本 | 说明 |
|---|---|---|
| 操作系统 | 麒麟V10 SP3 / Ubuntu 22.04 | 两者都实测过，推荐麒麟，驱动兼容问题少 |
| 加速卡 | 海光Z100L系列 | 显存32GB，CDNA架构 |
| ROCm | 5.7.3 | 不要用太新的版本，6.x对老卡支持有变化 |
| Pytorch | 2.1.1+rocm5.7 | 官方有对应Docker镜像，强烈建议直接用 |
| Python | 3.10 | 锁版本，别用3.11，有些算子编译过不去 |
| 推理脚本 | Python + torch.inference_mode | 主线保留Pytorch生态 |
这里有个非常重要的建议：直接用Pytorch官方发布的ROCm Docker镜像当基础环境，而不是自己手动从源码编译Pytorch。自己编译看起来可控，但ROCm版本和Pytorch版本的排列组合非常多，一旦某个依赖的ABI不一致，后续排查成本会高到让你怀疑人生。
3.2 从ROCm环境验证到模型加载
环境装好后，第一步不是急着跑模型，而是用一段非常简单的矩阵乘法验证ROCm链路是否真的打通。很多人在这一步就翻车：Pytorch表面上识别了GPU，但实际计算仍然走CPU。
# 验证ROCm环境是否可用 python -c " import torch print('Pytorch version:', torch.__version__) print('ROCm available:', torch.cuda.is_available()) print('GPU name:', torch.cuda.get_device_name(0)) # 简单的矩阵乘法测试，确认计算真的发生在GPU上 a = torch.randn(1024, 1024, device='cuda') b = torch.randn(1024, 1024, device='cuda') c = a @ b print('Matmul result device:', c.device) "正常情况会输出GPU名称。如果torch.cuda.is_available()返回False，大概率是ROCm驱动和用户权限的问题，检查/dev/kfd和/dev/dri设备的权限，把运行用户加入render和video组再重试。如果看到"Silicon"之类的报错，通常是驱动版本和内核模块不匹配，需要重新装驱动。
3.3 算子替换与热点优化的完整示例
小模型适配有一些细操作。举一个实际案例：文本向量化模型中，attention里的softmax操作，ROCm环境下默认实现性能不佳。我们把它替换成mem-efficient的SDPA实现，效果显著：
import torch import torch.nn.functional as F def attention_with_sdpa(query, key, value, mask=None): # 使用PyTorch 2.0后的scaled_dot_product_attention # 内部会根据输入自动选择flash/mem-efficient/math实现 if mask is not None: # mask需要是bool类型，True的位置会被mask掉 attn_mask = mask.logical_not() else: attn_mask = None output = F.scaled_dot_product_attention( query, key, value, attn_mask=attn_mask, dropout_p=0.0, is_causal=False ) return output替换后小模型推理时延降低了35%。这说明一个深坑：很多人以为大模型算子都有优化实现，但其实小模型的某些瓶颈算子容易被忽略。用torch.profiler去记录算子级别的耗时，哪个算子耗时高就针对性优化，这种按数据驱动的优化方法比凭感觉调参要靠谱得多。
3.4 多卡推理链路：从NCCL到RCCL的迁移细节
水獭大模型安全卫士在高峰期需要并发处理多路请求，单卡32GB显存放7B模型加KV Cache已经是极限，所以必须走多卡方案。NVIDIA时代我们用NCCL做张量并行，迁移到海光GPU后需要切到RCCL。
切的过程不复杂：安装ROCm的RCCL包，设置环境变量NCCL_DEBUG=INFO观察多卡通信是否正常工作。但这里有个非常隐蔽的问题：Pytorch里torch.distributed的初始化逻辑会主动检查NCCL版本，如果环境变量指向的共享库还是NVIDIA的NCCL，初始化会直接报错。我们的做法是在启动脚本里显式指定RCCL的库路径：
export LD_LIBRARY_PATH=/opt/rocm/lib/rccl:$LD_LIBRARY_PATH export NCCL_DEBUG=INFO export NCCL_PROTO=Simple export HCCL_OVER_NCCL=1 # 部分版本需要此变量让torch走RCCL路径更稳的办法是用torch.distributed配合一组worker脚本启动：
python -m torch.distributed.run \ --nproc_per_node=2 \ --master_port=29500 \ safety_guard_infer.py \ --model_path /data/models/guard-7b \ --max_batch_size=16启动后如果看到RCCL相关的初始化日志，说明多卡通信链路已经打通。首轮跑一个大batch做预热，观察显存占用是否符合预期。
4. 常见性能瓶颈与排查记录
4.1 显存泄漏排查：推理时间越长越卡
实测过程中最让人头疼的问题之一：服务的响应时延会随着运行时间增长而逐渐劣化，跑两三个小时后明显卡顿。第一反应是显存泄漏。
排查路径分三步走。第一步，用nvidia-smi的对应版本工具查看显存占用，确认有没有随时间线性增长。第二步，用torch.cuda.memory_summary()打印显存分配明细，重点看缓存池的占用。第三步，怀疑Python层的对象引用没有释放。
结果发现原因不在Pytorch本身，而是我们在处理长文本时使用了动态padding，导致每次batch的shape都不同，Pytorch的缓存分配器频繁申请释放显存块，产生严重碎片化。解决方案也很经典：固定一个最大长度做静态padding，或者使用torch.cuda.memory.set_per_process_memory_fraction限制最大显存申请，配合torch.cuda.empty_cache()在每批结束后清理未使用的缓存。
修复后连续跑48小时，显存占用保持平稳，时延曲线不再爬升。
4.2 算子编译卡死与临时禁用Inductor
用torch.compile做图优化的时候，有部分算子会因为ROCm代码生成路径的问题直接卡死，表现为CPU占用率100%但GPU利用率接近零。这个问题的根本原因是Inductor在后端生成了HIP代码，但调用hipcc编译时某些内联汇编在CDNA架构上无法正确翻译。
排查方法很简单：用TORCH_LOGS=+inductor打开编译日志，定位到卡住的具体算子。如果确实是框架不支持的算子，比较直接的方案是放弃对该模型使用torch.compile，改成手动融合热点算子。别小看这个退路，很多场景下torch.compile带来的提升主要是减少了kernel launch开销，而在推理batchsize较大时，手动融合的效果完全可以接近它。
4.3 典型问题速查表
| 现象 | 可能原因 | 排查手段 | 解决方案 |
|---|---|---|---|
| 启动时报找不到librocblas.so | ROCm环境变量未正确配置 | ldd检查动态库链接 | 检查LD_LIBRARY_PATH，确认包含/opt/rocm/lib |
| CPU跑满但GPU空闲 | 算子不兼容导致fallback到CPU | torch.profiler查看算子耗时分布 | 定位异常算子，替换实现或强制精度策略 |
| 多卡初始化卡住 | RCCL版本不一致或IB/RoCE配置冲突 | NCCL_DEBUG=INFO查看通信日志 | 检查各卡RCCL版本一致，调整NCCL_P2B_DISABLE等参数 |
| FP16输出偏差大 | 部分算子数值稳定性不足 | 分层比对中间张量 | 关键算子强制FP32，分区精度策略 |
| 推理时延逐渐劣化 | 显存碎片化 | memory_summary分析缓存池 | 静态padding，定期empty_cache |
5. 实测效果与经验沉淀
5.1 性能数据与业务可用性判断
适配完成后，我们做了完整的基准测试。先说结果，对比数据取的是稳定运行一周后的平均值，测试场景是文本内容安全检测，输入文本平均长度约500字。测试环境为2张海光Z100L，7B参数安全模型，最大batch size为16。
关键指标如下：单请求的端到端时延从初期的500毫秒以上降到了210毫秒左右，相比CUDA环境下的180毫秒只多出约15%劣化；模型吞吐量从适配初期的21 tokens/s提升到了46 tokens/s（CUDA环境下为55 tokens/s，约有16%的差距）；精度方面，内容安全检测在测试集上的准确率没有出现下降，F1分数保持了适配前的水平，只有长尾对抗样本上置信度分数有轻微浮动，但在阈值判定上没有任何翻车。对于内容安全场景来说，这个性能水平完全可以支撑生产环境。
5.2 适配成败的几个关键认知
整个过程走下来，最大的体会就是：国产化适配的真功夫不在“跑通”上，而在于精确地控制精度、性能和稳定性的三角平衡。有几个从项目里长出来的经验，值得多说几遍：
第一，不要盲目追求“零改动”。所有声称“一行代码不改就能迁移”的方案，要么是应用极简单，要么就是在撒谎。适配的核心是评估自己业务里哪些部分对底层算子版本敏感，哪些可以接受性能回退。水獭卫士这种内容安全产品，对精度和时延都有硬指标，就必须接受改造，但改造的范围可以控制得很小。
第二，精度问题必须用数据说话。很多时候模型输出的结果看起来对了，但概率分数已经漂移。内容安全系统对置信度阈值非常敏感，阈值附近如果发生漂移，就可能出现漏报或误报。所以只评价“结果对不对”是不够的，必须建立全链路的中间张量对比机制，在代码层面做好自动化的精度门禁。
第三，性能优化要有系统思维。不要一上来就抠某个算子的实现，先看数据：用profiler看算子时间占比，用性能计数器看显存带宽利用率，用通信日志看多卡唤醒模式。数据会告诉你瓶颈到底在计算、访存、通信还是Python层的开销。
第四，稳定性的坑比性能更隐蔽。性能问题通常马上暴露，稳定性问题则会在长尾场景里折磨你。一个显存碎片、一个动态shape导致的缓存抖动、一个多卡通信组网的握手超时，都可能成为定时炸弹。所以适配后的稳定性测试周期要拉长，至少保证满载场景连续跑48小时以上，再谈上线。
5.3 后面还能怎么扩展
这次适配解决的是当前这套模型和推理代码在国产化平台上的落地问题，但远不是终点。接下来有几个方向我觉得价值很大：一是结合ROCm生态做更深入的算子级定制，针对水獭卫士里几个高频的检测算子写专门的HIP kernel；二是把适配经验固化到CI/CD流水线里，每次模型更新后自动完成不同GPU平台的冒烟回归，防止新算子又引入兼容性问题；三是探索海光GPU在安全检测场景下的多实例部署方案，把GPU利用率从目前的60%左右再往上推一推。
说到底，国产化适配这条路一旦走上，就是一个持续迭代的过程。硬件驱动的版本更新、模型结构的变化、业务场景的扩展，每一个变量都可能带来新的适配需求。关键是把手里的方法论、自动化工具、排查清单沉淀下来，让每一次新的适配都成为增量经验，而不是从零开始。水獭大模型安全卫士这次完成海光GPU适配，对整个国产化AI安全链路来说算是补上了一块拼图，而对团队来说，最大的收获是把这一整套适配打法彻底打磨透了。
