国产算力芯片服务器部署，适配大模型踩坑记录
国产算力芯片服务器部署大模型，最难的不是装系统，而是驱动、工具链和推理框架之间版本对不上。
本文按真实踩坑顺序，讲清楚从开箱到跑通模型要检查什么、命令怎么敲、报错怎么定位，适合第一次接触国产加速卡的运维和开发。
先确认硬件和系统版本是否匹配
拿到服务器后不要急着装驱动，先记录加速卡型号、系统内核和 GCC 版本。
lspci | grep -i accel
uname -r
gcc --version把这三项发给厂商技术支持，索要对应的驱动和固件包。国产卡常见的坑是驱动只支持特定内核版本，比如内核升级到较新版本后，官方驱动编译直接失败。
如果系统是 Ubuntu，建议先用 apt-mark hold linux-image-generic 锁定内核，避免自动升级后驱动失效。
另一个容易忽略的点是 BIOS 里的 Above 4G Decoding 和 Resizable BAR，部分加速卡需要开启才能被完整识别。
开完保存重启，再用 lspci -vv 看链路速率是否达到标称值。
驱动和用户态工具链安装
驱动包通常分内核模块和用户态 runtime 两部分。
安装前先装依赖：
apt update
apt install -y build-essential dkms linux-headers-$(uname -r)然后按厂商文档顺序安装，先内核模块再 runtime。
装完执行厂商提供的检查命令，例如很多国产卡用 xxx-smi 查看卡状态：
xxx-smi正常输出会列出每张卡的型号、显存总量、温度和功耗。如果只显示部分卡或显存为 0，优先检查是否所有卡都在同一个 PCIe Switch 下，以及 BIOS 是否关闭了 IOMMU。
IOMMU 开启时部分驱动会分配不到连续地址，表现为初始化失败。
验证驱动是否真正可用，可以跑一个厂商自带的小算子测试，比看 xxx-smi 更可靠。
推理框架适配时最容易报错的地方
大模型推理常用 vLLM、TensorRT-LLM 或厂商自研框架。
国产卡适配层通常以插件形式提供，需要确认三件事：
- 框架版本和插件版本是否对应
- 算子库是否覆盖模型需要的算子
- 显存分配策略是否匹配卡的实际显存
以 vLLM 为例，安装厂商插件后启动命令大致如下：
python -m vllm.entrypoints.openai.api_server \
--model /data/models/Qwen2-7B-Instruct \
--tensor-parallel-size 2 \
--dtype float16最常见的报错是 No kernel found for op xxx，说明该模型用到的算子当前插件没实现。
处理办法是换用厂商已验证的模型版本，或者把模型转换为厂商提供的算子兼容格式。
不要硬改框架源码，后续升级会全部失效。
如果启动后显存只用了很少就报 OOM，
检查 --gpu-memory-utilization 是否被设得过低，
以及是否误把 --tensor-parallel-size 设成了大于实际卡数。
压测和稳定性验证不能省
模型能跑通不等于能上线。
用 ab 或 wrk 压 OpenAI 兼容接口：
wrk -t4 -c16 -d60s --latency \
-s post.lua http://127.0.0.1:8000/v1/chat/completions观察三个指标：首 token 延迟、每 token 输出速度和显存增长曲线。
如果跑几分钟后显存持续上涨，大概率是 KV Cache 没释放，需要检查框架的 max-model-len 和 block-size 配置。国产卡上稳定性问题往往在持续压测 30 分钟后才暴露，短时间测试通过不代表没问题。
同时用 dmesg -T | tail -50 看内核有没有报错，厂商驱动异常通常会在这里留下记录。
几个高频疑问
驱动装完 xxx-smi 能识别，但框架启动报找不到设备怎么办？
先确认运行框架的用户是否在驱动要求的用户组里，例如 video 或厂商自定义组，权限不对时用户态 runtime 无法打开设备节点。
模型转换后精度下降明显，是卡的问题吗？
多数情况是量化格式和卡支持的精度不匹配。
国产卡对 FP16、BF16、INT8 的支持程度不同，先用 FP16 跑通再考虑量化。
多卡推理时吞吐没有线性提升？
检查卡间通信走的是 PCIe 还是专用互联。
如果走 PCIe 且拓扑是跨 CPU 的，通信会成为瓶颈，可尝试调整 NCCL 或厂商集合通信库的拓扑配置。
部署国产算力芯片服务器跑大模型，核心是把驱动、工具链、框架三层版本锁死，再逐层验证。
遇到报错先看 dmesg 和框架日志，多数问题能定位到具体的算子或显存配置，而不是硬件本身。
