LLM Native Primitives: Next Golden PathLLM 原生原语:下一条黄金路径
“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 |
|---|---|
|
|
|
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."
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:
...
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 应用负载 | 其他应用负载 |
|---|---|
|
|
|
Peter DeSantis 在 re:Invent 2024 上的一场精彩主题演讲中强调:"AI 工作负载是纵向扩展(scale up)的工作负载。更大的模型需要更多计算资源。科学与算法上的限制决定了简单的横向扩展(scale out)行不通。"
最后一公里的交付
最近,我看到开源大模型推理框架蓬勃发展(比如 llm-d、Dynamo、SGLang……),以及缓存类项目如 LMCache、Mooncake,还有推理引擎 TensorRT、vLLM。回想 2023 年初,运行一块 GPU 就像搬砖头一样费劲,现在很明显,LLM 推理与优化正开始围绕一些尚不清晰但正在浮现的行业标准范式凝聚起来。作为一个亲手做了两年大模型服务的人,我觉得这非常令人振奋。
尽管这个领域没有像 Lilian Weng 或 Shunyu Yao(姚顺雨)这样受人尊敬的研究者的博客那样具有学术深度或社区影响力,也不像智能体层应用那样易于接触和流行,但它依然扮演着至关重要的角色。它很难归类:它不是模型本身,不是应用层,不是基础设施,也不是硬件。它或许最接近于 MCP 相对于智能体、K8s 相对于 CPU 的那种关系。它处于模型与硬件之间,你可以称之为"中间件层"。
这个中间件层致力于解决大规模部署 LLM 时真正的瓶颈问题:"LLM 推理太慢、太贵、太难扩展。"
这些都是"最后一公里"的问题:让 LLM 高效、可靠、弹性地运行,并把模型的能力转化为真正的用户价值。更值得一提的是,这个领域里几乎每一个项目都选择了开源协作作为前进的道路,这对那些热衷于为开源社区做贡献的人来说,无疑是极大的欢迎。这感觉很像十年前公有云的早期阶段:从 CPU → 虚拟化 → VM → 容器 → 无服务计算。
LLM/GPU 原生时代已经开始。
下一条黄金路径
在 Amazon 内部,有一个叫做"黄金路径"的概念:一套经过深思熟虑的、面向端到端构建者体验的最佳实践工具、架构和配置建议,比较流行的例子包括 AWS Lambda 和 ECS/Fargate。既然所有 CPU 原生的应用和平台都已走过了十年,那么 LLM 原生应用的黄金路径又会是什么?
社区似乎已经勾勒出了一些方向:
……
图:Transformer 的 Prefill 与 Decode 阶段
如今模型本身的差异正在缩小,未来,"如何更好地运行模型"这件事将成为关键的差异化因素之一。
与挑选一两个具体的软件方案相比,在等待下一个类似 K8s 时刻到来的同时,我更愿意谈论一种新的协作模式:产品、工程与研究比以往任何时候都更紧密地协作。这种整合方式前所未见,才刚刚开始成形。vLLM 就是一个代表性的例子。而未来,开源精神继续。