国产GPU扭亏为盈背后：AI开发者如何进行芯片平台选型

一家芯片公司扭亏为盈，为什么值得AI开发者专门研究？

因为对做AI工程的人来说，选芯片平台，本质上是在选未来两三年里，你的代码要长期跑在谁的操作系统、驱动和算子库上。这个选择一旦做错，迁移成本会被时间放大。沐曦股份2026年上半年归母净利润6.12亿元、同比扭亏为盈这个消息，放在整个AI芯片行业里，就是一个值得留意的重要信号。它说明“国产GPU没有商业订单、只能靠融资续命”的刻板印象，正在被实际业绩改写。

我写这篇文章，不会去复述财务报表里的营业收入、现金流等数据，那是财经媒体的工作。我更想从技术开发者的视角，把这次扭亏拆成三个问题来看：第一，财务数据背后到底透露出什么样的技术信号；第二，沐曦的技术底座和产品体系是怎样支撑起商业化的；第三，如果你正在评估国产AI算力平台，应该设计一套什么样的最小验证流程，而不是只凭宣传手册做决定。

1. 净利润6.12亿元，为什么在技术圈也值得重视

先回到事实本身。沐曦股份在2026年上半年实现归母净利润6.12亿元，同比扭亏为盈。单看数字，这是一个企业财务层面的变化；但芯片行业的财务变化，天然和技术进展深度绑定。

芯片公司的成本结构非常重。一次流片要投入巨额资金，硬件量产前还需要经过多轮架构验证和样片测试；量产之后，驱动开发、算子库补齐、框架适配、编译工具链维护，每一项都是持续投入，而且不会因为硬件卖得不错就自动消失。在很多年里，国产GPU公司的标准状态就是“产品做出来了，客户也愿意测试，但公司还在亏损”，因为收入规模撑不起那么重的研发成本。

所以，当一家GPU公司出现“归母净利润6.12亿元，同比扭亏为盈”这个结果，它的生态含义不只是“财务变好了”，更包括三件事：

• 产品已经进入真实的大规模出货阶段，客户愿意为它付费，而且付费规模跨过了成本覆盖的临界点。
• 公司的持续经营能力得到验证，后续软件栈更新、算子维护、框架适配不会因为资金紧张而中断。
• 研发投入有了更稳定的来源，下一代架构和工具链的迭代节奏会更有保障。

对开发者来说，这三点都比“峰值算力数字”更重要。因为选型国产AI芯片，最怕的往往不是单卡性能低，而是驱动没人维护、算子库长期不更新、产品线随时可能收缩。财务扭亏至少说明，公司已经进入“硬件出货带来收入，收入支撑软件研发，软件体验又反过来促进出货”的正循环。

但这里也要泼一盆冷水。扭亏不等于每一款芯片都适合你的业务，不等于性能测试可以跳过，更不等于你可以直接照搬别人的迁移方案。财务数据能放进“供应商可持续性”这个评估维度里作为加分项，但最终判断还是要回到你的模型、你的数据、你的部署环境上去验证。

2. 沐曦是谁：一家正在走向规模化的GPU公司

先交代背景。沐曦股份是一家成立于2020年的高性能通用GPU公司，创始团队在GPU芯片设计和软件领域有多年积累。从公开资料看，公司的定位不是只做某一类专用芯片，而是覆盖AI训练、AI推理和图形渲染等场景的全功能GPU路线。这意味着，它从一开始就希望用同一套软硬件底座，去服务不同种类的算力需求。

公开信息里经常提到的三条产品线可以做一个简单对应：

• 曦云系列：面向AI训练和高性能计算，主打高算力场景。
• 曦思系列：面向AI推理，强调能效比和部署成本。
• 曦和系列：面向图形渲染和通用计算场景。

三条线并行，并不是单纯把产品包装成多个型号，而是对应三种典型工作负载：大模型预训练和微调需要强算力；推理服务需要高吞吐、低功耗；图形渲染又对API兼容和驱动稳定性要求极高。一家公司能同时做这三类产品，说明它的底层架构设计有余量，也说明它有信心用同一套软件栈去承接不同客户的需求。

沐曦选择“全功能GPU”路线，本质上是为了降低客户迁移成本。很多团队已经用CUDA生态训练和部署模型，如果新平台要求重写代码，基本上不会被采纳。所以更务实的做法是提供CUDA兼容能力，让已有PyTorch代码和CUDA算子尽可能通过编译或运行时映射迁移过来。从工程实践看，这套思路比从零构建一套全新开发框架更容易落地，因为它保护的是客户手里已经跑通的代码和模型。

另外值得注意的一点是，沐曦的产品交付形式也在变化。早期很多国产芯片公司以单卡或者开发板形式提供产品，客户拿到之后还要自己做服务器适配、驱动集成和网络调优。而现在越来越多订单是整机柜、集群甚至算力中心方案，交付物从一块卡变成了“开箱可用的系统”。这种变化对收入规模和利润质量都有直接影响，也是公司能从亏损转向盈利的重要推动力。

3. 扭亏发生背后的四层技术逻辑

为什么是“现在”扭亏，而不是更早或更晚？这里面有行业需求的推动，也有公司自身产品成熟的积累。我倾向于从四个技术层面去理解。

3.1 AI推理需求进入规模化，成本敏感型客户开始入场

过去几年，行业的重心经历了一个明显变化：最开始大家关注的都是大模型预训练，训练需要大量GPU，但主要玩家是少数大厂；后来，推理部署开始走向规模化，大模型要放进业务系统里提供在线服务，需求从“顶级性能”转向“够用且便宜”。

推理场景对成本非常敏感。国产AI芯片在部分推理负载上，如果能达到可用的性能和能效，同时价格更低，就会成为很多云厂商和行业客户的选择。推理业务还特别依赖算子库、显存管理和推理引擎的适配，这对GPU厂商的软件成熟度要求很高。沐曦能在这个阶段接住需求、形成稳定收入，说明它的软件栈已经跨越了“能跑demo”的阶段，进入“可以在生产环境批量部署”的阶段。

3.2 软件栈成熟度决定了迁移成本，也决定了利润质量

GPU本身只是硬件，真正的壁垒是软件栈。CUDA生态沉淀了大量深度优化的算子、通信库、推理引擎和深度学习框架。任何新玩家要切入市场，都必须回答一个问题：客户把代码迁移过来，到底要付出多少成本？

如果软件栈不成熟，客户需要自己补算子、绕开不支持的API、调三方库版本，迁移周期以月为单位。如果软件栈成熟度足够，客户只需要安装适配版PyTorch，跑起代码，性能达标，就能快速上线。迁移成本低，客户才愿意批量采购；批量采购带来规模效应，公司的毛利和净利才能改善。

所以，扭亏可以部分理解为：沐曦的软件团队已经走出了“从0到1补算子”的阶段，开始进入“从1到N做优化”的阶段。这一转变对应用开发者的价值，可能比一次硬件发布会更大。

3.3 交付形态从单卡走向整机和集群，收入质量发生变化

芯片公司的收入质量，很大程度上取决于交付形态。卖一块卡，客户可能只是买来测试；卖一个带驱动的服务器整机，客户已经开始小范围部署；卖一个集群方案，客户已经进入了生产系统选型流程。

大规模AI算力交付，需要高速互连、集群管理、调度平台、监控运维等一整套能力。沐曦能够实现净利润转正，推测其整机、集群和行业解决方案的交付规模已经形成一定体量。交付形式从上游流片延伸到下游系统集成，这也会让公司对客户需求的把握更加准确，反过来指导下一代芯片的定义和软件栈的优化。

3.4 盈利带来的研发正循环，是长期技术竞争力的基础

芯片公司最重要的资产是研发团队。GPU架构迭代、算子库优化、编译器升级、新框架适配，都需要一支规模不小的团队持续投入。融资可以解决短期资金，但盈利能给研发一个更稳定的预期。净利润转正，意味着公司可以把一部分收入继续投入到下一代架构和下一代工具链里，从而形成技术竞争力，而不是停留在单一产品的修修补补。

理解这层逻辑之后，再看“归母净利润6.12亿元”这个数字，它就不再只是一条财务摘要，而是公司技术能力、产品成熟度和商业模式的综合结果。

4. 开发者在国产AI芯片选型时真正该看什么

很多团队评估AI芯片，容易一上来就对比“峰值算力”“显存带宽”“功耗”这些硬件指标。这些数字当然重要，但对一个要长期维护业务代码的团队来说，真正影响开发效率的是软件栈和生态能力。这里我给出一个更务实的评估框架，四个维度就够了。

每个维度都需要展开讲一下。

框架兼容性方面，团队主力框架是PyTorch，就一定要确认官方有没有提供匹配版本环境的适配版，安装源是否可以正常访问。如果只能从源码编译，你的团队就需要有人能处理编译和依赖冲突，维护成本马上上升。

算子覆盖是更隐蔽的坑。模型里可能只用到几十个基础算子，但工程化改造中不常用的特殊算子往往是最先报错的。跑demo时一切正常，一旦换成公司内部的定制模型，就可能遇到算子不支持的报错。因此在评估阶段，不要只跑官方示例，一定要拿自己业务里最常用的几个模型去做盲测。

推理引擎支持决定生产环境的上限。现在很多大模型推理服务都依赖成熟推理引擎来做批处理、连续批处理和量化。如果某个国产平台只能跑PyTorch原生推理，不支持主流推理引擎，性能差距可能会非常明显。选型时一定要确认官方是否提供适配支持，或者第三方社区是否有成熟方案。

工具链与运维常常被忽略。GPU卡在线上跑久了，驱动异常、温度报警、显存泄漏，这些都需要监控工具和运维能力兜底。你能不能用厂商提供的工具快速定位设备状态？出了问题能不能在文档或工单里找到支持？这些都会直接影响业务稳定性。

5. 从零开始：用最小成本验证沐曦环境是否可用

理解完选型维度，接下来进入可以实操的部分。下面这套流程以“通用国产AI芯片评估”为思路，沐曦官方如果已经有最新SDK和文档，以官方说明为准。重点不是给出某个固定安装脚本，而是提供一套可复制的验证路径。

5.1 列出版本清单，避免“版本地狱”

动手安装之前，先把下面这张版本清单列出来：

• 操作系统版本和内核版本。
• GPU驱动版本和厂商SDK版本。
• Python版本。
• PyTorch版本及是否是厂商适配版。
• 是否使用容器，容器的运行时和镜像版本。

很多环境问题都是版本错配引起的。比如操作系统太老，驱动装不上；Python版本太高，官方wheel包不支持；PyTorch用的是CPU版，自然检测不到设备。先把版本对齐，能省下大量排错时间。

5.2 安装厂商SDK和适配版PyTorch

这里先给一个结构示例。具体安装源和包的名称，要以沐曦官方文档为准，不要照搬下面的占位符。

这里真正容易踩坑的地方是：有些人会先去官网下载驱动和SDK，然后顺手 pip install torch，装回来一个CPU版本，结果代码跑起来没有任何加速效果。所以在安装依赖时，一定要确认PyTorch的安装源来自厂商适配仓库，而不是默认的PyPI。

5.3 检查加速设备是否可见

安装完成后，先不要急着跑大模型，用一个几十行的小脚本确认设备状态。

运行命令：

预期输出大致是：

如果设备不可用，不要急着改代码，优先检查三样东西：驱动是否加载成功、SDK路径是否配置、PyTorch是否来自厂商适配版。

5.4 跑一个最小算子验证基本算力

设备可见之后，再用一个矩阵乘法验证基本算力和显存分配。这个示例不是为了测性能，而是确认最基础的算子链路正常工作。

运行：

如果这个脚本能正常输出结果形状，说明最基本的矩阵乘法算子、显存分配、设备同步都已经跑通。如果耗时明显异常，比如比CPU还慢，就要检查是否是驱动降级、没有正确使用适配版框架，或者硬件处于节能状态。

6. 用一个小模型完整跑通推理验证

算子验证通过之后，可以拿一个自己常用的模型做完整推理测试。这里用HuggingFace Transformers风格示例，目的是验证“分词器加载、权重加载、前向计算、结果生成”的整条链路。

运行前先确认几件事：模型文件已经下载到本地，或者可以正常访问；磁盘空间和显存足够；模型的使用许可和你的业务场景不冲突。

这段验证的重点不是生成质量，而是链路完整性。如果整个流程能跑通，说明框架、权重加载、前向算子、显存管理都没有卡点。如果遇到算子不支持，不要一次处理多个报错，先把第一个报错里的算子名称记录下来，去官方算子支持清单里查一下，再看是否有替代实现。

7. 常见问题与排查思路

实际评估中，很多问题有共通性。下面列一个常见问题排查表，可以直接收藏备用。