1. 从一颗芯片的诞生说起为什么需要一张全栈软件地图一颗 AI 芯片从设计到量产硬件团队交付的是一块硅片但真正让这块硅片跑起来的是背后一整套软件栈。我见过太多团队在流片成功后才发现驱动没写好、编译器没适配、算子库缺了一大半芯片在实验室里跑分漂亮到了客户手里却连一个主流模型都跑不起来。这不是硬件的问题是软件地图没画清楚。所谓“全栈软件地图”指的是从最底层的固件、内核驱动到中间的运行时、编译器、算子库再到上层的框架适配、模型部署工具链这一整条链路上所有需要软件团队覆盖的模块及其依赖关系。它回答的是三个问题芯片上电之后第一行代码在哪里执行一个 PyTorch 模型从导出到在芯片上跑起来中间经过哪些层每一层由谁负责、交付物是什么、验收标准是什么这篇文章适合三类人看一是刚进入 AI 芯片公司的软件工程师需要快速建立全局认知二是硬件背景的架构师想理解软件栈的复杂度到底在哪里三是技术管理者需要一张地图来规划团队编制和里程碑。我会用 Agent 作为辅助工具来拆解这张地图但重点始终是地图本身——Agent 只是帮我们把信息组织得更清楚的手段。先给一个最粗的框架让你有个锚点。AI 芯片的全栈软件大致分四层固件与内核层、运行时与驱动层、编译器与算子层、框架与工具链层。每一层都有明确的输入输出层与层之间的接口就是软件团队最核心的交付物。下面我会逐层拆开讲每一层都会说清楚它解决什么问题、核心模块有哪些、关键交付物是什么、常见的坑在哪里。2. 用 Agent 拆解全栈软件地图的整体思路2.1 为什么选择 Agent 来做这件事你可能会问画一张软件地图为什么不用思维导图工具非要用 Agent原因很直接AI 芯片的软件栈涉及的知识域太宽了从 Linux 内核的 DMA 机制到 TVM 的算子调度策略从 PCIe 驱动到 ONNX 算子映射任何一个工程师都不可能同时精通所有层。传统做法是找各个领域的专家分别写文档然后拼在一起结果是文档之间接口对不上、术语不统一、版本不同步。Agent 的价值在于它可以基于一个统一的“芯片规格描述”作为输入自动推导出每一层需要哪些模块、模块之间的依赖关系是什么、每个模块的验收标准应该怎么定义。我实际用下来最有效的做法是先把芯片的硬件规格计算单元数量、内存带宽、互联方式、指令集架构整理成一份结构化的描述文件然后让 Agent 基于这份描述去生成软件栈的模块清单和依赖图。这样生成的地图层与层之间的接口是一致推导出来的不会出现“驱动团队以为运行时团队会处理某件事运行时团队以为驱动团队会处理”这种经典扯皮。2.2 拆解的核心原则以数据流为主线画软件地图最容易犯的错误是按组织架构来画——驱动组负责这一块、编译器组负责那一块。这样画出来的图看起来清晰实际上没法用因为一个模型跑起来的数据流是跨组的。我建议以数据流为主线来拆解从模型文件开始经过图编译、算子融合、内存分配、指令生成、任务调度、硬件执行最后输出结果。每一个数据流经过的节点就是一个软件模块节点之间的数据格式和接口协议就是需要定义的交付物。用 Agent 来做这件事的好处是你可以把数据流的每一个环节描述给 Agent让它帮你检查这个环节的输入格式和上一个环节的输出格式是否匹配这个环节需要的硬件能力芯片规格里是否提供了如果没提供软件上有没有 fallback 方案这种交叉检查人工做很容易漏Agent 做可以做到系统化。2.3 地图的粒度控制三层展开法一张全栈地图如果画得太细会有几百个模块没人看得过来画得太粗又没法指导实际工作。我的经验是采用三层展开法第一层只画四个大块固件/内核、运行时/驱动、编译器/算子、框架/工具链每个大块用一句话说明职责第二层把每个大块展开到 5 到 8 个核心模块每个模块标注输入输出和关键交付物第三层只对当前里程碑涉及的模块展开到函数级或接口级。这样既保证了全局视野又不会在不需要的地方浪费精力。Agent 在这个过程中的角色是你给它第一层的四个大块它帮你生成第二层的模块清单你选定某个模块它帮你生成第三层的接口定义草案。你始终是决策者Agent 是执行者。这个分工很重要因为芯片软件栈的很多决策依赖硬件细节和商业考量Agent 不可能替你做这些决策但它可以帮你把决策的后果推演清楚。3. 固件与内核层芯片上电后的第一行代码3.1 固件层到底做什么芯片上电之后CPU 核首先执行的是一段固化在 ROM 里的代码这段代码的任务是把芯片带到一个“可被操作系统接管”的状态。具体来说它需要完成时钟初始化、内存控制器初始化、PCIe 链路训练、安全启动校验、以及把主固件从 Flash 加载到内存并跳转执行。对于 AI 芯片来说固件层还有一个特殊任务初始化所有的计算单元和片上内存确保它们在操作系统加载驱动之前处于已知状态。这一层的核心交付物是固件镜像和固件-驱动接口规范。固件镜像通常分两级一级固件Boot ROM 代码在流片时就固化在芯片里不可更改二级固件通常叫 SPL 或 BL2可以从 Flash 加载负责更复杂的初始化。固件-驱动接口规范定义了驱动如何查询固件版本、如何触发固件升级、如何获取硬件状态信息。这个规范如果定义得不好后期驱动和固件联调时会非常痛苦。注意固件层的 bug 往往是最难排查的因为它的执行环境没有操作系统、没有日志系统、没有调试器。我的经验是在流片之前就要把固件的仿真环境搭好用 FPGA 原型验证固件的每一个初始化步骤。流片后再发现固件问题修复成本极高。3.2 内核驱动的核心模块操作系统加载后内核驱动负责把硬件设备暴露给用户态。对于 AI 芯片内核驱动通常包含以下模块PCIe 设备驱动负责枚举设备、映射 BAR 空间、处理中断、字符设备驱动提供用户态打开设备、发送命令、读写数据的接口、DMA 引擎驱动管理数据在主机内存和设备内存之间的搬运、内存管理模块管理设备侧的内存分配和映射。这里重点说 DMA 引擎驱动因为它是 AI 芯片数据通路的核心。一个典型的 AI 芯片会有多个 DMA 通道每个通道可以独立搬运数据。驱动需要实现通道的申请和释放、搬运任务的提交和完成通知、错误处理和超时重试。我见过不少团队在这里踩坑DMA 通道的并发控制没做好多个进程同时提交任务时出现数据错乱或者完成通知的机制设计得太简单高负载下丢中断。内核驱动的另一个关键点是中断处理。AI 芯片的中断源通常很多DMA 完成、计算完成、错误上报、温度告警等。中断处理程序需要快速响应把耗时的处理放到下半部或工作队列中。如果中断处理写得不好高负载下会出现中断风暴CPU 全部时间都在处理中断用户态任务得不到调度。3.3 UMD 与 KMD 的分工与接口UMDUser Mode Driver和 KMDKernel Mode Driver的分工是 AI 芯片软件栈设计中最关键的决策之一。KMD 运行在内核态负责硬件资源的直接管理和安全隔离UMD 运行在用户态负责命令的构建和提交。两者之间的接口通常通过 ioctl 实现。分工的原则是安全相关的、需要特权的操作放在 KMD比如设备初始化、内存映射、中断处理、DMA 通道管理性能相关的、频繁调用的操作放在 UMD比如命令缓冲区的构建、任务提交、同步对象的等待。这样设计的理由是ioctl 的系统调用开销比较大如果每次任务提交都走 ioctl性能会受影响。常见的做法是UMD 和 KMD 共享一块内存区域通过 mmap 映射UMD 在这块内存里构建命令然后通过一次 ioctl 通知 KMD 提交。UMD 和 KMD 的接口定义需要非常小心。我建议在项目早期就把接口用文档固定下来并且写一个 mock 实现让 UMD 和 KMD 可以独立开发和测试。接口变更的成本很高因为两边可能由不同的团队负责变更需要同步。4. 运行时与编译器从模型到指令的翻译过程4.1 运行时系统的核心职责运行时系统是连接上层框架和底层硬件的桥梁。它的核心职责包括内存管理设备内存的分配、释放、复用、流管理任务的顺序执行和并发执行、事件同步不同流之间的依赖关系、内核启动把编译好的内核加载到设备并执行。内存管理是运行时系统中最容易出问题的部分。AI 芯片的设备内存通常比较有限比如 16GB 或 32GB而一个大模型可能需要几十 GB 的内存。运行时需要实现内存池机制把频繁分配释放的小块内存缓存起来减少向 KMD 申请内存的次数。同时运行时还需要支持内存复用当两个张量的生命周期不重叠时可以复用同一块内存。这个分析通常在编译期完成运行时根据编译期生成的分配方案来执行。流管理是另一个关键点。AI 芯片通常支持多个流Stream每个流内的任务顺序执行不同流之间可以并发。运行时需要管理流的创建、销毁、任务提交、流之间的同步。我见过的一个典型问题是多个流同时提交任务时硬件资源比如计算单元的分配出现冲突导致某些任务饿死。解决方法是运行时实现一个资源调度器根据任务的优先级和资源需求来分配硬件资源。4.2 编译器栈的分层设计AI 芯片的编译器栈通常分三层图编译器、算子编译器、指令生成器。图编译器负责把上层框架的模型图比如 ONNX 图转换成芯片的中间表示IR并进行图级别的优化比如算子融合、常量折叠、死代码消除。算子编译器负责把 IR 中的每个算子编译成芯片的指令序列并进行算子级别的优化比如循环展开、向量化、流水线调度。指令生成器负责把优化后的指令序列编码成二进制并处理寄存器分配、指令调度等底层细节。图编译器的核心挑战是算子融合。比如一个 Conv Bias ReLU 的结构如果分别编译成三个算子会有两次额外的内存读写。融合成一个算子后中间结果留在片上内存不需要写回设备内存性能可以提升很多。但融合的决策需要考虑硬件能力片上内存够不够大、计算单元支不支持融合后的算子。这些决策需要编译器和硬件团队紧密合作。算子编译器的核心挑战是调度。同一个算子不同的调度策略性能差异可能达到数倍。比如矩阵乘法是分块大小取 32 还是 64是先把数据搬到片上内存再计算还是边搬边算这些选择需要根据硬件的内存带宽、计算单元数量、片上内存大小来定。我建议在项目早期就建立一个自动调优的框架让编译器可以自动搜索最优的调度参数而不是靠人工试。4.3 算子库的覆盖策略算子库是编译器栈的“最后一公里”。即使编译器再强大如果某个算子在算子库里没有实现模型就跑不起来。算子库的覆盖策略通常分三步第一步覆盖主流框架的核心算子比如 PyTorch 的 ATen 算子中频率最高的 100 个第二步覆盖主流模型中的特殊算子比如 Transformer 中的 Attention、LayerNorm第三步提供自定义算子的开发框架让用户自己实现算子库中没有的算子。这里有一个经验不要试图一开始就覆盖所有算子。我见过团队花大量时间实现了 500 个算子结果发现用户模型里用到的只有 50 个而且这 50 个中有 10 个的实现性能不达标。正确的做法是先和产品团队确认目标模型清单然后按模型来倒推算子需求优先实现高频且性能关键的算子。5. 框架与工具链让用户真正用起来5.1 框架适配的两种模式框架适配有两种模式插件模式和后端模式。插件模式是在框架内部注册一个新的设备类型框架的算子会调用插件提供的实现。这种模式的优点是改动小、上手快缺点是受限于框架的调度机制性能优化空间有限。后端模式是把框架的模型导出成中间表示比如 ONNX然后由芯片自己的编译器栈接管。这种模式的优点是性能优化空间大缺点是需要维护一个完整的编译器栈。我的建议是短期用插件模式快速跑通长期用后端模式追求性能。插件模式可以在几周内让模型跑起来给客户一个可用的版本后端模式需要几个月的开发但最终性能可以提升数倍。两个模式可以并行推进插件模式作为 fallback后端模式作为主路径。5.2 模型部署工具链的关键组件模型部署工具链通常包含模型转换工具把训练框架的模型转成芯片支持的格式、量化工具把 FP32 模型转成 INT8 或 FP16、性能分析工具分析模型在芯片上的性能瓶颈、调试工具定位精度问题或运行时错误。量化工具是其中最有价值也最难做的。INT8 量化可以把模型大小减少 75%推理速度提升 2 到 4 倍但精度损失需要控制在可接受范围内。量化工具需要支持训练后量化PTQ和量化感知训练QAT。PTQ 不需要重新训练但精度损失可能较大QAT 需要重新训练但精度可以接近 FP32。我建议先实现 PTQ覆盖大部分场景对于精度要求高的场景再支持 QAT。性能分析工具是另一个关键组件。用户需要知道模型在芯片上的瓶颈在哪里是计算单元利用率不够、还是内存带宽受限、还是任务调度有问题。性能分析工具需要采集硬件性能计数器比如计算单元活跃周期、内存读写带宽、DMA 传输次数并把这些数据关联到模型的算子上。这样用户才能有针对性地优化模型。5.3 工具链的验收标准工具链的验收标准应该从用户视角定义一个用户拿到芯片和工具链多长时间能把他的模型跑起来跑起来之后性能是多少精度损失是多少我建议设定三个指标首次跑通时间从拿到芯片到模型跑通的时间目标是一周内、性能达标率目标模型清单中性能达到预期值的比例目标是 90% 以上、精度达标率量化后精度损失在可接受范围内的比例目标是 95% 以上。这三个指标需要在项目早期就定义清楚并且定期跟踪。我见过团队在项目后期才发现工具链的易用性很差用户跑通一个模型需要一个月这时候再改已经来不及了。正确的做法是在工具链开发的同时就让内部用户比如算法团队试用收集反馈持续改进。6. 常见问题与排查技巧实录6.1 固件与驱动联调中的典型问题固件和驱动联调是问题最集中的阶段。我整理了一个常见问题速查表问题现象可能原因排查方法设备枚举失败PCIe 链路训练未完成检查固件中 PCIe 初始化代码用示波器看链路状态驱动加载后系统崩溃内存映射地址冲突检查 BAR 空间映射确认没有和系统其他设备冲突DMA 传输数据错乱通道并发控制缺失检查 DMA 通道的锁机制确认同一通道不会并发提交中断丢失中断处理程序执行时间过长检查中断处理程序把耗时操作移到下半部固件升级失败Flash 写入时序不对检查 Flash 时序参数确认写入前已擦除提示固件和驱动联调时建议先用一个简单的测试程序验证基本功能设备枚举、内存映射、DMA 传输再跑复杂的模型。这样可以把问题隔离在最小的范围内。6.2 编译器与算子库的精度问题排查精度问题是编译器栈中最难排查的。一个模型跑出来的结果和预期不符可能的原因有算子实现有 bug、量化参数不对、内存复用导致数据被覆盖、浮点累加顺序不同导致精度差异。排查的思路是先定位到具体的算子再定位到具体的实现。具体做法是用逐层对比的方式把模型的每一层输出和参考实现比如 CPU 上的 PyTorch对比找到第一个出现偏差的层。然后检查这个层的算子实现如果是量化算子检查量化参数scale 和 zero_point是否正确如果是浮点算子检查累加顺序是否和参考实现一致。我见过的一个经典问题是矩阵乘法的累加顺序不同导致 FP16 精度下结果差异较大。解决方法是调整累加顺序或者用 FP32 累加。6.3 性能不达标的排查思路性能不达标通常有三个原因计算单元利用率低、内存带宽受限、任务调度有问题。排查的顺序是先用性能分析工具看计算单元的利用率如果利用率低于 50%说明计算单元在等数据问题可能在内存带宽或任务调度如果利用率高于 80%但性能还是不够说明计算单元本身的能力不够需要优化算子实现或增加计算单元。内存带宽受限的典型表现是计算单元利用率不高但内存读写带宽已经接近峰值。解决方法是优化数据复用把频繁访问的数据放到片上内存减少对设备内存的访问。任务调度问题的典型表现是多个流之间的任务互相等待导致计算单元空闲。解决方法是优化流之间的同步关系减少不必要的依赖。6.4 工具链易用性问题的改进经验工具链易用性问题往往被低估。我见过一个工具链功能很强大但用户跑通一个模型需要手动执行十几个步骤每个步骤都有坑。改进的经验是把用户的操作步骤降到最少把能自动化的都自动化。比如模型转换用户只需要提供模型文件和目标芯片型号工具链自动完成图优化、量化、编译、部署。再比如性能分析用户只需要提供模型和输入数据工具链自动跑一遍并生成性能报告。另一个经验是提供端到端的示例。用户最喜欢的是“抄作业”给一个完整的示例从模型文件到最终部署每一步都有命令和预期输出。这样用户可以快速验证环境是否正确然后再替换成自己的模型。我建议为每个主流模型ResNet、BERT、LLaMA都提供一个端到端示例并且定期更新。7. 用 Agent 辅助软件栈开发的实操心得7.1 Agent 在代码生成中的边界Agent 可以帮我们生成很多代码驱动框架、算子实现、测试用例。但 Agent 生成的代码不能直接用于生产必须经过严格的审查和测试。我的经验是Agent 生成的代码适合作为初稿不适合作为终稿。比如生成一个 DMA 驱动的框架Agent 可以生成设备枚举、内存映射、中断注册的代码但 DMA 传输的具体实现需要人工根据硬件手册来写因为 Agent 不了解硬件的具体寄存器定义。另一个边界是Agent 不擅长处理硬件相关的时序问题。比如固件初始化中某个寄存器的写入需要等待几个时钟周期Agent 生成的代码可能没有加延时导致初始化失败。这类问题需要人工根据硬件手册来补充。7.2 Agent 在文档生成中的价值Agent 在文档生成中的价值比代码生成更大。因为文档的结构化程度高Agent 可以基于代码和注释自动生成 API 文档、架构文档、用户手册。我实际用下来最有效的做法是先把代码的注释写清楚每个函数的输入输出、每个模块的职责然后让 Agent 基于注释生成文档初稿人工再润色。这样可以把文档编写的时间减少一半以上。Agent 还可以帮我们检查文档的一致性比如驱动文档中描述的接口和运行时文档中引用的接口是否一致固件文档中描述的寄存器和驱动代码中使用的寄存器是否一致。这种交叉检查人工做很费时Agent 做可以做到系统化。7.3 Agent 在测试用例生成中的应用测试用例的生成是 Agent 的另一个强项。给定一个函数的接口定义和边界条件Agent 可以生成覆盖各种情况的测试用例正常输入、边界输入、异常输入。我建议把 Agent 生成的测试用例作为补充而不是替代人工编写的测试用例。因为 Agent 不了解硬件的特殊行为比如某些寄存器在特定条件下会返回错误码这类测试用例需要人工根据硬件手册来写。一个实用的技巧是把硬件手册中的寄存器描述整理成结构化的格式比如 JSON然后让 Agent 基于这个格式生成寄存器读写测试用例。这样可以覆盖大部分寄存器的基本功能人工只需要补充特殊场景的测试。8. 地图的维护与演进软件地图不是画一次就完了它需要随着项目进展不断更新。我的做法是每个里程碑结束时回顾地图更新模块的状态未开始、进行中、已完成、已验收并标注新发现的依赖关系。这样地图始终反映项目的真实状态而不是一张过时的图纸。另一个经验是地图要放在所有人都能访问的地方比如内部 Wiki 或代码仓库的 README。我见过团队把地图放在某个人的电脑里结果其他人看不到各自按自己的理解开发最后接口对不上。地图的价值在于共享只有所有人都能看到并参考才能发挥它的作用。最后分享一个我踩过的坑早期画地图时我只画了模块和依赖关系没有标注每个模块的负责人和交付时间。结果地图看起来很完整但没人知道谁该做什么、什么时候做完。后来我在每个模块上加了负责人和里程碑地图才真正变成了可执行的项目计划。这个教训是地图不仅是技术文档也是管理工具必须包含责任人和时间节点。