播客：使用llm-d、Wasm和TornadoVM在Kubernetes上进行分布式LLM推理
文字记录
Olimpiu Pop：大家好，我是 InfoQ 编辑 Olimpiu Pop，今天坐在我面前的是 Edoardo Vacchi，他是通常谈论“盒子里套盒子”的两个意大利人之一。另一个是 Andrea Peruffo。Edoardo 曾在 WebAssembly 生态工作很长时间，也探索过其他类型的 VM，如今他回到 Red Hat，正努力让 Kubernetes 和推理相关的事情变得更容易。对吗？
Edoardo Vacchi：是的。我的意思是，在我团队里。有几个人在做这件事，我只是其中之一，但这个描述很准确。我们具体在做 Kubernetes 上的分布式推理，项目叫 llm-d，它是 vLLM 项目家族的一部分。所以，是的，能回到 Red Hat 做最前沿的工作非常令人兴奋。
后端 WebAssembly 的现状 [01:35]
Olimpiu Pop：听起来不错。但在进入正题之前——因为那是你当前工作的核心——请告诉我们 WebAssembly 领域目前发生了什么。我这么问是因为，除了做 WebAssembly 的 Java 侧工作，如果我没记错，你还接触过 Wazero。
Edoardo Vacchi：没错。
Olimpiu Pop：所以，也许简单回顾一下。我知道 WebAssembly 领域发展很快，能否简短总结一下它现在处于什么阶段、发生了什么变化，以及接下来一段时间可以期待什么。
Edoardo Vacchi：好。为了听众们，我不知道大家对此有多熟悉，但你们会知道 Wasm 最初是为网页浏览器而生的；不过最近——现在说“最近”其实已经是指几年前了——人们也开始有兴趣在浏览器之外运行它，尤其是后端。也就是在 Wasm 上运行软件。从这个意义上说，它在精神上可以看作与 JVM 类似的东西。所以我猜，我们中一些原本做 JVM 的人也会对做 Wasm 感兴趣。
所以，Wasm 在某些方面变化很快，在某些方面演进迅速，在另一些方面则进展缓慢。围绕组件模型有很多讨论，这是围绕 WebAssembly 构建的新模块化体系。我会说，如今很多开发可能都发生在这里。但我想说，过去几年里后端 WebAssembly 的格局已经发生了很大变化。我认为我们整个开发生态都变了，所以事情发生了一些转变。我认为它今天非常有意义、非常相关，甚至可能比当初热度更高时还要相关，因为它和沙箱化有很大关系。你知道，沙箱化如今正风靡一时。
Olimpiu Pop：WebAssembly 的一个很好的得分点是，今年早些时候我和本地优先社区聊过。有趣的是，他们提到他们构建的一个库——名字我一下想不起来了——但他们的意思是，与其考虑用不同编程语言分别提供实现，不如直接用 Rust 构建，这样就可以把它编译成 WebAssembly，再通过 WebAssembly 供不同编程语言使用。这是他们觉得很好的地方，他们对结果相当满意。我认为 WebAssembly 的力量就在这里。或者我记得前一年我和几个以前做基础设施的人聊过，他们谈到了 Firecracker。有意思的是，他们说服务器机架里的硬件往往处于空闲状态。所以，他们在那些空闲资源之上放了非常小的 WebAssembly 机器……嗯，我觉得“容器”这个说法更合适。它们做一些非常小、但对其他人很有用的事情。所以，我觉得人们正在各种不同场景中使用 WebAssembly。
Edoardo Vacchi：是的。我认为与你刚才说的相关的一个有趣方面是，甚至可以以某种方式迁移工作负载：比如先在浏览器里运行东西，然后你又有这些 WebAssembly 运行时，它们可以在设备上、或者更广泛地在浏览器之外运行；同一个工作负载既能在浏览器里运行，我们也有演示，展示东西可以从浏览器迁移——甚至是实时迁移——到终端用户设备而不中断。这真的很吸引人。而且我认为，如今我们谈论智能体工作负载时，那是一个有趣的空间。我认为 Wasm 在那里仍然相关。我的意思是，Wasm 仍然相关，尤其是浏览器相关工作以及许多其他工作；但对开发者来说，如今变化很大的这些场景，正是能真正发光的用例。
Olimpiu Pop：是的。正如你提到的，隔离很重要，而且如今越来越重要。所以我觉得这很有用。有一件事困扰我至少一周了，可能下周我会试试，看看你怎么说：我想在浏览器的 WebAssembly 里运行一个小语言模型，这可行吗？还是不可行？
Edoardo Vacchi：可行，我的意思是这是可行的，有这样的例子。问题是，我已经被问过这个问题好几次了，所以简短回答是：视情况而定。
Olimpiu Pop：完美。
Edoardo Vacchi：WebAssembly 首先是为在 CPU 上运行而设计的。众所周知，我们可以在 CPU 上做推理，但通常 GPU 会好得多。对于 LLM 的工作方式，现代 LLM 的架构就是为高度并行的架构设计的，它们就是要在高度并行的架构上运行。CPU 是并行的，但没有 GPU 那么并行。所以长话短说，较小的模型——比如那些适合在浏览器里运行的模型——确实适合在 WebAssembly 中运行；而大得多的工作负载……嗯，一般来说，我们可能还是希望它们在 GPU 上运行。不过，我知道有一些实验在把 WebAssembly 转译成 GPU 内核。所以，是的，有可能。但简短版本是：对于那些在 CPU 上运行有意义的工作负载，也就是相对较小的语言模型，可以使用 Wasm，而且已经存在很多这类工作负载的版本。我想 Hugging Face 上一些最小的模型可以在你的浏览器里运行。还有几个例子，在 Wasm I/O 大会上，有不少演讲展示了这一点，尤其是在浏览器里运行这些工作负载来做推理。所以，是的，它确实可行，但这取决于你的工作负载。
TornadoVM：将 Java 代码转译为 GPU 内核 [08:26]
Olimpiu Pop：是的。好吧，我还是会说，这很简单，更多只是试一试，看看事情如何发展，并祈祷真能做出点什么，而不只是冒烟。但为了工作，也为了巩固我所说的“专家就是把盒子放进盒子里”这一点，你写过一些文章，我想是去年或前年，关于 TornadoVM。我知道你只是稍微接触过它，所以也许可以简短总结一下 TornadoVM 是什么，以及我们什么时候该用它？
Edoardo Vacchi：好。TornadoVM 可以说是 JVM 的一个变体，或者一个附加组件、JVM 插件，取决于你怎么看。TornadoVM 允许你基本上在 GPU 上运行 Java 代码。这是底线、卖点，也是非常简短的版本。情况比这更微妙一些。但是的，基本上可以——说到盒子里套盒子，是的。它之所以叫 VM，是因为它允许你在运行过程中转译 Java 代码，并即时编译成 GPU 特定的内核。比如 NVIDIA 的 PTX、SPIR-V 等等。它为你处理这种转译。所以，你基本上可以写 Java 代码，然后它会为 GPU 后端转译。你写的代码是 Java 代码，但必须以特定方式写。你可能需要使用 TornadoVM 提供的一些库。你不能基本上运行任何代码……你无法在 TornadoVM 上运行 Spring。我的意思是，可以运行，但它会以 Java 模式运行；你不会让 Spring 跑在 GPU 上，这就是重点。但是的，你可以用 Java 写 GPU 内核，这就是它的美妙之处。你提到的那篇博客文章，我想是去年的，我带着读者走一遍……代码中的一个例子，我想有一个写简单内核并在 GPU 上运行的例子，这是我们在博客里展示的一件事。但之后我们运行 GPU Llama 3，这是 Llama 3 模型在 GPU 上运行的一个实现，而且这个实现完全用 Java 写成。所以这很吸引人。博客文章会带你了解它如何工作。在最近的 DevOps Belgium 大会上，如果大家想补一下，他们做过演示；我确定有一个关于 TornadoVM 的演讲，也有 GraalVM 团队关于类似项目的演讲，讲的是用 GraalVM 运行 Llama 和其他语言模型，由 GraalVM 替你加速；还有一位前 GraalVM 团队成员出来创办了自己的公司。我想他叫 Alfonso Alfonso，我记得是因为他的昵称是 Alfonso Squared。他创办了自己的公司，基于他最初在 GraalVM 做的一些工作，同样是为了在 GPU 上运行 Java 代码和 LLM。所以，是的，很吸引人。所以，底线是，我开始研究这个的原因是，我喜欢“盒子里套盒子”，喜欢语言和编译器，所以这感觉像是我过去所做事情的自然演进，包括通过编译到 WebAssembly 来学习编译到 GPU。
vLLM 与 llm-d [12:11]
Olimpiu Pop：听起来很有趣，而且如今这确实很有道理。比如，我看到很多大公司直接用 Java 做推理，这完全说得通，正好把闭环合上。今天，你是 Red Hat 团队的一员——又回到 Red Hat——正在做 llm-d。我的理解是，退一步说，如果 vLLM 是确保一切在一个“盒子”里完美运行，那么 llm-d 就是确保当你有 Kubernetes 集群时一切都很高效。这个说法正确吗，还是我理解错了？
Edoardo Vacchi：不，不，在高层次上这是正确的。更具体地说，vLLM 是我们的推理引擎。你可以把它想成语言模型的 JVM。它支持多种语言模型，这里有个有趣的题外话：它是运行 LLM 的平台。有趣的题外话是，你可能会以为这是一个通用的 VM，而 LLM 是加载在它上面的软件。但不幸的是，每个 LLM 架构都略有不同。所以 vLLM 基本上必须包含每个发布出来的 LLM 的实现。所以，人们发布 LLM 时，并不发布运行它们的软件，而是发布权重。因此，像 vLLM 这样的推理引擎，它们做的就是实现软件、内核、组件，真正加载权重，然后真正进行推理。所以，vLLM 是我们运行核心的平台，实际上 vLLM 能够提供服务，它是一台服务器……我的意思是，它是推理引擎，同时也是服务器，暴露端点供你调用以进行推理，而且效率很高。vLLM 最初——我想 vLLM 里的 V 原本代表 virtual，也就是虚拟内存分配。因为它是第一个实现 PagedAttention（分页注意力）的引擎，这基本上是一种受经典系统编程启发的机制，用来对内存、内存页进行分页，但针对的是在 GPU 上分配的内存；这是非常高层面的说法。所以，vLLM 能够做高吞吐量推理。你可以同时发出多个请求，vLLM 会把它们打包，尝试一起服务，并在一次处理中为多个请求同时做推理，这叫做连续批处理。
但这只能带你到某一步。本质上，到了某个点，你机器上有 GPU、有推理引擎，就到此为止。你无法扩展到超过那台机器上的资源。那么，如何进一步扩展？你可以通过拥有更多 vLLM 实例来扩展，对吧？于是你有几个 vLLM 实例，你想用这些 vLLM 实例来服务推理请求。现在你又有另一个问题：如何在 vLLM 实例之间路由请求？如果你在 Kubernetes 上，你会怎么做……如今大多数人都在 Kubernetes 上，它是以高效方式服务平台和服务的标准。所以，你可以扩展 vLLM 实例，拥有几个 vLLM 实例来服务可能的同一个请求……我的意思是，由调度器、由 vLLM 调度器来选择。如果你按传统方式做，让 Kubernetes 的普通路由器在你复制的 vLLM 实例之间挑选，你不一定能获得好的性能。原因是推理的行为不像传统服务、传统 HTTP 服务。基本上，如果你把请求发给某个特定的 vLLM 实例，尤其是你在进行对话、聊天，或者做智能体编程——它基本上仍然是聊天——你和服务器之间、你的智能体和服务器之间会有大量来回交互。你会希望尽可能长时间地粘在同一个 vLLM 实例上。这在某种程度上可能反直觉，因为对于微服务，我们知道不想一遍又一遍地敲同一个服务，否则它会过载。我们想在各副本之间做轮询或随机分配。但问题是，微服务或一般服务通常在某种程度上是无状态的。状态通常存在别处，不是请求的一部分。我的意思是，请求可以由任何实例独立服务。不幸的是，对于 LLM，为了让 LLM 以高效方式进行推理，你会希望尽可能长时间粘在同一个实例上。但同时，你不能永远粘在同一个实例上，因为到了某个点你会达到某个限制。你不是那个 vLLM 实例的唯一用户。你想服务并分发负载到各个 vLLM 实例。所以你必须取得平衡：一方面留在同一个实例上，享受已有的缓存——KV 缓存、前缀缓存——以及那些让你高效推理并降低成本的系统；另一方面，你也不想让同一个实例过度过载。所以你也必须把这一点考虑进去。这不是传统 Kubernetes 调度器的工作。这就是 llm-d 的用武之地。这就是 llm-d 做的事。llm-d 不只是一个路由器或调度器，它实际上是一个项目家族，它们都旨在为你提供一套工具来做分布式推理，这样你就能利用你拥有的所有 GPU，尽可能发挥最大作用，从而获得最佳价值、最高性价比，因为无论你是租还是拥有这些硬件，它们都很昂贵。所以你会希望尽可能 100% 地使用它。这就是我们提供调度器的原因。我们有一些东西即将发布。我的意思是，在开源生态里，它已经发布了；我们也将把它作为 Red Hat 产品的一部分发布。这叫做批处理推理。批处理推理是指即使集群有负载时也能利用集群。因此，当集群未被充分利用时，你可以调度请求在后台做批处理，因为基本上这些硬件太贵了，你会希望它一直保持 100% 利用。所以，即使没有实时推理在进行，你也可以在你睡觉、实时工作较少的时候调度批处理运行。这就是 llm-d 做的事。它尽可能利用你的硬件，让你花的钱获得最佳价值，而且是在你自己的硬件上做，这样你就能在不把数据泄露给第三方的情况下进行推理，这在如今很重要。
Olimpiu Pop：所以，你的意思是，我们将能够使用之前的 Kubernetes 集群。也就是云原生时代留下来的东西——因为如今一切都是“原生”——并确保我们可以重建它，为 AI 原生时代也构建我们的隐私。
Edoardo Vacchi：是的。它让你能够做云原生推理，并以这样的方式演进你的基础设施：你可以像 AI 之前做云原生开发那样，在本地进行 AI。
Olimpiu Pop：嗯，这一直是个问题，但现在感觉我们在云原生里讨论时，大多数时候谈的是无状态。每当你调用某个东西时，并不总是按同一个门铃，因为那是一个问题。另一个问题在 Kubernetes 领域，是 I/O 部分，尤其是持久化数据，比如数据库之类。每当你和基础设施的人聊，他们会告诉你：“嗯，除了数据库，我们可以在 Kubernetes 里拥有所有东西，因为数据库这些东西会变得更复杂。”但我们一个一个来。你如何在一个像 Kubernetes 这样的无状态生态里——它在 Bing 里用得很多——处理理论上应该有状态的东西？因为如果我有一段对话，我想继续聊，比如我不知道，我跟 Gemini 或 Claude 或 OpenGPT 之类说的什么傻话，我不希望我的回复变成 Edoardo 对他的 LLM 说的内容的延续。
Edoardo Vacchi：是的，这肯定是个复杂问题。正如我说的，故事的一部分是……我的意思是，如果听众了解 LLM 通常如何工作，那么本质上，LLM 的有状态性在某种程度上是假的，因为它们实际上是无状态的。它们做推理的方式是，我们每次都把整段对话历史发给它们。所以，也许我直接跳到——
Olimpiu Pop：跳到结论了。
Edoardo Vacchi：是的，刚才直接跳到结论了。我讲了很多前缀缓存和 KV 缓存，但是的。本质上，LLM 的工作方式是，你总是把整段对话发给 LLM。真正发生的是，LLM 补全这段对话。我不知道大家是否记得几年前 OpenAI 和 GPT Lab playground 是怎么工作的。基本上就是补全 API。你写一句话，然后 LLM 写它的续写。很酷的是，有人发现，如果你把提示词写成对话，带引号的对话，“用户说哒哒哒，计算机说……”，LLM 就会继续这段对话。ChatGPT 基本上就是这样诞生的。人们注意到了这一点，注意到了这个模式。现在，LLM 正用这种模式训练，但这基本上就是它最初的工作方式。所以，如果你这样想，每一段对话其实都是一个很长的提示词，用来续写那段对话。LLM 的工作方式是，你发送对话历史，然后它继续给出下一个回答，你收到回答，然后你继续你的回答，如此往复。如果你在用 LLM，你会知道这些东西的定价，取决于你是按 token 付费还是订阅……嗯，如果你用订阅，那其实不太重要。但如果你按 token 定价，你会知道缓存响应和普通响应之间是有区别的。原因是，如果你没有命中缓存响应，那么你是在把整段对话历史发给 LLM。LLM 的缓存里没有那段对话，所以它必须对整个提示词做推理，这就是为什么那样会特别贵。但如果你来回交互了一段时间，没有长时间停顿，而且服务器上的缓存没有被驱逐，那么你一直在复用已存储的缓存状态来继续对话。这并不一定意味着你没有把整段历史发给 LLM；它只是意味着，即使你在发送整段历史，这段历史也被识别为某个缓存前缀的一部分，因此 LLM 可以只计算续写部分，而不是整个提示词。所以我们有这些缓存机制，基本上，如果缓存存在，LLM 可以只推理继续对话的最后几个 token，而不必从提示词重新计算整个状态。llm-d 为你做这件事。它同时维护 KV 缓存形式和前缀缓存形式。关于 KV 缓存如何工作，我们另说。这两种缓存机制都允许你在对话的多次交互之间持久化状态；这里的持久化是指存在易失性内存中，因为这些是缓存……通常它们不会长时间持久化。这也是为什么你通常想粘在同一个 vLLM 实例上，尽管 llm-d 也提供了在实例之间移动的方法。内容很多，我们没法解释所有细节。但总的来说，llm-d 允许你做到这一点，让你高效利用硬件，即使是有状态对话也能如此。
Olimpiu Pop：好。所以，如果我没记错，llm-d 也捐赠给了 CNCF 基金会，对吗？
Edoardo Vacchi：是的。它几天前刚达到 1.0。是的。
Olimpiu Pop：好，恭喜。所以我们来得正是时候。它处于什么状态？已经生产可用了吗？我们应该等它吗？
Edoardo Vacchi：哦不，它绝对已经生产可用，已经有不少公司在用了。在 Red Hat，我们实际上在很多事情上与 NVIDIA 是合作伙伴。我们已经有大量成功案例，人们在生产中使用它。是的，你绝对应该看看它。事实上，有时候我去参加会议，发现人们已经在用它了，或者也许他们在自己的基础设施上使用 vLLM，却不知道 llm-d。所以，vLLM 允许你以非常高性能、高质量的方式做推理，达到一定程度；而 llm-d 和 vLLM 项目在某种程度上是姊妹项目。我的意思是，整个栈之间有很多交流，所以我们在某种程度上属于同一个团队。但是的，llm-d 给你那份额外的优势。例如，vLLM 不做自动流控；即使你只运行一个 vLLM 实例，llm-d 也能让你控制 HTTP 请求的服务质量和优先级。所以，至少到几天前，我不知道最近是否有变化，这是 vLLM 做不到的事情。因此，即使你不一定运行在高度分布式的环境中，你也能从 llm-d 受益。
Olimpiu Pop：那意味着什么？即使没有集群，也使用 llm-d？
Edoardo Vacchi：即使你没有很多 GPU，即使你不需要把负载分布到不同 GPU 上，llm-d 仍然可能有用。而且，是的，你也可以在裸金属上运行它。所以，即使你不使用 Kubernetes，也可能想评估一下 llm-d。我的意思是，Kubernetes 是首要目标，但也支持裸金属。
Olimpiu Pop：好。所以它专注于推理，即使你还没有现成的基础设施。它只是试图提供对资源的最佳利用，不管你是否已有基础设施。看起来，我们录制时是 10 月底，而 llm-d 似乎是在 2024 年 10 月底启动的。
Edoardo Vacchi：是的。
Olimpiu Pop：所以，在这个时期推出第一个大版本是个好时机。恭喜。
Edoardo Vacchi：是的。
AI 集群中的可观测性与硬件异构性 [29:34]
Olimpiu Pop：不过，还是留在 Kubernetes 领域：人们偏好使用他们已经熟悉的东西，原因之一在于，与其他曾经出现的方案相比，Kubernetes 并不算很老，但它仍然是云原生领域最成熟的方案之一。而如今非常重要的一件事——或者说它一直很重要，但现在比以往更重要——就是可观测性。当我们讨论 llm-d 时，从可观测性的角度应该期待什么？我的意思是，正如你提到的，与 LLM 相关的一切都比其他东西更复杂，我们如何通过已有的可观测性方案让这种复杂性更容易消化？
Edoardo Vacchi：是的，这取决于情况。这是一个很宽泛的问题。llm-d 实际工作方式是，它利用大量基于指标的信号。vLLM 暴露了很多洞察、指标和数据，基本上解释了推理引擎内部发生了什么。llm-d 利用这些信息来做我前面解释的事情，也就是为跨实例路由提供依据。这意味着，本质上，当你使用 llm-d 和 vLLM 时，你不仅得到一个高效推理系统，还可以说免费得到一个丰富的系统，用来洞察不仅集群中、而且推理引擎中正在发生什么。你可以看到正在产生多少 token、遇到多少失败、吞吐量是多少；你可以在可能需要干预的情况下收到告警。例如，你可以控制集群的饱和度；饱和意味着请求太多，你难以服务。到那时，你可以增加机器，也可以对传入请求限流。所以你有许多可以调节的旋钮。llm-d 的可观测性故事也相当有趣，你拥有所有工具，可以从 GPU 和推理的角度洞察集群中正在发生什么。
Olimpiu Pop：嗯，你已经提到把它做对很复杂，但最难的是什么？
Edoardo Vacchi：啊。
Olimpiu Pop：所有东西。
Edoardo Vacchi：这是个有趣的问题。是的，所有东西。这个生态里有趣的一点是，一切都非常新。我会说，有挑战的事情之一——也许不是最难的——是，NVIDIA 可能是最大、最重要的厂商，但还有 AMD、Intel、Google 的 GPU，还有更多。还有很多初创公司在构建自己的硬件。对于 PC，我们长期受益于标准化的硬件组件和定义良好的指令集；而对于这些加速器和 GPU，语言/指令集差异很大。所以，vLLM 本身以及一般推理面临的挑战之一——也是为什么我们需要在其之上加一层框架——是你不能写一次 GPU 计算内核就面向所有加速器，因为一切都不一样。这就像同时有 Intel、ARM、RISC-V、Power PC，你必须根据厂商使用它们，并且必须支持所有这些。我的意思是，在我们的情况里，你想尽可能支持更多。所以这可能是这里最具挑战性的事情之一。从硬件角度看，另一个可能很有挑战的事情是需要传输大量数据。LLM 是大语言模型，我们听说数万亿参数权重，这会转化为 GB、TB、PB 级的数据。这些数据必须在机器之间移动。你不仅要有昂贵的 GPU，还必须在 GPU 之间建立昂贵的连接。我们说的是 RDMA。所以，你必须用非常昂贵的连接方式来连接这些硬件，才能实现非常快的数据传输。所以我会说，总的来说，从另一个角度看，这些都是非常有挑战的事情。同时，这也让这个领域非常迷人和有趣。
本地部署 AI 与面向合适规模模型的语义路由 [34:35]
Olimpiu Pop：是的，那是肯定的。但你提到，当我们讨论 GPU 时，可能性范围很广；GPU 本来是为别的用途设计的，但现在人们像往常一样，把它改造并用于不同视角。但现在我们可以看到，有些公司开始构建自己的硬件，我们在讨论 DPU。这会如何改变格局？
Edoardo Vacchi：是的，这是个有趣的问题。我不知道。希望它能让东西更可负担。我的意思是，竞争总是好事。一方面，这给在这些东西之上构建基础设施和软件的人带来挑战，也给想采购这些硬件的人带来挑战，因为硬件仍然非常昂贵。但同时，如果有更多竞争，希望价格最终会下降。我认为有一件非常重要的事，这也是我们想通过 llm-d、vLLM 传达的信息：我们正走到这样一个点，首先，你并不真的需要极其昂贵的硬件，才能把推理做到某种质量水平。显然，前沿模型总是会比旧模型更有能力，但开放模型越来越好，甚至一些相对较小、能在消费级硬件上运行的模型也是如此。我自己有一台相对强劲的 Mac，48GB 内存；这是公司配的 Mac，所以不是我付的钱，而且大概是在涨价前买的，所以时机不错。但这是相对较小的共享内存，因为它由 CPU 和 GPU 共享，这就是关键。我可以运行 27B，我想是 270 亿参数。这不算巨大，但相当有能力。最近人们在谈论 Qwen 3.8-27B，它在我的笔记本上跑得不是很好，但它仍然能在笔记本上运行，虽然不算特别快。所以，如果你有一台只比我的笔记本稍大一点的服务器，你就能以非常高效的方式服务大量请求。这个模型被拿来与 Opus 4.6 比较。而 Opus 4.6 才发布一年。去年我们还对 Opus 4.6 超级兴奋、印象深刻。所以，不要被社交媒体上那些公告冲昏头脑，说这些模型都超级强、旧模型不再有用了。旧模型仍然有用，而且如果你能在自己的硬件上运行它们，它们甚至更有用，因为这一点很重要：你不必把数据分享给一家你终究不知道是否真的能信任的公司。我认为这就是我们想传达的信息。你可以拥有你自己的 AI，你可以在如今相对……这里的关键词是“相对”？
Edoardo Vacchi：是的，相对可负担。这对公司尤其如此。我不是在说消费者，对消费者某种程度上也是如此，但对公司来说非常真实。他们可以采购这类硬件，为这些模型做推理；这些模型不如前沿模型那么大，但绝对相当不错，已经能解决很多有趣的问题。
Olimpiu Pop：是的。我认为重要的是让人们理解：我们是否真的所有事情都需要前沿模型。
Edoardo Vacchi：正是。
Olimpiu Pop：因为最终，正如你提到的，甚至能在笔记本上运行它们，这正变得触手可及。
Edoardo Vacchi：是的。
Olimpiu Pop：我提到的是相当基础的事情。比如点餐，我不知道，诸如此类。然后你其实不需要别的，只需要人类理解层面的细节。这样一个小模型就足够了，但场景很窄。这就是问题所在：是的，我们确实需要一种做这些事的视角，我们也需要，我不知道，Argon、Opus 以及其他所有前沿模型；但现在很多人在做实验。到了进入生产阶段时，你必须做精炼，必须做效率优化，然后一定要落在正确的位置上。我甚至在边缘侧也看到了类似情况：他们有非常定制的模型，只专注于非常薄、非常窄的用例，仅此而已。但现在我们很多人都在探索，却在衡量一些其实并不重要的东西。
Edoardo Vacchi：当然。我认为另一个有趣的方面是——这是我们在 llm-d 中孵化的另一个项目——叫做 llm-d Semantic Classifier。它处理路由，不仅高效，而且把请求路由到“正确”的模型，当然“正确”有某种定义。正确可能是基于成本，也可能是基于主题。所以，这个系统还有一个姊妹项目，叫做 vLLM Semantic Router。如果你感兴趣，llm-d 语义分类器可以说是它的兄弟项目，但目标不同。但目标是一样的。你有一个提示词，有一段正在进行的对话，你想把这段对话路由到正确的模型，这可能意味着规模合适的模型。这正是你刚才说的。所以，有时你有一个非常大的模型，能够回答所有可能的问题，这当然在很多情况下可能有用，但你也必须把成本效率摆上桌面。所以，你可能有在特定领域训练或微调的专用模型，我认为这就是我们应该走的方向，也是下一件事应该所在的地方。因为这真正把 LLM 推理、AI 总体以及智能体相关的东西带给大众；它让你能在自己的硬件上运行这些东西，用可达到的东西、可达到的目标，而不是没人买得起的超贵硬件。
Olimpiu Pop：我认为我们正处于——可以说——LLM 和 AI 对未来意味着什么的青少年时期，因为大家都在炫耀我们的模型有多少马力。但实际上我们堵在高峰时段，马力在不在并不重要。
Edoardo Vacchi：是的。我觉得“青少年时期”是个很好的比喻。
llm-d 路线图 [41:36]
Olimpiu Pop：也许最后聊聊你们的路线图。1.0 版本已经发布，接下来是什么？未来几个月、未来几年，llm-d 的目标是什么？
Edoardo Vacchi：是的，其实我已经提到几个了。llm-d 本身能够运行——因为在这种硬件上，你必须高效使用它——它能够通过跨机器共享来运行非常大的模型、混合专家模型。但我们正在实验并越来越完善的是批处理推理概念，这样你可以更高效地利用硬件，在流量低谷时提供服务、做推理，甚至做计划性推理，而不需要实时交互，从而 100% 复用你拥有的硬件。另一个显然就是我刚提到的语义分类，让你不仅使用正确的机器，还能在正确的时间使用正确的模型。例如，假设你有一个运行成本很高的大模型，还有一些运行更高效、可以在便宜得多的硬件上运行的小模型。根据你正在进行的对话、你发送的提示词，某些情况下你可能想用大模型，某些情况下想用小模型。这些就是我们目前在做的事情，还有更多，我甚至无法全部列出。但这是一个令人兴奋的领域，我认为未来几个月你会看到很多有趣的东西。
Olimpiu Pop：好，感谢你抽出时间。
Edoardo Vacchi：谢谢。
提及：
关于作者
Edoardo Vacchi
Edoardo Vacchi 是一名软件工程师，拥有米兰大学语言设计与实现方向博士学位。他曾在 UniCredit、Red Hat、Tetrate 和 Dylibso 工作，参与过 Drools、Kogito、wazero、Chicory 和 Extism 等项目。他最近回到 Red Hat，成为 AI 工程团队的一员。
显示更多 显示更少
你可以通过我们的 RSS 订阅 持续关注播客，也可以在 SoundCloud、Apple Podcasts、Spotify、Overcast 和 YouTube 上收听。你也可以从这个页面访问我们录制好的节目笔记。它们都有可点击的链接，能直接跳到音频中的对应部分。