0
0

推理 Infra 的高速演化期：为什么疯狂、未来 1–3 年如何收敛，以及职业窗口

2026-10-17
学习路线

问题起点

为什么 LLM inference infra 的变化速度异常快，甚至产生“一年像传统软件多年”的体感？未来 1–3 年会趋于稳定，还是继续无法收敛？这个领域究竟是工程主导还是理论主导？从数据库、云计算、CUDA 等历史阶段回看，进入这种早期系统领域意味着什么？

为什么当前变化如此剧烈

关键原因不是某一项技术更新快，而是 五个变量同时没有收敛：

模型架构
   ↕
推理算法
   ↕
Serving Architecture
   ↕
硬件与互联
   ↕
产品 Workload

传统系统通常拥有较稳定的问题定义；而 LLM inference 连 workload 本身仍在快速变化。

例如模型侧从 Dense Transformer 扩展到 GQA、MLA、MoE、Sparse Attention、Linear/State-Space/Hybrid Attention 后，会连续向下改变：

模型结构
  ↓
需要保存的 state
  ↓
cache layout
  ↓
memory manager
  ↓
scheduler
  ↓
parallelism
  ↓
communication
  ↓
kernel

因此一个上一代模型已经稳定的 abstraction，可能被下一代 workload 直接打破。

“一年顶十年”应该如何理解

这不是严格的软件工程度量，更适合作为 architecture churn 和信息密度 的比喻。

可以区分两个维度：

  • 架构和知识变化速度非常快：模型、parallelism、KV/state、serving mechanism 可能在一年内多次换代；
  • 工程成熟度并没有同步加速：可靠性、兼容性、API 稳定性、debugging、observability、故障恢复仍明显年轻。

所以更准确的判断是：

推理 Infra 正在高速探索正确系统边界，而不是已经用一年积累了传统数据库几十年的成熟度。

未来 1–3 年最可能的状态

更可能出现的是 核心 abstraction 逐渐收敛，实现继续快速变化，而不是整个领域突然稳定。

可能逐步稳定的系统角色包括：

Request
  ↓
Router / Admission Control
  ↓
Scheduler
  ↓
Compute Engine
  ↕
State / Cache Manager
  ↕
Communication / Transfer Layer
  ↓
Device Backend

未来不同系统即使实现不同，也大概率都需要回答同一组问题：

  • 请求如何路由与准入；
  • prefill / decode / expert 等计算如何分工；
  • KV、recurrent state、multimodal state 如何管理；
  • 数据如何跨设备、跨节点、跨内存层移动；
  • topology 如何影响 placement 与 scheduling；
  • backend 如何暴露硬件能力。

为什么仍不会完全稳定

上层 workload 会继续制造新扰动，尤其是 Agent 和长运行任务。

传统 chatbot request 更接近：

Prompt → Generate → Finish

Agent workload 更可能是：

Model → Tool → Model → Search → Model → Code → Model

这会强化以下问题：long-lived state、prefix reuse、KV persistence、inter-request sharing、动态 compute budget、irregular generation。即使底层框架 abstraction 稳定，上层调度策略仍会快速演化。

这是工程大于理论，还是理论大于工程

当前更接近 Systems Research：工程主导，但需要理论模型提供抽象和判断。

真正相关的理论不是单一的 Transformer 数学，而来自：

  • Operating Systems
  • Distributed Systems
  • Computer Architecture
  • Networking
  • Scheduling Theory
  • Queuing Theory
  • Caching Theory
  • Parallel Computing
  • Optimization

例如：

  • Scheduler 是 online scheduling + queueing；
  • KV eviction 是 caching / replacement；
  • P/D 资源配比是 queueing + resource allocation；
  • EP placement 是 load balance + routing + collective communication；
  • memory tiering 是 hierarchy + locality optimization。

系统研究的典型循环是：

真实 workload
  ↓
观察瓶颈
  ↓
抽象 cost model
  ↓
提出 mechanism / architecture
  ↓
实现
  ↓
benchmark
  ↓
修正 abstraction

因此不能简单说“理论 70%、工程 30%”或反过来。更关键的是能否完成 现象 → 模型 → 机制 → 实现 → 实验证据 的闭环。

历史类比

数据库早期

关系模型、query optimizer、B+ Tree、transaction、MVCC、buffer manager 等逐步形成后，后续几十年的系统都建立在这些 abstraction 上。

2005–2015 分布式与云

MapReduce、GFS、Bigtable、Hadoop、Spark、Docker、Kubernetes 等大量系统同时出现，早期看似碎片化，后续逐步收敛成 distributed storage、batch/stream computing、container orchestration 等稳定概念。

2010 年代 GPU / Deep Learning Systems

CUDA、cuDNN、NCCL、TensorFlow、PyTorch、TensorRT 等共同塑造了今天的 GPU AI stack。长期受益最大的不是只会某个 API 的人，而是理解 hardware–runtime–compiler–algorithm 关系的人。

职业窗口

早期系统领域的特点是：上限高，方差也高。

成熟领域中，新人通常学习已经确定的 abstraction；年轻领域则仍有机会参与定义 abstraction。这类机会能形成 architect、maintainer、technical lead 所需的能力。

但风险也很清楚：如果只学习 vendor-specific workaround、某个版本配置或某个暂时流行的项目，知识可能快速贬值。

更稳健的策略是投资系统不变量：

compute
memory
communication
scheduling
parallelism
locality
latency / throughput
queueing
fault tolerance

职业策略：投资 Invariant，而不是 Implementation

遇到 Ascend/HCCL 问题，不只记 API，而要追问：

  • 为什么 MoE 会产生 All-to-All？
  • communication complexity 与 topology 如何关联？
  • NCCL/HCCL 的实现差异来自硬件，还是算法？

遇到 KV Pool，不只记配置，而要追问：

  • state ownership 是什么？
  • placement、eviction、transfer、reuse 的通用问题是什么？

这样即使未来从 Ascend 切 CUDA、从 vLLM 切 SGLang、从 Mooncake 切其他实现，知识仍有效。

与已有笔记的联系

一个更稳健的三年目标

不是“记住所有 2026 年技术名词”，而是做到：

看到新的 DCP、AFD、KV Pool、Wide EP、Hybrid State 等机制时，能够迅速判断它重新切分的是 compute、memory、communication、scheduling 中的哪一个边界，以及它付出的 locality / synchronization / communication 成本是什么。