开头不用标题，直接写正文。
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 EPYC |
| GPU | 核心多，并行度高，擅长矩阵运算 | AI 训练、大规模图形渲染、科学计算 | NVIDIA A100/H100、壁仞数据中心 GPU |
| NPU | 面向 AI 算子深度定制，能效比高 | 边缘推理、端侧 AI | 手机 SoC 中的 AI 单元 |
| TPU | Google 定制，面向 TensorFlow 工作负载 | 云端训练与推理 | Google TPU |
对于国产 GPU，更准确的理解是：它属于通用 GPU 路线，理论上可以承载 AI 之外的科学计算任务，但在实际落地中，AI 负载仍然是当前最大的需求来源。
3.1 为什么软件生态是 GPU 产业的真正壁垒
很多开发者问过一个问题：国产 GPU 硬件追得很快，为什么大家还是觉得不够好用？答案很大程度在软件生态。
NVIDIA 的 CUDA 生态不是一天建成的，它包含驱动、编译器、数学库、通信库、性能分析工具，还有数百万开发者积累的论坛帖子和开源项目。这些资产让后来者在硬件上追赶时，必须额外面对一道软件高墙。
国产 GPU 的破局策略，大致分两类：
- 一类是自建生态，提供一套完整的软件栈，但需要开发者迁移和学习。
- 另一类是主动兼容主流开发习惯，在接口设计、编译工具上尽可能与 CUDA 生态对齐，降低迁移成本。
壁仞这类通用 GPU 厂商，更偏向后者。对开发者而言，这实际上是性价比最高的路径——代码不用推倒重写，只需要处理设备选择、算子兼容性和少量性能调优。
4. 环境准备：GPU 开发环境的基本组成
不管你是用 NVIDIA GPU 还是国产 GPU，AI 开发环境的基本组成是一致的，通常包括：
- 操作系统（生产环境一般用 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 在干活”。实际上，如果代码里没有显式把数据和模型转到 GPU，PyTorch 默认在 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(f"CPU 矩阵乘法耗时: {cpu_time:.4f} 秒") print(f"GPU 矩阵乘法耗时: {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_tensors="pt").to(device) with torch.no_grad(): outputs = model.generate( **inputs, max_new_tokens=64, do_sample=True, temperature=0.7 ) result = tokenizer.decode(outputs[0], skip_special_tokens=True) 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 不会是最后的选择，但更可能是未来很长一段时间里不可忽视的选项。
