开头不用标题直接写正文。GPU 缺货是这两年 AI 工程师最熟悉的焦虑。想训一个开源大模型先去各大云厂商抢卡抢不到就排队排到以后还要面对昂贵的按小时计费。在这种背景下国产 GPU 厂商的发展进度从来不只是股票新闻而是直接影响技术选型、成本结构和软件生态的重要变量。壁仞科技上半年收入 12.36 亿元同比增长 1997.6%。这个数字看起来像财报摘要但它背后是一个值得开发者认真对待的技术信号国产 GPU 正在从“样品展示期”进入“规模交付期”。营收大幅增长意味着厂商有了更多资金去完善驱动、编译器、计算库和框架适配而这些恰恰是普通开发者真正会踩坑的地方。这篇文章不打算只复述新闻。我会从技术人的视角拆解这个数据为什么重要、国产 GPU 和 NVIDIA GPU 的差异到底在哪里、当你拿到一台国产 GPU 服务器时该怎么评估、适配和排错。读完以后你至少能对“国产 GPU 能不能用、怎么用、值不值得用”建立一个更清晰的判断框架。1. 为什么一个 GPU 厂商的收入增长值得开发者关注先抛出一个更直接的判断**GPU 厂商的收入增长比它的跑分增长更值得关注。**跑分决定的是一块卡的理论上限收入决定的是一家厂商能否持续投入软件生态。过去几年国内有不少芯片团队陆续发布过 GPU 产品发布会上经常出现对标旗舰卡、算力密度高、功耗控制好这类说法。但从开发者角度看更关键的问题是这块卡能不能稳定跑 PyTorch算子支持全不全驱动会不会频繁报错这些问题靠发布会解决不了本质上靠钱解决——需要持续投入去写驱动、维护编译器、适配主流深度学习框架。壁仞科技的营收增长至少有几点技术层面的解读第一它说明产品有量在交付不是停留在 PPT 阶段。只有大规模部署才会产生持续性的收入只有客户真正在跑负载后续的兼容性问题、性能问题才能进入修复闭环。第二它意味着软件栈投入有了财务基础。一个年收入达到十亿级别的 GPU 厂商有底气去扩充软件团队、做更多框架适配。这对开发者是好事因为生态成熟度最终会体现在你能不能用现成工具链把模型跑起来。第三它改变了国内 AI 算力的供给结构。对于正在做技术选型的团队来说多一个可选项就意味着在议价、交付周期和供应链安全上多一份主动权。当然也要冷静看待高速增长有基数低的因素1997.6% 的同比增速并不能直接推导出国产 GPU 已经全面比肩行业标杆。更稳妥的判断是国产 GPU 来到了一个“能不能用”初步解决、“好不好用”仍需验证的阶段。2. 国产 GPU 行业的现状与壁仞科技的技术定位要理解壁仞科技的定位先看整个国产 GPU 赛道。目前业内经常提到的国产算力芯片厂商包括华为昇腾、寒武纪、海光、壁仞等。它们的技术路线和侧重点并不完全一样。有的走 AI 专用加速器路线有的做通用 GPU有的偏向训练有的主攻推理有的生态相对封闭有的更强调兼容主流开发习惯。壁仞科技的公开定位是面向人工智能计算和数据中心场景推出 GPU 产品强调通用计算能力。所谓“通用计算”意思是它不止能跑 AI 推理和训练也面向科学计算类负载。这个定位和 NVIDIA 的通用 GPU 路线更为接近决定了两件事一是目标客户在意的算力形式更宽二是对软件生态的完整性要求更高。从行业阶段看国产 GPU 整体还处于“硬件基本可用、生态加速补齐”的阶段。硬件层面芯片设计能力这几年有明显进步在算力密度、互联带宽等维度已经能支撑一定规模的 AI 训练软件层面从驱动到编译到框架适配相比 NVIDIA 的 CUDA 生态仍有差距。这种差距不是单纯靠堆人就能追上需要大量客户真实负载去暴露问题、修复问题。壁仞营收增长的意义恰好是这个阶段的缩影。它说明有一部分客户已经愿意在真实业务中部署国产 GPU。再往后真正决定产品口碑的不是首发性能数字而是生产环境中跑三个月后稳定性如何、算子覆盖率多高、出了问题响应多快。2.1 国产 GPU 的市场关注点从参数转向生态过去大家对国产 GPU 的关注往往集中在单卡算力、显存大小、互联带宽这些硬件参数上。这些确实重要但并不是项目跑不起来的首要原因。多数 AI 项目的技术栈是PyTorch/TensorFlow CUDA cuDNN 各种算子库。这套技术栈经过多年沉淀功能丰富、文档齐全、社区案例多。国产 GPU 如果只把硬件做出来而软件栈不够完善开发者拿到卡之后仍然会遇到“模型结构能识别、精度对不上、某个算子不支持”等一连串问题。所以国产 GPU 厂商真正要补的课是把以下这些软件能力补齐底层驱动的稳定性和性能。计算库类似 cuBLAS、cuDNN 的角色的功能覆盖。主流深度学习框架的适配和性能优化。调优工具、Profiling 工具是否好用。社区文档、示例代码、Issue 响应速度。从壁仞这次收入数字看它至少已经获得了一部分客户的付费信任。后续如果收入能维持高增长软件栈的补齐速度会明显加快。3. GPU 相关基础概念从 CPU 到 NPU再到国产 GPU聊到 GPU 生态很多人会混淆一批概念CPU、GPU、TPU、NPU 到底有什么不同这里先花一点篇幅把基础梳理清楚后面讲适配才有共同语言。用通俗比喻来说CPU 像一位学识渊博的教授擅长处理逻辑复杂、分支繁多的任务但核心数量有限不擅长海量重复劳动。GPU 像一支千人规模的流水线工人团队单个人不算顶尖但数量多、分工明确最适合做大量可并行计算的数学运算。NPU/TPU 更像是为 AI 运算专门定制的特种流水线针对矩阵乘、卷积这类操作做了更激进的优化灵活度通常低于通用 GPU。AI 训练和推理大量依赖矩阵乘法与卷积运算这类运算天然适合 GPU 的并行架构。这也是为什么大模型训练、微调、推理普遍把 GPU 作为主力计算设备。下面用一个简单表格对比处理器类型核心特点适合任务典型代表CPU核心少单核逻辑强频率高通用逻辑、分支判断、IO 调度Intel Xeon、AMD EPYCGPU核心多并行度高擅长矩阵运算AI 训练、大规模图形渲染、科学计算NVIDIA A100/H100、壁仞数据中心 GPUNPU面向 AI 算子深度定制能效比高边缘推理、端侧 AI手机 SoC 中的 AI 单元TPUGoogle 定制面向 TensorFlow 工作负载云端训练与推理Google TPU对于国产 GPU更准确的理解是它属于通用 GPU 路线理论上可以承载 AI 之外的科学计算任务但在实际落地中AI 负载仍然是当前最大的需求来源。3.1 为什么软件生态是 GPU 产业的真正壁垒很多开发者问过一个问题国产 GPU 硬件追得很快为什么大家还是觉得不够好用答案很大程度在软件生态。NVIDIA 的 CUDA 生态不是一天建成的它包含驱动、编译器、数学库、通信库、性能分析工具还有数百万开发者积累的论坛帖子和开源项目。这些资产让后来者在硬件上追赶时必须额外面对一道软件高墙。国产 GPU 的破局策略大致分两类一类是自建生态提供一套完整的软件栈但需要开发者迁移和学习。另一类是主动兼容主流开发习惯在接口设计、编译工具上尽可能与 CUDA 生态对齐降低迁移成本。壁仞这类通用 GPU 厂商更偏向后者。对开发者而言这实际上是性价比最高的路径——代码不用推倒重写只需要处理设备选择、算子兼容性和少量性能调优。4. 环境准备GPU 开发环境的基本组成不管你是用 NVIDIA GPU 还是国产 GPUAI 开发环境的基本组成是一致的通常包括操作系统生产环境一般用 Linux 服务器。GPU 驱动程序。计算库CUDA/cuDNN 或者对应的国产计算库。Python 环境与深度学习框架。包管理工具pip/conda。在真正进入国产 GPU 适配前先把这套环境概念理顺很重要。后续的排错思路基本都是围绕这几层逐层排查的。4.1 驱动层一切问题的大门GPU 驱动是操作系统与硬件之间的桥梁。驱动没装好上层一切免谈。在 NVIDIA 环境下我们用nvidia-smi查看驱动、显存和卡状态。这是每个做 AI 的开发者都熟悉的命令nvidia-smi输出的关键信息包括驱动版本、CUDA 版本、每块 GPU 的显存使用情况、利用率、当前进程。国产 GPU 环境也有对应的设备查看工具只是具体命令不同。因为不同厂商的软件栈命名不一这里不写死命令但排查思路是通用的驱动是否加载成功。系统是否识别到了 GPU 设备。计算库版本与驱动是否匹配。框架是否能识别到设备。4.2 工具链层从 CUDA 到国产计算库在 NVIDIA 环境里CUDA 包含编译器nvcc、运行时库、数学库 cuBLAS、深度学习库 cuDNN、通信库 NCCL 等。国产 GPU 厂商通常会提供功能对标的计算库接口设计上会尽量贴近主流习惯但实现和具体 API 会有差异。对于大多数 AI 工程师日常接触 CUDA 的机会可能只是安装 PyTorch 时选择带 CUDA 的版本。真正的关系是这样PyTorch - CUDA/cuDNN - GPU 驱动 - GPU 硬件每一层只依赖下一层。所以排查问题时应该从上往下走先看代码能否识别 GPU再看框架版本是否支持当前 GPU 的计算能力再看驱动是否正常最后才是硬件本身。5. 一个可落地的 GPU 适配示例从检测到模型推理这一部分我们用几个可在 GPU 服务器上运行的示例把“拿到一台 GPU 机器后应该做什么”讲清楚。示例以 PyTorch 为例因为它是当前 AI 开发者的主流框架。先说前提下面的代码在标准 NVIDIA GPU 环境下一定可以运行。国产 GPU 如果已完成 PyTorch 适配在自行安装对应的框架版本后多数代码也可以复用因为 PyTorch 的接口是统一的。5.1 示例一检测 GPU 是否可用这是所有 AI 项目的“开机自检”。把环境问题最早暴露出来比到模型训练中途再崩溃要省事得多。import torch print(PyTorch 版本:, torch.__version__) print(CUDA 是否可用:, torch.cuda.is_available()) print(GPU 数量:, torch.cuda.device_count()) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): props torch.cuda.get_device_properties(i) print(f设备 {i}: {props.name}, 显存: {round(props.total_memory / 1024**3)} GB) else: print(当前环境未检测到可用 GPU程序将回退到 CPU 运行)这段代码的意义在于快速判断环境可用性。如果torch.cuda.is_available()返回False说明驱动、计算库、框架三者之间至少有一层有问题。如果返回True才能继续往下走。5.2 示例二把张量放到 GPU 上执行运算很多新手会把“模型跑了”误认为“GPU 在干活”。实际上如果代码里没有显式把数据和模型转到 GPUPyTorch 默认在 CPU 上计算性能会很差。import torch # 构造两个随机矩阵 a torch.randn(4096, 4096) b torch.randn(4096, 4096) # CPU 计算 import time start time.time() c_cpu torch.matmul(a, b) cpu_time time.time() - start # GPU 计算 device torch.device(cuda if torch.cuda.is_available() else cpu) a_gpu a.to(device) b_gpu b.to(device) start time.time() c_gpu torch.matmul(a_gpu, b_gpu) gpu_time time.time() - start print(fCPU 矩阵乘法耗时: {cpu_time:.4f} 秒) print(fGPU 矩阵乘法耗时: {gpu_time:.4f} 秒)如果 GPU 环境正确矩阵乘法这种并行计算负载下GPU 耗时应该显著低于 CPU。这里要注意初始化 CUDA 上下文通常有额外开销所以更严谨的做法是在代码块前面先运行一个预热操作但作为快速验证已经足够。5.3 示例三加载 HuggingFace 模型到 GPU 做推理实际项目中我们更多要面对的是“把模型跑起来”这个完整任务。下面示例使用 transformers 库加载一个小型模型完成一次文本生成。from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_name microsoft/phi-2 device torch.device(cuda if torch.cuda.is_available() else cpu) print(f使用设备: {device}) tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) model.to(device) model.eval() prompt 国产 GPU 在 AI 时代的发展趋势是 inputs tokenizer(prompt, return_tensorspt).to(device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens64, do_sampleTrue, temperature0.7 ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) print(result)这段代码里值得注意的点有三个第一model.to(device)把模型权重搬到 GPU。忘记这行模型还是在 CPU 上跑。第二inputs.to(device)也很关键。输入数据如果不搬到 GPU执行时会发生设备不匹配的报错。第三torch.no_grad()在推理阶段关闭梯度计算减少内存占用这也是最佳实践。5.4 关于国产 GPU 适配版本的说明国产 GPU 厂商的 PyTorch 适配通常有两种方式提供编译好的专用 PyTorch 包通过 pip 安装。提供类似 CUDA 的计算库让标准 PyTorch 通过插件方式识别设备。具体走哪种方式以你拿到的厂商软件包为准。这里不写死某个命令因为不同阶段、不同产品线的安装方式差异很大。但一个通用建议是先向厂商或项目文档确认准确的安装命令再决定 pip install 的源和版本。宁可多花十分钟读文档也不要装完发现框架版本和计算库不匹配。6. 运行结果与性能验证前面几段代码跑通以后怎么判断“这是不是真的把 GPU 用好了”这里给出一套可执行的验证指标。6.1 观察设备状态在 NVIDIA 环境下最直观的方式是开另一个终端运行watch -n 1 nvidia-smi动态观察 GPU 利用率和显存变化。运行推理脚本时如果看到 Utilization 明显上涨、显存被占用说明 GPU 确实在参与计算。国产 GPU 环境同理用厂商提供的监控工具观察同一组指标即可。判断标准是一致的设备利用率没有明显波动说明待验证的负载并没有真正吃满 GPU。6.2 计算吞吐量对于 LLM 推理场景最常用的性能指标是每秒生成的 token 数。简单来说就是记录生成结束时间和生成文本长度计算出一个 tokens/s 数值。可以在上一节的生成代码里这样统计start_time time.time() outputs model.generate(...) elapsed time.time() - start_time generated_tokens outputs.shape[1] - inputs[input_ids].shape[1] throughput generated_tokens / elapsed print(f推理吞吐: {throughput:.2f} tokens/s)注意第一次推理包含模型加载和 CUDA 上下文初始化时间会明显偏长。如果要测评稳定性能应该先跑一次预热再开始计时。6.3 判断成功的标准不要把“程序没报错”当作唯一标准。更完整的成功标准是日志中明确显示设备为cuda:0或对应的国产设备编号。显存监控显示内存占用正常。推理结果符合预期。吞吐量处于合理范围。如果结果异常第一个排查方向永远是环境层级而不是代码逻辑。先确认设备可用再确认显存充足然后确认算子是否被当前计算库支持。7. 常见问题与排查思路结合很多 AI 项目的实际经验GPU 环境的报错大多集中在下面几类。以下表格可以作为快速排查清单。问题现象可能原因排查方式解决方案torch.cuda.is_available() 返回 False驱动未安装、框架版本不匹配、计算库缺失运行 nvidia-smi 查看驱动检查 PyTorch 版本是否为 GPU 版重装驱动安装匹配的 PyTorch GPU 版本报错 CUDA out of memory显存不足进程占用没有释放使用设备工具查看显存占用确认是否存在残留进程关掉残留进程减小 batch size梯度检查点模型权重加载后推理仍然慢设备分配语句遗漏模型仍跑在 CPU打印 model.device 检查设备位置观察 GPU 利用率添加 model.to(device) 和 inputs.to(device)算子不支持或报 NotImplementedError计算库版本过旧算子覆盖率不足查看报错的算子名称搜索对应支持版本升级计算库替换为等价算子多 GPU 时只有一张卡被使用代码未做并行化处理查看设备数量检查数据并行策略使用 DistributedDataParallel 或设备映射配置对于国产 GPU还有几个额外的排查建议第一先确认软件包来源。不要从非官方渠道安装驱动和计算库版本不匹配时问题最隐蔽。第二跑模型之前先跑一个最小的 tensor 运算脚本确认基础链路通不通。这样能把“环境问题”和“模型问题”快速分开。第三关注算子兼容性更新日志。国产 GPU 的算子支持列表是持续更新的今天不支持的算子可能下一版计算库就支持了。8. 部署国产 GPU 的最佳实践与工程建议营收数据的爆发意味着国产 GPU 会越来越多地出现在各级算力中心和政企采购清单里。作为开发者如果团队未来要评估或部署国产 GPU以下工程建议值得提前考虑。8.1 在代码层面抽象算力层不要把 CUDA 调用直接写在业务代码的每个角落。更推荐的做法是在项目里维护一个设备选择模块集中处理设备分配逻辑。这样将来无论是切换到国产 GPU还是从单卡扩展到多卡都不需要大面积改动。例如可以统一写一个工具文件import torch def get_device(): if torch.cuda.is_available(): return torch.device(cuda) return torch.device(cpu)然后在模型训练、推理、数据加载的代码里统一调用get_device()。这个习惯在 GPU 资源池化、混合部署的背景下很有价值。8.2 用标准 PyTorch 接口少碰特殊算子国产 GPU 适配的优先级通常以 PyTorch 高频算子为主。对开发者来说越标准的模型结构、越常规的算子迁移成本越低。反过来如果一个模型大量依赖自定义 CUDA Kernel那迁移到国产 GPU 时就需要额外做算子适配成本会显著上升。所以建议是优先选择主流开源模型架构。避免深度定制 CUDA Kernel除非是纯 CPU 或已确认目标 GPU 支持。训练时优先用 PyTorch 原生 API 完成分布式逻辑而不是依赖某个厂商的私有扩展。8.3 建立算子级兼容性测试清单在正式上线国产 GPU 环境前建议准备一组覆盖项目核心逻辑的最小测试用例数据加载。模型前向。模型反向。优化器 step。模型保存与加载。每个用例都记录是否通过、耗时、显存峰值。这套测试清单不仅适合初次适配也适合计算库升级后的回归验证。8.4 关注生产环境的备份与回滚在任何 GPU 环境变更前都要保持和数据库变更一样的谨慎记录当前驱动版本、计算库版本、框架版本。在高风险操作前备份系统配置或使用快照。保留回滚方案必要时先在一台非生产机器上验证。这条原则对 NVIDIA 环境适用对国产 GPU 环境更加适用。因为国产软件栈更新频率较高升级前做好回滚预案能避免很多不必要的生产事故。8.5 分阶段推进替换如果一个团队想尝试国产 GPU不必一上来就把核心生产任务全部迁移。更稳妥的分阶段策略是第一阶段用一个非核心的推理服务做技术验证。第二阶段验证稳定性、性能、运维工具链。第三阶段在评估结果达标后逐步扩大部署范围。这种方式既控制了风险也给了团队和厂商软件栈充分的磨合时间。9. 总结与后续学习方向回到开头的问题壁仞科技上半年收入 12.36 亿元、同比增长 1997.6%对普通开发者意味着什么我的判断是它意味着国产 GPU 已经走过了“能不能做出来”的阶段来到了“能不能卖好、好不好用”的阶段。这个阶段最直接的受益者就是开发者——更强的财务基础意味着软件生态会有更多投入更多客户的真实部署又意味着兼容性问题会被更快发现、更快修复。对开发者生态的补齐速度才是国产 GPU 能否立住的关键。从学习角度来看下一步值得关注的方向有四个第一关注主流深度学习框架对国产 GPU 的适配进度。PyTorch 新版本发布时留意是否有针对国产计算设备的适配说明。第二学习 GPU 编程基础理解算子、内核、显存调度等概念。不管是 NVIDIA 还是国产 GPU底层原理是相通的。第三在一台真实机器上跑通最小示例。没有上手实践所有讨论都只是纸面判断。第四搭建一套算力抽象层。无论未来团队怎么选型这一层都会帮你省下大量迁移成本。最后给一个落地建议下一次做 AI 项目时不妨在架构设计里把 GPU 设备抽成一个可配置项。技术上这并不复杂但它会大幅降低你在不同算力平台之间切换的摩擦。国产 GPU 不会是最后的选择但更可能是未来很长一段时间里不可忽视的选项。 国产GPU进入规模交付期：从生态评估到PyTorch适配实践
开头不用标题直接写正文。GPU 缺货是这两年 AI 工程师最熟悉的焦虑。想训一个开源大模型先去各大云厂商抢卡抢不到就排队排到以后还要面对昂贵的按小时计费。在这种背景下国产 GPU 厂商的发展进度从来不只是股票新闻而是直接影响技术选型、成本结构和软件生态的重要变量。壁仞科技上半年收入 12.36 亿元同比增长 1997.6%。这个数字看起来像财报摘要但它背后是一个值得开发者认真对待的技术信号国产 GPU 正在从“样品展示期”进入“规模交付期”。营收大幅增长意味着厂商有了更多资金去完善驱动、编译器、计算库和框架适配而这些恰恰是普通开发者真正会踩坑的地方。这篇文章不打算只复述新闻。我会从技术人的视角拆解这个数据为什么重要、国产 GPU 和 NVIDIA GPU 的差异到底在哪里、当你拿到一台国产 GPU 服务器时该怎么评估、适配和排错。读完以后你至少能对“国产 GPU 能不能用、怎么用、值不值得用”建立一个更清晰的判断框架。1. 为什么一个 GPU 厂商的收入增长值得开发者关注先抛出一个更直接的判断**GPU 厂商的收入增长比它的跑分增长更值得关注。**跑分决定的是一块卡的理论上限收入决定的是一家厂商能否持续投入软件生态。过去几年国内有不少芯片团队陆续发布过 GPU 产品发布会上经常出现对标旗舰卡、算力密度高、功耗控制好这类说法。但从开发者角度看更关键的问题是这块卡能不能稳定跑 PyTorch算子支持全不全驱动会不会频繁报错这些问题靠发布会解决不了本质上靠钱解决——需要持续投入去写驱动、维护编译器、适配主流深度学习框架。壁仞科技的营收增长至少有几点技术层面的解读第一它说明产品有量在交付不是停留在 PPT 阶段。只有大规模部署才会产生持续性的收入只有客户真正在跑负载后续的兼容性问题、性能问题才能进入修复闭环。第二它意味着软件栈投入有了财务基础。一个年收入达到十亿级别的 GPU 厂商有底气去扩充软件团队、做更多框架适配。这对开发者是好事因为生态成熟度最终会体现在你能不能用现成工具链把模型跑起来。第三它改变了国内 AI 算力的供给结构。对于正在做技术选型的团队来说多一个可选项就意味着在议价、交付周期和供应链安全上多一份主动权。当然也要冷静看待高速增长有基数低的因素1997.6% 的同比增速并不能直接推导出国产 GPU 已经全面比肩行业标杆。更稳妥的判断是国产 GPU 来到了一个“能不能用”初步解决、“好不好用”仍需验证的阶段。2. 国产 GPU 行业的现状与壁仞科技的技术定位要理解壁仞科技的定位先看整个国产 GPU 赛道。目前业内经常提到的国产算力芯片厂商包括华为昇腾、寒武纪、海光、壁仞等。它们的技术路线和侧重点并不完全一样。有的走 AI 专用加速器路线有的做通用 GPU有的偏向训练有的主攻推理有的生态相对封闭有的更强调兼容主流开发习惯。壁仞科技的公开定位是面向人工智能计算和数据中心场景推出 GPU 产品强调通用计算能力。所谓“通用计算”意思是它不止能跑 AI 推理和训练也面向科学计算类负载。这个定位和 NVIDIA 的通用 GPU 路线更为接近决定了两件事一是目标客户在意的算力形式更宽二是对软件生态的完整性要求更高。从行业阶段看国产 GPU 整体还处于“硬件基本可用、生态加速补齐”的阶段。硬件层面芯片设计能力这几年有明显进步在算力密度、互联带宽等维度已经能支撑一定规模的 AI 训练软件层面从驱动到编译到框架适配相比 NVIDIA 的 CUDA 生态仍有差距。这种差距不是单纯靠堆人就能追上需要大量客户真实负载去暴露问题、修复问题。壁仞营收增长的意义恰好是这个阶段的缩影。它说明有一部分客户已经愿意在真实业务中部署国产 GPU。再往后真正决定产品口碑的不是首发性能数字而是生产环境中跑三个月后稳定性如何、算子覆盖率多高、出了问题响应多快。2.1 国产 GPU 的市场关注点从参数转向生态过去大家对国产 GPU 的关注往往集中在单卡算力、显存大小、互联带宽这些硬件参数上。这些确实重要但并不是项目跑不起来的首要原因。多数 AI 项目的技术栈是PyTorch/TensorFlow CUDA cuDNN 各种算子库。这套技术栈经过多年沉淀功能丰富、文档齐全、社区案例多。国产 GPU 如果只把硬件做出来而软件栈不够完善开发者拿到卡之后仍然会遇到“模型结构能识别、精度对不上、某个算子不支持”等一连串问题。所以国产 GPU 厂商真正要补的课是把以下这些软件能力补齐底层驱动的稳定性和性能。计算库类似 cuBLAS、cuDNN 的角色的功能覆盖。主流深度学习框架的适配和性能优化。调优工具、Profiling 工具是否好用。社区文档、示例代码、Issue 响应速度。从壁仞这次收入数字看它至少已经获得了一部分客户的付费信任。后续如果收入能维持高增长软件栈的补齐速度会明显加快。3. GPU 相关基础概念从 CPU 到 NPU再到国产 GPU聊到 GPU 生态很多人会混淆一批概念CPU、GPU、TPU、NPU 到底有什么不同这里先花一点篇幅把基础梳理清楚后面讲适配才有共同语言。用通俗比喻来说CPU 像一位学识渊博的教授擅长处理逻辑复杂、分支繁多的任务但核心数量有限不擅长海量重复劳动。GPU 像一支千人规模的流水线工人团队单个人不算顶尖但数量多、分工明确最适合做大量可并行计算的数学运算。NPU/TPU 更像是为 AI 运算专门定制的特种流水线针对矩阵乘、卷积这类操作做了更激进的优化灵活度通常低于通用 GPU。AI 训练和推理大量依赖矩阵乘法与卷积运算这类运算天然适合 GPU 的并行架构。这也是为什么大模型训练、微调、推理普遍把 GPU 作为主力计算设备。下面用一个简单表格对比处理器类型核心特点适合任务典型代表CPU核心少单核逻辑强频率高通用逻辑、分支判断、IO 调度Intel Xeon、AMD EPYCGPU核心多并行度高擅长矩阵运算AI 训练、大规模图形渲染、科学计算NVIDIA A100/H100、壁仞数据中心 GPUNPU面向 AI 算子深度定制能效比高边缘推理、端侧 AI手机 SoC 中的 AI 单元TPUGoogle 定制面向 TensorFlow 工作负载云端训练与推理Google TPU对于国产 GPU更准确的理解是它属于通用 GPU 路线理论上可以承载 AI 之外的科学计算任务但在实际落地中AI 负载仍然是当前最大的需求来源。3.1 为什么软件生态是 GPU 产业的真正壁垒很多开发者问过一个问题国产 GPU 硬件追得很快为什么大家还是觉得不够好用答案很大程度在软件生态。NVIDIA 的 CUDA 生态不是一天建成的它包含驱动、编译器、数学库、通信库、性能分析工具还有数百万开发者积累的论坛帖子和开源项目。这些资产让后来者在硬件上追赶时必须额外面对一道软件高墙。国产 GPU 的破局策略大致分两类一类是自建生态提供一套完整的软件栈但需要开发者迁移和学习。另一类是主动兼容主流开发习惯在接口设计、编译工具上尽可能与 CUDA 生态对齐降低迁移成本。壁仞这类通用 GPU 厂商更偏向后者。对开发者而言这实际上是性价比最高的路径——代码不用推倒重写只需要处理设备选择、算子兼容性和少量性能调优。4. 环境准备GPU 开发环境的基本组成不管你是用 NVIDIA GPU 还是国产 GPUAI 开发环境的基本组成是一致的通常包括操作系统生产环境一般用 Linux 服务器。GPU 驱动程序。计算库CUDA/cuDNN 或者对应的国产计算库。Python 环境与深度学习框架。包管理工具pip/conda。在真正进入国产 GPU 适配前先把这套环境概念理顺很重要。后续的排错思路基本都是围绕这几层逐层排查的。4.1 驱动层一切问题的大门GPU 驱动是操作系统与硬件之间的桥梁。驱动没装好上层一切免谈。在 NVIDIA 环境下我们用nvidia-smi查看驱动、显存和卡状态。这是每个做 AI 的开发者都熟悉的命令nvidia-smi输出的关键信息包括驱动版本、CUDA 版本、每块 GPU 的显存使用情况、利用率、当前进程。国产 GPU 环境也有对应的设备查看工具只是具体命令不同。因为不同厂商的软件栈命名不一这里不写死命令但排查思路是通用的驱动是否加载成功。系统是否识别到了 GPU 设备。计算库版本与驱动是否匹配。框架是否能识别到设备。4.2 工具链层从 CUDA 到国产计算库在 NVIDIA 环境里CUDA 包含编译器nvcc、运行时库、数学库 cuBLAS、深度学习库 cuDNN、通信库 NCCL 等。国产 GPU 厂商通常会提供功能对标的计算库接口设计上会尽量贴近主流习惯但实现和具体 API 会有差异。对于大多数 AI 工程师日常接触 CUDA 的机会可能只是安装 PyTorch 时选择带 CUDA 的版本。真正的关系是这样PyTorch - CUDA/cuDNN - GPU 驱动 - GPU 硬件每一层只依赖下一层。所以排查问题时应该从上往下走先看代码能否识别 GPU再看框架版本是否支持当前 GPU 的计算能力再看驱动是否正常最后才是硬件本身。5. 一个可落地的 GPU 适配示例从检测到模型推理这一部分我们用几个可在 GPU 服务器上运行的示例把“拿到一台 GPU 机器后应该做什么”讲清楚。示例以 PyTorch 为例因为它是当前 AI 开发者的主流框架。先说前提下面的代码在标准 NVIDIA GPU 环境下一定可以运行。国产 GPU 如果已完成 PyTorch 适配在自行安装对应的框架版本后多数代码也可以复用因为 PyTorch 的接口是统一的。5.1 示例一检测 GPU 是否可用这是所有 AI 项目的“开机自检”。把环境问题最早暴露出来比到模型训练中途再崩溃要省事得多。import torch print(PyTorch 版本:, torch.__version__) print(CUDA 是否可用:, torch.cuda.is_available()) print(GPU 数量:, torch.cuda.device_count()) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): props torch.cuda.get_device_properties(i) print(f设备 {i}: {props.name}, 显存: {round(props.total_memory / 1024**3)} GB) else: print(当前环境未检测到可用 GPU程序将回退到 CPU 运行)这段代码的意义在于快速判断环境可用性。如果torch.cuda.is_available()返回False说明驱动、计算库、框架三者之间至少有一层有问题。如果返回True才能继续往下走。5.2 示例二把张量放到 GPU 上执行运算很多新手会把“模型跑了”误认为“GPU 在干活”。实际上如果代码里没有显式把数据和模型转到 GPUPyTorch 默认在 CPU 上计算性能会很差。import torch # 构造两个随机矩阵 a torch.randn(4096, 4096) b torch.randn(4096, 4096) # CPU 计算 import time start time.time() c_cpu torch.matmul(a, b) cpu_time time.time() - start # GPU 计算 device torch.device(cuda if torch.cuda.is_available() else cpu) a_gpu a.to(device) b_gpu b.to(device) start time.time() c_gpu torch.matmul(a_gpu, b_gpu) gpu_time time.time() - start print(fCPU 矩阵乘法耗时: {cpu_time:.4f} 秒) print(fGPU 矩阵乘法耗时: {gpu_time:.4f} 秒)如果 GPU 环境正确矩阵乘法这种并行计算负载下GPU 耗时应该显著低于 CPU。这里要注意初始化 CUDA 上下文通常有额外开销所以更严谨的做法是在代码块前面先运行一个预热操作但作为快速验证已经足够。5.3 示例三加载 HuggingFace 模型到 GPU 做推理实际项目中我们更多要面对的是“把模型跑起来”这个完整任务。下面示例使用 transformers 库加载一个小型模型完成一次文本生成。from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_name microsoft/phi-2 device torch.device(cuda if torch.cuda.is_available() else cpu) print(f使用设备: {device}) tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) model.to(device) model.eval() prompt 国产 GPU 在 AI 时代的发展趋势是 inputs tokenizer(prompt, return_tensorspt).to(device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens64, do_sampleTrue, temperature0.7 ) result tokenizer.decode(outputs[0], skip_special_tokensTrue) print(result)这段代码里值得注意的点有三个第一model.to(device)把模型权重搬到 GPU。忘记这行模型还是在 CPU 上跑。第二inputs.to(device)也很关键。输入数据如果不搬到 GPU执行时会发生设备不匹配的报错。第三torch.no_grad()在推理阶段关闭梯度计算减少内存占用这也是最佳实践。5.4 关于国产 GPU 适配版本的说明国产 GPU 厂商的 PyTorch 适配通常有两种方式提供编译好的专用 PyTorch 包通过 pip 安装。提供类似 CUDA 的计算库让标准 PyTorch 通过插件方式识别设备。具体走哪种方式以你拿到的厂商软件包为准。这里不写死某个命令因为不同阶段、不同产品线的安装方式差异很大。但一个通用建议是先向厂商或项目文档确认准确的安装命令再决定 pip install 的源和版本。宁可多花十分钟读文档也不要装完发现框架版本和计算库不匹配。6. 运行结果与性能验证前面几段代码跑通以后怎么判断“这是不是真的把 GPU 用好了”这里给出一套可执行的验证指标。6.1 观察设备状态在 NVIDIA 环境下最直观的方式是开另一个终端运行watch -n 1 nvidia-smi动态观察 GPU 利用率和显存变化。运行推理脚本时如果看到 Utilization 明显上涨、显存被占用说明 GPU 确实在参与计算。国产 GPU 环境同理用厂商提供的监控工具观察同一组指标即可。判断标准是一致的设备利用率没有明显波动说明待验证的负载并没有真正吃满 GPU。6.2 计算吞吐量对于 LLM 推理场景最常用的性能指标是每秒生成的 token 数。简单来说就是记录生成结束时间和生成文本长度计算出一个 tokens/s 数值。可以在上一节的生成代码里这样统计start_time time.time() outputs model.generate(...) elapsed time.time() - start_time generated_tokens outputs.shape[1] - inputs[input_ids].shape[1] throughput generated_tokens / elapsed print(f推理吞吐: {throughput:.2f} tokens/s)注意第一次推理包含模型加载和 CUDA 上下文初始化时间会明显偏长。如果要测评稳定性能应该先跑一次预热再开始计时。6.3 判断成功的标准不要把“程序没报错”当作唯一标准。更完整的成功标准是日志中明确显示设备为cuda:0或对应的国产设备编号。显存监控显示内存占用正常。推理结果符合预期。吞吐量处于合理范围。如果结果异常第一个排查方向永远是环境层级而不是代码逻辑。先确认设备可用再确认显存充足然后确认算子是否被当前计算库支持。7. 常见问题与排查思路结合很多 AI 项目的实际经验GPU 环境的报错大多集中在下面几类。以下表格可以作为快速排查清单。问题现象可能原因排查方式解决方案torch.cuda.is_available() 返回 False驱动未安装、框架版本不匹配、计算库缺失运行 nvidia-smi 查看驱动检查 PyTorch 版本是否为 GPU 版重装驱动安装匹配的 PyTorch GPU 版本报错 CUDA out of memory显存不足进程占用没有释放使用设备工具查看显存占用确认是否存在残留进程关掉残留进程减小 batch size梯度检查点模型权重加载后推理仍然慢设备分配语句遗漏模型仍跑在 CPU打印 model.device 检查设备位置观察 GPU 利用率添加 model.to(device) 和 inputs.to(device)算子不支持或报 NotImplementedError计算库版本过旧算子覆盖率不足查看报错的算子名称搜索对应支持版本升级计算库替换为等价算子多 GPU 时只有一张卡被使用代码未做并行化处理查看设备数量检查数据并行策略使用 DistributedDataParallel 或设备映射配置对于国产 GPU还有几个额外的排查建议第一先确认软件包来源。不要从非官方渠道安装驱动和计算库版本不匹配时问题最隐蔽。第二跑模型之前先跑一个最小的 tensor 运算脚本确认基础链路通不通。这样能把“环境问题”和“模型问题”快速分开。第三关注算子兼容性更新日志。国产 GPU 的算子支持列表是持续更新的今天不支持的算子可能下一版计算库就支持了。8. 部署国产 GPU 的最佳实践与工程建议营收数据的爆发意味着国产 GPU 会越来越多地出现在各级算力中心和政企采购清单里。作为开发者如果团队未来要评估或部署国产 GPU以下工程建议值得提前考虑。8.1 在代码层面抽象算力层不要把 CUDA 调用直接写在业务代码的每个角落。更推荐的做法是在项目里维护一个设备选择模块集中处理设备分配逻辑。这样将来无论是切换到国产 GPU还是从单卡扩展到多卡都不需要大面积改动。例如可以统一写一个工具文件import torch def get_device(): if torch.cuda.is_available(): return torch.device(cuda) return torch.device(cpu)然后在模型训练、推理、数据加载的代码里统一调用get_device()。这个习惯在 GPU 资源池化、混合部署的背景下很有价值。8.2 用标准 PyTorch 接口少碰特殊算子国产 GPU 适配的优先级通常以 PyTorch 高频算子为主。对开发者来说越标准的模型结构、越常规的算子迁移成本越低。反过来如果一个模型大量依赖自定义 CUDA Kernel那迁移到国产 GPU 时就需要额外做算子适配成本会显著上升。所以建议是优先选择主流开源模型架构。避免深度定制 CUDA Kernel除非是纯 CPU 或已确认目标 GPU 支持。训练时优先用 PyTorch 原生 API 完成分布式逻辑而不是依赖某个厂商的私有扩展。8.3 建立算子级兼容性测试清单在正式上线国产 GPU 环境前建议准备一组覆盖项目核心逻辑的最小测试用例数据加载。模型前向。模型反向。优化器 step。模型保存与加载。每个用例都记录是否通过、耗时、显存峰值。这套测试清单不仅适合初次适配也适合计算库升级后的回归验证。8.4 关注生产环境的备份与回滚在任何 GPU 环境变更前都要保持和数据库变更一样的谨慎记录当前驱动版本、计算库版本、框架版本。在高风险操作前备份系统配置或使用快照。保留回滚方案必要时先在一台非生产机器上验证。这条原则对 NVIDIA 环境适用对国产 GPU 环境更加适用。因为国产软件栈更新频率较高升级前做好回滚预案能避免很多不必要的生产事故。8.5 分阶段推进替换如果一个团队想尝试国产 GPU不必一上来就把核心生产任务全部迁移。更稳妥的分阶段策略是第一阶段用一个非核心的推理服务做技术验证。第二阶段验证稳定性、性能、运维工具链。第三阶段在评估结果达标后逐步扩大部署范围。这种方式既控制了风险也给了团队和厂商软件栈充分的磨合时间。9. 总结与后续学习方向回到开头的问题壁仞科技上半年收入 12.36 亿元、同比增长 1997.6%对普通开发者意味着什么我的判断是它意味着国产 GPU 已经走过了“能不能做出来”的阶段来到了“能不能卖好、好不好用”的阶段。这个阶段最直接的受益者就是开发者——更强的财务基础意味着软件生态会有更多投入更多客户的真实部署又意味着兼容性问题会被更快发现、更快修复。对开发者生态的补齐速度才是国产 GPU 能否立住的关键。从学习角度来看下一步值得关注的方向有四个第一关注主流深度学习框架对国产 GPU 的适配进度。PyTorch 新版本发布时留意是否有针对国产计算设备的适配说明。第二学习 GPU 编程基础理解算子、内核、显存调度等概念。不管是 NVIDIA 还是国产 GPU底层原理是相通的。第三在一台真实机器上跑通最小示例。没有上手实践所有讨论都只是纸面判断。第四搭建一套算力抽象层。无论未来团队怎么选型这一层都会帮你省下大量迁移成本。最后给一个落地建议下一次做 AI 项目时不妨在架构设计里把 GPU 设备抽成一个可配置项。技术上这并不复杂但它会大幅降低你在不同算力平台之间切换的摩擦。国产 GPU 不会是最后的选择但更可能是未来很长一段时间里不可忽视的选项。