AI芯片软件栈（二）

新年快乐！这篇算是写跨年了。

最近这几周大家应该都挺难熬的，愿您和家人、同事皆平安熬渡过这一波。

不知道各位当前的状态机处于哪个状态了：等🐑、幻🐑、已🐑、🐑康还是不幸的重🐑。

不管怎样，没🐑的，做好防护，争取成为决赛圈天选打工人。

🐑过的，以个人看到的各种信息来看，友情建议在这一波医疗挤兑结束后，一定去医院做个肺部CT吧。

书归正传。

☢️高能预警☢️：从本篇开始我会尽量写短一些，能不展开的就不展开了，能不解释的就不解释了（看后台数据中途跳出率挺高的，好伤心）。重点就放在我的一些核心理解和观点上了。

这样也可以不浪费大家太多的时间了，所以，欢迎有兴趣的单读讨论吧。

做好软件栈，有一个靠谱的顶层规划和路线图是非常重要的，这个本就无需多言，我确信没有人会不明白。

实践中做不好，问题很少会出现在认知层面，基本都是具体执行过程中受限于各种因素，顶层规划和把控，动作变形，PPT高手太多，执行思路飘忽或者就是单纯的能力受限，导致了理想很丰满，现实很骨感。

纵观整个芯片领域，初创、第一代产品就一炮而红的案例，少之又少。一般而言，产品研发基本需要18个月，芯片回片，还要和客户在一起至少打磨12～18个月才能实现比较好的PMF（Product Market Fit）量产。这里面还忽略了一个很重要的环节：产品定义，在做产品研发前需要花多少时间来思考这个问题？3个月、6个月还是18个月？

打磨一个有一定竞争力产品，三年基本是起步价。

正常情况下，一个产品想要走的远一点，开始的时候就要多想想，慢一点、稳一点。

但是，考虑到大家都是Startup，快就成了最重要的事情，所有影响快的因素，都要为高速前进，快速流片、快速量产让路。

而且，虽然核心团队可能师出同门，组成一个初创公司过程中会必然会引入各路人才，但这个阶段公司没有成熟的管理和技术体系，大家过去工作中积累的技术认知、技术思路和技术习惯不可能全部一致，实践中会形成冲撞。虽然这些方法论的事情本就无对错，但如果没有足够全面和服众的技术一把手掌舵和定调，有可能引发冲突、反复、内耗和动荡。

所以，AI芯片创业公司，在出发的这一刻，就和一些经典的管理理论产生了冲突，并带着管理隐患蒙眼高速狂奔，不能简单的评判这种快速让产品面向客户的逻辑的对与错，事后诸葛亮也没有什么帮助。

只能说，如何在高速前进中抓住主要矛盾，始终保持对最终目标的关注与可达成的思考，并及时对执行方法进行修正，这是非常考验核心团队管理、视野、工程、技术、隐忍的功底与快速学习陌生领域知识的能力。

要求所有人聚焦于公司核心目标，而不是自己那一亩三分地的利益，这个要求放到具体几个天才工程师，不难（哪怕不是天才工程师，团队不大，人少都不太难）。

但是放到一个大几百、过千人的团队，就会非常讲究管理的艺术了。

今天的想说的主题可能依然有点儿出其不意了。👇👇👇

重构是不可避免的

俗话说好汉不提当年勇，但是我估计不是好汉，因为我准备讲个当年的故事。

前司在找我之前，接了一个几千万的纯软件项目，和算法等无关的业务平台交给4个人，每人带3～4个外包开发。

此为背景。

等我入职的时候，这个项目已经遇到了不少困难，上述小组的工作大概已经持续了几个月，但进展不理想，算法等事情亦然。

仔细梳理了一遍项目，看了看代码和文档，该单聊的都聊一遍，对开发的问题基本心里有数了。

到三个月左右的时候，给老板汇报工作，提了一嘴：那十几人的开发进度慢，能力是一方面，关键是规划没做好，基本没做设计，公共组件没做抽象，就蒙着头往前干，重复代码太多了。

到呆了差不多半年，人也盘清楚了，该送走的送走了，该补的也找到自己觉得靠谱可胜任的了。

另外，基本的管理权威和技术威信也建立了，可以做点动作了。

时机成熟了，给老板说明项目真实问题，那十几个人的开发就是图快、没经验的乱来，正常干的话，上4个人干3个月差不多就完事了。老板大惊：“那几百万就打水漂了？”。答曰：是。再问：不推到重来风险有多大？答：难维护，而且是交源码的项目，这种工程交出去给人笑话，丢公司的人。再问：怎么会人月差这么多就能搞定？答：找我来不就是做这事么。

这个故事，想说三件事：

• 急活没好活，尤其是遇到经验、技术视野不够的选手的时候
• 想明白再出手，让合适的人去做，往往事半功倍
• 技术虽然是个非常明确直接的事情，但是实操环节还是要非常讲究艺术性，当然有个能信任，懂授权，敢放权的老板也很重要

训练软件栈

之前有朋友聊天说感觉我是做推理芯片的，主要说的是推理相关的事情。这个事情是这样的，训练、推理两种芯片的软件栈都接触了才更不敢愿多谈训练相关的事情，原因大致如下：

• 各种分布式。从机内互连到机柜内互连到跨机柜互连，各种Ring，2D Torus、3D Torus……，涉及了从同步算法到软件工程到系统集成的拓扑设计，太难了，太难了。

• 算子支持。说起来目前TensorFlow和PyTorch的算子也就两千多个，但是这两千多个大多数都有底层cuDNN和CUDA高性能算子兜住的。两千多个OP数量和质量都能搞定，这个工作量不好说啊。

• 动态图支持。两千多个OP太多了，换条路走XLA，先不讨论XLA有没有坑，看起来至少原子算子数量一下少了一个数量级，但是，PyTorch现在是妥妥的训练框架的老大了，走这条路，Eager的支持怎么办，总不能说2023年了还不支持动态图吧。

• 多框架支持。虽然现在PyTorch是主流，但是很多公司还有很多legacy模型和代码停留在TF1.x上，所以这两个框架没什么好说的，都要支持起来吧（TF2.x反正工业界用的真不算太多，可以先缓缓）。之前讨论过一个问题，那就是to B/G的生意可能是短期营收的主要来源，GPT又带火了生成模型和大模型，那么老师木的OneFlow这个国产的分布式优先的训练框架要不要支持起来？

• 升级代价。假设先聚焦PyTorch进行适配，代码侵入有多大规模，跟着官方版本平滑的做版本升级，有多大工作量，滞后几个月能完成升级？2.0已经发布了，多久能在自己芯片上跑起来，这是个必须考虑的问题。

• CUDA兼容当然是一条shortcut，但是我不太想讨论这个问题。看看AMD的ROCm基本上把CUDA API的风格“平移”到了HIP，并提供了HIPify把CUDA源码翻译成HIP C++代码。思考：为什么不直接兼容，而是要翻译？

• 不敢说懂认知有限的事情，不能乱说，以免贻笑大方。

反正，现阶段AI芯片主要还是聚焦在推理市场（训练市场NV的老大地位真太稳了），所以本系列文章会尽量避开对训练软件栈的讨论，能把推理软件栈说点皮毛就行了。

你以为的产品也许是MVP

MVP（Minimum Viable Product ）最小可行性产品，通过Eric Ries的《精益创业》这本书使这一概念得到推广，抄一段Wikipedia的解释：

A minimum viable product has just enough core features to effectively deploy the product, and no more. Developers typically deploy the product to a subset of possible customers, such as early adopters who are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. This strategy targets avoiding building products that customers do not want and seek to maximize information about the customer with the least money spent. The technique falls under the Lean Startup methodology as MVPs aim to test business hypotheses and validated learning is one of the five principles of the Lean Startup method. It contrasts strongly with the traditional “stealth mode” method of product development where businesses make detailed business plans spanning a considerable time horizon.

关键词：核心功能、有效部署、更宽容、提供反馈、避免开发客户不想要的产品、长周期的商业计划。

凡事都有两面性，凡事都有不同观点和认识，来看看对产品MVP方法的批评声音：

Some research has shown that early release of an MVP may hurt a company more than help when companies risk imitation by a competitor and have not established other barriers to imitation. It has also indicated that negative feedback on an MVP can negatively affect a company’s reputation. …… . Also, products that do not offer the expected minimum standard of quality are inferior to competitors that enter the market with a higher standard.

关键词：护城河、易被模仿、负面反馈、公司声誉、最低质量标准。

看完MVP的定义以及一些关键解释后，大家可以开始琢磨一个问题了：我司在做的软件产品究竟是真产品还是仅仅就是一个满足早期客户送测最低限度要求的MVP？

我想，答案不言自明。

在之前的财报季，AI芯片公司营收数字之多少中，引用了一段Jim Keller的话，大家可以回去在看一眼，核心思路其实就是走MVP路线，快速让程序员用起来，收集反馈，而不是去get some huge contract。

到什么山唱什么歌。

不怕意识到现阶段软件产品只是MVP，仅“可用”，就怕盲目乐观、自信的认为软件已经做好了。

有一个很有趣的事实。

从AI芯片，尤其是推理芯片初创公司的软件岗招聘节奏，其实就能看出来对软件栈理解的深刻程度，以及可能没有意识到在做MVP这件事情。

按一个“标准”的招聘节奏，驱动、固件、编译器、算子、工具做为第一批软开陆续到位，那整个软件做的方式大概率是Down-Top这种自下而上的堆砌实现模式，往上做遇到实现比较别扭、缺底层方法支撑的概率就越高，那就只能一层一层重构了。

大环境就这样，就算“凑”出来上市门槛，能不能上去是第一个问题；会不会破发是第二个问题；能不能持续有拿得出手、收入构成有质量，经得起推敲的营收支撑股价是第三个问题；什么时候能利润回正，满足套现退出条件，这是第四个问题。

越早意识到软件还差得远，能够以Top-Down的视角去从最终目标反推阶段目标、交付侧刚需、研发节奏、必知必会，以便很好的安排招聘节奏，把猎头费用在最关键的岗位，最重要的是：控制不切实际的市场目标与预期，集中精力在有真实交付能力、能落单的客户身上，以免忙了一年梦想志向远大最终颗粒无收。一步一个脚印，稳扎稳打，跑赢友商，大浪淘沙后也许就剩者为王了。

虽然不一定全部想明白了后面怎么做，甚至做的人也没招到，但是起码知道还要做什么，架构师可以去做些基本调研，在架构层面做些基础的解耦、分层工作，争取让个模块职责单一，越能为未来跑不掉的重构降低风险。在当前这个赶工的阶段，就要想清楚：现在做的功能，在未来完备的软件栈中的定位和后产品化开发需要在设计层面充分考虑和预留的东西。

软件栈全貌

虽然，推理软件栈确实相对训练要做的事情少了很多。

一方面，之前的文章说了AI芯片公司的四个主要目标市场：互联网/云计算、运营商、G与大B、ISV。

另一方面，目前的情况基本上是，聚焦于边缘侧的公司在做云侧的产品，之前PR做数据中心产品的，基本在做芯片的时候都打了埋伏，通过“小Die+互联”技术，做到了一次流片回来，可以有多款产品覆盖数据中心+边缘两个产品线。

做板卡和芯片可以有“讨巧”的机会，但是从软件栈来说，除了底层最基本的软件，往上走，两个场景对软件的需求其实差距挺大，而且，对涉及到的技术背景要求有很大的不同。

所以，讨论软件栈时候，我们需要结合数据中心、边缘的推理业务的单体部署与互联网业务的大型工程化验证与部署需求，整体来分析与规划软件路线图。

一孔之见，对推理芯片的软件栈按功能完备性来考虑，可能分为下面这几个层次（就不画图了，懒）。

端到端业务部署：快速部署工具或者平台，这个各有理解，不会有什么标准答案，可以参考：NVAIE(NVIDIA AI Enterprise)或者PaddlePaddle的FastDeploy，看看两个完全不同类型的厂商在降低用户部署AI算法的复杂性和难度方面做的思考和工作。

云原生能力：云计算在当下的重要意义没什么需要解释的，做为AI芯片公司，在这一层，K8S之上的平台基本没太多工作要做，但是要懂，起码AE、FAE、解决方案团队能在自己的测试/演示环境中搭一套Kubeflow，挂个能用的推理后端，玩起来，客户来参观了，演示起来。 K8S(Kubernetes)是容器编排系统的事实标准，也几乎是云原生应用的操作系统，但K8S的调度器不认识贵司的卡，是没法调度的，所以要参考Device Manager Proposal实现一套自己的Device Plugins才行。当然还有支持Prometheus监控等，不难，但是都需要有人来实现。另外，要是讲云边一体的故事，K3S和KubeEdge同样需要要考虑也玩起来了。

SDK on SDK：或者是Libraries on SDK，这一层其实是整个软件栈工作量最大，且要持续不断投入迭代的。各家AI芯片公司软件负责人对AI生态、用户业务场景、参考设计/Demo的设计思路、用户编程习惯、NVDIA CUDA X软件生态、国内友商软件生态、自己公司商业模式和市场战略等的理解程度和AI落地交付的认识，会直接反应在这部分工作的规划、排期、速度、质量以及丰富程度。这个可以参考的就太多了，CUDA X 是终极目标，放在心底默默学习，跑的快、落地好的几个友商，才是真需要抄袭参考的目标，看自己的人力储备和底层软件成熟度，做好规划，一点点实现就好。

服务化推理能力：除了部分边缘场景可能用一体化应用是合理方案以外，在微服务为主流的现代IT架构体系下，AI推理能力作为一种服务交付，然后业务系统通过REST/RPC来请求，基本是基础设施的标准方案，NVIDIA虽然不是第一个做的，但是Triton Inference Server基本上给出了标准答案，而且，提供了一组 Backend API，把自家的硬件注册进去那是真不难啊。当然TensorFlow Serving做的最早，开源最早，也是好的参考学习目标。另外，PaddlePaddle、PyTorch也有对应的开源软件，可以多看看找找思路.

进阶能力：虚拟化必不可少，当然是SR-IOV的虚拟化支持了，虚拟化的最小单位与故障隔离能力是很重要的两个事情，一张卡上一个虚拟化实例挂了，整张卡上其余实例都躺枪的虚拟化，估计是卖不出去的。如果目标客户有云平台的话，能支持超卖显然是更好的。另外就是容器技术（Docker让容器技术飞入寻常百姓家，但他不是容器技术的全部，仅仅容器引擎的一个优秀实现）的支持，为什么要做，解决了什么问题，细节不展开说，NVIDIA Container Toolkit文档说的非常详细了，照猫画虎就是了。

开发工具链：除了编译工具链，还需要有性能剖析，GBD调试，精度分析，日志分析，数据可视化，部署完备性快速验证，推理引擎及系统管理接口工具/程序等一系列工具与程序，帮助开发者完成调式、优化、部署、监控等一系列模型迁移及推理代码开发、部署的基本需求。

基础能力：驱动、固件、运行时、AI编译器（含量化工具）、算子库、多媒体处理库，以及带上必要的头文件包出来一个基础SDK，向下对外屏蔽硬件实现细节，向上提供一套编程接口，方便编程者使用硬件能力。

一不小心写了个七层，弄的像OSI七层一样😁。芯片人还是比较喜欢起名字，弄代号的，咱也不能例外，那这个模型就叫：

哈哈哈。

自己寻开心结束，回到正题。

罗马不是一天建成的，我们张口闭口说的“CUDA 生态”，NVIDIA也不是一天搞起来的。从开始做 CUDA 到 NVIDIA 觉得做的差不多了，提出构建在 CUDA 之上的 CUDA X 这个工具和库的集合，经过了十几年的时间。

哪里有那么多“弯道超车”的好事，学习、分析、研究，理解其每个库、工具、SDK的功能、定位，以及试图解决的问题与解决方式，猜测其这样做的意图和思考。能够厘清哪些是因为后向兼容和技术负债带来的新增开发工作，哪些是对AI计算和部署需求的洞察，抓住核心软件需求，迎头赶上。

当然，同样可以参考下跑的快的友商的软件栈，看看他们做了哪些，同样也能有不少启发。

毕竟，这么多年的技术积累的护城河，基本上很多概念和编程模型已经形成了“事实标准”，让AI编程者形成了“这就是标准方案”的认识和错觉。

举个简单的例子吧。

推理场景，为了把N卡的算力打满，一般都会加大batch size，已获取更高的利用率和吞吐量。但是，副作用也非常明显：牺牲了延迟。在延迟敏感场景，显然是很难把算力跑满，造成投资收益比下降。

对于做DSA芯片的兄弟们来说，微架构上一般都有天然的优势把这个吞吐和延迟的Trade off做的更平衡（要不DSA的IP就设计了个寂寞啊😂），但是用户不一定理解这件事。

FAE很有可能遇到这样的困扰：用户模型推理原来的BS=32,可能准备和N卡混合部署做服务端跑业务，业务测试阶段，要求同样支持这个batch size。

这个需求，站在用户的角度是有其合理性的：如果用户是服务化的推理平台，把组批和计算调度分离，这样就可以抹平不同AI计算硬件的差异，做到计算能力对需求方透明，保持BS不变，就不需要做组批和调度逻辑的业务代码修改。

那么，这时候FAE是讲道理说这个BS下延迟是负收益，说服用户按照不同的计算加速后端改造业务逻辑和调度逻辑，还是默默支持就行了？

小小一件事，要改变用户理解，需要做很多提前准备：

• 跑各种主流网络的实测数据，让用户一眼看到“甜点”超参是什么；
• 培训FAE，能基本解释清楚这件事；
• 遇到好奇心比较重的用户，可能还要更多的解释才能让人家理解这件事的收益，愿意改造现有代码。

回到软件栈。

在大家算子还不全，编译器还需要大量手工代码才能完成模型编译，后量化还不能支持所有量化方法的这个时间点，说这么大的一个软件栈，似乎是有点不合时宜和没事找事的。

但是，凡事预则立，不预则废。走一步看一步，没有战略规划，只能步步受挫，步步被动挨打。

这事，不多说了，相信每家都有自己的认知和理解。

回到开头的故事

大厂螺丝钉这个说法没有人会陌生。企业大了之后，流程、分工必然更细，每个人只要做好自己手里的事情就好，慢慢成为一个领域专家。但，这种割裂的细分培养出来的专家，进入创业公司这种更希望在领域专业性之外具备全面性的需求的时候，会发生什么，大家都懂。

而且，越是早期，这样的领域专业人才越需要，其中一定会有一些过去的旧部能得到极大的信任，走上了管理岗位，提拔重用的副作用可能是需要管理一片几乎陌生的技术领域。

在这种人力配置和管理分工下，要求做到Top-Down去规划软件栈，其实挺难的，听到过不少这样的奇闻逸事。

当MVP做出来，拿去面对一个个极其专业又挑剔的客户的时候，软件的功能缺失，设计偏差，接口不友好，甚至代码质量都会无情的暴漏出来。

另一方面，软件工程能力也是一个问题。

能搞定一个单体的小软件或者实现架构师设计好的软件栈的一部分，大多都是体力活，不是太难的事情，难的事有没有从零开始抽象和设计一套软件的能力。

见过不少面试问设计模式，虚函数，算法，数据结构这些八股文问的一套一套的，自己拿出来的设计，连几个基本的原则都遵守不了，更不要提高内聚低耦合了。甚至是为了图快、省事，直接对实现编程，接口设计应付了事，根本没有考虑到后续可能重构或者功能扩展的事情，更是不可思议了。

这个时候，很自然的，公司会考虑请大牛、找高手。先不说各家JD中描述的那样的软件人才，市场上有多少可以挖得动的，假设能找到合适的真高手来。

大多数技术人员，或多或少都是很轴的，能做到时刻保持自省、敢于自我否定的就更凤毛麟角了，如果再要求理解人性和懂得管理的艺术，那就更少了。

好了，意思基本上都表达到位了，说太透就没意思了吧。

空降兵其实很难找，也很难用的。

因为信任的基础并不高，信任是脆弱的。

越往上，能分的位置就屈指可数，是新造一个还是拿下一个，拿下的怎么安排，安抚。

空降兵出手太重，老班底，老团队会反弹，抱团对抗。

不出手，做老好人，那是肯定稳不住基本盘的，很难呆久。

挑毛病，说假大空、伟光正的正确的废话，太容易，带着解决方案指出问题就很难了，还要让做错的人 buy-in 那就无异于登天了。

即使空降兵是对的，也有足够的能力解决问题，关键决策的时候，一张嘴怎么搞定“群殴”。

管理本就是一件很难的事情，再加上技术这个变量和技术负债需要清理这个事实，重构就变成了一件极其困难的工作。

回到我的当年勇，大家可以琢磨下我当时做的所有动作的意图、思考与困扰。

所以，虽然公司可能意识到了问题，也有重构的动力与决心，有没有人能撑起来，能不能做成，一切依然是未知数。

真的要珍惜自己的公司和这个芯片好机会，视野开阔点，多反思，多学习，把事情做成才是真本事。

欢迎加我的微信“doubtthings”，欢迎交流与探讨。

欢迎关注我的公众号“书不可尽信”，原创文章第一时间推送。