LLM Native Primitives: Next Golden PathLLM 原生原语:下一条黄金路径

Hits

“Primitives are the raw parts or the most foundational-level building blocks for software developers. They’re indivisible (if they can be functionally split into two they must) and they do one thing really well. They’re meant to be used together rather than as solutions in and of themselves. And, we’ll build them for maximum developer flexibility. We won’t put a bunch of constraints on primitives to guard against developers hurting themselves. Rather, we’ll optimize for developer freedom and innovation.” - 2003 AWS Vision document




"Transformer" turns 8, Cloud Native Computing Foundation (CNCF) turns 10 (refer post), Kubernetes, Lambda, ECS and Alexa turn 11, Bedrock and Claude turn 2. The shift from CPU-native to LLM/GPU-native applications has begun. What's the next golden path for this era ?


LLMs vs Other Apps

I spent two years working on SOTA LLM inference, both closed-source models (Anthropic) and open-source models (Llama and DeepSeek). More recently, I transitioned concentration on model optimization and inference acceleration. The closer you get to the models themselves, the more you realize how non-trivial it is to run and optimize them effectively.

Red Hat AI's tweets "LLM inference is too slow, too expensive, and too hard to scale." provided an in-depth descriptions of those challenges.

LLMs Apps Workloads Other Apps Workloads
  • Slow
  • Resource-heavy
  • Non-uniform
  • Highly sensitive to latency
  • Short-lived, uniform requests
  • Consistent SLOs
  • Even replica performance
  • No benefit from coordinating across replicas

  • Peter DeSantis had an excellent keynote in re:Invent 2024 that highlighted "AI workloads are Scale up workloads. Larger models demand more compute. Science and algorithmic limitations decide simple scale out doesn't work."

  • Request Variance: LLM requests vary in size and resource use, RAG → long inputs, short outputs, Reasoning → short inputs, long outputs. This unevenness causes overloaded replicas, leading to longer inter-token latency.
  • Decode ≠ Prefill: LLM inference is two workloads, Prefill is compute-bound and Decode is memory-bound. Prefill needs a lot of computing resources to convert input into data structure that gets handed off to the next process. Decode (token generation) is that the model generates each token sequentially one at a time. And this puts a very different set of demands on AI infrastructure. Each time a token is generated, the entire model has to be read from memory, but only a small amount of compute is used. For this reason, token generation puts lots of demand on memory but only a small amount of compute. And for agentic AI scenario, customers care about fast prefill and really fast token generation. Standard deployments run both phases on the same GPU—inefficient. Disaggregated serving become necessary, separating these phases to independently scale and optimize them.
  • Mar 26, 2026 · Cerebras CEO & Founder @andrewdfeldman elaborated on "What is disaggregated inference?" in a tweet.
    Feb 2026 · Amazon published an article, "What is AI inference? The backbone of the AI revolution," that explains this process in a clear, easy-to-understand way.
  • Prompt caching essential. Many workloads are multi-turn (chat agents, tool-use, code completion). Routing to replicas with cached context avoids redundant prefill computation. This improves tail latencies by orders of magnitude when done right.
  • Capacity Scarcity: GPU / accelerators limited. Computing resources are highly limited for every organization, a major difference compared to CPU-native apps, where resource constraints are typically less severe. In this context, Optimized Inference Scheduler (Cache-aware + disaggregation-aware scoring), QoS-aware inference (align latency-sensitive and latency-tolerant workloads to the right infra with better efficiency) and Variant Autoscaling (Traffic + hardware-aware autoscaler) become important. High availability and utilization are essential in the world of LLMs.

  • Last Mile Delivery

    Lately, I’ve seen a flourishing of open-source large model inference frameworks (like llm-d, Dynamo, SGLang..), as well as caching projects such as LMCache, Mooncake, and engines TensorRT, vLLM. Looking back to early 2023, when running a GPU felt like lugging bricks, it’s clear that LLM inference and optimization are now starting to coalesce around some fuzzy but emerging industry-standard paradigms. As someone who’s been hands-on with large model serving for two years, I find this really encouraging.

    Although this area doesn’t have the academic depth or community influence of blogs from respected researchers like Lilian Weng or Shunyu Yao, and it lacks the accessibility and popularity of agent-level applications, it still plays a vital role. It’s hard to classify, it's not the model itself, not the application layer, not infrastructure, and not hardware either. It’s perhaps closest in relationship to MCP vs agents and K8s vs CPU. Sitting between the model and the hardware, you could call this the 'middleware layer.'

    This middleware layer aims to tackle the real bottlenecks that stand in the way of deploying LLMs at scale: “LLM inference is too slow, too expensive, and too hard to scale.”

    These are ‘last mile’ problems, making LLMs run efficiently, reliably, and elastically, and turning model capabilities into real user value. What’s more, nearly every project in this space is choosing open-source collaboration as the path forward, which is incredibly welcoming for those who are passionate about contributing to open-source communities. It feels a lot like the early days of public cloud 10 years ago: from CPU → virtualization → VM → containers → serverless.

    The LLM/GPU-native era has begun.


    Next Golden Path

    At Amazon, there's an internal concept known as 'the golden path', a set of opinionated best practice tooling, architecture, and configuration recommendations for the end-to-end builder experiences, popular options like AWS Lambda and ECS/Fargate. As all CPU-native apps and platforms passed decade, what's the golden path for LLM-native applications?

    Communities appear to have already draw a few lines:

  • Prefill and Decode Disaggregation: Nvidia's recent research publication "Beyond the Buzz: A Pragmatic Take on Inference Disaggregation" offers a detailed explanation and presents practical design principles.
    Mar 16, 2026 · NVIDIA GTC Keynote 2026, NVIDIA Founder and CEO Jensen Huang shared disaggregated inference on Vera Rubin Prefill + Groq Decode.
    Mar 13, 2026 · AWS and Cerebras team up to build new disaggregated inference solution: Trainium Prefill + Cerebras Decode.
  • Prefix / KV (key-value) Cache
  • Context-Aware Routing and AI-Aware Network Routing (LB)
  • QoS-Aware Routing
  • Variant Autoscaling
  • ...


    Figure: Prefill and Decode Phases of the Transformer


    Now the model itself differentiation is shrinking, in the future, this area will become one of key differentiators: how to run models better.

    Rather than picking one or two specific software solutions, while waiting the next K8s timing coming, I prefer to talk about a new working model where Product, Engineering, and Research collaborate more closely than ever before. This kind of integration, unlike anything we've seen in the past, is just beginning to take shape. vLLM is a representative example. And the future remains wide open.


    "原语是软件开发者最原始、最基础层面的构建模块。它们不可再分(如果功能上可以拆成两个,就必须拆开),并且只专注做好一件事。它们的设计初衷是被组合使用,而不是作为独立的解决方案本身。而且,我们会为了最大化开发者的灵活性去构建它们。我们不会给原语加上一大堆限制来防止开发者'伤到自己'。相反,我们会为开发者的自由与创新去做优化。" —— 2003 年 AWS 愿景文档




    "Transformer" 迎来第 8 个生日,云原生计算基金会(CNCF)十周年(参见这篇文章),Kubernetes、Lambda、ECS 和 Alexa 十一周年,Bedrock 与 Claude 两周年。从 CPU 原生到 LLM/GPU 原生应用的转变已经开始。这个时代的下一条"黄金路径"会是什么?


    LLM 应用 vs 其他应用

    我曾花两年时间从事业界最先进(SOTA)的 LLM 推理工作,既涉及闭源模型(Anthropic),也涉及开源模型(Llama 和 DeepSeek)。最近,我把关注点转向了模型优化和推理加速。你越接近模型本身,就越会发现,要有效地运行和优化它们,绝非易事。

    Red Hat AI 的推文"LLM 推理太慢、太贵、太难扩展"对这些挑战做了深入的描述。

    LLM 应用负载 其他应用负载
  • 资源消耗大
  • 不均匀
  • 对延迟高度敏感
  • 短生命周期、均匀请求
  • 一致的 SLO
  • 各副本性能均衡
  • 副本间协调无额外收益

  • Peter DeSantis 在 re:Invent 2024 上的一场精彩主题演讲中强调:"AI 工作负载是纵向扩展(scale up)的工作负载。更大的模型需要更多计算资源。科学与算法上的限制决定了简单的横向扩展(scale out)行不通。"

  • 请求方差:LLM 请求在大小和资源使用上差异很大,RAG 场景 → 长输入、短输出,推理(Reasoning)场景 → 短输入、长输出。这种不均匀性会导致某些副本过载,从而拉长 token 间的生成延迟。
  • 解码(Decode)≠ 预填充(Prefill):LLM 推理实际上是两种工作负载,Prefill 是计算密集型,Decode 是内存密集型。Prefill 需要大量计算资源,将输入转化为传递给下一阶段的数据结构。Decode(token 生成)则是模型逐个、依次生成每一个 token。这对 AI 基础设施提出了截然不同的要求:每生成一个 token,都必须把整个模型从内存中读取一遍,但实际用到的计算量却很小。因此,token 生成对内存的需求很高,对计算的需求却很低。而在智能体 AI 场景下,客户既关心快速的 Prefill,也关心极快的 token 生成速度。标准部署方式让这两个阶段共用同一块 GPU——效率低下。因此,将这两个阶段分离、独立扩展和优化的"分离式服务"(disaggregated serving)变得必要。
  • 2026 年 3 月 26 日 · Cerebras CEO 兼创始人 @andrewdfeldman 在一条推文中详细阐述了"什么是分离式推理?"
    2026 年 2 月 · Amazon 发布了一篇文章《什么是 AI 推理?AI 革命的支柱》,用清晰易懂的方式解释了这一过程。
  • 提示缓存(Prompt caching)至关重要:许多工作负载都是多轮的(聊天智能体、工具调用、代码补全)。将请求路由到已缓存上下文的副本,可以避免重复的 Prefill 计算。做得好的话,能把尾部延迟降低几个数量级。
  • 容量稀缺:GPU / 加速器有限。对每个组织而言,计算资源都极为有限,这与 CPU 原生应用相比是一个重大差异——CPU 原生应用的资源限制通常没这么严重。在这种背景下,优化推理调度器(具备缓存感知 + 分离感知评分能力)、QoS 感知推理(把延迟敏感与延迟容忍的工作负载,更高效地匹配到合适的基础设施上)以及变体自动扩缩容(Variant Autoscaling,兼顾流量与硬件感知的自动扩缩容)都变得重要起来。在 LLM 的世界里,高可用性与高利用率至关重要。

  • 最后一公里的交付

    最近,我看到开源大模型推理框架蓬勃发展(比如 llm-d、Dynamo、SGLang……),以及缓存类项目如 LMCache、Mooncake,还有推理引擎 TensorRT、vLLM。回想 2023 年初,运行一块 GPU 就像搬砖头一样费劲,现在很明显,LLM 推理与优化正开始围绕一些尚不清晰但正在浮现的行业标准范式凝聚起来。作为一个亲手做了两年大模型服务的人,我觉得这非常令人振奋。

    尽管这个领域没有像 Lilian WengShunyu Yao(姚顺雨)这样受人尊敬的研究者的博客那样具有学术深度或社区影响力,也不像智能体层应用那样易于接触和流行,但它依然扮演着至关重要的角色。它很难归类:它不是模型本身,不是应用层,不是基础设施,也不是硬件。它或许最接近于 MCP 相对于智能体、K8s 相对于 CPU 的那种关系。它处于模型与硬件之间,你可以称之为"中间件层"。

    这个中间件层致力于解决大规模部署 LLM 时真正的瓶颈问题:"LLM 推理太慢、太贵、太难扩展。"

    这些都是"最后一公里"的问题:让 LLM 高效、可靠、弹性地运行,并把模型的能力转化为真正的用户价值。更值得一提的是,这个领域里几乎每一个项目都选择了开源协作作为前进的道路,这对那些热衷于为开源社区做贡献的人来说,无疑是极大的欢迎。这感觉很像十年前公有云的早期阶段:从 CPU → 虚拟化 → VM → 容器 → 无服务计算。

    LLM/GPU 原生时代已经开始。


    下一条黄金路径

    在 Amazon 内部,有一个叫做"黄金路径"的概念:一套经过深思熟虑的、面向端到端构建者体验的最佳实践工具、架构和配置建议,比较流行的例子包括 AWS Lambda 和 ECS/Fargate。既然所有 CPU 原生的应用和平台都已走过了十年,那么 LLM 原生应用的黄金路径又会是什么?

    社区似乎已经勾勒出了一些方向:

  • Prefill 与 Decode 分离:Nvidia 最近发表的研究论文 "Beyond the Buzz: A Pragmatic Take on Inference Disaggregation" 对此做了详细阐述,并给出了实用的设计原则。
    2026 年 3 月 16 日 · 在 NVIDIA GTC 2026 主题演讲中,NVIDIA 创始人兼 CEO Jensen Huang(黄仁勋)分享了Vera Rubin Prefill + Groq Decode的分离式推理方案。
    2026 年 3 月 13 日 · AWS 与 Cerebras 联手打造新的分离式推理解决方案:Trainium Prefill + Cerebras Decode
  • 前缀 / KV(键值)缓存
  • 上下文感知路由与 AI 感知网络路由(负载均衡)
  • QoS 感知路由
  • 变体自动扩缩容(Variant Autoscaling)
  • ……


    图:Transformer 的 Prefill 与 Decode 阶段


    如今模型本身的差异正在缩小,未来,"如何更好地运行模型"这件事将成为关键的差异化因素之一。

    与挑选一两个具体的软件方案相比,在等待下一个类似 K8s 时刻到来的同时,我更愿意谈论一种新的协作模式:产品、工程与研究比以往任何时候都更紧密地协作。这种整合方式前所未见,才刚刚开始成形。vLLM 就是一个代表性的例子。而未来,开源精神继续。