如果只看新闻标题很多人会把“国产 GPU 收入同比增长 1997.6%”当成一条普通的融资或财报消息划过去就算了。但放在 AI 算力紧张、大模型训练推理成本居高不下的背景下这个数字值得展开聊一聊壁仞科技上半年收入 12.36 亿元同比增速接近 20 倍说明国产 GPU 已经从“能不能用”进入“有没有人批量买”的阶段。这篇文章不打算复述新闻稿而是从技术选型和本地部署的角度拆解这件事壁仞的产品线覆盖哪些场景如果你想在国产 GPU 上跑模型推理或训练环境该准备什么驱动、框架、监控工具怎么搭跑通后怎么验证性能和显存占用以及最容易被忽略的生态适配问题。无论你是做 AI 基础设施选型还是团队里已经有国产 GPU 服务器、准备把 PyTorch 推理任务从 CUDA 迁过来这篇都可以作为一份偏实战的参考清单。整个过程按“看懂数据 - 知道产品线 - 准备环境 - 启动服务 - 跑通验证 - 排查问题”展开。1. 核心数据速览12.36 亿收入背后的关键信号先把标题里最关键的两个信息拆开看。数据项数值信号意义上半年收入12.36 亿元已形成规模化销售不再是样品或小批量供货收入同比增速1997.6%去年同期基数较低但增速本身说明出货量在快速放大收入性质硬件销售为主国产 GPU 进入商业化交付阶段定位国产通用 GPU / AI 加速卡覆盖训练、推理两大方向从技术角度解读1997.6% 的同比增速能说明两类问题一是国产 GPU 的客户不再只集中在研究所和高校。互联网厂商、AI 创业公司、智算中心开始把国产卡纳入真实业务环境采购量才能把收入拉起来。二是软件栈的成熟度在提升。如果驱动、编译器、PyTorch 适配始终不可用客户买回去只能跑 demo不会有二次采购。能出现 20 倍增长说明至少有一部分客户已经在跑真实业务负载。不过这里也要泼一盆冷水收入增速高不代表整体生态已经完全追平 CUDA。对开发者来说国产 GPU 的框架适配、算子覆盖、分布式通信库成熟度才是决定能不能落地的核心变量。后面几节会专门展开。2. 壁仞科技产品线与技术路线看点壁仞科技的产品线公开资料里覆盖了几个方向AI 训练、AI 推理、通用计算。不同型号的芯片定位不同有的偏向高算力训练有的偏向高性价比推理有的主打通用计算场景。官方没有统一公开每一款卡的全部参数所以这里不做具体数字罗列只梳理技术选型时需要关注的产品维度。2.1 训练场景看算力和互联大模型训练对 GPU 的核心要求有两个单卡算力够不够高多卡互联带宽够不够大。壁仞这类国产训练卡通常会在以下规格上做差异化FP16 / BF16 算力决定混合精度训练速度显存容量决定单卡能不能装下大模型卡间互联带宽决定多卡并行时梯度同步效率是否支持类似 NCCL 的分布式通信库决定能否跑大规模并行训练从公开资料看壁仞在训练卡的互联方案上强调高带宽和低延迟整体思路与主流 AI 加速卡一致。但真正要验证的还是 PyTorch DDP 或 DeepSpeed 这类框架在国产卡上的实际加速比。2.2 推理场景看显存、吞吐和延迟推理任务通常更关注单位成本能处理多少并发请求。模型推理卡的核心指标包括显存容量和带宽影响 batch size 上限INT8 / FP8 量化支持影响推理吞吐单卡功耗和散热影响机房部署密度兼容 PyTorch / ONNX Runtime / vLLM 的程度影响主流推理框架能否直接跑如果国产 GPU 能稳定运行 vLLM、TGI 这类推理加速框架那么开发者迁移成本会大幅降低。如果只能跑自家推理引擎就需要评估引擎的 API 兼容性和社区活跃度。2.3 生态适配决定开发体验的关键变量对开发者来说性能数据再好看框架跑不起来就等于零。选型国产 GPU 时生态方面至少要看这几层驱动是否支持主流 Linux 发行版是否有类似 CUDA 的计算平台层还是完全自研PyTorch 是官方适配还是第三方补丁版本跟随是否及时常用算子覆盖情况特别是 Transformer、卷积、MatMul、Attention 等高频算子是否能跑主流 AI 推理框架vLLM、TGI、TensorRT-LLM 的国产卡版本从材料看壁仞在生态层面的投入在增加但具体算子覆盖还需要根据你的实际模型做验证。最稳妥的方式是拿自己业务的 1 到 2 个典型模型先在卡上跑一遍 benchmark再决定是否做批量迁移。3. 国产 GPU 本地部署环境准备跑推理任务的前置条件不管买的是壁仞的卡还是其他国产 GPU本地部署的第一步都是确认硬件、系统、驱动、框架四层环境是否匹配。以下是一套通用的环境检查清单适用对象是负责部署的工程师。3.1 硬件层检查先确认服务器是否能正常识别 GPU 设备。# 查看 PCIe 设备列表中的 GPU 设备 lspci | grep -i processing\|accelerator # 查看系统是否识别到 GPU 设备节点 ls /dev/dri/ ls /dev/accel* 2/dev/null如果设备节点存在说明系统层面已经识别到了硬件。如果没有任何输出先查 PCIe 插槽接触和主板 BIOS 设置。3.2 操作系统和内核国产 GPU 驱动通常对 Linux 发行版有一定要求常见支持范围是 CentOS / Ubuntu / 统信 / 麒麟等。# 查看系统版本 cat /etc/os-release # 查看内核版本 uname -r建议优先使用官方驱动文档中明确列出的操作系统版本。内核版本过新或过旧都可能导致驱动编译失败或加载异常。3.3 驱动安装国产 GPU 驱动安装通常有几种形式官方 deb/rpm 包、一键安装脚本、源码编译。通用安装流程模板# 下载驱动包后解压 tar -xzf driver_package.tar.gz cd driver_package # 执行安装脚本通常需要 root 权限 sudo ./install.sh # 安装完成后重启或重新加载驱动 sudo reboot安装完成后使用厂商提供的监控工具检查驱动状态类似 N 卡的nvidia-smi# 检查 GPU 状态 # 具体命令以厂商工具为准可能是 bcesmi / br-smi / xsmi 等如果系统里找不到监控命令检查驱动安装路径是否加入了 PATH或者驱动工具是否安装到/usr/bin。3.4 计算框架安装国产 GPU 通常不会直接兼容 CUDA需要安装对应的计算平台运行时和 PyTorch 适配版本。通用步骤如下# 创建虚拟环境避免污染系统 Python python3 -m venv venv_gpu source venv_gpu/bin/activate # 安装 PyTorch 适配版本 # 注意需要使用厂商适配的 wheel 包而不是官方默认版本 pip install torch torchvision torchaudio --index-url 厂商提供的源安装完成后用一小段代码验证设备是否可见。import torch # 检查设备是否存在 print(torch.cuda.is_available()) # 如果框架层做了 CUDA 兼容这里可能返回 True print(torch.cuda.device_count()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else No GPU)如果 PyTorch 版本是厂商深度适配过的torch.cuda.is_available()可能会返回True从应用层看和 CUDA 使用方式一致。如果返回False说明框架和驱动之间存在问题后文会讲排查思路。4. 驱动、计算框架与开发启动流程环境准备好之后接下来要跑通一条从“设备识别”到“模型推理”的最小链路。4.1 确认 GPU 设备可见驱动安装完成后先确认设备状态正常。# 查看设备整体状态 gpu-smi 2/dev/null || echo 请使用厂商提供的监控工具常见输出信息包括GPU 型号、驱动版本、显存总量、已用显存、温度、利用率。如果显存显示为 0 或设备状态异常优先检查驱动是否匹配当前内核。4.2 跑一个最小张量计算用 PyTorch 在 GPU 上执行一次矩阵乘法验证基础计算链路。import torch # 构造两个随机矩阵 a torch.randn(1024, 1024, devicecuda) b torch.randn(1024, 1024, devicecuda) # 执行矩阵乘法 c torch.matmul(a, b) # 将结果同步回 CPU触发一次计算完成确认 result c.cpu() print(result.shape) print(GPU compute ok)这段代码如果能顺利执行说明驱动、计算运行时、PyTorch 适配层都正常。4.3 跑一个真实的大模型推理下一步用一个公开小模型验证完整推理链路。from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-0.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name).to(cuda) prompt 解释一下什么是 GPU 显存 inputs tokenizer(prompt, return_tensorspt).to(cuda) outputs model.generate(**inputs, max_new_tokens128) response tokenizer.decode(outputs[0], skip_special_tokensTrue) print(response)这一步会真实反映几个问题模型能否成功加载到显存算子是否全部有适配实现生成速度是否可用如果在这个环节报算子不支持或者显存不足就需要回到框架版本和模型精度上做调整。4.4 启动推理服务模型验证通过后可以用 FastAPI 或 vLLM 起一个简单的 HTTP 推理服务。pip install fastapi uvicornfrom fastapi import FastAPI, Request from transformers import AutoModelForCausalLM, AutoTokenizer import uvicorn app FastAPI() tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-0.5B-Instruct) model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-0.5B-Instruct).to(cuda) app.post(/generate) async def generate(request: Request): data await request.json() prompt data.get(prompt, ) inputs tokenizer(prompt, return_tensorspt).to(cuda) outputs model.generate(**inputs, max_new_tokens128) response tokenizer.decode(outputs[0], skip_special_tokensTrue) return {response: response} if __name__ __main__: uvicorn.run(app, host127.0.0.1, port8000)python server.py启动后可以用 curl 测试接口curl -X POST http://127.0.0.1:8000/generate \ -H Content-Type: application/json \ -d {prompt: 用一句话介绍壁仞科技}到这里国产 GPU 的本地推理链路就算完整跑通了。5. 在国产 GPU 上做功能测试与效果验证设备跑通之后还需要一套系统化的测试方案才能判断这块卡适不适合你的业务。以下测试矩阵可以直接复用。5.1 设备识别测试测试目的确认驱动和框架层都能正确识别设备和显存。验证命令查看总显存、可用显存、设备名称是否正确。5.2 基础算力测试测试目的确认高频算子有适配实现性能是否符合预期。测试内容密集矩阵乘法、大规模张量拷贝、卷积运算。5.3 大模型推理测试测试目的验证真实业务模型的兼容性。测试步骤选一个和业务接近的开源模型分别用 FP32 / FP16 / INT8 加载记录加载时间和显存占用用相同提示词生成固定长度文本记录延迟和吞吐建议记录表格模板测试项输入大小显存占用生成速度成功率小模型 FP32128 tokens待测待测待测小模型 FP16128 tokens待测待测待测量化 INT8128 tokens待测待测待测批量 4 请求128 tokens待测待测待测5.4 批量任务测试生产环境通常需要批量推理。建议构造 100 到 1000 条真实请求测试服务的稳定性。import requests import threading import time url http://127.0.0.1:8000/generate prompts [测试文本 {}.format(i) for i in range(20)] def send_request(prompt): response requests.post(url, json{prompt: prompt}, timeout120) return response.status_code start time.time() threads [] for prompt in prompts: t threading.Thread(targetsend_request, args(prompt,)) t.start() threads.append(t) for t in threads: t.join() print(耗时, time.time() - start)批量测试重点观察显存是否会持续上涨不释放、是否存在内存泄漏、任务是否卡死。5.5 训练任务测试如果业务涉及微调需要额外验证训练链路。建议先用 LoRA 方式做一个小规模微调不要直接跑全量训练。观察指标是否支持反向传播显存占用峰值多卡并行是否正常梯度同步是否有明显瓶颈从材料看国产 GPU 在训练侧的适配普遍比推理侧复杂务必先用最小配置验证。6. 资源占用与性能观察方法部署 AI 服务时只看“能不能跑”不够还得知道“跑得怎么样”。6.1 显存占用观察方法国产 GPU 一般会提供类似nvidia-smi的监控工具。如果没有独立工具也可以通过 PyTorch 查询显存状态import torch if torch.cuda.is_available(): total_memory torch.cuda.get_device_properties(0).total_memory allocated_memory torch.cuda.memory_allocated(0) reserved_memory torch.cuda.memory_reserved(0) print(总显存, total_memory / 1024**3, GB) print(已分配, allocated_memory / 1024**3, GB) print(已预占, reserved_memory / 1024**3, GB)也可以使用torch.cuda.memory_summary()查看更详细的显存分配情况。6.2 CPU / 内存占用观察用系统工具实时观察# 每 2 秒刷新一次 GPU 状态 watch -n 2 gpu监控工具 # 查看 CPU 和内存 top如果推理过程中 CPU 占用持续接近 100%说明数据预处理或 Tokenizer 部分成了瓶颈需要优化或异步化。6.3 影响性能的关键参数推理性能受几个参数影响明显batch size增大 batch 能提升吞吐但显存占用随之上升输入序列长度越长显存占用越高部分算子耗时呈平方增长输出长度直接影响单次请求延迟量化精度FP16 和 INT8 的吞吐差异可能很大并发请求数过高会导致排队和显存溢出建议先用小 batch 跑通再逐步加压找到性能和显存的平衡点。6.4 如何降低显存占用如果遇到显存不足按以下顺序尝试切换为 FP16 混合精度加载开启量化INT8 / INT4减小最大输入长度降低 batch size使用 offload 方案将部分层放在 CPU 上需要强调的是量化后模型精度会变化必须在测试集上验证输出质量。7. 国产 GPU 生态适配与常见问题排查国产 GPU 部署过程中开发者遇到最多的问题集中在驱动、框架、显存、WSL 访问几个方面。下面整理一张常见问题排查表。问题现象可能原因排查方式解决方案装完驱动后 GPU 工具无输出驱动加载失败或工具未加入 PATHlsmodgrep 模块名查看内核模块PyTorch 检测不到设备框架版本和驱动不匹配运行python -c import torch; print(torch.cuda.is_available())安装厂商推荐的 PyTorch 适配版本模型加载时报算子不支持PyTorch 适配层算子覆盖不全查看报错中提示的算子名称确认是否有替代实现升级框架版本或改用厂商建议的模型结构推理速度比预期慢很多未开启图模式或算子未融合对比 CPU/GPU 执行时间查看 GPU 利用率开启torch.compile或厂商提供的加速方案WSL 环境下 GPU 访问被阻止操作系统或虚拟化层未配置 GPU 直通检查报错信息中是否包含gpu access blocked by the operating system在 Windows 主机侧更新 WSL 或关闭阻止 GPU 访问的安全策略显存不足batch size 过大或显存碎片化观察实际占用减小 batch启用量化批量任务卡住死锁或显存泄漏查看日志和显存占用趋势任务级超时、失败重试、定期重启服务API 请求超时并发过高或单次生成过长查看服务端日志和队列长度加限流控制并发数优化模型长度驱动安装后系统无法启动驱动与内核模块冲突进入恢复模式卸载驱动重新安装与内核版本匹配的驱动其中 WSL 环境下的 GPU 访问问题比较典型。很多开发者习惯在 Windows 上用 WSL 跑 Linux 环境但国产 GPU 驱动对 WSL 的支持程度需要提前确认。如果看到gpu access blocked by the operating system大概率是 GPU 直通策略或 WSL 版本问题优先在 Windows 主机侧排查而不是在 Linux 环境里反复重装驱动。8. 最佳实践与使用建议结合国产 GPU 的生态现状给准备落地的团队几个实操建议。8.1 第一次接触先跑通最小案例不要一上来就跑 70B 大模型或大规模分布式训练。先拿一个 0.5B 或 1B 的开源模型跑通驱动、框架、推理服务三个环节确认全链路没有隐藏问题再逐步增加模型规模和并发。8.2 保留一套最小可运行环境记录把最终验证通过的以下信息记录下来操作系统版本和内核版本驱动版本和安装方式Python 版本和 PyTorch 适配版本模型名称和加载精度关键启动命令这套记录在后续排障时价值极高尤其是团队内部环境不一致的情况下。8.3 模型文件、输入素材、输出结果分目录管理建议目录结构如下/home/user/ ├── models/ # 模型权重 ├── inputs/ # 测试输入 ├── outputs/ # 推理输出 ├── logs/ # 服务日志 └── scripts/ # 部署和测试脚本避免把所有文件堆在同一个目录后续排查问题会非常痛苦。8.4 批量任务要加日志和失败重试批量推理不是“循环调用接口”这么简单。生产级批量任务至少要做到每个任务记录开始时间、结束时间、状态失败任务自动重试 1 到 2 次重试仍失败的任务单独落盘便于复盘设置单任务超时时间防止卡死拖垮整个队列8.5 接口服务要限制访问范围如果开启 HTTP 接口服务默认只绑定在 127.0.0.1不要直接暴露到公网。uvicorn.run(app, host127.0.0.1, port8000)如果需要在局域网内访问也要加认证和 IP 白名单。8.6 涉及人脸、声音、版权素材时确认授权如果国产 GPU 跑的是图像生成、语音合成、数字人这类任务务必确认训练数据和推理素材都具备合法授权。特别是人脸和声音相关能力绝不能用于未授权的身份模仿。8.7 发布或商用前做效果复核国产 GPU 在量化精度、算子实现上和主流 GPU 可能存在细微差异。同样的模型在不同硬件上输出可能有偏差。商用前建议在固定测试集上做效果对比确认输出质量符合要求。9. 总结与后续关注点回到开头那个数据12.36 亿元收入、1997.6% 同比增长。这个数字对产业界意味着国产 GPU 已经走完了“样品验证”阶段开始进入规模化交付。但对开发者来说真正的考验是在具体服务器上把模型跑起来、跑得快、跑得稳。最值得优先验证的不是跑分而是这几件事驱动装完设备是否能稳定识别PyTorch 适配版本能不能覆盖你业务的高频算子你常用的推理框架是否能直接跑还是需要额外适配批量任务和接口服务在持续压力下是否稳定最容易踩的坑也很集中框架版本和驱动不匹配、算子不支持、显存管理策略不熟悉、WSL 环境访问被阻止。这些问题的排查思路在上文表格里已经列出来了遇到时可以对照处理。后续值得继续观察的方向包括壁仞产品线在训练场景的分布式能力、国产卡对 vLLM 等主流推理框架的适配程度、以及大规模量化推理时的稳定性和精度表现。对于已经在做国产化适配的团队建议先用文中这套流程跑通一个最小业务模型拿到真实的显存占用和性能数据后再决定是否扩大迁移范围。如果想跟进国产 GPU 相关技术进展建议收藏本文后面有新的适配版本或工具链信息可以在此基础上继续验证。