1. 从“卡脖子”到“备胎转正”：国产算力的现实与突围
最近和几个做模型训练和推理部署的朋友聊天，话题总绕不开一个词：算力。大家普遍的感受是，国际主流GPU的获取难度和成本越来越高，无论是租用云端实例还是采购实体卡，都面临着诸多不确定性。这种不确定性，已经从单纯的技术选型问题，演变成了影响项目排期、研发节奏乃至商业模式的战略风险。正是在这种背景下，“国产算力”从一个备选方案，迅速走到了台前，成为每个技术决策者都无法回避的课题。
我花了近一个月时间，密集调研了市面上主流的国产AI算力产品，从芯片、板卡到整机、云服务，与厂商、集成商、一线开发者进行了多轮交流，也亲自上手测试了几款主流产品。这篇文章，就是这次调研的总结。它不是一份简单的产品列表，而是一个从技术选型者视角出发，试图回答几个核心问题的深度分析：国产算力的真实性能到底如何？生态适配的“坑”有多深？从国际平台迁移过来的成本和风险有多大？以及，在当下这个节点，我们该如何理性地看待和规划国产算力的引入路径。
无论你是负责技术架构的CTO、攻坚模型算法的研究员，还是负责基础设施运维的工程师，这篇文章都将为你提供一个基于实战视角的参考框架，帮助你在纷繁的信息和宣传中，找到那条最务实、最可行的路径。
2. 性能迷雾：实测数据与纸面参数的巨大鸿沟
谈到国产算力，第一个被问及的问题永远是：“性能怎么样？能达到A100/H100的几成？”这是一个极其合理的问题，但答案却远比一个简单的百分比复杂。我的调研发现，国产算力在性能评估上存在一个显著的“迷雾区”：纸面算力（TFLOPS）与实际应用性能（如训练吞吐量、推理延迟）之间，往往存在巨大差异。
2.1 算力指标的“文字游戏”：FP32、FP16、BF16与INT8
首先，我们必须拆解“算力”这个笼统的概念。国际厂商通常宣传的是其核心张量单元（如NVIDIA的Tensor Core）在特定精度下的峰值算力，例如H100的FP16/BF16算力高达1979 TFLOPS。而许多国产芯片的宣传材料，往往会突出一个非常高的FP32或INT8算力数字。
这里的关键在于应用匹配度。现代大模型训练，尤其是混合精度训练，核心计算密集环节大量使用BF16或FP16精度，推理则广泛使用INT8甚至更低精度。如果一个芯片的FP32算力很高，但张量单元对BF16/FP16的支持效率不佳，或者缺乏专用的低精度计算单元，那么它在训练大模型时的实际表现就会远低于纸面峰值。
在实测中，我遇到过这样的情况：某国产芯片A标称INT8算力是某国际芯片B的1.5倍，但在运行相同的视觉Transformer模型进行INT8量化推理时，芯片A的吞吐量只有芯片B的80%。经过与厂商工程师深度排查，原因在于芯片B的INT8计算单元与内存、片上缓存之间的数据通路经过了极致优化，并且其配套的推理引擎能实现极致的算子融合，减少了数据搬运开销。而芯片A的架构更偏向于通用计算，高算力在遇到复杂的数据依赖和访存瓶颈时，无法被有效释放。
注意：对比性能时，绝不能只看最高精度的峰值算力。必须明确你的核心负载（训练/推理）主要运行在哪种精度下，并索要该精度下的实际基准测试数据，最好是与你业务相似的模型（如BERT、GPT类、ResNet等）的测试结果。
2.2 内存带宽与互联：被忽视的“隐形天花板”
对于大模型训练，另一个比核心算力更关键的指标是内存带宽和卡间互联带宽。模型参数、优化器状态、梯度、激活值等都需要在显存中存放。当模型规模大到一定程度（例如千亿参数），单卡显存放不下，就必须进行模型并行。此时，GPU之间交换数据（如梯度同步）的速度，直接决定了训练效率。
目前领先的国际芯片，其HBM高带宽内存的带宽可达数TB/s，NVLink互联带宽也达到900GB/s。国产芯片在这一领域的差距相对核心算力而言更为明显。多数国产芯片仍使用GDDR6甚至更早的内存，带宽在数百GB/s量级；卡间互联多依赖PCIe 4.0或定制互联协议，双向带宽通常在100-200GB/s左右。
这意味着什么？意味着在训练百亿参数以上模型时，国产算力集群可能更容易遇到通信瓶颈。计算卡很快完成了本地计算，但需要花费大量时间等待与其他卡同步数据，导致整体利用率上不去。在测试一个中等规模的集群时，我们观察到，当把数据并行维度扩大时，由于All-Reduce通信开销激增，国产集群的加速比迅速衰减，而基于NVLink的集群则表现得更线性。
给选型者的建议：如果你的应用场景是单卡推理或小规模微调，可以更关注单卡算力和内存容量。但如果涉及大规模分布式训练，必须将互联拓扑和带宽作为核心评估指标，并实际测试在目标模型和并行策略下的扩展效率。不要只看单卡性能报告。
2.3 软件栈的“性能损耗”：从芯片到应用的漫长路径
这是国产算力面临的最大挑战之一，也是性能迷雾中最浓的部分。国际大厂的CUDA生态，经过十多年迭代，其编译器、算子库（cuDNN, cuBLAS）、通信库（NCCL）和框架（PyTorch, TensorFlow）集成已经高度优化，能将硬件性能几乎“无损”地传递给应用层。
而国产算力大多需要一套独立的软件栈：自己的驱动、自己的算子库、自己的编译器，以及一个用于将PyTorch/TensorFlow代码“翻译”过来的适配层（例如通过定制化的算子或图编译工具）。每一层都可能带来性能损耗。
- 算子覆盖度：cuDNN有上千个高度优化的深度学习算子。国产芯片的算子库往往先覆盖最常用的几十到上百个算子。当你的模型用到某个生僻算子时，可能会回落到效率较低的通用计算路径，甚至无法运行。
- 图编译与优化：为了提升性能，国产软件栈通常会引入一个图编译器（类似TensorRT），将动态图转为静态图进行优化。这个过程本身需要时间，且其优化能力（如算子融合、内存复用）的成熟度，直接决定了最终性能。在测试中，同一个模型，使用厂商的图编译工具优化后，性能可能比直接运行提升2-5倍，但这个优化过程可能不稳定，对模型结构有特定要求。
- 框架适配的透明性：理想情况是用户无需修改代码。现实是，为了兼容和性能，你可能需要将模型代码中的某些部分，替换成厂商提供的定制化API，或者按照其最佳实践调整模型结构（如特定的算子组合方式）。这带来了额外的迁移和锁定成本。
我的实测体会是，对于一款成熟的国产芯片，在运行其“官方优化过”的标杆模型（如ResNet-50、BERT）时，性能可能达到同级别国际芯片的70%-90%，这是一个相当不错的成绩。但一旦运行一个结构较新的、自定义的模型，性能可能会下降到30%-50%，甚至需要投入大量工程精力进行调优才能跑通。这种性能的不确定性，是评估国产算力时必须计入的风险成本。
3. 生态困境：从“能用”到“好用”的漫长征途
性能决定了国产算力的“天花板”，而生态则决定了它的“地板”——即日常使用的便捷性和稳定性。生态不仅仅是软件栈，它涵盖了从开发、部署到监控、调试的完整生命周期体验。
3.1 开发体验：IDE、调试与 profiling 工具的缺失
对于CUDA开发者，有Nsight系列工具链，可以方便地进行性能剖析（profiling）、内存错误检测、并发问题调试。你可以清晰地看到每个kernel的执行时间、内存吞吐、SM利用率，快速定位热点和瓶颈。
目前，国产算力平台在这方面的工具链普遍处于早期阶段。提供的 profiling 工具信息可能比较粗糙，难以进行细粒度的性能分析。调试手段也相对单一，当遇到内核执行错误或内存越界时，定位问题的难度较大。这导致开发调试周期变长，尤其对于需要深度性能优化的场景，会感到“有力使不出”。
3.2 部署与运维：容器化、编排与监控的集成度
现代AI生产环境几乎都建立在Kubernetes等容器编排平台之上。国际芯片的GPU资源可以通过Kubernetes Device Plugin被方便地调度和管理，并有成熟的监控方案（如DCGM）来收集每张卡的利用率、温度、功耗、显存使用情况。
国产算力在这方面的集成度参差不齐。有些厂商提供了完整的Kubernetes Device Plugin和监控 exporter，可以相对平滑地融入现有云原生体系。有些则可能需要运维人员手动安装驱动、配置设备，监控也需要通过厂商自己的命令行工具来采集数据，再接入监控系统。这增加了运维的复杂度和定制化开发的工作量。
3.3 社区与知识沉淀：遇到问题怎么办？
这是最现实的挑战。当你使用CUDA遇到一个诡异的问题时，你有极大概率能在Stack Overflow、GitHub Issues或技术博客中找到相似的提问和解决方案。因为这是一个拥有数百万开发者的全球性生态。
而使用一款国产芯片，你遇到问题时，首要的（有时是唯一的）求助对象是厂商的支持团队。社区力量薄弱，可参考的公开案例和解决方案很少。这意味着解决问题的速度很大程度上依赖于厂商支持团队的响应速度和技术能力。对于一些复杂、边缘的问题，可能会陷入漫长的等待和排查。因此，评估一个国产算力产品时，其厂商的技术支持能力和已有客户的案例参考，是一个至关重要的软性指标。
4. 迁移成本评估：不仅仅是代码改写
当决定尝试国产算力时，下一个问题就是：迁移要花多大代价？很多人第一反应是重写CUDA代码。但实际上，对于大多数使用高级框架（PyTorch/TensorFlow）的AI应用，需要直接写CUDA Kernel的场景并不多。迁移成本主要体现在其他更隐蔽的方面。
4.1 模型代码的适配性修改
如前所述，为了达到最佳性能或仅仅是为了能运行，你可能需要：
- 替换算子：将模型中的某些算子替换为厂商优化过的等效算子。
- 调整模型结构：例如，将某些操作序列改为符合厂商图编译器优化偏好的形式。
- 插入编译指令：在代码中添加特定的装饰器或上下文管理器，以指导厂商的编译器进行优化。 这些修改虽然可能不涉及算法逻辑，但破坏了代码的“纯洁性”，使得同一份代码库需要为不同的硬件维护多个版本，增加了长期维护成本。
4.2 训练 pipeline 与工具链的调整
你的训练流程可能依赖一系列围绕CUDA生态构建的工具：
- 混合精度训练：使用
torch.cuda.amp。国产平台可能需要换用厂商提供的AMP替代方案，其稳定性和效果需要验证。 - 分布式训练：使用
torch.distributed+ NCCL。国产平台需要替换通信后端为厂商提供的库（如华为的HCCL，寒武纪的CNCL），其在大规模集群下的稳定性和性能至关重要。 - 数据加载与预处理：如果使用了
torchvision的GPU加速变换或DALI库，需要确认是否有替代实现或回退到CPU处理。 - 自定义CUDA扩展：如果你或你依赖的第三方库有自定义的CUDA扩展（C++/CUDA），那么这就是迁移中最大的难点，几乎需要为国产芯片重写。
4.3 量化与推理部署的额外工作
在推理侧，迁移挑战更大。如果你原本使用TensorRT或Torch-TensorRT来优化和部署模型，那么切换到国产平台，意味着你需要学习并使用一套全新的推理优化工具链。这套工具链的自动化程度、优化效果、以及对复杂模型（如动态shape、多分支结构）的支持能力，都需要从头评估和测试。
一个实际的迁移案例是，一个原本在T4上使用TensorRT部署的服务，迁移到某国产卡时，需要先将模型转换为ONNX，再用厂商的工具链对ONNX模型进行编译优化。过程中遇到了多个算子不支持的问题，需要回退到上游修改模型结构或寻找替代实现，整个迁移和调优周期长达数周。
5. 选型策略与落地路径：务实者的行动指南
基于以上分析，对于考虑引入国产算力的团队，我建议采取一种分阶段、场景驱动的务实策略，而不是“All-in”或“完全拒绝”的二元选择。
5.1 场景分级：哪里是国产算力的“甜点区”？
并非所有AI工作负载都同等适合国产算力起步。我们可以根据需求，划分出优先级：
- 高优先级（推荐先行试点）：
- 离线推理任务：对延迟不敏感的视频分析、内容审核、数据预处理等。可以容忍一定的性能波动和调试时间。
- 模型微调（Fine-tuning）：尤其是参数量在百亿以下，基于LoRA等参数高效方法的微调。计算模式相对固定，通信压力小于预训练。
- 特定算法验证与开发：在受控环境下，验证国产平台对特定算法的支持度，为未来迁移积累经验。
- 中优先级（条件成熟后考虑）：
- 在线推理服务：需要严格评估其推理延迟、吞吐量和稳定性是否满足SLA，并做好充分的压力测试和降级方案。
- 中小规模分布式训练（数十卡以内）：需要重点测试其通信库的稳定性和扩展效率。
- 低优先级（暂不建议）：
- 千亿参数级别的大模型预训练：对算力、通信、软件栈稳定性和集群运维的要求都极高，目前仍是国产算力挑战最大的领域。
5.2 概念验证（PoC）必须包含的测试项
在正式采购或大规模部署前，必须进行严格的PoC测试。测试不应只是跑一个Benchmark脚本，而应模拟真实生产环境：
- 功能完整性测试：用你的核心业务模型和数据从头到尾跑通训练或推理流程，确保所有算子支持，结果正确。
- 性能基准测试：在相同配置（CPU、内存、存储、网络）下，与国际芯片对比吞吐量、延迟、能效比（性能/功耗）。记录峰值性能和持续稳定运行时的性能。
- 稳定性与压力测试：连续运行任务72小时以上，观察是否有内存泄漏、显存错误、进程崩溃等问题。模拟高并发推理场景。
- 迁移工作量评估：详细记录为适配国产平台所做的代码修改、配置调整、问题排查所花费的人时，这是评估总拥有成本（TCO）的关键。
- 运维流程测试：尝试在你们的Kubernetes集群中部署、监控、扩容缩容基于国产算力的应用，评估运维复杂度。
5.3 混合架构与渐进式迁移
最稳妥的策略是构建混合算力架构。在云上或数据中心内，同时保有国际算力池和国产算力池。通过集群管理软件，根据作业的类型、优先级和资源需求，将其调度到不同的算力池中。
- 初期：将离线推理、开发测试环境迁移到国产算力池。
- 中期：将部分在线流量（如非核心业务、低峰期流量）切到国产算力进行服务，并持续监控。
- 长期：随着国产算力生态的成熟和团队经验的积累，逐步扩大其承载的业务范围。
这种架构既能控制风险，保证核心业务的连续性，又能持续积累国产算力的使用经验，培养团队能力，为未来的不可预测性做好准备。
6. 主流玩家与产品图谱：谁在做什么？
国产AI算力并非铁板一块，其内部根据技术路线、产品形态和市场定位，形成了差异化的竞争格局。了解主要玩家及其特点，是选型的第一步。
6.1 芯片级玩家：自研架构与生态构建
这是技术门槛最高的领域，目标是做出对标GPU的通用AI加速芯片。
- 华为昇腾（Ascend）：目前生态最完善、产品线最全的玩家。从昇腾910（训练）到310（推理）芯片，到Atlas系列板卡/服务器，再到全栈软件（CANN异构计算架构、MindSpore框架、昇思模型库）。其优势在于软硬件垂直整合能力强，且有华为云作为落地出口。挑战在于其生态相对封闭，与PyTorch/TensorFlow的兼容层（如torch_npu）仍需持续完善，且受外部因素影响供应链存在不确定性。
- 寒武纪（Cambricon）：国内较早专注AI芯片的公司，思元（MLU）系列芯片覆盖云边端。其软件栈（Cambricon NeuWare）也在不断迭代，支持主流框架。寒武纪的架构设计有自身特点，在某些特定模型上表现突出，但通用性和生态丰富度与昇腾相比仍有差距。
- 壁仞科技（Biren）：新兴GPU公司，旨在开发原创架构的通用GPU。其首款产品BR100系列宣称了很高的纸面算力。壁仞的潜力在于其全新的架构设计可能带来更好的能效比，但其软件栈和生态从零开始建设，成熟度需要时间验证，是目前最大的不确定性。
- 摩尔线程（Moore Threads）：定位也是全功能GPU，其产品更强调图形渲染与AI计算的融合。在AI计算方面，其软件栈正在积极适配PyTorch等生态。与壁仞类似，其生态建设是成败关键。
选型思考：如果追求相对成熟的生态和全栈解决方案，昇腾是目前风险较低的选择。如果愿意与厂商共同成长，承担早期生态不完善的风险以获取更紧密的合作关系或特定优势，可以关注壁仞、摩尔线程等新兴玩家。
6.2 板卡与服务器集成商：将芯片转化为产品
芯片需要被做成板卡，再集成到服务器中。这个领域既有华为、浪潮、新华三这样同时做芯片和整机的大厂，也有像宁畅、安擎等专业的服务器厂商，他们基于华为昇腾、寒武纪等芯片，设计、生产并销售AI服务器。
- 价值：他们提供的是开箱即用的硬件产品，负责硬件兼容性测试、散热设计、基础固件和驱动集成。对于用户来说，采购这类整机可以免去底层硬件适配的烦恼。
- 选择关键：关注其产品与上游芯片厂商软件栈的认证和优化程度，以及他们自身提供的增值服务，如定制化配置、本地化技术支持、运维工具等。
6.3 云服务商：提供算力即服务
这是最便捷的使用方式。国内主流云厂商（阿里云、腾讯云、百度云、华为云等）均已上线基于国产AI芯片的算力实例。
- 优势：
- 零成本尝试：按需付费，无需承担高昂的硬件采购成本和漫长的交付周期。
- 免运维：无需关心底层硬件运维、驱动升级。
- 弹性伸缩：可以快速创建大规模集群进行短期训练任务。
- 生态集成：云厂商通常会做深度优化，提供预装好软件栈的镜像、与对象存储高速对接的工具、以及监控告警服务。
- 劣势：
- 长期成本：对于需要长期、稳定、高负载使用的场景，自建机房的总体拥有成本可能更低。
- 定制化限制：云服务的硬件配置和软件环境是标准化的，难以进行深度定制。
- 数据安全与合规：对于数据敏感性极高的行业，上云可能存在顾虑。
建议：对于初步调研、PoC测试、弹性任务（如临时性的大规模训练），优先使用云服务。这是验证国产算力是否适合你业务场景的最快、最经济的方式。在云上完成技术验证和初步适配后，再根据长期需求决定是否自建。
7. 未来展望与团队能力建设
国产算力的发展不是一蹴而就的，它是一场需要产业链上下游共同参与的“马拉松”。对于最终用户而言，除了关注产品本身，更需要构建与之匹配的团队能力。
7.1 技术趋势观察
- 软硬件协同设计深化：下一代国产芯片将更紧密地与自家或深度合作的软件栈绑定，通过定制指令集、存储架构来进一步提升特定负载的效率，与CUDA生态的通用性差距可能长期存在，但会在特定赛道形成优势。
- 开源与开放成为关键：越来越多的国产芯片厂商开始将部分软件栈开源（如算子库、编译器前端），或更积极地向上游主流框架（PyTorch）贡献代码，以降低开发者的移植门槛，融入更广阔的生态。这是决定其发展速度的关键因素。
- Chiplet与先进封装：在单一芯片工艺追赶受限的背景下，通过Chiplet（芯粒）技术和先进封装，将多个不同工艺、不同功能的裸片集成在一起，成为提升性能、降低成本的重要路径。
- 推理芯片的差异化竞争：在推理市场，场景更加碎片化，对能效比、成本更敏感。这将催生更多针对视觉、语音、推荐系统等特定场景优化的推理芯片，形成百花齐放的格局。
7.2 团队能力建设清单
引入国产算力，不仅仅是换一批硬件，更是对团队技术栈的一次拓展。建议有意识地培养以下能力：
- 异构计算基础：团队成员需要理解基本的计算机体系结构、内存层次、并行计算原理，这有助于理解不同芯片的架构特点，更好地进行性能分析和调优。
- 框架底层知识：不再满足于调用PyTorch/TensorFlow的高级API，需要有人能深入理解计算图、算子分发、自动微分等机制，以便在遇到兼容性问题时能快速定位是框架层、算子层还是驱动层的问题。
- 性能剖析与调优技能：掌握国产平台提供的（哪怕是不完善的）Profiling工具，学会从系统层面（CPU、内存、IO、网络）和芯片层面（算力利用率、内存带宽、通信开销）综合分析性能瓶颈。
- 跨平台抽象能力：在业务代码和硬件之间，构建一层薄薄的抽象接口或中间件。将硬件相关的适配代码（如算子替换、编译指令）集中管理，使核心业务逻辑保持硬件无关。这能极大降低未来维护和迁移的成本。
- 与厂商协同的能力：学会如何高效地向厂商技术支持提问题（提供完整的复现步骤、日志、环境信息），并积极参与社区或早期用户计划，将需求反馈给厂商，推动其生态完善。
国产算力的道路注定不会平坦，它充满了性能、生态、迁移成本上的挑战。但对于中国的AI产业而言，这是一条必须走通的路。作为一线的技术实践者，我们既不能盲目乐观，也不应消极回避。最务实的态度是：认清差距，积极测试，场景切入，小步快跑。在可控的风险范围内，开始积累经验，培养团队，为未来更复杂的算力环境做好准备。这个过程本身，就是对团队技术深度和架构能力的一次极好锤炼。当潮水再次变化时，那些早已在泳池中练习的人，才能从容应对。
