
沐曦股份披露 2026 年上半年经营数据归属于母公司股东的净利润为 6.12 亿元同比扭亏为盈。这个数字放到 AI 基础设施圈最直接的联想是国产 GPU 厂商能不能在产品上证明自己也开始在经营上证明自己。作为长期关注非 NVIDIA 算力方案的开发者我看到这条消息后最关心三个问题软件栈是否跟得上、真实负载是否稳定、采购之后能不能把模型顺利跑起来。本文不评价股价也不做财务分析而是从技术选型和开发者使用的角度拆解这条消息里值得关注的信息并给出一套可以复用的国产 GPU 评估流程。先给结论扭亏为盈是一个积极信号但不等于生态成熟。GPU 公司属于重研发、重投入、长周期行业从亏损到盈利说明收入规模开始覆盖成本也说明市场确实在采购它的产品。开发者真正该关心的是盈利之后公司会不会持续投入软件栈、社区支持和产品迭代。这些因素才决定一款非 NVIDIA GPU 在真实项目中能不能用、好不好用。本文适合以下读者正在做算力选型的算法工程师负责推理服务的基础设施团队关注国产芯片软件生态的技术管理者以及想本地尝试非 NVIDIA 平台的硬件玩家。文章会包含消息解读、公司背景、通用评估流程、代码示例、选型建议和风险清单重点提供一套从零验证国产 GPU 可用性的方法而不是只看一个利润数字。1. 核心信号速览先把这条消息的关键信息拆成一张表方便对照。项目内容公司沐曦股份主营业务GPU 芯片设计覆盖人工智能、高性能计算、图形处理等方向披露数据2026 年上半年归属于母公司股东的净利润 6.12 亿元同比表现扭亏为盈2025 年上半年归母净利润为亏损具体金额以官方披露为准开发者关注点商业化可持续性、软件栈完善度、模型适配能力、售后支持适用读者AI 推理与训练工程、算力采购、本地部署、基础设施团队信息边界本文只基于标题明确的财务结果其余经营细节需要等正式报告这张表想表达的核心是净利润为正不等于“开发者遇到的每个算子都能顺利跑通”。对技术团队来说公司的商业健康度解决的是“会不会长期支持和更新”的问题而模型能不能跑通仍然要回到硬件、驱动、运行时和框架的逐层验证。2. 这条财务信号为什么值得技术团队关注GPU 设计公司是典型的“高研发、长周期”公司。一款芯片从架构定义到量产往往需要数年时间期间要持续投入流片、软件栈和产品团队即使产品量产真正形成稳定收入也需要依赖大规模客户的验证周期。因此当一家成立时间不长的 GPU 公司首次实现归母净利润扭亏为盈往往意味着它的产品已经进入规模化交付阶段收入不再停留在送测样片和少量试点上。对技术团队来说这个信号最直接的参考价值是供应商可持续性。如果你准备把推理服务部署在国产 GPU 上你需要的不只是一张卡而是后续一年甚至多年的驱动更新、框架适配、漏洞修复和技术支持。一家长期亏损的公司即使产品不错也可能面临融资压力、团队不稳定、支持响应放缓等风险。反过来实现盈利说明公司已经有能力用经营性收入覆盖刚性支出至少在企业存续层面更让人放心。不过要强调的是单一半年度的净利润数字只能说明“这段时间赚了钱”不能直接推导出全年盈利或稳定盈利。非经常性损益、补贴、政府补助、投资收益等都可能影响净利润具体要看归属上市公司股东的扣除非经常性损益后的净利润以及营收、毛利率、现金流等配套指标。尤其对技术选型来说公司财务健康只是必要条件不是充分条件。3. 沐曦股份是一家什么样的公司公开资料显示沐曦股份是一家 GPU 芯片设计公司成立于 2020 年核心团队具有国际 GPU 企业研发背景。公司产品布局主要覆盖人工智能训练、人工智能推理、通用计算以及图形处理等方向面向数据中心、行业客户和高性能计算场景。近两年随着大模型推理和训练需求快速增长国产 GPU 厂商的产品开始更多出现在智算中心、运营商、互联网和科研机构的采购清单里沐曦也是其中被频繁提及的一家。需要注意的是本文没有列出具体产品型号和软件栈名称。原因是 GPU 芯片产品线迭代很快不同时期的产品命名、规格和支持范围会调整而且底层软件栈的适配情况需要以官方文档和实测结果为准。如果你在文档中看到某个产品型号建议直接去官网核对“硬件规格、驱动版本、支持的深度学习框架、推理引擎、容器镜像”这几项不要只依赖第三方文章。从生态定位看沐曦要解决的核心问题是“如何让主流 AI 工作负载在非 NVIDIA 硬件上跑起来”。这个问题的难度不仅在于芯片设计本身还在于 CUDA 生态已经非常成熟大量模型、算子库和推理引擎默认针对 NVIDIA 优化。后来者要把 PyTorch、Transformer 系列的常用模型、推理框架都适配完整工作量非常大。正因如此评价一家国产 GPU 公司不能只看利润还要看它的软件栈到底覆盖了多少真实场景。4. 开发者视角盈利与“能不能用”不是一回事我经常看到一种误判公司赚钱了所以它的卡一定好用。这个逻辑对财务成立对技术不成立。你最终面对的是这样一个事实链芯片支持不等于驱动支持驱动支持不等于 PyTorch 支持PyTorch 支持不等于某个具体模型能顺利跑通模型能跑通不等于长时间推理不崩溃。在 NVIDIA 平台上这些环节被 CUDA 生态抹平了你装好驱动和 CUDA 之后大多数模型开箱即用。但在非 NVIDIA 平台上每一个环节都可能出问题。常见情况包括官方提供的 PyTorch 版本与驱动版本不匹配某个自定义算子在推理时无人实现量化算子精度不对多卡通信库不支持容器镜像缺少固件驱动等。所以在采购或部署之前你应该建立一套自己的验收清单。建议至少覆盖以下几个维度驱动与运行时是否能正常安装官方是否提供适配过的 PyTorch 或其他框架是否可以运行矩阵乘法、卷积等基础算子是否可以加载真实模型完成一次推理连续批次任务是否会崩溃显存管理和释放是否正常。下一节给出一个可复用的通用验证流程。5. 非 NVIDIA GPU 的通用评估流程这里给出一套不依赖具体厂商工具的评估方法。流程顺序是先确认硬件被系统识别再确认驱动和运行时然后做算子冒烟测试最后用真实模型压测。每一步失败都先回来检查前一步。5.1 收集本机信息先确认操作系统、CPU、内存、磁盘和 GPU 设备是否被系统识别。这个步骤可以只用 Linux 通用命令完成。# 查看系统发行版、内核、内存和 CPU cat /etc/os-release uname -a free -h nproc # 查看 PCI 设备确认 GPU 是否被系统识别 lspci | grep -iE vga|3d|display如果lspci已经能看到 GPU 设备说明硬件层面是通的。接下来要看厂商驱动是否安装。不同厂商提供的状态工具名称不同例如 NVIDIA 有nvidia-smiAMD 有amd-smi部分国产厂商也有类似工具。你可以先本机探测一下。# 探测常见厂商工具是否存在命令名以实际驱动包为准 which nvidia-smi 2/dev/null which amd-smi 2/dev/null如果这两个都不存在并不代表没有安装驱动只说明你还没有找到对应厂商的状态工具。正确做法是查官方安装文档看驱动安装完成后应该出现哪个命令然后运行它确认驱动版本和设备状态。5.2 安装驱动和运行时驱动安装是整条链路上最容易出问题的一步也是最需要“以官方文档为准”的一步。下面是通用思路实际包名和仓库地址必须替换成官方说明。# 通用示意实际包名和命令以官方驱动文档为准 sudo apt update sudo apt install -y driver-package sudo reboot安装完成后用厂商提供的方式确认驱动是否正常加载。如果官方要求先装内核模块、再安装用户态运行时顺序不能反。常见的失败集中在内核头文件不匹配、Secure Boot 拦截、依赖库版本冲突、需要重新编译模块。遇到这类问题不要盲目改系统配置先看驱动安装日志和官方 FAQ。5.3 PyTorch 兼容性冒烟测试驱动装好之后第一件事不是跑大模型而是确认 PyTorch 是否能识别当前 GPU。很多国产 GPU 会提供兼容 CUDA 的运行时让 PyTorch 通过cuda接口访问硬件也有的需要安装官方专门编译的 PyTorch 分支。import torch print(torch version:, torch.__version__) print(cuda available:, torch.cuda.is_available()) print(gpu count:, torch.cuda.device_count()) if torch.cuda.is_available(): for i in range(torch.cuda.device_count()): print(device, i, torch.cuda.get_device_name(i))如果你的环境把设备暴露为cuda:0这个脚本会输出设备信息。如果cuda available为 False先确认安装的 PyTorch 是否是厂商推荐版本而不是从默认源装的原版 CPU 包。这里不建议直接跑torch.cuda.is_available()后用“不能用 CUDA”就下结论要先排除“包装错”这种常见问题。5.4 矩阵计算与显存管理测试基础环境通过后用一个略大的矩阵乘法验证算子和显存接口。这个测试不算性能基准只确认基础计算链路可用。import torch if torch.cuda.is_available(): device cuda else: device cpu print(device:, device) a torch.randn(4096, 4096, devicedevice) b torch.randn(4096, 4096, devicedevice) c a b if device cuda: torch.cuda.synchronize() print(matmul shape:, c.shape) if torch.cuda.is_available(): print(allocated GB:, round(torch.cuda.memory_allocated() / 1024**3, 2)) print(reserved GB:, round(torch.cuda.memory_reserved() / 1024**3, 2))矩阵乘法能够正常执行说明 PyTorch 与底层算子的基本链路是通的。接下来要注意显存释放反复执行同一段代码观察memory_allocated是否会持续增大。如果每次执行都增长且不释放很可能是算子实现或显存管理存在泄漏这类问题在批量任务场景下会很快变成 OOM。5.5 真实模型推理冒烟测试基础算子通过后进入真正有参考价值的环节加载一个真实模型跑一次前向和生成。这里以小参数生成式模型为例建议先下载到本地避免推理时还要拉取权重。# 小型生成式模型冒烟测试需要提前安装 transformers # 建议先把模型权重下载到本地目录再替换 model_name import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name /data/models/qwen2-0.5b-instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name) if torch.cuda.is_available(): model model.cuda() inputs tokenizer(介绍一下GPU计算。, return_tensorspt) if torch.cuda.is_available(): inputs {k: v.cuda() for k, v in inputs.items()} out model.generate(**inputs, max_new_tokens32) print(tokenizer.decode(out[0], skip_special_tokensTrue))这段代码能跑通说明模型加载、权重搬运、前向计算、采样生成这条主链路是通的。如果这一步失败先看报错是算子缺失、显存不足还是精度异常。算子缺失通常会在日志里打印具体算子名你需要去厂商问题反馈渠道确认是否支持显存不足则要降低模型规模或减小 batch size。5.6 持续负载与稳定性观察冒烟测试只能说明“能跑一次”批量生产场景还需要观察“连续跑很久”。建议用一个固定脚本连续跑 100 轮推理每轮记录延迟、显存、是否出现异常退出。如果连续运行过程中显存持续增长说明需要排查内存泄漏如果偶发 deadlock 或 NaN说明算子实现或精度处理还存在问题。这个测试不一定要多复杂关键是真实反映你的长期负载。对推理服务来说稳定性和显存可控往往比单次延迟更重要对训练来说