前 100 字内出现核心关键词自然一点：可以从一条财报消息切入。
国产 GPU 厂商壁仞科技发布了上半年收入数据：12.36 亿元，同比增长 1997.6%。看到这个数字，很多人第一反应是“国产 GPU 终于起量了”。这个判断不算错，但真正值得追问的不是数字本身，而是这背后的验证逻辑：当一个硬件厂商开始在真实项目里被大规模调用时，软硬件的成熟度到底能不能跟上增长的速度。
我过去几年一直在做 AI 基础设施相关的工作，也深度用过不同来源的 GPU 环境。对于国产 GPU，我的整体判断是：硬件已经走过了“能不能做出来”的阶段，但生态和工具链还在“能不能用得顺手”的爬坡期。这篇文章从壁仞科技的收入增长这个切面出发，聊聊国产 GPU 在工程和技术层面真正要过的关，以及个人开发者和企业用户实际落地时应该怎么验证、怎么选型、怎么避坑。重点不是吹捧某个厂商，而是把工程视角下的真实挑战讲清楚。
1. 上半年收入增长背后，国产 GPU 走到了哪个阶段
1.1 一级市场热词退潮之后，数字开始说话
前几年市场上关于国产 GPU 的讨论，大量停留在融资、流片和“对标国际大厂”的口号上。那些讨论有一个共同特征：没有足够的出货量，也没有真实客户反馈来验证硬件的好坏。如今壁仞科技公开的 12.36 亿元收入，至少说明了一件事：有客户在真实购买，而不是停留在样片阶段。
从工程经验看，这个转变的意义很大。一个 GPU 厂商从“能流片”到“能持续卖出芯片并形成收入”，中间隔着稳定供货、软件栈成熟、售后支持、客户信任等多道门槛。收入出现高增长，通常意味着产品已经能在某些具体场景中替代既有方案，或者说至少完成了从实验室到样板间再到小批量交付的跨越。
但也要冷静看待。高增长本身受基数影响显著，如果上一年的基数很低，即便客户单量不大，同比增长也会显得很高。因此这个数字更适合被理解为“国产 GPU 商业化进入正反馈阶段的早期信号”，而不是“已经可以和头部国际厂商正面竞争”的定论。真正决定壁仞科技以及整个国产 GPU 阵营能走多远的，不是一款芯片的参数表，而是围绕它构建的工程生态。
1.2 收入增长不等于生态成熟：硬件出货只是第一张门票
一个 GPU 能否在真实 AI 工作流里被用起来，硬件只占一部分。开发者第一次拿到一张新卡时，通常会有三个连问：
- 我训练 PyTorch 或 PaddlePaddle 模型时，能不能直接跑？
- 我的推理服务能不能把显存管理好，不出现漏内存或随机崩溃？
- 我熟悉的 monitoring、日志、调度工具，能不能识别这块卡？
这三个问题，本质上都是软件生态问题。芯片厂商如果没有提供与主流框架匹配的适配层、驱动解释、算子库和容器镜像，硬件出货再多，开发者也很难真正用起来。国产 GPU 目前最大的工程挑战，恰恰就在这一层。
从行业观察看，部分国产 GPU 厂商已经在适配 PyTorch、ONNX Runtime、TensorFlow 等主流框架，也提供了类 CUDA 的编程接口，目的是降低迁移成本。但“能用”和“好用到可以立刻迁移存量业务”之间，通常还差着不少性能和稳定性验证。尤其对于依赖 CUDA 深度特性的项目，比如自定义算子、动态形状敏感的网络、依赖 tensor core 的矩阵运算，迁移周期可能会被明显拉长。
因此我认为，收入增速只能作为观察国产 GPU 进入商用周期的参考指标。真正值得持续跟踪的是另外几个指标：有多少开发者下载过官方 SDK、有多少生产项目完成了国产 GPU 适配、社区里有多少可复用的踩坑记录、出现兼容性问题后厂商反馈周期有多长。这些指标更贴近工程师的真实体验，也比收入数字更能说明生态成熟度。
2. 国产 GPU 真正的分水岭不在跑分，而在软件栈和工具链
2.1 硬件参数好看，不等于实际推理性能好用
很多初看国产 GPU 资料的人，会把注意力放在 TFLOPS、显存带宽、制程工艺这些参数上。这些数据当然有意义，但工程实践里，硬件峰值性能和使用性能之间的差距，往往比大多数新品发布会展示的 Benchmark 要明显。
一个常见的反直觉现象是：同一张 GPU，在纯矩阵运算基准里可能表现非常好，但一旦进入真实推理场景，比如部署一个大语言模型或视觉模型，实际吞吐会受算子实现、显存分配策略、数据搬运、host 端同步等因素限制。其中最关键的是算子库的成熟度。英伟达之所以能成为行业默认选项，底层靠的不是简单的“算力堆砌”，而是几十年积累的 cuDNN、cuBLAS、TensorRT 等算子库和运行时优化。国产 GPU 如果只把硬件做出来了，却没有同步建立起适配主流算子的高效实现，那么实际性能可能只有峰值的 50% 甚至更低。
我一般会建议工程师在评估国产 GPU 时，除了看官方算力，还要跑三类贴近业务的测试：
- 一个典型卷积或 Transformer 子结构的真实耗时。
- 一个带批量推理的小型服务的压测结果，例如 QPS 和 P99 延迟。
- 一个包含数据加载、预处理、设备间拷贝、后处理的完整 pipeline 测试。
这三类测试能反映出“在真实工作中到底好不好用”，而不是只看“理论峰值有多高”。
2.2 从 CUDA 惯性到异构迁移的成本结构
很多团队长期使用 CUDA 生态，代码和心智模型都已经深度绑定。迁移到国产 GPU 时，最先遇到的不是硬件不兼容，而是各种历史代码里的“CUDA 惯性”。比如用到torch.cuda系列接口的日志、使用了cudnn.benchmark的配置、或者依赖某个特定版本的 CUDA 工具链构建的 edge runtime。
迁移成本结构大致可以拆成四块：
- 框架适配层成本：模型代码基本不用动，但如果使用 PyTorch 自带的高层 API，就需要确认国产卡的适配版本是否和训练框架完全匹配。
- 算子兼容成本：自定义算子是否能在目标芯片上正常编译和执行，是否需要改写为芯片厂商提供的底层接口。
- 性能调优成本：即使功能跑通，性能和显存占用往往需要单独调优，不能因为跑通就认为已经完成迁移。
- 运维成本：监控、日志收集、调度系统是否能识别新硬件，容器镜像是否包含对应驱动，都是容易被忽视的维护工作。
在真实项目里，最容易被低估的是第四类成本。很多团队把模型代码迁移过去后，发现部署环境里驱动版本不一致，或者 GPU 显存无法被 k8s 正确识别和调度，最后又不得不回退到原方案。这也是为什么国产 GPU 的“可用性”不能只停留在跑通一个训练脚本。
2.3 PyTorch、PaddleOCR、Ollama 这类工具怎么落地到国产芯片
让国产 GPU 进入开发者日常工作流，关键不是再造一套全新的 AI 框架，而是让已有的主流工具尽量平滑地跑起来。目前常见的中文 AI 场景里，PyTorch、PaddleOCR、Ollama 是三个被反复提到的名字。
拿 PyTorch 举例，使用国产 GPU 时通常需要安装芯片厂商提供的 PyTorch 适配版本，而不是直接安装默认的官方 wheel。安装之后还需要确认torch.cuda.is_available()是否能返回 True、设备索引是否正确、显存占用能否被正常读取。不同厂商提供的适配层命名可能不同，有的直接沿用cuda命名空间，有的会提供独立扩展包，具体情况要以官方文档为准。
Ollama 是很多个人开发者用来本地跑大模型的工具。它的 GPU 支持逻辑通常依赖底层 runtime 对硬件设备的识别。如果芯片厂商提供了符合 Ollama 兼容要求的资源，比如通过 ROCm 或类 CUDA 接口实现加速，那么在国产 GPU 上运行 Ollama 就有落地可能。但要注意，Ollama 或 llama.cpp 一类的工具对部分新硬件的支持往往是社区驱动，官方可能不会第一时间提供认证，需要到目标平台仓库确认是否有独立的 PR 或分支。
PaddleOCR 这类成熟的中文 OCR 工具，在国产 GPU 上落地也有类似的路径：先确认 PaddlePaddle 官方框架是否支持对应芯片，再检查 PaddleOCR 的模型是否能在该框架版本下正常推理，最后验证输出稳定性。整体原则是：优先使用厂商提供的适配容器或基础镜像，尽量固定版本，避免在生产环境里频繁升级。
这些工具能不能顺利跑起来，并不完全由壁仞科技这样的硬件厂商单独决定，而是取决于整个上游框架社区和硬件厂商之间的协作程度。从这个角度看，国产 GPU 需要补的课，是让“不确定支持”变成“默认支持”。
3. 从单卡验证到多卡训练，国产 GPU 在生产环境里的使用路径
3.1 为什么先跑通最小用例比直接上满配置更重要
在评估或迁移阶段，最常见的错误是一上来就跑完整业务。比如直接加载十几个 GB 的大模型训练任务，或者把一个生产环境的推理服务从 CUDA 迁移到国产 GPU 上做全量测试。这种思路很容易浪费大量时间，因为问题可能出现在输入、环境、权限、驱动、版本、显存、算子、调度等多个环节，一旦出错，排查成本很高。
更稳妥的做法是先做一个“最小可运行闭环”。这里的最小不是指模型小，而是指覆盖关键链路的精简版本：
# 示例结构：最小闭环验证 import torch import torch.nn as nn # 1. 确认设备可用 print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) # 2. 创建小规模模型和输入 model = nn.Linear(256, 128).cuda() input_tensor = torch.randn(8, 256).cuda() # 3. 跑一次前向和反向 output = model(input_tensor) loss = output.sum() loss.backward() # 4. 确认梯度更新和多卡可见性 print("multi gpu count:", torch.cuda.device_count())这段代码不解决具体业务问题，但它能一次性验证最关键的信息：驱动是否装好、PyTorch 适配层是否正常、设备索引是否识别、基础算子能否完成前向反向。只有这一层验证通过，后续的大型模型和复杂业务才值得继续推进。
这个思路在 PyTorch、PaddlePaddle、TensorFlow 等框架上都适用。核心原则是：先让一条最简单的数据流走通，再逐步增加复杂性。
3.2 单卡推理、多卡并行、资源监控的实操建议
单卡推理是大多数刚接触国产 GPU 的第一场景。建议按以下顺序操作：
- 确认驱动和运行时版本。不同驱动版本对应的算子库差异可能很大，先在厂商官方文档里核对。
- 创建带 GPU 运行的容器或虚拟环境。优先使用厂商提供的镜像，不要自己从零编译驱动。
- 用业务里最核心的一个模型做推理测试。不只是看能否输出结果，还要记录首 token 延迟、平均延迟、显存峰值。
- 做一个简单的并发测试。例如用 10 个并发请求跑 5 分钟，观察是否有异常退出、显存泄漏和延迟抖动。
多卡训练或推理并行时的坑更明显。首先是 NCCL 这个生态依赖问题，很多分布式训练脚本默认依赖 NCCL 做集合通信。不同厂商提供的替代通信库可能命名或调用方式不同，需要单独适配。其次是多卡之间的通信带宽和拓扑，可能直接影响大规模训练效率。最后是调度系统对多卡资源的识别能力，比如 Kubernetes 是否能根据设备插件正确分配 GPU 给不同 Pod。
资源监控也值得提前设计。GPU 温度、显存占用、利用率、功耗这些指标，在英伟达体系里有 nvidia-smi 可以查看。国产 GPU 通常有厂商自带的监控工具或 API。落地时不要只依赖默认命令，要尽量把监控指标接入已有的 Prometheus 体系，这样后续做容量规划时才有数据支撑。
3.3 可复用的三步验证法：输入、环境、资源
结合长期工程经验，我把国产 GPU 的落地排查和验证收敛成一个三步法，适用于大部分场景：
第一步，检查输入链路。确认数据格式、文件路径、batch size、张量 shape 和模型输入是否一致。很多国产芯片适配层的报错信息晦涩，容易被误判为环境问题，其实是输入尺寸或类型不匹配。
第二步，检查环境链路。依次核对驱动版本、运行时版本、框架版本、容器镜像、环境变量、Python 包依赖。这里有一个容易被忽略的点：如果机器上同时存在多个 Python 环境，或者用户没用激活虚拟环境就运行脚本，很可能会加载到错误版本的框架适配包。
第三步，检查资源和权限。至少确认四个方面：显存是否足够、GPU 能否被当前用户访问、设备索引是否与物理卡对应、文件系统是否对输出目录有写入权限。显存不足、设备访问被阻止、输出盘空间不够，是生产环境里最高频的三大隐性故障。
这个三步法本身没有任何炫技成分，但它的价值在于给排查提供一个稳定的顺序。遇到问题不要先乱改代码，也不要上来就重装驱动，先看输入、环境、资源，能省下大量时间。
4. 新手最容易踩坑的地方：驱动、显存、版本和“半支持”生态
4.1 环境准备时最容易忽略的依赖问题
很多新手在国产 GPU 上安装深度学习环境时，会直接按照英伟达 GPU 的教程操作。比如执行pip install torch之后，发现torch.cuda.is_available()还是 False，就以为驱动或硬件有问题。实际上，很可能是因为版本不兼容：默认安装的 PyTorch 是从官方 PyPI 拉取的 CUDA 版，而不是目标芯片厂商的适配版。
这里有一个稳定的排查顺序：
- 先确认厂商是否提供适配的 wheel 或容器镜像。
- 再检查当前驱动的版本是否支持到目标框架版本。
- 如果必须使用 conda 环境，注意不要在创建环境后手动混装多个来源包，否则很容易引起运行时 ABI 冲突。
- 最后验证一个小数点的版本差异。比如
torch 2.1可以用，但torch 2.2可能就未适配，需要以厂商支持列表为准。
另一个容易被忽略的问题是：宿主机内核和驱动模块匹配。很多国产 GPU 驱动的安装依赖特定内核头文件，如果升级了内核但没有重新安装驱动模块，设备就无法被正常识别。建议在安装之前，先确认操作系统版本和内核版本。
4.2 性能不达预期时，先查哪几层
当模型在国产 GPU 上能跑通，但速度比预期慢很多时，不要急着下“性能不行”的结论。按照下面的层次检查，往往能找到真正瓶颈：
- 第一层：框架是否真的调用了 GPU。有的情况下，模型代码里漏了
.cuda()，或者推理 API 默认走 CPU，看起来在“跑”，但实际没有使用 GPU。 - 第二层：是否存在 CPU 与 GPU 频繁同步。每次设备间张量拷贝，或者
.item()调用，都可能打断异步执行，造成时间损耗。 - 第三层：算子是否走高效实现。检查日志或 profiling 工具，确认关键算子在目标 GPU 上是否匹配高效的算子库，还是落入低效 fallback 路径。
- 第四层：显存分配策略。频繁申请和释放显存会导致碎片化，看起来显存足够但分配失败，或者性能因为分配机制而下降。
- 第五层：多进程/多线程并发。数据加载进程如果过慢，GPU 会长时间等待，导致利用率不高。
这一层一层走下来，才会得到相对可靠的性能结论。
4.3 四个避坑经验
围绕国产 GPU 的工程实践，我整理了四个高频避坑经验:
第一，不要贪新求快。新驱动不一定比旧驱动好，新框架版本也不一定比旧版本稳定。在没有明确必要性的前提下，优先沿用厂商已验证的版本组合。
第二，不要只看“能不能跑”。功能跑通只是及格线，应记录一份基准数据，例如吞吐、延迟、显存峰值，后续每次改动环境时，都用同一份基准回归测试。
第三，不要把单卡经验直接照搬到多卡。多卡问题是另一类复杂性，涉及通信、拓扑和调度。先在单卡场景把问题验证透，再考虑多卡扩展。
第四，关注厂商发布的已知问题列表和发布说明。很多国产 GPU 平台正处于快速迭代期，已知问题的公开速度往往比国外大厂更活跃。上线前核对已知问题列表，可以提前避开很多硬坑。
注意：不要一上来就把批量数和并发数拉满，先用一条样例确认输入、输出和日志都正常，再把压力逐步加上去。
5. 适合谁、不适合谁：国产 GPU 的适用边界与选型建议
5.1 适合的场景与不适合的场景
国产 GPU 当前并不适合所有 AI 场景。基于常见工程实践，我把它大致分为三类：
适合优先尝试的场景：
- 对数据安全有强要求的政企和内部私有化部署。
- 需要国产化适配的垂直行业项目，例如金融、能源、政务里的 AI 推理服务。
- 标准化部署的 CV 推理场景，比如以 CNN 为主的图像分类、目标检测、OCR。
- 对成本敏感、愿意投入精力做软硬件适配的团队。
可以尝试但需要预留调试时间的场景：
- 大语言模型推理服务。虽然已经有不少适配进展，但服务稳定性、显存管理、吞吐和易用性仍需实际验证。
- 分布式训练任务，特别是依赖集合通信时情况比较复杂，后续排查链路会更长。
- 涉及大量自定义算子的模型，需要逐个确认算子兼容性。
不建议当前阶段直接迁移的场景：
- 依赖深度优化过的 CUDA 加速库、TensorRT 推理优化的存量商业模型。
- 对 P99 延迟极其敏感、运行环境完全无法容忍兼容性风险的线上核心服务。
- 团队没有任何 GPU 迁移经验、纯黑盒应用场景，也没有厂商技术支持预算的长期项目。
这里的边界不是固定的，而是随着厂商软件栈迭代而动态变化。一个项目现在不适合，不代表半年后还不适合，关键是要有自己的验证方法，而不是听单方面的营销判断。
5.2 如何判断一个存量项目要不要迁移到国产 GPU
我给团队做选型建议时，通常会给出一个四步判断法：
第一步，先确认项目是否已经跑在 CUDA 生态里。如果还没有，例如本来就是 CPU 推理或普通服务器，那么国产 GPU 是一个相对自然的优化方向。如果已经完全跑在英伟达生态且已调优到很高水位，迁移成本会明显上升。
第二步，盘点代码对 CUDA 特性的依赖深度。只依赖高层框架 API 的项目，迁移成本通常较低；大量使用自定义 CUDA kernel、TensorRT plugin 或深度调优算子的项目，迁移成本以月为单位计算。
第三步，算清量产和部署规模。如果只是原型验证，没必要迁移；如果预计要交付成百上千台设备，那么硬件可得性、供应稳定性和国产化要求会占更高权重。
第四步，做一次小规模 PoC。用 1 到 2 周时间，跑通核心模型并提供量化结果：正确性、性能、稳定性、人力投入。这个 PoC 的结果，远比任何纸面参数和收入数字都更有说服力。
5.3 接下来半年最值得观察什么
壁仞科技这份收入数据里，有一个值得长期关注的隐含信息：国产 GPU 厂商已经从“要不要用”的问题，进入“在哪些场景里用得好”的问题。接下来半年，我更关注三件事：
第一，厂商的适配库迭代频率。如果 PyTorch、PaddlePaddle、推理引擎的适配版本更新节奏能够跟上上游框架的版本节奏，说明生态在真正变好；如果仍停留在早期固定版本，实际选型时就要更谨慎。
第二，数据库模型库或工具链的社区活跃度。是否有更多第三方教程、开源示例和社区贡献者围绕国产 GPU 构建工具链，是判断生态健康度的重要信号。
第三，多卡通信稳定性和大规模部署反馈。收入增长之后，一定会有人尝试把国产 GPU 放进更大的分布式集群。这个过程中暴露出来的问题数、厂商响应速度，才是决定国产 GPU 是不是真正进入成熟商用阶段的关键。
我倾向于把国产 GPU 目前的状态定义为“工程可用性正在从 30 分爬到 70 分”的爬坡期。如果你所在的团队有精力做技术适配，也有耐心解决版本和环境问题，那么现在入场反而可能拿到一套正在快速成熟的卡位优势。如果完全没有适配资源，或者业务不能接受任何稳定性波动，那也不妨再等等。选择本身没有对错，关键是判断清楚自己的场景有没有余量去承担不确定性。
从收入信号到生态验证，国产 GPU 显然还处于一场长跑的中段。我们真正应该关注的，不是哪家厂商增速最快，而是围绕这些硬件的软件链条是否已经形成了良性的反馈循环。至少从壁仞科技这份成绩单来看，已经有真实客户愿意把业务放到这套新生态里，这就给了后续所有工程改进一个可靠的前进引擎。
