AI Native：人类作为AI模型的协作者而非工具
最近这段时间在处理一些复杂的团队协作事务，反倒让我更坚定了自己一直以来的做事原则：比起复杂的人际博弈和名利争夺，我更愿意沉下心来专注做好具体的事情。我从来不会刻意去争抢项目中的功劳，反而习惯把合作方当作项目的主导者，安静陪伴他们达成目标，即便能获得一点认可也会心怀感激。在我看来，个人在项目中的付出自己心知肚明就足够，没必要为了虚名去争抢，更不必居高临下地施舍功劳——毕竟名利终究是过眼云烟，与其纠结这些，不如带着好奇心去探索这个世界的本质。
当然这种与世无争的态度也难免留下遗憾：不少领先行业的想法没能在当时落地，反倒在几年后被其他人实现。当年从某跨国科技公司离职多少也带着这样的遗憾——2018年我在该公司负责AI基础设施相关工作，从分布式强化学习到ScaleUP架构布局，再到后来行业兴起的以太网ScaleUP浪潮，如今再看该公司几乎完全错过了这个赛道。但我并不抱怨什么，反而在和前同事聊天时发现，这段经历让我学会了更成熟的为人处世之道。
这段时间一边处理琐碎的协作事务，一边也挤时间读了些书，还花了大约10个小时完成了Anthropic的一道公开面试题。在资源受限的情况下，我只能依靠通用CPU并行开展大规模搜索来弥补模型能力的不足，最终勉强拿到了前10的成绩（不过发文时排名已经变化了）。这种感觉让我找回了当年参加学科竞赛的状态：亲自思考一遍问题，收获远比直接交给模型处理要多得多。这也是我想聊聊“AI Native”这个话题的初衷——AI时代的核心应该是人作为模型的副驾驶，而非反过来被模型主导。
即便没有充足的高端算力资源，也不妨碍我们做出扎实的成果。没有顶级加速卡的时候，我们也曾逆向研究相关架构，利用闲余的算力资源完成工作，哪怕需要熬夜加班也在所不惜。我们团队在DPU领域已经做到了全球第一，也是唯一一个从体系结构层面完全区分CPU、GPU和DPU的团队。我们的CIPU产品在安全、性能、稳定性和成本四个维度都表现出色：相比部分厂商的产品需要频繁停机修复CVE漏洞，相比某些网卡长期无法解决网络拥塞问题，我们的eRDMA在大规模部署时几乎没有出现过问题，同时因为兼容RC Verbs接口，生态迁移也没有任何适配障碍，行业内折腾多年都没能在多路径和拥塞控制算法上追上我们的水平。反观海外大厂，AWS没有标准的RC Verbs接口，Google的Falcon至今没有大规模部署，微软Azure的语义支持也并不完整，而头部厂商的相关方案在推理时代也会面临更多挑战。
AI Native的核心内涵与实践方向
在讨论AI Native之前，我们首先需要明确概念的本质。就像当年的云原生概念，很多人并没有真正理解云的内涵，只是将其等同于代码基础设施化。回到AI Native这个话题，我和同事聊天时曾讨论过一个有趣的问题：手握成熟办公套件和代码托管平台的头部企业，却没能在办公场景和编程工具领域做出突破性的AI产品，反而要成立新公司专注于部署相关业务，这背后的原因是什么？
如今我已经很少打开传统办公软件，反而更习惯使用专业的协作平台。那些依附于现有文档、即时通讯工具的AI辅助平台，从一开始就注定难以成功，根源就在于理念的偏差。“Copilot”这个词本身就不是真正的AI Native，真正的AI Native应该是Human as a Copilot for AI Model——也就是首先承认模型比自己更聪明，不要用自身的过往经验去束缚模型的思考。
很多人在设计AI应用技能时，都会不自觉地带入自己的经验，这反而会成为模型的瓶颈。比如在处理VLIW Kernel的问题时，过度依赖过往经验反而会限制思路。我早年做量化交易时就秉持同样的理念：当行业都在做多因子模型、反复寻找因子和调参时，我选择从系统层面分析，从不使用任何因子或回归类方法，这套模型至今依然能稳定运行。
现在很多团队都在做模型蒸馏，但真正的智能真的能靠“刷题”刷出来吗？答案显然是否定的，我们需要的是更扎实的基础研究。比如Anthropic的transformer-circuits.pub项目，多年来始终坚持深耕底层研究，这才是真正有价值的方向。用“第一性原理”来拆解的话，AI Native的实践可以分为三个核心层面：
首先是模型架构层面
要实现大规模扩展，首先要正视芯片的底层限制：算力本身很容易横向扩展，但访存带宽却是难以突破的瓶颈。因此我们必须在算法层面坚持稀疏化处理，相关模型架构始终围绕这一核心展开：从早期的混合专家模型路径，到细粒度MoE的演进，再到注意力机制的多种优化方向，整个过程都在聚焦稀疏化和降低访存成本，而外界很多人只是简单将其理解为降本增效。反观那些盲目使用Linear Attention的团队，当试图将5~10M的上下文压缩进状态矩阵时，真的能保证良好的表示效果吗？多数消融实验的良好表现，或许只是因为测试样本的上下文窗口都在100K以内而已。
其次是算法层面
当前深度学习的数学基础还停留在19世纪，大量依赖微积分和线性代数，近代数学的成果几乎没有进入算法研究的主流赛道。这本质上是人类分工和认知的缺陷：很多前沿数学内容需要纯数学方向的博士阶段才能接触到，而算法工程师的知识背景普遍存在短板，这也暴露出行业组织结构的问题。比如代数拓扑相关的算法很难在当前GPU架构上实现并行，而数学上的精确解在低精度芯片运算中又会出现诸多问题。多数模型团队的创新都只是在现有工作上做微小调整，缺乏真正的架构级突破。
最后，核心在于细节落地
很多关键问题都藏在细节之中。优秀的基础模型团队不仅要有扎实的算法研究，更要注重工程细节的打磨。很多聪明人不屑于做工程上的基础工作，这也是他们职业发展受限的重要原因。无论是算法上的严谨还是工程上的细致，都是非常重要的研究品质——有些人天生具备这种特质，而像我这样的普通人，大多是在反复实践中才学会了重视细节。
想起Sutton的《苦涩的教训》，这篇文章其实本质上就在探讨AI Native的核心：在算力约束的背景下，我们需要更聪明地实现算法和芯片架构的协同设计。当前头部厂商的GPU微架构已经遇到了瓶颈：从早期架构开始就面临寄存器瓶颈，后续的优化版本也只是缓解了部分问题，但单芯片的性能扩展已经遇到天花板，极端负载下还会出现严重降频。而相关多芯片封装方案也暴露出诸多问题。那么，如何结合算法特性设计全新的AI Native加速器？我已经有了清晰的答案，等我们明年在相关领域取得进一步突破后，再详细聊聊这个话题。
最近我也在研读相关前沿研究内容，就不在这里展开了，敬请期待后续的分享。
塔猴是一个专注于为用户提供系统学习、内容创作与商业连接的AIGC综合服务平台，致力于为每一位AI探索者打造理想的创作、成长家园。在塔猴，你不仅可以学习众多AIGC类实战课程，获得与时俱进的AIGC技能和视野，还有机会获得长期商业合作和接单机会！点击进入：https://www.tahou.com/
AI生成内容提示：本文由人工智能辅助创作，内容仅供参考，不代表平台观点。请注意核实信息的准确性，并理性判断。
