大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！
文章目录
摘要
随着 AI 应用从实验室走向真实世界，服务端的高效并发推理成了一道绕不开的坎。大语言模型（LLM）计算量巨大，逐个请求处理显然不现实。像 动态批量合并（Dynamic Batching）、Token 流式输出（ChatGPT 式响应） 和 KV Cache 管理 这些技术，正是让大模型推理服务化落地的关键。
vLLM 作为代表性的推理框架，把这些能力整合在一起，帮助开发者实现高吞吐、低延迟的并发推理。本文将结合实战代码，带你搭建一个能真正并发高效响应的推理服务。
引言
大家平时用 ChatGPT，看到的效果是边打字边出字，像是 AI 正在“思考”。但实际上，后台有成千上万个用户在同时发起请求，共享着有限的算力资源。
如果简单粗暴地“一人一张 GPU”，不光烧钱，连资源都撑不住。这时候，就需要 动态批量合并（Dynamic Batching） 和 KV Cache 复用（Cache Reuse） 出马了。
vLLM 就是专门为这种高并发场景做优化的框架，它不仅能动态合批，还能在批次中灵活插入新请求、移除完成的请求，让算力利用率拉满。
本文将会详细讲解：
- 并发推理为什么离不开批量合并？
- Token 流式输出对服务架构有啥挑战？
- KV Cache 如何帮我们省下大把算力？
- vLLM + FastAPI，手把手带你搭一个并发推理服务。
而且每个环节都会配上实战代码，写出来就能跑。
用 vLLM 搭建高效并发推理服务
什么是动态批量合并？为什么它很重要？
设想下：你有 100 个用户同时发起生成请求。如果一条条慢慢跑，不光慢，还浪费 GPU 算力。
大模型是矩阵乘法专家，最擅长一锅端（批量处理）。但现实中用户请求来的时间点、需求长度都不一样，怎么凑够一个完整 batch 呢？
动态批量合并（Dynamic Batching） 就是动态凑批次，来了就塞进 batch，保证响应及时，又能吃满算力。
vLLM 在这个基础上，还做了 Token Swapping 优化：一个 batch 里，谁先跑完就被踢出去，新的请求随时能顶上，不浪费 Cache，不重新算，真正做到批次动态变化、GPU 一刻不停。
Token 流式输出：为什么不能等所有 Token 生成完再返回？
普通推理服务通常是“结果算完再发回去”，但像 ChatGPT 这种对话类应用，必须一边生成一边发回去（Token Streaming），否则体验很糟糕。
流式输出面临的挑战：
- 用户感知的延迟必须低。
- 服务端还要合批提高效率。
- 每个用户生成的 token 数量不同，流式拆分难度大。
vLLM 在引擎内部实现了 连续解码（Continuous Decoding），在批量推理的同时，把每个用户的 token 单独分流回去，实现低延迟的 token 流式输出体验。
实战代码示例：用 vLLM 搭建一个并发推理服务
环境准备
pip install vllm fastapi uvicorn
Inference 服务代码
from fastapi import FastAPI, WebSocket
from vllm import LLM, SamplingParams
import asyncio
app = FastAPI()
llm_engine = LLM(model="facebook/opt-1.3b") # 可替换为任意支持的模型
@app.websocket("/chat")
async def chat_websocket(websocket: WebSocket):
await websocket.accept()
user_prompt = await websocket.receive_text()
sampling_params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=128)
# 启动流式生成任务
async for output in llm_engine.generate(user_prompt, sampling_params, stream=True):
token = output.outputs[0].text
await websocket.send_text(token)
await websocket.close()
代码解读：
- 用户通过 WebSocket 连接
/chat。 - 接收到用户 prompt 后，启动 vLLM 的流式生成。
- 每生成一个 token，就通过 WebSocket 立即发回给用户。
- 多个用户同时访问时，vLLM 会自动做批量合并和 KV Cache 复用。
应用场景示例 1：实时对话平台
假设你正在做一个 Chatbot 平台，需要同时服务成千上万的用户，每个响应都要求实时流式返回。
解决方案：
- 后端用 vLLM 部署 LLM 推理服务。
- 前端 WebSocket 接 token 流式输出。
- 动态批量策略根据流量自动调整 batch size。
- KV Cache 复用减少重复计算，提升吞吐。
应用场景示例 2：文档摘要 API 服务
一个文档摘要 API 接口，用户请求不稳定，高峰低谷交替，单个请求计算量较大。
解决方案：
- vLLM 动态批量将多个文档摘要请求合批处理。
- 流式返回每个摘要片段，用户边看边收。
- 监控队列延迟，根据请求密度动态调整 batch 合并策略。
QA 问答环节
Q1：vLLM 支持多大的模型？
可以支持 13B 以上的模型，但需要多卡配合，vLLM 在 KV Cache 管理上做了极致优化，可以在硬件条件允许下最大化模型载入。
Q2：KV Cache 在并发推理中有啥作用？
KV Cache 会保存模型前面 token 的注意力结果，后续生成新 token 时不用重复计算，尤其在多用户动态合批时，Cache 复用能极大提升效率。
Q3：batch 中如果有用户提前生成完成，其他用户会受影响吗？
不会。vLLM 的 Token Swapping 机制会把完成的请求踢出 batch，同时把新的请求无缝插入，batch 动态变换，后续请求不受影响。
Q4：可以自定义合批调度策略吗？
vLLM 提供了部分批量策略参数调节，如果有更复杂的需求，也可以通过修改源码实现自定义调度逻辑。
总结
做 LLM 服务，GPU 不是越堆越多就能解决问题。动态批量、流式返回、KV Cache 复用 是三大核心优化手段，真正让并发推理跑得快、跑得稳。
vLLM 把这些复杂度封装起来，让开发者用几行代码就能搭出一个高效的推理服务。无论是做 Chatbot、摘要 API，还是文档问答系统，这些优化都是必备武器。
掌握好这些技巧，才能在有限资源下跑出最好的用户体验。