生产环境别用Ollama

梯形图转SCL | 博途AI辅助编程文档 | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

您使用Ollama在MacBook上构建了一个出色的自主代理。在终端中，响应很快。推理循环完美运行。但是当您将其推送到暂存环境时，延迟飙升，队列停滞。罪魁祸首不是您的代码；而是Ollama的顺序设计与代理循环所需的大量上下文重用之间的架构不匹配。这就是为什么您用于原型设计的基础设施正在悄悄破坏您的生产代理，以及为什么vLLM和SGLang是唯一可行的升级。

1、本地主机幻觉：为什么您的代理在生产中停滞

如果您今天正在构建AI代理，您可能从Ollama开始。Ollama是单用户本地原型设计的无可争议的王者。它非常易于安装，在Apple Silicon上优雅运行，并抽象了在本地运行大型语言模型的复杂性。对于测试单个对话线程的单个开发者来说，它感觉像魔法。

然而，生产代理工作流的现实与简单的聊天界面完全不同。代理循环不是线性的；它们是周期性和迭代的。它们依赖于大量重叠的上下文。代理持续将动态令牌（例如工具输出、便笺或中间推理步骤）注入其上下文窗口，将整个累积的提示重新提交给模型。

当您从单个开发人员一次发送一个请求过渡到具有并发代理流量的生产环境时，"本地主机幻觉"就会破碎。Ollama依赖隐式FIFO（先进先出）队列来管理请求。在并发负载下，此队列会崩溃。请求开始堆积，并且由于Ollama无法有效地交错或共享这些并发请求的内存状态，系统会逐渐停止。

生产环境中的性能差距是惊人的。在高负载压力测试中，vLLM每秒可以处理大约793个令牌（TPS），而Ollama仅管理41 TPS。业界共识很明确：虽然Ollama在本地原型设计方面表现出色，但缺乏高级前缀缓存和顺序处理使其在重复的多轮代理循环中陷入困境。

2、瓶颈的架构

要理解为什么会发生这种情况，我们需要深入了解请求的处理方式和内存的处理方式。

在其核心，Ollama的架构使用隐式FIFO队列。想象一下杂货店的单个结账通道。每个购物者（请求）必须等待轮到他们。更糟糕的是，如果购物者忘记了一件物品并跑回过道（类似于代理从工具调用注入动态令牌并重新提交其提示），他们必须重新加入队列或在获取物品时使整条线停滞。没有机制来处理多个购物者同时共享其购物车中的相同物品。

在像ReAct这样的多步骤推理框架中，代理反复发送一个庞大的、主要是静态的系统提示，并附加其过去操作的增长历史和刚刚检索到的新动态令牌。理想的基础设施会识别出95%的提示与上一个请求相同，并且只处理新的令牌。

不幸的是，Ollama的隐式缓存很容易被动态令牌注入破坏。当缓存被破坏时，模型被迫从头开始重新计算整个共享提示的键值（KV）缓存。这种重新计算完全是浪费的计算。一遍又一遍地重新计算完全相同的系统指令和早期对话历史的延迟成本，就是导致您的代理响应时间从毫秒膨胀到生产中几分钟的原因。

3、内存作为一等公民：vLLM和PagedAttention

如果我们想要扩展代理，我们必须将内存管理视为一等公民。这就是vLLM作为基线生产标准进入画面的地方。

在LLM推理中，KV缓存存储过去令牌的中间张量状态，以便模型不必重新读取整个提示来生成下一个词。在传统服务系统中，KV缓存内存被分配在连续的块中。由于请求长度不可预测，这会导致严重的KV缓存碎片——就像旧操作系统中的内存碎片一样。您可能有足够的总内存来服务请求，但由于它在GPU上是碎片化的，系统无法利用它，导致队列停滞。

vLLM通过一个名为PagedAttention的突破解决了这个问题。受传统操作系统架构中的虚拟内存和分页启发，PagedAttention支持基于块的非连续KV缓存分配。通过将缓存分解为可管理的"页面"，vLLM实际上消除了碎片，允许系统同时批处理更多请求。

这种内存效率启用了连续批处理。vLLM无需等待一批请求完全完成再接受新请求，而是在迭代级别将新请求注入计算管道。

对于代理循环，vLLM还引入了自动前缀缓存（APC）。启用后，vLLM会自动识别并重用跨不同请求的共享前缀的KV块。

以下是在vLLM中为您的代理循环启用前缀缓存的简单方法：

from vllm import LLM, SamplingParams

# Initialize with APC enabled
llm = LLM(model="meta-llama/Llama-3-8b", enable_prefix_caching=True)
sampling_params = SamplingParams(temperature=0.8, top_p=0.95)

# Notice how the base agent context is perfectly identical
prompts = [
    "[Agent Context: You are a helpful financial assistant...] User: Hi",
    "[Agent Context: You are a helpful financial assistant...] User: Hello"
]

# KV blocks of the shared prefix are cached automatically
outputs = llm.generate(prompts, sampling_params)

通过主动管理内存和连续批处理，vLLM确保您的代理循环不会因等待计算资源而卡住。

4、代理引擎：SGLang和RadixAttention

虽然vLLM为生产设定了基线，但SGLang将架构提升为专门针对复杂的多轮代理工作流进行优化。如果前缀缓存是vLLM中的一个功能，那么它就是SGLang的基础哲学。

为什么前缀缓存是代理的圣杯？因为代理是极其冗余的。系统提示、工具模式和总体任务参数在数十个回合中保持不变。SGLang认识到这一点并引入了RadixAttention。

RadixAttention不是仅仅查找匹配的块，而是将KV缓存视为所有请求的持久共享基数树。此数据结构允许SGLang以结构优雅的方式主动缓存和重用令牌前缀。当新请求到来时，SGLang遍历基数树以找到最长的匹配前缀，并立即重用该计算状态。

性能增益是异常的。当前缀重叠度高时，与非树调度器相比，SGLang实现了20-40%更低的首令牌时间（TTFT）。基础设施工程师广泛认为SGLang是代理的首选引擎，这得益于其对前缀缓存、结构化生成和其执行模型的编程性质的深入关注。

SGLang还带来了对严格结构化JSON生成的原生支持——这对于需要输出健壮、机器可读有效负载的工具密集型代理至关重要。此外，SGLang引入了一个重量缓存守护程序，该程序利用CUDA IPC零拷贝进行快速模型加载，从而实现了惊人的约785倍模型加载时间加速。

5、改变多轮代理的经济学

技术优雅令人满意，但这些架构转变的真正影响体现在单位经济学和业务ROI中。

当您重用代理提示的90%的缓存时，您直接降低了每次代理运行的计算成本。您不再需要向云提供商支付每天数百万次重新读取完全相同的系统指令的费用。

考虑多代理审议系统的部署，其中几个专门的代理相互批评和完善彼此的输出。这些代理在大量共享的上下文中运行——它们查看相同的源文档和相同的聊天历史记录。在RadixAttention系统中，该共享上下文恰好计算一次。多代理系统的吞吐量改进是变革性的，将迟缓、昂贵的架构转变为高度并发、经济高效的工作流。

这同样适用于扩展RAG（检索增强生成）系统。通过在多个用户查询中积极缓存长系统提示和检索到的文档，您的基础设施可以在相同的硬件占用空间上服务指数级更多的用户。这弥合了很酷的原型与有利可图的SaaS部署之间的差距。

6、编排权衡（何时使用什么）

采用这些先进的服务引擎并非没有代价。虽然功能强大，但与Ollama的即插即用本地开发人员体验相比，vLLM和SGLang引入了编排复杂性和基础设施开销。从业人员需要一个平衡的决策框架来选择他们的技术栈。

Ollama：在Apple Silicon和CPU上进行本地原型设计时坚持使用Ollama。如果您是单个开发人员在笔记本电脑上测试代理逻辑、提示工程或工具调用，Ollama提供了无与伦比的无摩擦开发人员体验。当您是唯一用户时，不需要最大吞吐量。

vLLM：这是高吞吐量生产API端点的标准。如果您为具有相对多样化提示的数千个用户提供服务，vLLM的PagedAttention和连续批处理使其成为强大、高度可靠的选择。虽然它具有前缀缓存，但与SGLang的Radix树相比，它有时在大量、复杂上下文重用方面的优化程度较低。

SGLang：这是具有大量共享上下文的复杂推理代理的首选引擎。如果您的架构依赖于多代理审议、大型系统提示或严格的JSON工具使用，SGLang的RadixAttention将提供最佳的单位经济学和最低的延迟。但是，请注意，SGLang对于唯一的、非缓存提示可能具有更高的TTFT开销，因此它在上下文重叠度高时特别出色。

7、结束语

审计您当前的代理部署管道。如果您遇到Ollama的扩展瓶颈，请使用最常见的共享提示对其与vLLM或SGLang进行负载测试。更换您的端点并测量首令牌时间（TTFT）和吞吐量改进。

您在生产中使用什么框架来路由代理流量？请在评论中告诉我您会选择哪个引擎用于您的技术栈以及原因。如果您觉得此架构分析有用，请突出显示您计划在下次部署中引用的部分！

原文链接：Stop Using Ollama in Production: Why vLLM & SGLang Win

汇智网翻译整理，转载请标明出处