国产 GPU 厂商壁仞科技上半年收入 12.36 亿元同比增长 1997.6%这个数字在算力圈里被反复讨论。营收大幅增长说明国产 GPU 已经不只是停留在发布会和测试报告里而是开始被真实客户采购、部署到机房并承担具体的训练或推理任务。对于开发者和运维人员来说这个信号带来的思考更直接当服务器里真有一块国产 GPU 时应该怎么装环境、怎么验证功能、怎么判断性能、怎么排查问题。这篇内容不讨论股价和市场预测只围绕国产 GPU 落地的完整链路讲清楚从硬件识别到生产上线需要做的事。技术社区里关于 GPU 的高频问题已经从“哪块卡算力最强”逐渐变成“驱动怎么装”“PyTorch 怎么让程序用 GPU”“Ollama 怎么指定 GPU”“多卡训练为什么速度不升反降”“容器里怎么把设备透传进去”。这些问题恰恰是国产 GPU 从采购到可用之间最容易被低估的部分。买卡只是开始能不能把算力真正变成业务结果取决于后面每一步是否扎实。1. 从营收数据看国产 GPU重点已经从“有没有”转向“能不能用”1.1 营收增长说明市场启动但不能直接代表单卡体验壁仞科技上半年收入 12.36 亿元同比增长 1997.6%这个数据背后最直接的含义是有企业在为国产 GPU 付费并且付的是真金白银。营收规模上升通常意味着产品已经通过了某些政企项目或智算中心的基础验收也意味着开发团队开始把业务模型迁移到国产算力上。但营收增长并不等于单卡体验已经追平国际主流产品。GPU 能否用起来不只看峰值算力还要看驱动是否稳定、算子是否覆盖、框架版本是否匹配、多卡通信是否顺畅、监控运维是否齐全。很多项目在采购阶段只看 FP16/BF16 的算力数字落地之后才发现模型里的某个算子不兼容或者驱动在特定内核版本下无法加载。这些问题不会体现在营收报表里但会直接影响交付周期。1.2 开发者真正要关注的四个能力维度面对国产 GPU可以按四个维度做技术评估。只看“显存大不大、算力高不高”是不够的。能力维度判断方法容易忽视的问题驱动成熟度安装文档是否完整是否支持常见 Linux 发行版和内核版本升级系统内核后驱动失效算子覆盖度跑真实的模型脚本而不是只跑官方 demo某个模型只有 80% 的算子被支持剩余部分会退化到 CPU框架对接层检查 PyTorch、TensorFlow、ONNX Runtime 是否有对应版本框架版本太新厂商插件还没适配运维生态是否有设备监控命令、容器镜像、Kubernetes device plugin多卡调度和故障定位困难实际项目里建议把“算子覆盖度”排在算力之前。因为 GPU 的算力只有在算子被正确执行时才能发挥出来。一个模型只要有一个关键算子跑到 CPU 上整体训练速度就可能下降数倍最终结果比低算力但全算子走 GPU 的设备还要慢。2. 拿到国产 GPU 后的第一步先确认硬件和驱动环境2.1 通过系统命令确认设备是否被操作系统识别国产 GPU 上机后的第一件事不是急着安装 PyTorch也不是直接跑大模型而是先确认操作系统层面看到了这块设备。很多环境问题在一开始就被掩盖最后全部爆发在模型启动阶段。先记录系统信息cat /etc/os-release uname -r uname -m然后检查 PCI 设备列表确认 GPU 是否被系统枚举出来lspci | grep -i -E vga|3d|display|processing如果系统里没有lspci命令先安装pciutils# Debian/Ubuntu sudo apt update sudo apt install -y pciutils # CentOS/RHEL sudo yum install -y pciutilslspci输出里如果能看到 GPU 厂商相关的 Vendor ID 或设备名称说明硬件已经被系统识别。此时不要急着跑训练要继续确认驱动层是否可用。注意国产 GPU 的驱动模块名、管理命令名各厂商并不统一。不要凭经验使用 NVIDIA 的nvidia-smi或固定的/dev/nvidia0一切以对应厂商官方文档为准。2.2 安装驱动和运行时先看官方支持矩阵GPU 驱动安装最容易出错的点是版本不匹配。同一个 GPU在不同 Linux 发行版、不同内核版本、不同容器环境下表现可能完全不同。安装前需要确认三个版本操作系统版本和内核版本。GPU 驱动版本。上层运行时版本比如 PyTorch 依赖的加速后端版本。查看内核模块是否已经加载可以使用lsmod | grep -i -E gpu|biren|nvidia|amd如果没有输出说明驱动还没有加载。此时需要按厂商手册安装驱动。安装过程中要重点记录是否要求关闭安全启动。是否需要修改内核启动参数。安装后是否需要重新生成 initramfs。是否与 GCC 或 DKMS 版本有关。这些信息在官方支持矩阵里通常都有说明。不要直接下载一个通用驱动硬装否则容易出现“安装成功但重启后设备消失”的情况。2.3 验证设备状态和管理命令驱动安装完成后需要确认 GPU 管理命令能否正常读取设备信息。许多国产 GPU 会提供类似gpu-smi的命令用于查看设备数量、显存占用、温度、算力利用率。可以用一个保守的方式先探测命令是否存在command -v gpu-smi gpu-smi如果不存在阅读官方文档找到对应的管理命令。这里的核心不是死记命令名而是确认下面几个信息设备数量是否正确。每块设备的显存总量是否和采购配置一致。驱动版本和运行时版本是否与安装文档一致。设备状态是否显示为正常或 Active。如果系统无法识别设备继续往下装框架大概率失败。先停下回到驱动和硬件层排查。3. 搭建算力环境框架、加速后端、算子库必须三层匹配3.1 先想清楚三层关系对于普通业务开发来说不需要重写 GPU 驱动但必须理解软件栈的分层第一层是框架层也就是 PyTorch、TensorFlow、PaddlePaddle、ONNX Runtime 这类工具。第二层是加速后端负责把框架的计算图翻译成 GPU 能执行的指令。第三层是算子库和编译器负责具体矩阵乘法、卷积、归一化等算子的实现。很多国产 GPU 在框架层做的是兼容方案也就是说 PyTorch 代码可以不改但安装 PyTorch 时不能直接使用默认的 CUDA 版本而要安装厂商适配过的 wheel 版本或运行时插件。安装错了程序的torch.cuda.is_available()可能仍然返回 False或者设备列表为空。推理工具也一样。比如 Ollama 这类模型运行工具能不能把模型放到国产 GPU 上执行取决于底层后端是否已经支持对应设备。如果后端没有适配日志里显示的可能是 CPU 推理设备利用率会非常低。3.2 用虚拟环境隔离依赖不要污染系统 Python推荐在每个国产 GPU 项目里使用独立的 conda 环境或 venv 环境。原因很简单不同模型依赖的 PyTorch 版本不同厂商适配插件也可能只支持某个版本区间。系统级 Python 环境一旦被装乱排查成本非常高。创建 conda 环境conda create -n gpu_project python3.10 -y conda activate gpu_project安装依赖时优先使用厂商提供的镜像源或适配清单。不要在不确定的情况下直接执行pip install torch torchvision因为 install 成功的 torch 不一定能调用国产 GPU。正确的做法是先查官方文档确认应该安装哪个 PyTorch 版本、哪个加速后端版本、是否需要额外安装插件包。一个典型的 requirements 文件可能是这样torch2.1.1 torchvision0.16.1 transformers4.38.2具体版本号以官方适配表为准。不要复制别的项目的版本号特别是厂商刚发布新版驱动时版本兼容关系很敏感。3.3 写一个设备检查脚本把环境状态打印清楚环境是否可用应该用脚本验证而不是靠肉眼判断。下面这段脚本可以打印 PyTorch 版本、设备数量、设备名称和显存的初步信息import sys try: import torch print(torch version:, torch.__version__) except Exception as e: print(torch import failed:, e) sys.exit(1) def check_device(): if hasattr(torch, cuda) and torch.cuda.is_available(): print(device count:, torch.cuda.device_count()) for i in range(torch.cuda.device_count()): print(device, i, torch.cuda.get_device_name(i)) return True # 部分国产 GPU 不通过 torch.cuda 暴露设备需要检查厂商插件 print(torch.cuda not available, need check vendor plugin) return False if not check_device(): sys.exit(1)执行脚本python check_device.py如果脚本找不到设备可能出现三种情况驱动层有问题设备没有被系统识别。框架与后端不匹配安装的 PyTorch 不包含对应后端。环境变量或设备权限没配置好比如当前用户无法访问/dev下的设备文件。这一步要比“程序能启动”更可靠。能启动不代表 GPU 真的在工作。4. 用最小模型做功能验证用标准 benchmark 做性能验证4.1 先做最小矩阵运算验证设备能被 PyTorch 看到之后先不要直接微调大模型。用最小计算任务验证 GPU 是否真的参与计算这一步能把硬件问题、驱动问题、框架问题快速暴露出来。import torch device torch.device(cuda:0) x torch.randn(256, 256, devicedevice) y torch.randn(256, 256, devicedevice) for i in range(5): z torch.mm(x, y) print(matmul ok, output shape:, z.shape)如果设备不可用torch.device(cuda:0)不会立即报错但把张量放到该设备时会抛出 RuntimeError。如果在torch.mm这行报错说明算子执行链有问题需要看后端日志。4.2 用标准脚本记录性能基线功能验证通过后要做性能验证。性能验证不能只跑一次也不能只观察程序启动时间。下面是一个简单的矩阵乘法压测脚本用于观察 GPU 的稳定输出能力import time import torch def bench_matmul(device, sizes, repeat10): for n in sizes: a torch.randn(n, n, devicedevice) b torch.randn(n, n, devicedevice) # 预热避免第一次执行包含初始化开销 _ a b if device.type cuda: torch.cuda.synchronize() start time.perf_counter() for _ in range(repeat): c a b if device.type cuda: torch.cuda.synchronize() avg_ms (time.perf_counter() - start) / repeat * 1000 print(f{n}x{n}: avg {avg_ms:.3f} ms) device torch.device(cuda:0) bench_matmul(device, [512, 1024, 2048, 4096])执行命令python bench.py这里的关键不是追求某一个数字而是记录稳定后的平均值。多次执行时前几次可能偏慢原因是运行时初始化、显存分配策略和算子编译缓存。只有预热之后的稳定值才能作为后续调优的基线。4.3 性能验证要区分学习环境和生产环境验证项学习环境生产环境设备固定单机单卡即可要覆盖机器上的全部 GPU驱动状态确认能加载即可确认驱动版本被运维基线锁定模型规模小模型或单层算子真实业务模型和真实数据规模稳定性跑通几次即可连续运行数小时观察显存和温度数据记录只记录时间记录版本、输入、输出、日志和监控指标无论 GPU 是自购还是租用验收思路都一样。租用 GPU 时尤其要注意不同机器可能使用不同驱动版本、不同 PCIe 配置跑出的 benchmark 差异很大不能直接拿一个数字代表全部机器。5. 接入真实业务前最常踩的四个坑5.1 设备能识别但关键算子不支持现象torch.cuda.is_available()返回 True也能创建随机张量但跑 Transformer 模型时某个算子报 “not implemented” 或 “fallback to CPU”。常见原因厂商算子库覆盖不全某个复杂算子没有提供 GPU 实现。检查方式在代码中打印模型使用的算子逐个确认是否走了 GPU观察日志中是否有 CPU fallback 的告警。处理建议先尝试升级厂商运行时或算子库如果该算子确实没有适配需要修改模型结构用等价算子替换都不行时再考虑降级方案。5.2 容器里看不到 GPU现象宿主机上设备正常但进入容器后gpu-smi或框架脚本看不到 GPU。常见原因容器启动时没有把 GPU 设备节点、驱动模块目录和对应库文件挂载进容器。检查方式先在宿主机确认设备路径再对比容器内是否存在相同路径。不同厂商容器挂载方式不同不要默认使用docker run --gpus all。处理建议使用厂商提供的容器镜像或者按官方文档挂载设备节点和库目录。生产环境使用 Kubernetes 时必须确认厂商是否提供 device plugin。5.3 多卡训练速度不升反降现象从单卡扩展到多卡后总吞吐量没有提升反而比单卡更慢。常见原因数据加载成为瓶颈多卡通信没有走高速链路或者框架的分布式初始化没有真正把每个进程绑定到不同设备上。检查方式nproc观察启动日志中每个进程对应的设备编号。如果多个进程被分配到同一个设备后续通信就会出现资源争抢。处理建议先做单卡基准再做多卡小规模测试确认模型输入管线有足够并行度排查 PCIe 通道、NVLink 等价互联链路的状态。多卡性能不是配置几个环境变量就一定能提升的。5.4 虚拟机或容器环境中出现设备访问失败现象启动程序时日志出现类似failed to initialize nvml: gpu access blocked by the operating system的提示。常见原因在 WSL、虚拟机或受限容器中使用 GPU 时宿主系统没有开放设备透传权限或者安全策略阻止了驱动访问硬件。检查方式确认当前环境是物理机、虚拟机还是 WSL。确认宿主机的虚拟化设置允许 GPU 透传。确认当前用户是否有权限访问设备文件。处理建议如果只需要学习优先使用物理 Linux 环境或使用官方支持的容器方案。生产环境不要绕过权限限制应该通过正规的设备分配机制把 GPU 提供给虚拟机或容器。6. 从开发验证到生产上线一份可复用的检查清单6.1 新设备验收清单新到一台带国产 GPU 的服务器建议按下面的顺序逐项检查操作系统版本和内核版本是否在官方支持矩阵内。通过lspci确认 GPU 设备被系统识别。驱动安装完成后用厂商管理命令确认设备数量和显存正确。创建独立 Python 环境安装适配版本的 PyTorch 和插件。运行设备检查脚本确认框架能列出 GPU。运行最小矩阵运算确认算子执行正常。运行真实模型确认没有 CPU fallback 告警。记录 benchmark 基线包括设备名、驱动版本、框架版本、输入尺寸和耗时。长时间空载和满载各运行一段时间观察温度、显存和日志。这套清单同样适用于 GPU 租用场景。租用的机器如果没有通过验收性能问题会很难归因。6.2 生产环境还要补齐运维能力开发环境跑通只是第一步。生产上线前要额外确认以下内容检查项具体要求日志驱动、框架、业务日志要能独立采集和检索监控设备温度、显存占用、算力利用率要有指标采集权限GPU 设备权限要受控不能随便让业务容器拿到所有设备回滚驱动和框架版本要能快速回滚建议保留已验证的软件组合调度多机多卡场景要明确使用哪个分布式框架和通信方式备份模型权重和训练检查点要独立备份不能只依赖 GPU 服务器注意生产环境不要只验证“程序能启动”。输入输出是否符合预期、异常分支是否会被记录、显存泄漏是否会发生这些都比启动成功更重要。6.3 不要把性能验收变成单点跑分做性能评估时最好固定三类信息硬件型号、软件版本、测试脚本。三者只要有一个变化对比就没有意义。建议把每次测试的信息保存成一个文本文件放在 benchmark 结果旁边gpu_model: biren gpu driver_version: 以官方文档为准 pytorch_version: 2.1.1 os: ubuntu 22.04 kernel: 5.15.0-91-generic test_case: llama2-7b inference, batch_size8 result: xxx tokens/s issue: 备注这样后续排查性能回退时可以快速判断是硬件变化、驱动变化还是模型输入变化。否则同样的模型在不同版本下跑出不同速度很难定位问题。7. 后续需要持续观察的三个方向国产 GPU 从“能跑 demo”到“能扛生产任务”还有三个地方值得长期关注。第一个是算子覆盖率和编译能力。GPU 的上限由芯片决定但实际体验的上限由编译器、算子库和框架适配决定。算子覆盖越完整业务模型越不需要为 GPU 修改结构。第二个是推理服务化和资源调度。真实业务更多是推理场景需要把 GPU 接入到在线服务、容器调度和弹性扩缩容体系中。调度层是否支持设备隔离、显存隔离和故障转移直接影响运维成本。第三个是长期稳定性。一次 benchmark 跑得快不代表连续运行一周不出问题。内存泄漏、驱动崩溃、多卡通信超时、温度过高触发的降频都需要通过真实业务逐步暴露。回到开头那个数字壁仞科技上半年收入 12.36 亿元同比增长 1997.6%说明国产 GPU 正在进入规模化采购阶段。但采购之后研发团队要面对的才是真正的技术考验能不能在三天内把环境跑通能不能让真实模型稳定运行能不能在出问题时快速定位到驱动层、框架层还是业务层。这些问题没有捷径只能靠一套清晰的环境检查、功能验证、性能基准和问题排查流程来解决。把这一步做扎实比只看营收数字更能决定国产 GPU 能否真正从机房走向业务。
