前 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 显然还处于一场长跑的中段。我们真正应该关注的不是哪家厂商增速最快而是围绕这些硬件的软件链条是否已经形成了良性的反馈循环。至少从壁仞科技这份成绩单来看已经有真实客户愿意把业务放到这套新生态里这就给了后续所有工程改进一个可靠的前进引擎。