本文来自微信公众号： 碳基智 ，作者：碳基智
前一阵有猎头给推荐了一家做AI Infra的初创公司HC，虽然暂时没有挪窝的打算（因为公司给的token额度实在太香了），但还是出于好奇和学习，去研究了一下AI Infra的领域，把自己的学习心得记录了下来。
先说结论：
跟《Harness就是控制论》这篇发现的现象类似，我发现其实偏硬件层面的AI Infra领域，也没什么新东西出现，还是一些老问题换了个新战场
1
Hacker News上曾经有人发表过这样一条评论，大概意思是：
AI圈总是把其他领域已经发明过的东西再发明一遍，还自鸣得意。
在深入学习的过程中，我发现这评论太特么经典了，简直不要太真实。
我花了挺长时间去把AI Infra的核心工程挑战拆开，一个一个跟传统后台服务做对照，最后发现那些听起来唬得你一愣一愣的概念，什么模型并行啦、什么通信计算重叠啦、什么CUDA Graph啦、什么KV Cache啦，都是传统后台玩剩下的东西。
2
互联网时代，整个行业被灌输的核心范式信仰是分布式的，要能横向扩展、要去IOE，要用软件创新重构出高可用低成本的互联网基础设施。可以说过去十年，技术发展的脉络就是按照这个逻辑走的。
但AI时代，动辄千亿参数的模型训练，需要千卡/万卡GPU集群协同，通过专用网络互联构建出一个所谓的「AI超算」，这设计逻辑是不是有点眼熟？
IBM大型机：没错，正是在下。
以硬件集中化换取极致性能与可靠性。原因也很简单，传统后台服务可以容忍毫秒级的延迟，但GPU的算力是CPU的数百倍，微秒级的等待就是巨大的算力损耗，所以必须做到高度集成。
当下的AI正处在「AI大型机」的阶段，硬件集中化的红利还没吃完，软件层面的去中心化创新还没成熟，恰好跟阿里当年提去IOE的历史阶段有点像。
更进一步，因为高端算力的紧缺，以及自主可控的内在要求，我们是否会走上一个「AI去NVIDIA化」的阶段？我觉得这是一个大概率的问题，只是我们还需要在软件层面做出更大的创新去重构基础设施，让高端算力不再成为掣肘，同时也要寄希望于国产算力实现突破。
所以，昇腾们、DeepSeek们，加油吧！
3
上面这张图，是AI Infra领域和传统后台领域的5组同构映射，你就说这些东西看着熟不熟。
OOM→Sharding分片
一个千亿参数的模型有多大？光参数本身就两三百GB，训练过程中产生的中间数据比参数还大好几倍。一张卡141GB显存，根本塞不下。怎么办？切。把模型按层切、按矩阵切，分散到多张卡上，每张卡只负责一部分。
传统后台也这么干：数据库单表太大就做分片（Sharding），按用户ID拆、按时间拆，一张大表切成小表分散到多台机器。思路完全一样，只不过以前切的是数据，现在切的是模型。
通信计算重叠→多线程异步IO。
模型切完分散到多张卡上，卡和卡之间就得通信传数据。如果跟鸡排哥一样，「算完你的算他的，传完他的传你的」，GPU就有大量时间在等网络，利用率直接暴跌。解法是让通信和计算同时进行：GPU一边算当前这批数据，一边把上一批的结果往外传。
传统后台也这么干：服务器处理请求的时候不干等数据库返回，用异步IO，主线程继续干活，数据回来了再处理。本质都是同一句话：花了那么多钱堆资源，肯定要站起来蹬才划算。
CUDA Graph→Redis Lua脚本。
模型推理时GPU需要反复执行一组固定操作。问题是每执行一个小操作，CPU都要跟GPU通信一次：“摩西摩西，该干活了”。操作本身可能只要1微秒，但这个吱一声的开销可能要10微秒。一千个小操作下来，绝大部分时间都花在了沟通上。CUDA Graph的做法是把这一千个操作打包成一张「施工图纸」，一次性递给GPU说就按这个办。
Redis Lua脚本也这么干：把多条Redis命令打包成一个脚本一次性发过去执行，省掉了每条命令单独走一次网络的开销。核心逻辑都是多次往返合并成一次提交。
连续批处理→Work Stealing算法。
传统批处理像早年间的中巴车，非要凑够一车人才发车，先来的人得等后到的。LLM场景下问题更严重：有人问今天几号（3个字），有人说给我写篇论文（3000字）。如果等那篇论文写完才放下一批进来，GPU大量时间在空转。连续批处理（Continuous Batching）的逻辑像顺风车，有人下车立刻有新乘客上车，GPU永远满载运行。
传统后台的线程池用Work Stealing解决同类问题：忙完的线程主动去别的队列里「偷」任务来做，不让任何一个线程闲着。本质都是调度问题。
KV Cache→缓存。
LLM每生成一个字，都要回头看一遍前面所有的内容。如果每次都从头算，生成第100个字的时候要重新计算前99个字的结果，越往后越慢。KV Cache的做法极其朴素：算过的结果存起来，下次直接用。这也是你花钱的DeepSeek V4这么便宜的一大重要原因。
传统后台用Redis做缓存：数据库查过一次的热数据存Redis里，下次直接返回，不用再查一遍库。这回连名字都懒得换了，就叫Cache。
五组映射摆完，规律已经很明显了。战场从CPU转移到GPU，延迟敏感度从毫秒变成微秒，数据规模从GB变成TB，但解决问题的抽象思路，分片、缓存、异步、批处理、任务调度，一个都没变，还是经典的那套。
4
最后，再来聊聊AI爆炸式的发展所带来的行业FOMO焦虑问题。
我觉得一个重要的核心原因就是过度包装，就像开篇提到的那条评论一样。AI Infra的概念被包裹在GPU编程、CUDA、Triton、PyTorch这层所谓的新词汇里，加上硬件成本确实惊人，一台机器顶一个深圳首付嘛，制造出了「这是完全不同的知识体系」的幻觉。
GPU编程确实有真实门槛。GPU采用SIMT架构，分组后的线程同一时刻只能执行相同指令，跟传统CPU串行思维存在根本性冲突。这个问题是真的。但这是「编程范式切换」的门槛，你不会因为从C++转Python就说自己的系统设计能力过时了吧？
真正该焦虑的，反而是「我有没有能力在新硬件上重新应用这些技能」，这是增量学习的问题，跟技能归零被取代完全是两回事。
所以，我觉得大家更没有必要焦虑了，经典的工程方法论，就是你最强有力的武器。