企业官网建设流程全解析

1. 大模型规模膨胀背后的真实困境

过去两年，我一直在做AI推理侧的系统优化和部署工作，从最早在单卡上跑7B模型，到后来折腾多卡推理、显存优化、算子融合，再到最近帮几个团队做国产芯片的适配评估。说实话，大模型参数量的增长速度远超大多数人的预期。2023年初大家还在讨论13B能不能跑在消费级显卡上，到了2024年，70B已经成了很多场景的起步门槛，MoE架构的模型更是把总参数量推到了千亿甚至万亿级别。

这个趋势带来的直接后果就是：算力需求不再是线性增长，而是指数级膨胀。训练侧还好说，毕竟训练任务可以排队、可以切分、可以用时间换空间。但推理侧不一样，推理是要面向真实用户的，延迟、吞吐、并发，每一个指标都卡得很死。你不可能让用户等三十秒才看到一个回答，也不可能为了省算力就把模型量化到效果崩掉。

这就引出了一个很现实的问题：国内AI芯片到底能不能扛住这波大模型的压力？

我见过太多团队在选型时踩坑。有人只看纸面算力，觉得某款芯片的TOPS数字很漂亮就下单了，结果模型一部署，发现算子不支持、显存带宽跟不上、多卡通信效率低得离谱。也有人迷信生态，觉得只要兼容CUDA就万事大吉，结果发现兼容层带来的性能损耗高达百分之三四十，根本达不到业务要求。

这些问题的根源，其实不在于某一颗芯片本身不够强，而在于整个技术栈没有形成协同。芯片、编译器、框架、算子库、模型结构、部署工具，这六个环节但凡有一个掉链子，整体性能就会大打折扣。我经常跟团队里的人说，做AI芯片适配就像组一支篮球队，不是把五个最强的球员堆在一起就能赢球，关键是配合。

所以当我看到“大模型规模膨胀时代，国内AI芯片的胜负手在全栈协同”这个判断时，我是深有同感的。这篇文章，我想从一线实操的角度，把全栈协同这件事拆开来讲清楚：为什么它重要、难在哪里、怎么落地、有哪些坑可以提前避开。无论你是做芯片选型的架构师，还是做模型部署的工程师，或者只是对国产AI芯片生态感兴趣的技术人，希望这些经验能帮你少走一些弯路。

2. 全栈协同到底在协同什么

2.1 从一颗芯片到一次推理请求的完整链路

很多人理解AI芯片，就是看它的算力峰值。但在实际部署中，一颗芯片从接收到推理请求到返回结果，中间要经过一条很长的链路。我把它拆成六个环节：

• 芯片硬件层：包括计算单元、显存、片间互联、PCIe带宽等物理资源。
• 驱动与运行时层：负责资源调度、内存管理、任务分发。
• 编译器与算子库层：把高层算子映射到硬件指令，决定实际执行效率。
• 深度学习框架层：PyTorch、TensorFlow等，提供模型表达和自动微分能力。
• 模型结构与算法层：Transformer、MoE、注意力机制的具体实现。
• 部署与服务层：推理引擎、批处理策略、KV Cache管理、流式输出。

这六层每一层都有自己的优化空间，但真正的挑战在于层与层之间的接口。比如编译器生成的指令能不能充分利用硬件的矩阵计算单元？框架的算子实现能不能匹配编译器的优化模式？部署引擎的批处理策略能不能和芯片的显存带宽相匹配？

我举个具体的例子。某国产芯片的矩阵计算单元理论峰值是256 TFLOPS，但在跑一个70B模型时，实测只跑出了不到60 TFLOPS。排查下来发现，问题出在算子库的注意力实现上：它没有针对该芯片的显存层次结构做分块优化，导致大量时间花在数据搬运上，计算单元经常处于空闲状态。这就是典型的“硬件很强，但软件没跟上”。

2.2 为什么单点突破解决不了问题

过去几年，国内AI芯片的新闻很多，今天这家发布新品，明天那家宣布融资。但如果你真正做过部署，就会发现一个残酷的现实：纸面参数和实际性能之间的差距，往往比想象中大得多。

我整理过一个对比表，是我们在实际项目中测试过的几款国产芯片在跑同一个70B模型时的表现：

注意看最后一列，没有一款芯片的算力利用率超过25%。这意味着超过四分之三的算力被浪费掉了。浪费在哪里？不是硬件不行，而是软件栈没有把硬件的潜力释放出来。

这就是为什么我说单点突破解决不了问题。你把芯片的算力再翻一倍，如果软件栈还是这个水平，利用率可能反而更低。真正需要的是全栈协同优化：芯片设计时就要考虑编译器的需求，编译器要理解框架的算子模式，框架要适配部署引擎的调度策略，部署引擎要针对模型结构做专门优化。

2.3 全栈协同的三个核心维度

根据我的实操经验，全栈协同可以归纳为三个核心维度：

第一个维度是纵向协同，也就是从芯片到应用的自上而下打通。这要求芯片厂商不能只卖硬件，还要提供完整的软件栈支持。我见过一些团队，买了芯片之后发现连基本的PyTorch适配都没有，要自己写算子、自己调驱动，这个成本高得离谱。

第二个维度是横向协同，也就是不同组件之间的接口标准化。比如编译器的中间表示（IR）要能同时对接多种框架，算子库要能同时支持多种芯片架构。这需要行业层面的标准推动，但短期内更现实的做法是选择生态相对成熟的方案。

第三个维度是动态协同，也就是在运行时根据实际负载动态调整策略。比如根据请求的batch size动态选择最优的算子实现，根据显存压力动态调整KV Cache的存储策略。这需要部署引擎和底层运行时之间有良好的反馈机制。

实操心得：在做芯片选型时，不要只看芯片厂商提供的benchmark数据。一定要拿你自己的模型、你自己的数据、你自己的业务场景去实测。我见过太多“实验室性能”和“生产性能”差距巨大的案例。

3. 芯片、编译器、框架的三角关系怎么理顺

3.1 编译器：被低估的关键环节

在大模型部署的讨论中，编译器往往是被忽视的一环。大家更关注芯片的算力、框架的功能、模型的效果，但编译器才是把这三者连接起来的桥梁。

我打个比方：芯片是发动机，框架是方向盘，模型是目的地，编译器就是变速箱。发动机再强，如果变速箱匹配不好，车也跑不快。

国内AI芯片的编译器生态，目前主要有三种模式：

• 自研编译器：芯片厂商自己开发一套编译器，针对自家硬件做深度优化。优点是优化程度高，缺点是生态封闭，迁移成本大。
• 基于开源编译器二次开发：比如基于TVM、MLIR等开源项目做定制。优点是生态相对开放，缺点是优化深度可能不够。
• 兼容主流编译器：通过兼容CUDA或其他主流生态来降低迁移成本。优点是上手快，缺点是性能损耗大。

我们团队在多个项目中对比过这三种模式，结论是：短期看兼容模式最省事，长期看自研模式最有潜力，但中期最现实的是基于开源做深度定制。

为什么这么说？兼容模式的性能损耗通常在20%到40%之间，对于延迟敏感的业务来说是不可接受的。自研模式虽然优化好，但生态建设需要时间，而且容易形成技术锁定。基于开源做定制，既能利用社区的力量，又能针对特定硬件做优化，是目前比较平衡的选择。

3.2 算子库：决定实际性能的胜负手

如果说编译器是变速箱，那算子库就是发动机的燃油喷射系统。它决定了每一滴“算力燃油”能不能被充分燃烧。

大模型的核心算子其实不多：矩阵乘法、注意力、层归一化、激活函数、Softmax等。但就是这几个算子，在不同芯片上的实现差异巨大。

我以注意力算子为例。标准的注意力计算包括QK^T、Softmax、与V的乘法三个步骤。在GPU上，通常会用FlashAttention这样的融合算子来减少显存访问。但在国产芯片上，FlashAttention的适配往往是个大问题。

我们曾经在一个项目上遇到过这样的情况：某国产芯片的矩阵乘法算子性能很好，但注意力算子没有做融合优化，导致中间结果要反复写入显存再读出来，显存带宽成了瓶颈。后来我们和芯片厂商的工程师一起，针对该芯片的显存层次结构重新设计了分块策略，把注意力算子的性能提升了将近两倍。

这个经历让我深刻体会到：算子库不是写完就完了，而是要针对具体硬件做持续调优。而且这个调优不是一劳永逸的，模型结构一变，最优的算子实现可能就要跟着变。

3.3 框架适配：不只是“能跑就行”

PyTorch目前是国内大模型开发的事实标准。所以芯片厂商能不能提供高质量的PyTorch适配，直接决定了开发者的迁移成本。

但“能跑”和“跑得好”是两回事。我见过一些芯片厂商的PyTorch适配，只是把算子映射过去了，能跑通推理，但性能惨不忍睹。问题出在哪里？主要是三个方面：

第一是算子覆盖不全。大模型用到的算子虽然不多，但有一些是比较新的，比如RoPE位置编码、SwiGLU激活函数、Group Query Attention等。如果这些算子没有原生支持，就要回退到Python实现，性能直接崩掉。

第二是自动微分支持不完整。虽然推理不需要反向传播，但很多团队在部署前会做微调。如果芯片不支持完整的自动微分，微调就得换到别的硬件上做，工作流就断了。

第三是分布式支持薄弱。大模型推理往往需要多卡甚至多机，如果框架层面的分布式支持不好，多卡并行的效率就会很低。

注意事项：在评估芯片的框架适配时，一定要问清楚三个问题：支持哪些算子？支持哪些模型结构？多卡并行的效率如何？不要只看官方文档，要自己写测试用例去验证。

4. 实操：从模型到芯片的适配流程

4.1 环境准备与基础验证

假设你现在拿到了一款新的国产AI芯片，要在一个70B模型上做部署验证。我建议按照以下流程来走，这个流程是我们团队经过多个项目打磨出来的，能帮你快速判断这款芯片到底能不能用。

第一步是环境搭建。不要急着跑模型，先把基础环境搭好。包括驱动安装、运行时配置、框架适配包安装。这一步看起来简单，但坑很多。我遇到过驱动版本和框架版本不匹配导致的各种诡异问题，排查起来非常耗时。

建议的做法是：严格按照芯片厂商提供的版本对应关系来安装，不要自己随意升级或降级。如果厂商提供了Docker镜像，优先用镜像，这样可以避免很多环境问题。

第二步是基础算子验证。写一个简单的测试脚本，逐个验证大模型用到的核心算子。包括矩阵乘法、注意力、层归一化、激活函数等。重点看两个方面：一是功能是否正确，二是性能是否达标。

我通常会用一个对照表来记录测试结果：

如果发现某个算子性能差距太大，就要深入排查原因。是算子实现的问题，还是硬件本身的限制，还是数据布局不匹配。

4.2 模型转换与图优化

基础算子验证通过后，下一步是把完整的模型跑起来。这里的关键是模型转换和图优化。

大模型通常是在GPU上训练的，保存的权重格式和计算图可能和国产芯片的期望格式不一致。所以需要一个转换过程。这个转换不只是格式转换，更重要的是图优化。

图优化包括算子融合、常量折叠、内存复用等。我以算子融合为例：在GPU上，LayerNorm通常会被融合成一个算子，减少显存访问。但在国产芯片上，如果编译器不支持这种融合，就会退化成多个小算子，性能差距可能达到两三倍。

我们在一个项目上做过对比：同一个模型，经过图优化后，端到端推理延迟从120ms降到了75ms，提升了将近40%。这个提升不是来自硬件，而是来自软件栈的优化。

图优化的具体做法，通常是通过芯片厂商提供的转换工具，把PyTorch模型转换成芯片支持的中间表示，然后在中间表示层面做优化。这个过程需要反复迭代，因为不同的优化策略对不同的模型结构效果不一样。

4.3 多卡并行与通信优化

70B模型单卡放不下，必须做多卡并行。这就涉及到通信优化。

多卡并行的方式主要有两种：张量并行和流水线并行。张量并行是把单个算子切分到多张卡上，流水线并行是把不同的层放到不同的卡上。

在实际部署中，通常是两种方式混合使用。比如8卡部署70B模型，可能会用4路张量并行加2路流水线并行。

通信优化的关键在于减少通信量和重叠通信与计算。我以张量并行为例：在Transformer层中，注意力算子和前馈网络算子都需要做All-Reduce通信。如果通信和计算不能重叠，那么通信时间就会成为瓶颈。

我们实测过，在某个国产芯片平台上，如果不做通信优化，多卡并行的效率只有单卡的60%左右。经过优化后，提升到了85%以上。优化的手段包括：使用更高效的通信原语、调整通信和计算的重叠策略、优化数据布局减少通信量等。

实操心得：多卡并行时，不要盲目追求卡数。有时候4卡的效果比8卡更好，因为通信开销更小。关键是要找到适合你模型和硬件的并行策略。

5. 常见问题与排查技巧实录

5.1 性能不达预期怎么排查

这是最常见的问题。模型跑起来了，但性能远低于预期。我总结了一个排查流程，按照这个流程走，大部分问题都能定位到。

第一步是确认瓶颈在哪里。是计算瓶颈、显存瓶颈还是通信瓶颈？用profiling工具跑一遍，看时间花在哪里。如果计算单元利用率很低，那可能是算子实现的问题。如果显存带宽利用率很高，那可能是数据搬运太多。如果通信时间占比很高，那可能是并行策略的问题。

第二步是逐层排查。把模型拆开，一层一层地测。看是哪一层的性能特别差。通常问题会集中在注意力层和前馈网络层。

第三步是对比排查。同样的模型，在GPU上跑一遍，对比每一层的耗时。差距最大的那一层，就是优化的重点。

我整理了一个常见性能问题的速查表：

5.2 算子不支持怎么办

这是国产芯片适配中最常见的问题之一。大模型用到的算子虽然不多，但总有一些是比较新的或者比较冷门的。

遇到算子不支持，通常有三种解决方案：

第一种是回退到Python实现。这是最简单的方案，但性能最差。只适合验证阶段，不适合生产环境。

第二种是自己写算子。这需要了解芯片的编程模型和指令集，门槛较高。但如果这个算子很关键，自己写是值得的。我们曾经为了一个自定义的注意力变体，自己写了一个算子，性能比回退方案提升了五倍。

第三种是推动芯片厂商支持。这是最理想的方案，但需要时间。如果厂商的响应速度快，通常几周内就能提供支持。

我的建议是：在选型阶段就要确认算子覆盖情况。不要等到部署时才发现关键算子不支持。可以提前把模型用到的算子列一个清单，让芯片厂商确认哪些支持、哪些不支持、不支持的计划是什么。

5.3 精度对齐的坑

国产芯片和GPU在浮点计算上可能存在细微差异。这些差异在单层可能看不出来，但经过几十层累积后，可能会导致输出结果明显不同。

我们遇到过一个案例：同一个模型，在GPU上输出正常，在国产芯片上输出乱码。排查了很久，最后发现是某个激活函数的实现精度不够，导致数值溢出。

解决精度问题的方法包括：使用更高精度的计算、调整数值稳定性的实现、在关键位置插入精度检查点。但最根本的，还是要在芯片和编译器层面保证浮点计算的正确性。

注意事项：精度对齐不是一次性的工作。每次模型更新、每次编译器升级，都要重新验证。建议把精度验证做成自动化流程，每次部署前都跑一遍。

6. 全栈协同的落地建议

6.1 选型阶段的评估框架

基于我们团队的经验，我整理了一个芯片选型的评估框架，包含五个维度：

第一个维度是硬件指标，包括算力、显存容量、显存带宽、互联带宽等。这些是基础，但不是全部。

第二个维度是软件栈成熟度，包括编译器、算子库、框架适配、部署工具等。这个维度往往比硬件指标更重要。

第三个维度是生态兼容性，包括对主流框架的支持、对常用模型的支持、对社区工具的兼容等。

第四个维度是厂商支持能力，包括响应速度、技术支持质量、定制化能力等。

第五个维度是长期演进路线，包括芯片迭代计划、软件栈更新频率、生态建设投入等。

每个维度可以打分，最后加权得到一个综合评分。根据我们的经验，软件栈成熟度的权重应该最高，因为硬件可以迭代，但软件栈的差距很难在短期内追上。

6.2 部署阶段的优化优先级

部署阶段，优化资源总是有限的。我建议按照以下优先级来分配：

第一优先级是算子级别的优化。这是投入产出比最高的。一个关键算子的优化，可能带来整体性能的显著提升。

第二优先级是图级别的优化。包括算子融合、内存复用、计算图重排等。这些优化不需要修改硬件或底层软件，见效快。

第三优先级是并行策略的优化。包括并行度的选择、通信和计算的重叠、负载均衡等。

第四优先级是服务层面的优化。包括批处理策略、KV Cache管理、请求调度等。

这个优先级不是绝对的，要根据具体情况调整。但总体原则是：先做能快速见效的，再做需要深入投入的。

6.3 长期协同的机制建设

全栈协同不是一次性的项目，而是需要长期投入的机制。我建议从三个方面来建设：

第一是建立跨团队的技术对接机制。芯片厂商的工程师、框架开发者、模型开发者、部署工程师，需要有一个常态化的沟通渠道。很多问题不是技术难题，而是信息不对称造成的。

第二是建立标准化的测试和评估流程。包括性能测试、精度测试、稳定性测试等。这些测试要自动化、可重复、可对比。

第三是建立知识沉淀和共享机制。把踩过的坑、优化的经验、最佳实践记录下来，形成团队的知识库。这样新人可以快速上手，老人也可以避免重复踩坑。

我在实际项目中最大的体会是：全栈协同的难点不在技术，而在组织和流程。技术问题总有解决方案，但如果没有一个好的协同机制，再好的技术也发挥不出来。国内AI芯片的胜负手，最终还是要落到能不能把芯片、编译器、框架、模型、部署这五个环节真正打通，形成一个高效运转的整体。这件事没有捷径，只能一步一步地做，一个算子一个算子地优化，一个项目一个项目地积累。但只要我们坚持做下去，国产AI芯片的竞争力一定会越来越强。