AI智能体可以将单个用户请求转化为多次大语言模型调用，这使得推理成为性能瓶颈。

在本教程中，Darsh将讲解vLLM如何更高效地处理这些工作负载。

你将了解大语言模型推理的工作原理，以及vLLM如何运用连续批处理、PagedAttention和前缀缓存等技术。

https://freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/…

如何使用vLLM扩展AI智能体的大语言模型推理

来源：https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/ 如何使用vLLM扩展AI智能体的大语言模型推理。在本教程中，我将向你展示如何使用vLLM扩展AI智能体的大语言模型推理。我将帮助你理解大语言模型推理的工作原理，探讨为何智能体工作负载会给GPU调度和内存带来压力，并分析vLLM如何设计以提升吞吐量。

接着，我们将运行一个本地vLLM服务器，并通过其OpenAI兼容API，使用一个AI智能体连接到它。

目录

• 背景 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-background)
• 前提条件 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-prerequisites)
• 什么是大语言模型推理？ (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-what-is-llm-inference)
• 大语言模型推理如何使用CPU和GPU (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-how-llm-inference-uses-the-cpu-and-gpu)
• 为何AI智能体工作负载难以服务 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-why-ai-agent-workloads-are-hard-to-serve)
• vLLM如何服务智能体工作负载 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-how-vllm-serves-agent-workloads)
• 动机与架构 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-motivation-and-architecture)
• 步骤1：安装vLLM (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-step-1-install-vllm)
• 步骤2：启动vLLM服务器 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-step-2-start-the-vllm-server)
• 步骤3：将你的AI智能体连接到vLLM (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-step-3-connect-your-ai-agent-to-vllm)
• 步骤4：运行智能体 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-step-4-run-the-agent)
• 示例输出 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-sample-output)
• 为何KV缓存、PagedAttention、连续批处理和前缀缓存很重要 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-why-kv-caching-pagedattention-continuous-batching-and-prefix-caching-matter)
• 何时应使用vLLM？ (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-when-should-you-use-vllm)
• 结论 (https://www.freecodecamp.org/news/how-to-scale-llm-inference-for-ai-agents-using-vllm/#heading-conclusion)

背景

一个简单的AI智能体在只有一个用户、一个请求和一个模型响应的情况下通常运行良好。但生产环境则大不相同。

想象一下，数百个用户同时发送提示词。而单个用户请求很容易转变为10到30次独立的大语言模型调用，用于规划、工具选择、摘要、重试和最终响应生成。在几十或几百个用户中进行这样的计算，推理层会迅速成为瓶颈。

前提条件

要学习本教程，你应该熟悉基本的Python和终端命令。你还应该安装Python、一个包管理器（如pip或uv）以及一个代码编辑器。

对大语言模型提示和API客户端有一定了解会有帮助，但不需要具备AI智能体、vLLM或推理优化方面的先验经验。要了解更多关于AI智能体的信息，你可以阅读这篇文章（https://www.freecodecamp.org/news/how-to-build-yourown-local-ai-agent-with-tool-calling-and-memory/）。

本教程使用vLLM-Metal，以便示例可以在Apple Silicon上本地运行。本教程适用于macOS、Windows和Linux。我使用的是配备32 GB内存且没有外部GPU的MacBook Pro，但通过使用更小的预训练模型，该工作流也可以在配置更有限的硬件上运行。

什么是大语言模型推理？

推理是使用训练好的模型根据输入生成输出的过程。对于大语言模型而言，这意味着处理提示词并逐个token预测输出。

推理不同于训练。在训练期间，模型通过调整其权重进行学习。在推理期间，这些权重保持固定，模型利用已学到的知识生成响应。

虽然模型不再学习，但推理仍然可能很昂贵。更大的模型需要更多的内存和计算，更长的提示词需要更多的处理工作，更长的响应则需要更多的生成步骤。当许多用户并发提交请求时，推理层可能迅速成为性能瓶颈。

大语言模型推理如何使用CPU和GPU

模型服务系统有两个主要职责：协调请求和执行模型。

在主机端，服务系统接收请求、对提示词进行分词、跟踪请求状态，并决定在每个执行步骤中应包含哪些请求。在加速器端（通常是GPU），模型执行处理提示词和生成token所需的张量运算。

大语言模型推理主要包括两个阶段：预填充（prefill）和解码（decode）。

在预填充阶段，模型处理输入提示词中的所有token。由于许多提示词token可以并行处理，预填充阶段往往是计算密集型的。因此，包含对话历史、检索文档或工具指令的长提示词会增加第一个输出token出现之前的等待时间。

在解码阶段，模型逐个token生成输出。每个新token都依赖于其前面的token，这使得解码步骤的生成是顺序进行的。因此，长响应需要许多独立的模型执行步骤。

简而言之：

• 长输入使得预填充阶段成本更高。
• 长输出使得解码阶段成本更高。
• 更多的并发请求增加了调度和内存压力。

GPU受限于计算能力和内存容量。它必须容纳模型权重、临时执行数据以及与活动请求相关的状态。

最重要的请求状态之一是KV缓存（KV cache）。在注意力机制期间，模型会为之前处理过的token创建键（key）和值（value）表示。存储这些表示允许模型在后续生成token时重用它们，而不是在每个解码步骤中重新计算整个序列。

KV缓存使自回归生成变得可行，但它也消耗内存。随着提示词和生成响应的增长，每个活动请求需要更多的KV缓存空间。这意味着可用的KV缓存内存会直接影响服务器可以并发处理的请求数量。

为何AI智能体工作负载难以服务

AI智能体会放大这些推理挑战，因为一个用户请求可能触发多次模型调用。

智能体可能调用模型来规划其下一步行动、选择工具、解释工具结果、总结检索到的信息、从错误中恢复、决定是否需要更多工作或生成最终响应。

单个用户交互可能变成10、20甚至更多的推理请求。当几十或几百个用户活跃时，模型调用次数会迅速增长。

智能体请求也是不均匀的。一个请求可能包含一个简短的问题，而另一个则包含一个很长的系统提示、对话历史、检索文档和几个工具结果。它们的生成响应长度也可能差异显著。

这创造了一种动态工作负载，请求在不同时间到达、消耗不同数量的内存，并在不同时间完成。要高效地服务这些请求，不仅仅是将模型加载到GPU上。服务层必须持续调度工作、管理内存，并防止短请求被不必要的长请求延迟。

vLLM如何服务智能体工作负载

vLLM（https://docs.vllm.ai/）是一个专为大语言模型设计的开源推理运行时和服务引擎。它提供一个OpenAI兼容的API，同时管理模型执行、请求调度、批处理和KV缓存内存。

应用程序不再直接加载模型并调用诸如model.generate()之类的方法，而是向vLLM服务器发送HTTP请求。这将应用程序或智能体逻辑与其底层的推理基础设施分离。

当多个请求处于活动状态时，vLLM将它们一起调度，而不是通过一个孤立的模型循环处理每个请求。这使得服务层可以更有效地使用可用的加速器。

vLLM的几个特性对智能体工作负载尤为重要：

• 连续批处理（Continuous batching） 在请求到达和完成时更新活动批次。当一个请求完成时，另一个请求可以在后续执行步骤中接替它的位置，而无需等待原始批次中的每个请求都完成。
• PagedAttention 使用固定大小的块来管理KV缓存内存，而不是要求每个请求占据一大块连续区域。这减少了内存碎片，并使释放的缓存块更容易重用。
• 自动前缀缓存（Automatic prefix caching） 允许具有匹配提示词前缀的请求重用现有的KV缓存块。当智能体请求共享相同的系统提示、工具定义、对话历史或检索文档时，这非常有价值。
• OpenAI兼容API 允许现有应用程序和智能体框架通过相对较小的配置更改连接到vLLM。

普通的KV缓存是现代自回归推理的标准组成部分。vLLM的优势在于它如何调度请求以及如何跨并发工作负载管理、分配和重用KV缓存内存。

特别是前缀缓存，可以减少预填充阶段的重复工作。它不会加速新输出token的生成，因此当请求共享长前缀时，其收益最大。

这些优化共同作用，使得vLLM在智能体应用程序超越单用户原型并开始处理并发、不均衡且内存密集型的推理工作负载时非常有用。

动机与架构

一旦AI智能体开始处理并发流量，模型推理可能成为其主要性能瓶颈之一。智能体可能大部分时间都花在等待模型处理提示词和生成token上。

无需重写智能体逻辑，你可以改进其底层的模型服务层。这就是vLLM的用武之地：它提供了一个OpenAI兼容的推理服务器，旨在通过连续批处理和KV缓存管理等特性高效处理并发请求。

请求流程如下所示：

用户发送提示词 ↓ 智能体发送OpenAI兼容请求 ↓ vLLM接收请求并调度该请求 ↓ 提示词进入连续批处理 ↓ 预填充阶段处理提示词并填充KV缓存 ↓ 解码阶段在重用KV缓存的同时生成token ↓ vLLM返回生成的响应 ↓ 智能体接收最终文本

当多个请求并发到达时，vLLM可以将兼容的工作组合成不断变化的批次。新请求可以在早期请求完成时加入，这有助于提高硬件利用率和整体吞吐量。

步骤1：安装vLLM

标准的vLLM安装主要针对Linux系统和支持的加速器（如NVIDIA GPU）。在Apple Silicon Mac上，你可以使用vLLM-Metal，这是一个社区维护的vLLM硬件插件，它使用MLX和Apple的Metal框架。

`` $ curl -fsSL https://raw.githubusercontent.com/vllm-project/vllm-metal/main/install.sh | bash

$ source ~/.venv-vllm-metal/bin/activate

$ pip install openai ``

官方文档提供了针对平台和环境的安装说明，特别是针对GPU和CUDA设置（在此文档中了解更多 https://docs.vllm.ai/projects/vllm-metal/en/latest/installation/）。

步骤2：启动vLLM服务器

现在使用一个模型启动OpenAI兼容的服务器：

vllm serve mlx-community/Qwen2.5-0.5B-Instruct-4bit --host 127.0.0.1 --port 8000

vllm serve命令启动一个用于模型推理的本地OpenAI兼容API服务器。

vLLM服务器在启动时会显示类似以下的输出：

... (APIServer pid=35422) INFO 08-13 22:17:00 [launcher.py:99] API server: waiting for HTTP server to start (APIServer pid=35422) INFO: Started server process [35422] (APIServer pid=35422) INFO: Waiting for application startup. (APIServer pid=35422) INFO: Application startup complete. (APIServer pid=35422) INFO 08-13 22:17:01 [launcher.py:105] API server: HTTP server started

启动后，你的服务器通常会在类似以下的本地端点监听：

http://localhost:8000/v1

你可以验证服务器是否正在运行，并检查其暴露的模型名称：

`` $ curl http://localhost:8000/v1/models

{“object”:“list”,“data”:[{“id”:“mlx-community/Qwen2.5-0.5B-Instruct-4bit”,“object”:“model”,“created”:1786685135,“owned_by”:“vllm”,“root”:“mlx-community/Qwen2.5-0.5B-Instruct-4bit”,“parent”:null,“max_model_len”:32768,“permission”:[{“id”:“modelperm-b05a3fc5dd824296”,“object”:“model_permission”,“created”:1786685135,“allow_create_engine”:false,“allow_sampling”:true,“allow_logprobs”:true,“allow_search_indices”:false,“allow_view”:true,“allow_fine_tuning”:false,“organization”:“*”,“group”:null,“is_blocking”:false}]}]}% ``

步骤3：将你的AI智能体连接到vLLM

现在将你的智能体连接到vLLM服务器。由于vLLM是OpenAI兼容的，你可以使用OpenAI Python客户端并将其指向你的本地服务器。将以下文件保存为vllm_agent.py：

`` from openai import OpenAI

client = OpenAI( base_url=“http://localhost:8000/v1”, api_key=“NA”, )

def ask_model(user_input: str) -> str: response = client.chat.completions.create( model=“mlx-community/Qwen2.5-0.5B-Instruct-4bit”, messages=[ {“role”: “system”, “content”: “You are a helpful assistant.”}, {“role”: “user”, “content”: user_input}, ], temperature=0, )

return response.choices[0].message.content

print(ask_model(“Why are automated tests useful?”)) ``

你不需要真实的OpenAI API密钥，因为请求是发送到你的本地vLLM服务器，而不是OpenAI API。

步骤4：运行智能体

在新终端中运行智能体。确保vLLM服务器正在运行。

$ python vllm_agent.py

智能体将向vLLM发送请求进行推理。vLLM将使用该模型运行推理并生成响应。

示例输出

vLLM服务器日志显示：

(APIServer pid=35422) INFO: 127.0.0.1:59866 - "POST /v1/chat/completions HTTP/1.1" 200 OK (APIServer pid=35422) INFO 08-13 22:36:11 [loggers.py:310] Engine 000: Avg prompt throughput: 2.5 tokens/s, Avg generation throughput: 20.4 tokens/s, Running: 0 reqs, Waiting: 0 reqs, GPU KV cache usage: 0.0%, Prefix cache hit rate: 33.7%

33.7%的前缀缓存命中率表明，33.7%的符合条件的提示词前缀token在vLLM的缓存中被找到并重用，而不是重新计算。