企业官网建设流程全解析

大模型规模膨胀已经是明牌，国内AI芯片在过去两年被推到风口浪尖，但真正冷静下来想，单卡算力的军备竞赛只是一层皮。刚接触这个领域的人很容易盯着TFLOPS、显存带宽这些纸面参数，以为数字上去了就万事大吉。可实际跑过千亿参数模型训练和推理的人都知道，瓶颈根本不在那张卡的峰值算力，而是整条链路能不能顺畅地转起来。大模型时代AI芯片的胜负手，早就不再是单纯的硬件工程，而是全栈协同——从芯片指令集到编译器、运行时、框架适配、分布式并行策略，再到上层应用，每一层都必须咬合紧密。

这篇文章不打算做那种“某某芯片发布、性能翻倍”的新闻式复述，我想从一线开发和部署的视角，把国内AI芯片在这场规模竞赛里真正要过的关、要踩的坑、要补的课拆开讲清楚。如果你正在评估国产算力方案，或者作为算法工程师要给团队做大模型基础设施选型，又或者在考虑要不要投入精力做芯片软件栈适配，这篇内容应该能给你一个比较完整的参照系。

1. 大模型“规模膨胀”究竟把压力加在了哪里

1.1 参数增长只是最表层的压力

这几年大模型的参数规模从百亿冲到千亿、万亿，大家都盯着参数量看。但参数量增长带来的不只是“存储变大了”这么简单，它同时放大了三层压力：第一层是显存容量的压力，第二层是计算量的压力，第三层是通信量的压力。

显存容量这块最好理解，1750亿参数的模型，光参数用FP16存就要350GB，这已经超出任何单张AI芯片的显存上限。于是张量并行、流水线并行、专家并行这些分布式策略成了必经之路。但并行策略一上，通信就来了。张量并行每一步前向反向都要做AllReduce，流水线并行有 bubble 开销，专家并行的 All-to-All 通信更是出了名的“通信杀手”。我见过很多团队拿着单卡性能很漂亮的国产芯片，一上MoE模型，吞吐率直接腰斩，问题全出在互联和集合通信库上。

第二层计算量的压力，很多人体感不强。大家习惯说“算力是FLOPs”，但大模型时代真正要看的不是峰值FLOPs，而是“有效算力利用率”，也就是MFU（Model FLOPs Utilization）。英伟达的GPU跑GPT级别的稠密模型，MFU能做到45%到55%已经很不错了，MoE模型更是经常掉到30%以下。国产芯片的纸面算力这几年追得很猛，但实际把模型跑起来，MFU能到35%以上的不多。这不是芯片本身的计算单元不行，而是算力调度、显存带宽匹配、算子实现质量这些全栈环节没跟上。

第三层通信压力是最容易被低估的。千卡集群跑大模型，每过几个step就要做一次全集群的梯度同步，通信占比随规模上升而上升。国产芯片的互联协议、集合通信库、网络拓扑调度，直接决定了能不能把“千卡线性扩展”这件事做到接近理想值。很多芯片单卡性能不错，一上规模就露馅，原因就在这里。

1.2 上下文长度和KV Cache带来的隐性膨胀

除了参数规模，大模型规模膨胀的另一个隐蔽维度是上下文长度。现在主流模型都往128K、1M token走了，这直接让KV Cache成为显存消耗的大头。我做过一个粗略测算：7B模型、FP16权重占14GB，但跑32K上下文时KV Cache能吃掉额外的12到16GB，这几乎等于模型权重本身。到了1M上下文，KV Cache的显存需求会是非线性飙升，就算做GQA（分组查询注意力）、MLA（多头潜在注意力）这些优化，依然对显存容量和带宽提出极高要求。

这对AI芯片意味着什么？意味着除了算力，芯片的HBM容量、HBM带宽、片上缓存调度能力都成了硬指标。很多国产芯片为了拼算力，把流处理器堆得很高，但显存带宽跟不上，跑长上下文时大量时间耗在访存等待上。实测下来，attention部分的内存密集型计算会把整卡利用率拖下去。这也是为什么我做芯片选型时，会先看“带宽容量比”这个指标，而不是只看TOPS。

KV Cache这个隐性膨胀还带来一个工程问题：推理时的显存管理。大模型推理服务要动态管理KV Cache内存池，处理不好就会出现显存碎片化、OOM、或者beam search并发度上不去。芯片方如果能在驱动和运行时层面提供更好的显存管理接口，对上层推理框架的优化效果是实打实的。这块英伟达做得最早也最完整，国产芯片在这块还处于追赶状态。

注意：KV Cache的显存需求可以通过公式粗略估算：2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批量大小 × 字节数。算一次你就能理解为什么长上下文对芯片显存是场灾难。

1.3 规模膨胀从训练卷到了推理

训练端的规模膨胀大家感知很深，但2024年下半年以后，推理端的膨胀更值得关注。OpenAI o1带火了推理时计算（inference-time compute），模型在生成答案之前要先做内部推理、反思、多轮采样，这导致单次请求的算力消耗比传统生成高出一个数量级。换句话说，大模型的应用规模也在膨胀，不只是模型规模。

这对AI芯片的影响呈现在两个维度：一是推理服务的延迟敏感性与吞吐需求并存，二是推理负载的多样性要求芯片架构有更强的通用性。过去一些芯片把精力都押在训练场景的矩阵运算上，一到推理阶段，面对不同的模型结构、不同的量化精度、不同的并发模式，优化空间就显得局促。我实际测过一款国产芯片，训练性能纸面参数不错，但跑 Stable Diffusion 或者多模态模型时，因为不适应非标准形状的卷积和注意力算子，性能掉得非常厉害。

所以大模型规模膨胀带来的不是一个线性增长的“算力需求”，而是一个多维度、全链路的压力矩阵。芯片厂商如果只盯着单卡峰值算力这一项，基本是在回避真正的问题。这也是为什么我们说全栈协同才是胜负手——因为压力分布在整个技术栈的每一个环节里。

2. 单点芯片性能之外的“隐性战场”

2.1 算力利用率：纸面算力和真实吞吐是两回事

金融圈和媒体喜欢看芯片的“XX TOPS”或者“XX PFLOPS”，但真正跑大模型的人心里清楚，峰值算力这个数字能说明的东西非常有限。我在实际测试里见过很多次，同一款芯片在不同框架上的表现可以差出3倍以上，同一张卡在不同并行策略下的MFU也能差出近一倍。原因在于大模型计算不是单纯在跑GEMM，而是大量算子拼接、显存搬运、kernel launch的集合。

以GPT-3级别的稠密模型为例。一次训练step包含前向几百个算子、反向再翻一倍、每N步还要做梯度聚合和参数更新。每一个算子都需要kernel实现得高效，kernel之间的调度和显存复用也需要合理。如果芯片的软件栈里算子库覆盖不全、性能不佳，某些关键算子就要fallback到generic实现，性能可能掉一个数量级。

更关键的是，大模型里最重的几个算子往往不是标准的矩阵乘，而是融合了多种操作的复合算子。例如FlashAttention把attention的计算和显存访问做了融合处理，这事对芯片架构很敏感。英伟达的FlashAttention性能之所以高，不只是算法好，还因为H100的Tensor Core、共享内存容量、线程调度都在为这种融合算子服务。国产芯片如果要达到同等级别的性能，必须在指令集、缓存层级、同步原语上都为这种融合模式做专门设计，并且通过编译器把上层算法高效映射到底层硬件。

我跑过一组对比：同样是大规模矩阵乘，用厂商自带的tuned kernel和用上一代通用kernel，性能差距可以达到2.5倍。这就意味着，芯片的真实性能上限是由软件栈里预置的kernel集合决定的。算子覆盖不全、调优不到位的芯片，即便硬件理论性能再高，用户实际能用到的也只有一小部分。这件事在芯片行业叫“可达性能”（achievable performance），它和“峰值性能”（peak performance）之间的鸿沟，就是全栈协同要填的坑。

2.2 内存墙：大模型时代最硬的那堵墙

过去十年芯片设计最头疼的问题是“内存墙”——计算单元越来越快，但数据从内存搬到计算单元的速度没跟上。大模型把这个矛盾放到了最大。transformer模型的核心计算是attention和FFN，它们的共同特征是“数据复用率低”，几乎每个计算都依赖新鲜的输入数据，缓存命中率上不去，算力再高也得等数据。

一个直观的数字：H100的HBM带宽是3.35TB/s，看起来很高对吧？但折算到FP16的BF16计算上，每TB/s带宽只能支撑大约500到700 TFLOPS的稠密计算吞吐。H100的BF16算力接近1000 TFLOPS，这意味着单靠HBM带宽根本喂不饱算力，必须靠稀疏化、缓存复用、算子融合来减少访存需求。这就是英伟达不断加大L2缓存、引入Transformer Engine的原因。国产AI芯片的算力如果对标H100，但HBM带宽只做到2TB/s甚至更低，那真实计算吞吐一定被带宽卡脖子。

对推理场景，内存墙的影响更致命。解码阶段是token-by-token生成，每次只算一个token，计算量极小，但权重和KV Cache都得从头读一遍，大模型推理本质上是“带宽受限”任务。这时候芯片的带宽优势比算力优势更管用。很多国产芯片做推理性能测试时数据不错，就是靠少数几个高带宽模型硬撑；一到低比特量化、长上下文、高并发这些复杂组合，带宽短板就暴露了。

这也是为什么国内AI芯片设计上需要越来越重视以下几个方向：

• HBM容量和带宽的提升，尤其是带宽不能落后于算力太多
• 片上SRAM的容量和带宽设计，为算子融合提供足够“临时仓库”
• 数据通路设计，减少计算单元和片上存储之间的搬运开销

拿1.1节提过的7B模型推理举例：权重14GB（FP16）+ 32K上下文的KV Cache约12GB，总共26GB。如果芯片只有32GB显存，同时开64路并发，KV Cache共享策略就要精细设计。芯片方的显存管理和内存复用能力如果弱，推理框架的调度优化全白搭。这种底层短板，靠上层软件优化是补不齐的。

2.3 互联与集群：千卡万卡时代的隐形胜负手

单卡做得好只能在中小规模场景自嗨，大模型训练和超大规模推理拼的都是集群能力。千卡集群跑一个万亿模型，每step的梯度同步数据量可能是几十GB，全部要通过NVLink或者自研互联网络汇聚。任何一个环节的带宽瓶颈、拓扑不均、拥塞控制不到位，都会让集群的有效算力远低于简单相加。

国产芯片的互联方案，客观说要承认差距。PCIe带宽有限，而专用互联协议（对标NVLink）需要深厚的SerDes、光模块、网络拓扑、拥塞控制的全栈技术积累。更麻烦的是集合通信库——英伟达的NCCL经过十年迭代，针对各种拓扑和消息大小做了精细调优。国产芯片的集合通信库要么基于开源修改，要么自研但成熟度不足，实际跑千卡规模时经常出现通信拖尾、小消息延迟高、或者拓扑感知调度不合理的问题。

我做过多机多卡训练部署，印象最深的一件事是：同一套代码，在英伟达集群上扩展效率能做到0.85以上，在换上国产芯片集群后直接掉到0.7甚至更低。这不是说国产芯片硬件不行，而是通信库没把硬件能力充分释放出来。芯片互联的物理带宽是一回事，软件能不能把这个带宽按正确的方式用起来是另一回事。全栈协同的价值在这里体现得最充分。

大模型集群还有一个隐蔽问题：故障率。千卡以上集群，每天都有卡或节点出现异常。分布式训练框架需要快速感知故障、自动踢出异常节点、做状态同步和checkpoint恢复。这个“韧性能力”也是全栈的一部分。芯片方提供的驱动、运行时、健康检测接口越完善，上层作业调度系统就能做得越稳。反过来，如果驱动不稳定、健康检测不准确，运维团队就要疲于奔命地排查“薛定谔的故障”。

3. 全栈协同：从芯片到框架的每一层都要打通

3.1 全栈栈的七个层次

全栈协同不是一句口号，它有非常具体的层级结构。我习惯把大模型时代的AI芯片软件栈分成七层：

1. 硬件层：芯片、内存、互联、片内缓存
2. 驱动与运行时：设备管理、显存分配、kernel launch、事件同步
3. 算子库：基础算子、融合算子、手写高性能kernel
4. 编译器：图优化、算子映射、自动调优、代码生成
5. 框架适配层：PyTorch、TensorFlow、MindSpore等框架的算子对接
6. 分布式并行层：集合通信、并行策略、自动并行、流水调度
7. 应用与服务层：推理引擎、微调工具、部署平台、多模态应用

英伟达之所以长时间一家独大，绝不仅仅是硬件性能强。CUDA生态从第3层到第7层都做了非常深度的绑定和优化。PyTorch的torch.cuda、NCCL、cuDNN、TensorRT、Triton，这是一整套严丝合缝的协同体系。你用PyTorch在英伟达GPU上写代码，几乎可以认为框架和硬件的适配是“出厂完成”的。

国产芯片面临的问题是：第1层和第2层可以自研，第3层的算子库可以慢慢补，但第4层到第7层不是靠芯片厂商一家能做到完美的。PyTorch是社区的，分布式并行策略是学术界的，推理引擎是多个独立项目的。芯片厂商必须在别人的代码里以自己的硬件为后端来优化，这是一个被动的、持续追赶的过程。全栈协同的意思，恰恰是在这种被动中建立主动的适配和优化机制。

3.2 芯片厂商必须做厚“中间层”

AI芯片和CPU、GPU一个最大的不同是：AI芯片的硬件特性暴露面非常大，上层软件不可能完全无视硬件特性来获得好性能。这意味着芯片厂商必须把“中间层”做厚，去承接上层框架的通用性和底层硬件的高效性之间的矛盾。

具体来说，中间层要做四件事：

• 把PyTorch等框架的算子调用翻译成芯片原生的高效kernel调用
• 对计算图做硬件友好的优化，比如算子融合、内存布局转换、通信与计算重叠
• 提供灵活的编程接口，允许高级用户用类Triton的语言写自定义算子
• 做自动调优，针对特定模型和特定硬件组合搜索最优的执行计划

我见过一家国产芯片厂商的做法很有趣，他们在中间层做了一个“算子兼容层”，目标是让PyTorch的torch.nn模块不经改动就能调用芯片的高效kernel，同时支持部分Triton方言。这种做法短期内能换来“框架兼容”的好名声，但长期看还是要在性能上下苦功夫。因为兼容不代表了高效，PyTorch默认的算子实现可能不是你的硬件上最高效的方式，你必须自己去改写和调优。

做个类比：CPU和操作系统之间的关系。Windows给应用提供稳定的API，但游戏厂商追求极致性能时还是要深度了解GPU驱动和硬件特性。AI芯片和大模型框架之间的关系，更像游戏引擎和显卡之间那种需要深度协同的关系——你不能只提供“API能跑”，你得让引擎知道你硬件上哪条链路最快。

3.3 框架适配的“最后一公里”

很多国产芯片厂商说“我们已经适配了PyTorch”，但实际用起来根本是两回事。能在PyTorch上跑通一个模型，和能在这个芯片上高效跑大模型训练，中间隔着非常远的距离。我做适配测试时习惯用这几个维度来衡量：

• 算子覆盖率：模型里的算子有多少能在芯片上跑原生kernel，多少会fallback
• 性能命中率：关键算子能否用上芯片的Tensor Core类专用单元
• 动态shape支持：大模型推理时的变长输入能否高效处理
• 显存管理效率：框架的显存缓存、释放策略与芯片驱动的配合度

列个简单的对比表，帮助理解框架适配成熟度：

“最后一公里”的适配工作远比想象中琐碎。比如PyTorch里一个很常见的内存格式问题：channels_last布局在某些芯片上支持得不好，模型跑起来没报错但性能低了20%。再比如torch.compile引入的编译路径，很多国产芯片的编译器并没能完全走通，用户一开compile反而更慢。这些问题用户很少会去深究，最后就汇总成了“国产芯片不好用”的刻板印象。

4. 实操经验：国产芯片跑大模型的常见坑和排查思路

4.1 算子fallback悄无声息，性能翻车无从查起

我做大模型部署踩过最深的坑：模型能跑，但性能差到怀疑人生，排查了很久才发现是某个关键的layernorm算子根本没有原生的高效实现，静默fallback到了通用实现。因为整个过程没有任何报错，日志里看起来一切正常。

后来我学乖了，做性能摸底测试时一定会看kernel层面的执行统计，逐个检查关键算子用的是不是原生实现。具体做法是在profiling工具里把每个算子的执行时间排个序，看Top20热点算子里有没有异常偏低的情况。像RMSNorm、RoPE、softmax这些看似不起眼的算子，在大模型里出现的频率极高，它们的kernel质量直接影响整体性能。

注意，算子融合是目前大模型性能优化的核心手段：把多个操作融合成一个kernel，减少显存读写和kernel launch开销。比如QKV投影、缩放、mask、softmax、输出投影可以融合成“融合attention”。芯片方如果提供了一套好用的融合算子库，上层性能会明显提升；如果只有基础算子，开发者就得自己去写custom kernel，这对国产芯片的编程生态是一个很大的考验。我见过团队为了解决算子性能问题，硬是花一个月把Triton方言适配到国产芯片上，效果确实好，但投入产出比需要认真评估。

提示：拿到一款新芯片，先别急着跑大模型，先跑一遍算子基准测试。把矩阵乘、卷积、attention、layernorm、softmax这几个核心算子的性能和厂商给出的数据对比一下，差得太多说明软件栈还没准备好。

4.2 显存管理的“隐性碎片”拖垮推理并发

大模型推理服务的显存管理比训练更细腻。推理时每个请求都会动态申请KV Cache的内存块，请求结束后释放。这种高频的分配释放很容易产生显存碎片。PyTorch的缓存分配器有memory pool机制还好，但到了推理引擎层面（比如vLLM），PagedAttention的思路是把KV Cache切成固定大小的块来分配，本质上是学操作系统的虚拟内存管理。

国产芯片的驱动层如果提供了高效的显存池接口，推理框架的优化空间就很大。但不少芯片的驱动还是传统的“分配-释放”模型，不支持细粒度的内存映射和sub-allocation，导致推理框架只能在自己的用户态内存池里曲线救国，性能损耗难以避免。实测下来，同样一个7B模型做并发推理，显存管理效率高的芯片可以轻松跑满64路并发，效率低的可能到32路就开始频繁GC或者OOM。

排查这类问题我通常先看显存占用的时间线：如果显存总量没满但频繁报OOM，大概率是碎片化问题；如果显存总量很低但性能上不去，可能是内存池太大或太小的问题。另外要留意驱动版本和推理框架版本的配合，很多时候厂商在某次驱动更新里优化了内存分配策略，但推理框架没升级适配，就发挥不出来。

4.3 并行策略与芯片互联特性的匹配

大模型训练的并行策略不是随便选的。张量并行（TP）对芯片间的低延迟高带宽要求极高，流水线并行（PP）对显存容量要求很高，数据并行（DP）对梯度通信带宽要求高，MoE模型还要考虑专家并行（EP）的高阶All-to-All通信。芯片的互联拓扑和通信库能力，直接决定了哪些并行策略是“推荐使用”、哪些是“慎用”。

主流大模型并行配置示例（8机64卡场景）：

# 张量并行4 + 流水线并行4 + 数据并行4 # 需要芯片互联支持TP4的通信模式 torchrun --nproc_per_node=8 --nnodes=8 \ --master_addr=... --master_port=... \ train.py \ --tensor-parallel-size 4 \ --pipeline-parallel-size 4 \ --data-parallel-size 4 \ --micro-batch-size 2 \ --gradient-checkpointing \ --zero-optimizer stage=1

硬件互联能力差时，优先降低TP的度数，用PP和DP补齐；通讯性能好则可以提高TP度数来减少流水线bubble和显存重复。但很多团队的默认配置是为英伟达的NVLink+InfiniBand优化的，换到国产芯片上如果不调整并行策略，性能会非常差。我做国产芯片适配的经验是：先做一轮并行策略的网格搜索，找一个最契合当前芯片互联拓扑的配置组合，往往能多榨出20%到30%的集群利用率。

这个“20%到30%”不是玄学。芯片的互联拓扑和通信库特性不同，最优并行策略也不同。比如某国产芯片的机内互联带宽远高于机间互联，那就应该把TP控制在一机内、跨机尽量走PP或DP，避免跨机AllReduce。这些细节如果没有人去“协同”调整，而以“兼容PyTorch”为目标的话，永远只能跑成低效模式。

4.4 推理框架选型：并不只有vLLM一条路

大模型推理框架里vLLM是绕不开的名字，PagedAttention解决KV Cache碎片化问题的思路确实漂亮。但实际部署国产芯片时，我建议别把vLLM当作默认选项直接上。因为vLLM是为CUDA深度优化过的，在国产芯片上跑要么性能不好，要么需要大量适配工作。

推理框架选型的几个替代方案：

• 芯片厂商自家的推理引擎，比如部分国产厂商提供深度定制的推理栈，性能通常最稳
• Text Generation Inference（TGI），在某些硬件上的适配成熟度也不错
• TensorRT-LLM的国产芯片适配版本，但复杂度偏高
• 自己基于主流推理框架二次开发，成本高但可控性强

无论如何，跑推理服务前一定要做压测：不同并发数下的吞吐与延迟曲线，long prompt和short prompt混合场景的表现，连续多次调用是否会触发显存泄漏。我有一个习惯，压测时专门用超长上下文的prompt去测，因为KV Cache的峰值占用往往在这种场景下才暴露出来。很多芯片标称的并发能力都是基于短上下文的benchmark，拿长上下文一压就现原形。

注意：推理服务的性能指标不要只看“吞吐量”，还要看TTFT（首token延迟）和TPOT（逐token输出延迟）。这两个指标对用户体感影响极大。有些芯片在offline benchmark里吞吐数据不错，但online模式下首token延迟高得离谱，就是因为prefill阶段的算力调度和显存带宽没优化好。

5. 从“可用”到“好用”：国产AI芯片的路还差在哪

5.1 从兼容到深入：重心要前移到“性能兑现”

国产AI芯片的第一阶段目标是“兼容”，让现有大模型代码能跑通。第二阶段才是真正的考验——“性能兑现”，也就是在国产芯片上把模型的性能发挥到接近硬件极限。现在很多国产芯片处在第一阶段到第二阶段的过渡期。

“性能兑现”这个词是我做实测后总结的。意思很简单：厂商PPT里那颗芯片的算力、带宽、互联数字，最终用户能在自己的模型和场景里用出百分之多少。兑现率越高，芯片的真实竞争力就越强。我测过一款标称算力不错的国产芯片，跑超大规模卷积网络（CNN类模型）时性能兑现率只有40%左右，主要原因是卷积算子的kernel质量不佳，跑transformer反而好一点。这提醒我们，不同芯片的优势场景差异很大，选型时要用自己的真实负载去验证。

国产芯片要提升性能兑现率，一方面要继续补算子库、融合算子、通信库等基础软件能力；另一方面要深入到模型结构层面做联合设计。大模型结构还在快速演进，MoE、长上下文、多模态、推理时计算这些新方向都对芯片设计和软件栈提出新的要求。芯片厂商如果只守着一个“通用矩阵乘引擎”打天下，在新模型结构面前很快就会落后。

5.2 模型结构演进对芯片设计的反馈

大模型结构不是静止的。2023年是稠密transformer的天下，2024年MoE模型大量出现，2025年长上下文和多模态更普及。每一轮模型结构的变化，都会反馈到芯片设计的需求上。

举几个具体例子：

• MoE模型：稀疏激活降低了单卡的算力需求，但All-to-All通信、专家负载均衡、显存管理更加复杂，芯片需要更强大的互联能力和更灵活的调度能力
• 长上下文模型：attention的访存模式从“计算密集”转向“访存密集”，芯片需要更大的片上缓存和更高效的KV Cache压缩
• 多模态模型：卷积、attention、对比学习多种计算模式混合，芯片的架构需要兼顾矩阵运算的通用性和多样性
• 推理时计算（类似o1）：大量串行推理步骤，对单step延迟和中间状态管理的效率要求极高
• AGNes这类新形态：自主智能体的推理模式不再是简单的prompt-response，而是多次工具调用和规划，这对芯片的调度灵活性提出更高要求

芯片厂商如果和模型团队保持深度协同，可以更早地感知到这些趋势，在芯片设计阶段就为这些负载预埋优化。这属于“架构层面的全栈协同”，是真正的长期竞争力。

5.3 开源生态与开发者社区：全栈协同的长期燃料

全栈协同不能只靠芯片厂商内部的人，还需要外部的开发者生态贡献。英伟达生态的强大之处在于，全球有几十万开发者在使用CUDA、写custom kernel、分享优化经验，这些反馈进一步反哺了软硬件设计。国产芯片要建立这种生态，还有很长的路要走。

包容性生态的典型问题：国产芯片的自定义kernel编程体验。很多国产芯片的编程模型对标CUDA，但开发工具链的完善程度差得远。调试器、profiler、性能分析工具的易用性不足，会让开发者的适配成本显著上升。另外，国内高校和研究机构里，使用国产芯片做研究和教学的比例仍然很低，这意味着新一代工程师对国产芯片的熟悉度不够。

现在一些国产芯片厂商开始支持Triton方言和类Triton的编程语言，这是一个好方向。Triton的核心思路是让开发者用Python-like DSL写高性能kernel，屏蔽底层硬件细节。如果国产芯片能在这条路上做好，就能借助开源生态的力量，让更多开发者参与到算子开发和优化中来。这种“借力开源生态”的做法，我觉得比闭门造车地堆算子库更可持续。

6. 写在最后的实操建议

大模型规模膨胀时代，AI芯片的竞争已经从“单卡性能”全面转向“全栈协同”。对芯片厂商来说，比堆算力更重要的是把软件栈做厚、做透。对用芯片的人来说，比看参数更重要的是用真实负载去验证性能兑现率。

如果让我给正在做国产芯片选型或适配的团队三条最实用的建议：

第一，建立自己的“性能基准测试套件”。不要轻信厂商的benchmark，用你自己要跑的模型结构、并发模式、上下文长度去压测。至少包含大模型训练（稠密+MoE）和在线推理（短长混合上下文）两类场景。

第二，并行策略和集群配置一定要做一轮网格搜索。不同芯片互联特性差异很大，默认配置往往不是最优配置。花两三天把这轮实验做了，回收的算力利用率提升相当可观。

第三，做好kernel级性能剖析。跑模型时不要只看整体吞吐，要深入到算子级别看热点、看fallback、看显存访问模式。性能问题的答案基本都藏在这些细节里。

芯片的竞争是一场长跑。谁能把“从芯片到应用”的全链路协同做到极致，谁就能在大模型规模膨胀时代真正掌握胜负手。