企业官网建设流程全解析

1. 大模型规模膨胀，AI芯片的账本正在被改写

1.1 算力需求的复利曲线，早就超过摩尔定律

大模型的参数规模还在疯涨，AI芯片的算力账单越拉越长，但真正决定胜负的，已经不再是单颗芯片的峰值算力，而是从硬件到软件栈再到应用场景的全栈协同。这个判断不是概念包装，是我这两年在模型微调、分布式训练和推理部署里反复被现实教育出来的结论。如果你也在帮客户部署大模型，或者正在评估国产AI芯片，应该能明显感受到：纸面参数越来越像安慰剂，真正让人头疼的是模型跑起来之后那一堆软硬件摩擦。

先算一笔简单的账。训练一个Dense Transformer模型，总计算量大致可以用 6ND 来估算，N是模型参数量，D是训练数据量。也就是说，模型参数从7B涨到70B，训练数据通常也会跟着涨，总计算量不是线性翻10倍，而是两个维度同时放大。大模型规模膨胀这件事，对GPU、AI芯片、网络和软件栈的冲击是按复利算的，不是按加法算的。

问题是，单颗AI芯片的算力增长并没有跟上这个复利曲线。工艺逼近物理极限，功耗墙越来越严重，HBM带宽的增长速度更是远低于算力增长速度。以前还能靠单卡能力提升硬扛，现在行业默认答案已经变成“多卡并联、多节点扩展”。但多卡并联从来不是免费的：张量并行要频繁通信，数据并行要同步梯度，流水并行要处理气泡，显存和互联带宽一旦跟不上，扩展效率会断崖式下跌。这也是为什么“AI芯片”这个词在这个时代看起来热闹，真正要解决的问题却已经悄悄从“芯片本身”变成了“包括芯片在内的整套系统”。

1.2 显存、带宽和互联，三个瓶颈一起卡脖子

模型规模膨胀最直接的压力，首先落在显存上。一个700亿参数的模型，光权重用BF16存就要接近140GB，主流单卡如果只有80GB显存，根本放不下。哪怕用8卡把权重切开，每次前向传播都涉及跨卡通信；再算上梯度、优化器状态、中间激活，训练时的显存压力比很多人想象中更大。

推理场景同样不轻松。模型可以量化到4bit，70B模型权重能压到35GB左右，似乎勉强单卡能放，但真正跑起来还有KV Cache。长上下文、多并发请求下，KV Cache会以非常快的速度吃显存。你试过就会发现，模型权重反而只是清单的一部分，真正决定能塞多少个并发请求的，往往是KV Cache和显存管理策略。

更隐蔽的是带宽。大模型计算里很多操作是访存密集型的，比如归一化、残差连接、激活函数、注意力里的Softmax。算力可以靠堆核心解决，但显存带宽一旦不够，数据搬来搬去的时间早就超过计算时间。单卡内部是这样，多卡之间更是这样。集群规模越大，通信开销越容易被放大：卡间互联带宽、网卡绑定、拓扑结构、集合通信算法的实现质量，任何一个环节掉链子，都会让整批卡的实际利用率变得很难看。

所以在这个阶段再谈AI芯片，不能只谈单颗芯片的TFLOPS，而是要谈端到端的有效算力。有效算力是什么？不是厂商PPT上的峰值，而是你训练一个模型实际每秒能跑多少step，是推理服务每秒能吐多少个token，是集群在忙时能维持多少MFU。这些东西，单看芯片设计图看不出来，必须把硬件、系统软件、框架和应用串起来一起看。这就是全栈协同存在的意义。

2. 为什么国产AI芯片的胜负手不是单点性能

2.1 峰值算力只是纸面参数，端到端效果才是真成绩

我一直觉得，用跑车和皮卡来做类比最直观。跑车在封闭赛道上的极速肯定吓人，但你要拉一车货走泥泞山路，跑车反而跑不过皮卡。大模型训练和推理就是这样一条泥泞山路：前向计算、反向传播、归一化、残差、注意力、量化、通信、显存搬运，每一个环节都在消耗时间和带宽。峰值算力只是封闭赛道上的极速，端到端效果才是真实环境里的平均速度。

国产AI芯片最容易被质疑的，恰恰就是“单卡算力”。我见过不少参数看起来很漂亮的加速卡，跑标准benchmark时数据不错，但一上真实模型就露馅：某个算子没实现，回退到CPU；某个融合规则不成熟，激活值频繁落回显存；某个通信算法和网络拓扑不匹配，多卡效率直线下降。最后算下来，纸面算力很高，真正跑模型时的有效利用率可能连一半都不到。

用户不是买参数，用户是要结果的。客户问的问题永远是：这个模型训练一轮要多久？推理并发能到多少？P95时延能不能压得住？显存能不能多塞几个用户？这些问题没有一个能用“峰值算力”回答。所以国产AI芯片要证明实力，不能只靠benchmark，得拿真实模型、真实负载、真实部署场景来说话。而真实场景里，软件栈的表现往往比硬件峰值更能决定用户体感。

2.2 全栈协同：硬件、系统软件、框架和应用的四层联动

全栈协同听起来像口号，拆开看其实很实在。我从下往上分成四层：

• 硬件层：计算单元、显存、缓存、卡间互联、网络接口。这一层决定了算力和带宽的上限。
• 系统软件层：驱动、运行时、算子库、图编译器、集合通信库。这一层决定了硬件能力能被释放多少。
• 框架层：PyTorch适配、分布式并行策略、混合精度支持、内存管理。这一层决定了开发者能不能用熟悉的方式写代码。
• 应用层：微调脚本、推理引擎、部署工具、监控调优手段。这一层决定了最终交付是否可用。

全栈协同的意思，就是这四层不能各干各的。芯片在预研阶段就要想清楚：模型里的FlashAttention用什么样的数据流实现？KV Cache用页式管理还是连续分配？MoE模型的路由权重放哪里？如果等到流片之后再让软件团队去“补齐”，很多结构性问题根本补不了，只能靠上层绕过，性能和可维护性都会很差。

反过来说，全栈协同也不等于所有事情都自己做。正确的姿势是“内核自主、接口开放”：关键路径上的算子和通信要有自己的实现，但对外要尽量兼容开发者熟悉的接口和生态。用户用PyTorch写好的代码，不应该为了换一块卡就重写一遍。真正好用的国产AI芯片，应该让用户感觉到“我熟悉的框架还能用，模型还能跑，而且速度不差”。能做到这一点的前提，就是软硬件从一开始就绑在一起设计。

3. 全栈协同的五个关键战场

3.1 算子库与编译器：决定芯片能不能“被用得起来”

第一个直接决定生死的是算子库。一个Transformer模型跑起来，日常要碰到的算子里除了GEMM，还有RMSNorm、Softmax、RoPE、GELU、注意力、拼接、切片、逐点乘加。这些算子看起来不起眼，但它们决定了访存开销和kernel launch开销。同一个操作，手写kernel和naive实现的性能可以差出几倍甚至一个数量级。

我见过最典型的情况：模型在某个算子上没有高性能实现，框架层回退到一个很原始的版本，于是单卡算力明明够，step time却怎么都压不下去。解决方式只有一个：把算子补齐。但“补齐”不是把PyTorch里的操作一个个翻译成硬件指令，而是要针对实际模型做算子融合，比如把residual加法和GELU融合进同一个kernel，让中间结果不落回全局显存；又比如FlashAttention这种把分块计算和Online Softmax放在一起的融合实现，避免反复读写Q、K、V矩阵。

编译器在这个阶段同样重要。图编译器做的事情是把用户Python层计算图优化成高效的底层执行序列，包括算子融合、内存复用、布局转换、并行切分。国产AI芯片如果走“通用指令+通用编译器”的路线，编译器不成熟，直接影响就是用户直接写一套PyTorch代码跑得很慢，必须让原厂工程师反复手工调kernel。反过来，如果编译器成熟度高，很多常规优化能自动完成，客户上手成本会低很多。我自己评估一块AI芯片好不好用，会先拿目标模型跑一遍，再用profiler把kernel占比拉出来，看是不是热点都能被软件栈覆盖到。这一步比看任何参数表都准。

3.2 通信库与集合通信：集群越大，这张网越关键

大模型训练本质上是一场频繁的“集体开会”。数据并行每几步就要同步一次梯度，张量并行每层都要做AllReduce或AllGather，流水并行要在设备之间不停传中间激活。单机8卡还能靠卡间高速互联硬扛，一旦跨节点，网络交换、拥塞控制、拓扑结构都会成为新瓶颈。

集合通信这件事，很多做单卡优化的人容易低估。以张量并行为例，每一层前后都要通信，通信频率极高。哪怕是理论上最高效的Ring AllReduce，也需要每个rank做多次收发。如果通信库没有针对硬件拓扑做路由优化，或者计算和通信没有重叠，训练效率会一塌糊涂。多节点场景更敏感：节点间网络延迟比卡间互联高一个量级，通信库如果只按默认顺序发消息，很容易让某条链路成为瓶颈。

实际调优时，我一般会先看三件事：第一，rank分配是否和网络拓扑对齐，尽量让通信量大的rank落在同一个交换机下；第二，集合通信的融合粒度，小梯度消息太多会放大启动开销，需要把小块梯度合并成大块；第三，计算通信重叠，让反向传播早算出来的梯度先开始AllReduce，而不是等所有梯度都算完再统一通信。很多国产AI芯片的软件栈里，这些能力都有，但默认参数不一定适合你的模型，需要手动去配。这也是为什么“能跑通”和“跑得快”之间经常隔着大量调试工作。

3.3 框架适配与分布式并行：大部分坑都埋在这里

现在大模型生态几乎是以PyTorch为事实标准的，国产AI芯片要融入生态，就必须做好PyTorch适配。常见的做法有三类：一是做后端插件，让PyTorch的算子调度落到自家算子库；二是维护一个内部patch版本，把分布式并行、混合精度、内存管理等能力深度集成；三是做自己的高层框架，兼容PyTorch API。无论哪种方式，目标都只有一个：让用户用习惯的代码，能跑起来，然后跑得快。

框架层真正复杂的不是单个算子，而是分布式并行策略。大模型训练一般会在不同维度混合使用数据并行、张量并行、流水并行和FSDP这类参数分片策略。每种策略各有取舍：张量并行通信最频繁，适合卡间互联带宽高的场景；流水并行减少通信量，但会引入气泡和调度复杂度；FSDP把参数分片到所有设备，按需通信，工程实现难度不小。选错策略，或者策略之间的通信组规划不对，性能会断崖式下降。

我自己踩过最典型的坑是：模型切分方式和实际卡拓扑没对齐。比如8卡里，rank 0到3和4到7物理上分属不同交换域，但默认把张量并行组设置成0,1,2,3,4,5,6,7，结果每次AllReduce都要跨交换域跑一遍，慢得离谱。改成按拓扑分组之后，通信量不变，性能却好了不少。框架层看起来只是“适配”，实际上分布式并行、内存池、梯度累加、混合精度，每一样都需要和底层系统软件深度配合。这也是全栈协同最吃功夫的环节。

3.4 推理引擎与KV Cache优化：上线之前过最后一关

训练是马拉松，推理是日常运营。训练慢一点客户能忍，线上推理时延高、并发上不去，用户立刻就会流失。大模型推理的瓶颈其实不在单纯算力，而在显存带宽、KV Cache管理和batch策略这三件事上。

现在主流推理引擎都引入了Continuous Batching和Paged KV Cache。Continuous Batching的思路是不再等一个batch全部生成完才接收新请求，而是每个step动态插入请求，让GPU算力尽量饱满；Paged KV Cache则把KV Cache按页分配，避免显存碎片，提高显存利用率。这两个优化合起来，可以让推理吞吐提升非常明显，尤其在长上下文场景。

举个例子，用vLLM这类引擎启动一个Qwen2.5-7B服务，代码层面其实很简单：

from vllm import LLM, SamplingParams llm = LLM( model="Qwen2.5-7B", tensor_parallel_size=2, gpu_memory_utilization=0.92, max_model_len=8192, ) params = SamplingParams(temperature=0.7, max_tokens=256) outs = llm.generate(["全栈协同为什么重要？"], params)

但代码简单，不代表底层的适配简单。推理引擎里的Attention kernel、量化kernel、采样kernel、显存管理器，都必须和具体芯片深度对齐。如果芯片的软件栈只把训练优化做好，推理引擎一上就回退到朴素实现，那线上服务的吞吐和时延都会很难看。推理引擎是模型上线的“最后一公里”，这公里只要没铺好，前面所有训练优化都白费。

3.5 模型压缩与MoE路由：让算力花在刀刃上

大模型规模膨胀不意味着所有算力都要“硬扛”。MoE（混合专家）模型就是个典型例子：虽然总参数量巨大，但每次推理只激活一小部分专家，理论计算量远低于同等参数量的Dense模型。问题在于，MoE的“稀疏计算”在硬件层面并不天然友好：即使只激活两个专家，显存里往往还是要驻留所有专家权重；路由决策和专家权重的动态加载，会引入大量访存和通信。

这恰恰是全栈协同能大展身手的地方。如果硬件层为MoE设计了高效率的权重分片和访存模式，系统软件层能感知路由并预取专家权重，框架层能灵活调度专家放哪个设备，那么MoE模型的“理论省算力”才能变成“实际省算力”。否则就会遇到最尴尬的局面：模型稀疏了，但GPU并没有闲下来，因为时间都花在搬数据上了。

除了MoE，常见的省算力手段还有蒸馏、量化和投机解码。蒸馏是把大模型知识压缩进小模型，降低日常服务成本；量化把权重从FP16压到INT8甚至INT4，减少显存和带宽压力；投机解码用小模型先生成草稿，再由大模型验证，一次能多生成几个token。这些手段看着是“模型层”的技术，实际执行时样样依赖芯片的算子库和推理引擎是否支持到位。模型压缩和路由优化，本质上也是全栈协同的一部分。

4. 一次真实训练调优复盘：怎么把“能跑”变成“跑得快”

4.1 复盘背景与优化目标

这里分享一次我实际做过的调优复盘。当时团队要在一台国产AI芯片服务器上做Qwen2.5-7B的LoRA微调，单机8卡。刚拿到手的时候，代码确实能跑通，但速度完全没法看。刚开始的基线数据大概是：step time约2.55秒，通信占比接近28%，显存峰值39GB。对于7B模型LoRA微调来说，这个速度显然不合格，目标是把step time压到1.5秒以内。

先说清楚，这个数字只是当时的实测记录，不同框架版本、不同驱动版本、不同数据长度都会影响结果。我拿出来复盘，主要是想说优化思路比绝对数字更有参考价值。

4.2 第一板斧：先把热点定位出来

拿到一个“能跑但慢”的任务，我第一件事从来不是调超参，而是开profiler。用PyTorch的profiler或者厂商自带的性能分析工具跑一两个step，把每个kernel的耗时占比拉出来排序。看起来是个简单的动作，但绝大多数性能问题都能在这一步暴露出来。

当时的结果很清楚：原生Attention实现占了接近23%的时间，因为模型没有走到融合kernel，而是用了naive实现，反复读写Q、K、V和中间Softmax结果；RMSNorm、残差、激活这些零碎算子加起来也有12%左右。这些操作单看都不大，但架不住每个Transformer层都有，层数一多，访存开销被放大得很厉害。

我做的第一件事是把Attention替换成融合实现，同时确保RMSNorm和激活函数走到算子库里对应的高性能版本。这一步做完，step time从2.55秒降到1.95秒左右，通信占比也降到21%，显存峰值降到36GB。单算子优化往往就是这种立竿见影，痛点清晰，效果也清晰。

4.3 第二板斧：通信重叠和显存换性能

热点算子处理完之后，下一个大头就是通信。28%的通信占比意味着每跑一步，接近三分之一的时间在等数据同步。我当时做了两件事：一是打开梯度AllReduce的融合开关，让小梯度消息先合并再传输；二是把通信和反向传播的重叠打开，让先算出来的梯度不用等所有梯度都算完，而是立刻开始归约。

这两件事做完，通信占比明显降到了9%左右。与此同时，我还把batch size从1调到2，用更多显存换更高算力利用率。显存峰值虽然涨到38GB，但step time进一步降到1.42秒。整体对比大致是这样：

从2.55到1.42秒，没有换卡，没有改模型结构，只靠软件栈和部署参数优化就完成了。这个案例给我最大的启发是：国产AI芯片很多时候不是性能不行，而是软件栈的默认状态太“素”了，需要一层层把该有的优化打开。

4.4 踩坑速查表

调优过程中踩过的坑，我也整理了一份速查表，给后来人省点时间：

这些坑看起来零碎，但每一条都卡过真实项目。全栈协同的价值就在这里：厂商的软件栈如果能把这些问题提前吸掉，客户就不会在集成阶段反复撞墙。

5. 全栈协同背后，真正难的是组织和生态

5.1 客户要的不是芯片，是能交活的方案

芯片是工具，不是目的。客户买AI芯片，是想把大模型跑起来、把服务上线。所以真正有说服力的交付，不只是一块卡和一个驱动，而是“你用这块卡跑7B模型能达到什么性能”的参考实现，是“遇到通信瓶颈该怎么调”的调优报告，是“这个模型跑推理用什么量化方案最划算”的推荐配置。

我有一次和客户聊到很晚，对方从头到尾没有问峰值算力，只问了三件事：70B模型训练一轮多久，7B模型线上推理能扛多少并发，出了性能问题谁能第一时间定位。这三个问题，背后全是软件栈和工程能力。国产AI芯片如果在交付时只给硬件，不给方案，客户落地周期会非常长，口碑也很难建立。

5.2 开放标准和工具链，比封闭优化更持久

全栈协同容易走偏成“封闭铁桶”，什么都自己造，最后生态越来越窄。我的看法是，国产AI芯片要在关键路径上有自己的核心实现，但在接口层面必须开放：支持主流的模型格式、兼容常见的分布式并行API、提供可以对接PyTorch和推理引擎的插件机制。

开放的好处不只是方便客户，更重要的是能让整个社区帮厂商补短板。模型迭代极快，今天流行MLA，明天可能又冒出新的注意力变体。如果每个新结构都只能靠原厂团队去适配，速度一定跟不上。反过来，如果工具链开放，社区贡献者可以直接写kernel、提PR，芯片的适配速度和覆盖面会宽很多。

5.3 我对国产AI芯片全栈协同的真实感受

说了这么多，我最真实的体会是：全栈协同不是一次技术升级，而是一条需要长期投入的路。芯片设计要等软件栈成熟，软件栈又要跟着模型演进而不断重构；算子库要补，编译器要调，通信库要优化，推理引擎要适配。每一层都是脏活累活，短期看不到爆发式回报，但恰恰是这些脏活，决定了用户拿到卡之后是先骂一句还是先夸一句。

我自己评估一块国产AI芯片，第一件事从来不是看它的峰值算力，而是拿目标模型跑一遍端到端，再打开profiler看有效计算占比。如果软件栈能让我把热点一个个抠掉，这块卡大概率是好卡；如果只能靠原厂远程改代码救火，那就还得等。大模型规模还在膨胀，AI芯片的比拼也远没到终局，但方向已经很清楚了：谁能把全栈协同做到位，谁就能在大模型时代的应用里真正站稳。