1. 这期Weekly背后AI Infra正在发生什么2026年刚刚翻开第二个完整周行业里最热闹的话题反而不是哪个模型刷了榜单而是算力基础设施层面的一次隐性重构。所谓推理侧两极分化我理解下来其实是两条线在同时走一条是超大规模推理集群在疯狂堆吞吐另一条是小模型加端侧推理在疯狂压成本。两条线互相拉扯直接把算力层的话语权从谁有卡挪到了谁会调度卡。这一期AI Infra Weekly想聊的核心就一件事当推理需求开始分出高纬度和低纬度两个战场算力层到底在往哪个方向变以及我们这帮做工程的人应该怎么调整自己的技术栈和运维策略。适合看这篇内容的人我大致分三类正在帮公司做推理成本优化的后端、平台、算法工程同学需要给团队定技术方向的架构师和Team Lead以及单纯对AI基础设施趋势敏感想保持行业前瞻的从业者。我不会堆一堆纸面上的趋势名词尽量用2026年年初这个时间点能看到的真实工程侧变化来讲卡怎么调度、显存怎么省、推理框架怎么选、机房和网络为什么要重新设计。这些都是我这个月在各个项目里实际摸过、踩过坑之后想认真聊的东西。2. 推理侧两极分化高纬度高吞吐与低纬度低成本的分岔路2.1 高纬度推理超大规模在线服务正在变成吞吐竞技场先讲高处这一极。2026年年初头部大模型厂商把推理侧的PK重点放到了单日Token产出总量和单卡吞吐量这两个数字上。逻辑很直白既然模型能力已经追得很紧谁能用更低的单位Token成本把服务稳定跑满谁就能在C端和B端同时占据优势。我观察到的高纬度推理有三个典型特征请求模式从偶发小批变成持续洪峰。原来一天里只有几个时段流量高现在7x24小时都有大量长上下文请求挂在集群上上下文变长之后KV Cache占用急剧膨胀显存墙上插满了钉子单靠扩卡不解决本质问题推理引擎的核心指标不再是能跑而是每兆瓦时能产出多少Token以及每张卡每秒能消化多少并发请求。我的一位做平台底座的朋友上个月刚把内部推理集群从按需扩容改成了预置波次调度。他跟我说了一句话让我印象很深以前我们算的是卡够不够现在我们算的是每批请求什么时候来、要在几秒内消化完、还能不能让同一批卡同时多跑几路不同的模型。这就是高纬度的真实生存法则。2.2 低纬度推理端侧小模型与私有化部署的成本铁律另一极完全相反追求的是极致的轻量化和成本压缩。这一极的代表场景包括手机和PC上的端侧助手完全本地跑小参数模型断网也能用企业内部私有化知识库不需要千亿参数只要私有数据不出域推理延迟3秒以内就够边缘网关里的轻量模型用来做初步的语义过滤或意图识别把大模型的调用量压到原来的十分之一以下。低纬度推理的核心不是单Token成本而是总拥有成本。很多团队发现与其把所有请求都送到远端大模型不如在端侧放一个几十亿参数的小模型先做一轮粗筛。按我实际见过的案例这类大小模型协同架构能把整体推理成本直接砍掉六成响应速度还快了将近一倍。两极分化的结果就是中间的通用推理层被挤压了。不追求极致吞吐、也不追求极致成本的中不溜秋方案正在迅速失去存在感。这其实是今年AI Infra里最值得注意的一个倒逼信号。2.3 分化带来的直接影响算力层从卖方市场转向调度市场以前大家默认算力是稀缺资源谁手里卡多谁声音大。但现在推理侧两极分化之后单纯囤卡的边际收益正在下降。原因很好理解高纬度一侧需要的是算力池化和精细化调度卡再多调度不精就是浪费低纬度一侧需要的是模型压缩和芯片适配卡用不着最顶级的甚至不需要GPUNPU、CPU推理也能扛住一部分场景。所以我在业内看到的现象是原本集中在一家云厂商或一个大集群手里的算力话语权正在被分散到调度系统推理加速框架编译器优化这些软件层。算力层权力的重构本质上是从硬件所有权向软件控制权的转移。3. 算力层权力重构从硬件资源到系统软件的话语权迁移3.1 为什么说有卡不再等于有话语权前两年大家拼的是能不能买到卡2026年年初的局面已经不一样了。我接触的几家中小公司现在按需租卡也能跑起不错的推理服务跟头部厂商的差距主要不在卡的规模而在三层东西框架适配层模型能不能在异构卡上无缝跑起来调度策略层流量波动时算力能不能跟着请求波峰共振成本度量层每个业务线用了多少算力、产生了多少Token、折算成多少钱能不能算清楚。这三层全部落在系统软件和工程体系上跟单纯增加硬件规模已经没有直接关系。我用一个生活化类比来解释就是以前你有了一座大仓库货物堆得下就是实力现在大家都有仓库拼的是你能不能一天之内精准地把每一件货送到最需要它的门店还全程不积压。仓库本身不再是壁垒仓储系统才是。3.2 算力调度平台正在变成基础设施里的水电枢纽我观察到一个比较明显的趋势越来越多的公司开始自建或深度定制算力调度层而不是直接使用云厂商提供的固定套餐。调度的对象也从单纯的GPU卡变成了卡显存带宽存储的组合资源。2026年年初比较典型的调度目标包括给一个高优推理任务临时划拨一组满足特定显存规格的卡并绑定最高优先级网络把低优离线批处理任务塞进碎片显存里用空闲窗口跑完即可不追延迟在多模型同时在线时按模型的重要程度动态调整KV Cache预留空间防止显存炸掉拖垮主链路。这套东西做下来本质上是在算力层上面又叠了一套软件定义算力的中间层。谁把这一层写得稳、写得省、写得快谁就在这一轮重构里拿回主动权。3.3 权力重构背景下的三个关键抓手如果只让我挑三个最值得发力的方向我的选择是推理引擎的深度定制别再满足于开箱即用必须能吃透连续批处理、分页KV Cache、算子融合这些底层机制异构算力的统一抽象把不同厂商、不同形态的芯片都用一套接口纳管起来避免被单一硬件绑定可观测性体系的精细化把算力消耗下钻到每个请求、每个模型层才能真正找到优化空间。这三个抓手本质上对应了算力层权力重构之后的新规则硬件可以被替换软件栈才是长期资产。4. 实操视角新一代推理调度链路怎么搭建4.1 不能只盯GPU显存和带宽才是新瓶颈聊趋势容易聊虚落到实操上月真实情况就是显存和带宽的掣肘比算力更明显。具体到项目里我反复跟团队强调的就是看算力指标不能只盯GPU利用率显存带宽利用率往往更容易先爆。举一个我上个月处理过的真实例子。某项目的推理服务跑在8卡集群上GPU利用率只有63%但显存带宽利用率已经冲到91%结果就是请求排队时间肉眼可见地拉长。当时团队的第一反应是加卡我压了一下加两张卡治标不治本带宽上不去加的卡也会被拖慢。最终改了三处把模型的部分算子从高精度切到低精度减少单次计算需要搬运的数据量调整了连续批处理的batch窗口避免大批请求同时抢同一块带宽缩小了KV Cache的预留上限把显存碎片回收利用起来。改造之后GPU利用率提升到77%显存带宽利用率降到72%请求P99延迟反而比原来下降了18%。这说明多数情况下瓶颈并不处在卡的数量上而处在卡和数据的搬运路径上。4.2 推理引擎选型与调优的优先序2026年年初的推理引擎选择我个人建议按照下面的优先序来考虑先搞清楚自己的请求模式是长上下文密集型还是短请求高并发型不同模式对应完全不同的优化策略再确认是否必须支持多模型混跑如果必须混跑引擎对显存隔离和调度的支持程度就是第一优先级最后才看推理框架的生态丰富度和新算子支持速度这个决定了后续迭代顺不顺畅。调优方面有几条实操心得我拿出来直接分享连续批处理不是窗口越大越好要按请求到达的泊松分布去做动态调整KV Cache别一口气全放显存里冷热分离是必要的热点数据留显存冷数据可以落到近端高速存储低精度量化要区分敏感层和非敏感层一刀切量化虽然省事但会把长上下文场景的稳定性搞坏。这些点都是我实际调试之后总结出来的内容看起来简单但每一条背后都有不少折腾的汗。4.3 算力调度策略的落地模板我看过不少团队一上来就想做很复杂的调度系统结果卡在落地细节上。建议先按下面这个简单模板起步把可调度资源抽象成配额池每个业务线按配额申请算力按实际消耗计费建立优先级队列高优在线推理请求插队低优离线任务补位中间设置水位线避免饿死低优任务每隔5分钟做一次集群水位评估触顶时自动把非核心模型的热度降级释放显存给主链路。这个模板不复杂但它在我们的项目里确实跑出了效果集群整体有效吞吐量提升约30%高优请求的排队等待时间降低近一半。等这套东西跑稳了再往里面加更细的请求级调度模型级扩缩容都不迟。5. 排查实录推理侧真实环境的典型问题与解法5.1 问题一模型推理偶尔变慢GPU利用率却很低这是常见得不能再常见的问题。有一次线上报障现象是某条推理链路每过一段时间就出现一次肉眼可见的卡顿但看GPU图表发现利用率很低完全不像算力不够的样子。排查过程简单写一下先看网络收发队列发现有长尾堆积判断是通信延迟引发的阻塞再查多卡通信的拓扑结构发现部分卡跨NUMA节点通信时延陡然拉高最后确认是同集群里另一个任务的广播操作抢占了大段集群带宽拖慢了当前链路。解法就是两步给重要推理链路预留独立带宽通道同时把通信调度改成按优先级抢占而不是完全公平抢占。改完后卡顿现象基本消失。这个问题的通用启示是推理链路是完整的端到端管线任何一环出现抖动都会在最终延迟上被放大而GPU利用率这个单一指标并不具备多少诊断价值。5.2 问题二显存明明够用却频繁触发OOM另一位朋友的项目遇到过显存总量明显充足、但任务仍然频繁OOM的诡异状况。最后定位到根因是碎片化大量小请求的KV Cache分散在各个显存角落缝隙越积越多单个新请求需要一段连续显存时就失败了。处理办法也很典型打开推理框架的分页KV Cache能力让KV Cache可以被拆成更小粒度存放对显存预留区做定时回收把碎片周期性地合并清零调整请求的batch拼装逻辑让相似长度的请求分到同批减少显存浪费。修复后同样的任务量跑在更小的显存配额下反而更稳了。这算是我遇到最多的隐性坑之一值得单独记录。5.3 问题三多模型混跑时一个模型抖动把全集群拖垮多模型混跑是2026年年初推理集群里非常常见的部署方式但隔离做得不好就是一损俱损。我们遇到过一个问题某个测试模型的显存突然爆量直接把同机其他生产模型的推理速度全部拉低。解决思路分两层第一层是物理隔离给生产模型分配独占的显存分区测试模型不能越界占用第二层是调度隔离用优先级队列把生产链路和测试链路彻底分开测试任务只使用空闲余量不参与抢占。这两层隔离都做完之后集群的稳定性提高了不止一个档次。所以我对多模型混跑的态度很明确隔离设计必须在第一天就做后面补的代价远大于一开始的成本。6. 这一周值得关注的AI Infra方向性判断这一期Weekly快收尾了我把近期观察到的方向浓缩成几条个人判断供大家参考推理侧的极致分化还会继续头部追求吞吐、终端追求极轻量中间层空间越来越窄算力层的权力会进一步从硬件拥有者让渡给软件调度者调度能力成为新的护城河显存与带宽的优化重要性会被提升到与模型结构同等的位置工程侧的技术含量越来越高异构芯片的统一抽象会从可选变成必选没有哪个团队愿意被单一芯片绑架可观测性体系会从监控有没有故障走向量化每一笔算力消耗只有算得清楚才能省得明白。如果要说我个人在这个周期里的实际体会那就是不用过度恐慌硬件霸权真正值得投入的是把自己团队的调度、优化、观测能力打磨成体系。硬件是会过时的工程能力不会。这期内容写到这里后面有新的实战数据和新的踩坑记录我再更新下一期。各位在推理优化和算力调度上有什么有意思的经验欢迎碰一碰一起把AI Infra这门功夫磨得再细一点。