详细摘要 摘要
生成:2025-11-16 17:22摘要详情
- 音频文件
- 2025-11-10 | GOSIM开源创新汇 | vLLM: 人人可用的简单、快速且低成本的大模型服务方案
- 摘要类型
- 详细摘要
- LLM 提供商
- openrouter
- LLM 模型
- anthropic/claude-sonnet-4.5
- 温度
- 0.3
- 已创建
- 2025-11-16 17:22:23
摘要内容
vLLM项目介绍与最新进展总结
概览/核心摘要
vLLM是一个快速、易用的大模型推理引擎,起源于2023年UC Berkeley发表的PageAttention论文。该项目自2023年6月开源以来发展迅速,截至2025年9月已获得超过57,000个GitHub Star,在蚂蚁开源报告中排名第二(仅次于PyTorch)。vLLM通过PageAttention和Continuous Batching技术高效管理KV Cache,支持超过百种主流模型(包括文本、多模态模型)和多种硬件平台(NVIDIA、AMD、Intel、Google TPU等)。2024年12月,vLLM加入PyTorch生态系统;2025年成为PyTorch基金会顶级项目,与PyTorch深度集成。最新技术进展包括:混合模型架构支持、KV Connector、基于Torch Compile的通用优化、分层CUDA Graph、Decode Context Parallel等创新功能。项目拥有超过1,500名贡献者和40多名committer,社区活跃,每月CI测试成本达5万美元。
项目背景与发展历程
vLLM的起源
- 技术基础:2023年UC Berkeley发表PageAttention论文,提出高效组织KV Cache的方法,提高显存利用率并加速大模型推理
- 核心技术:PageAttention + Continuous Batching构成vLLM项目雏形
- 关键问题:大模型采用自回归(auto-regressive)结构,中间状态管理(KV Cache)是高效推理的关键
项目发展里程碑
- 2023年6月:项目开源
- 2024年3月:演讲者尤凯超加入项目(当时约1万Star)
- 2024年12月:加入PyTorch生态系统
- 2025年:成为PyTorch基金会顶级项目(与PyTorch平级)
- 当前状态(截至2025年9月):超过57,000 GitHub Star,增长速度持续加快
社区认可
- 蚂蚁集团开源报告显示vLLM在开源社区排名第二
- 在外滩大会和GopherCon等多个技术大会被多次提及
生态系统与应用场景
广泛的生态支持
训练与微调框架集成:
- 后训练框架:RLHF、unsloth、llama-factory
- 支持微调、量化等全流程
应用框架集成:
- LangChain、Dify等应用框架
产业合作伙伴:
- 芯片厂商:NVIDIA、AMD
- 云厂商:Google Cloud、AWS、阿里云
- 模型开发商:DeepSeek、Moonshot、千问
使用方式
- Offline推理:LM Layer方式,强化学习框架(如RLHF)通过offline inference接入
- API服务:提供OpenAI兼容的API服务器,已成为社区标准
- 中间件集成:通过转换键接入Cloud Code、Gemini CLI
- 后端服务:作为推理引擎管理器后端(如NVIDIA Triton Inference Server通过async lm engine接入)
模型支持能力
支持的模型范围
主流文本生成模型:全面覆盖
国内最新开源模型(截至2025年9月):
- Step 3
- Kimi K2
- 千问3及千问3 Next
- GLM 4.5
- 文心一言4.5
- 腾讯混元
- 书生S1
模型支持的三个维度
架构层面:
- 标准Transformer
- MOE(混合专家)模型
- State Space模型
- Linear Attention模型
模态层面:
- 文本
- 语音
- 图片
- 视频
- 混合模态
任务层面:
- 自回归生成任务
- Pooling任务:embedding计算、reward、rerank等一次性生成任务
扩展机制
Transformers后端:
- 与Hugging Face Transformers合作
- 可直接运行Transformer支持的模型
- 目前支持文本生成和视觉输入模型
模型注册方案:
- 允许开发者将vLLM外部模块导入vLLM
- 无需修改vLLM代码
I/O Processor插件:
- 定制输入输出处理方式
- 可处理图片、视频甚至雷达数据
- 应用案例:IBM Research Team使用vLLM进行城市洪水区域识别(segmentation任务)
Recipes子项目
- 网站:recipes.vllm.ai
- 功能:记录常见模型的运行命令,方便用户快速上手
硬件支持与插件机制
支持的硬件平台
主流硬件:
- NVIDIA GPU(使用最广泛)
- AMD GPU
- Intel GPU
- Google TPU
- x86和ARM CPU
通过插件支持的硬件:
- AWS Neuron
- 华为升腾
- Intel Gaudi
- IBM Sparrow
- 国内厂商:沐曦等
硬件插件机制
设计理念:
- vLLM作为接口定义,包含NVIDIA GPU上的标准参考实现
- 硬件厂商提供各自平台的实现(如vLLM-Ascend)
- 用户安装接口包+实现包即可在特定硬件上运行
优势:
- 简化vLLM代码,减少硬件相关代码
- 硬件厂商可独立开发插件,无需vLLM参与
- 统一接口便于跨硬件优化
示例:升腾适配
- 安装vLLM(接口)+ vLLM-Ascend 0.7.1(升腾实现)
- 即可在升腾硬件上运行vLLM
与PyTorch基金会的深度集成
加入PyTorch基金会
时间线:
- 2024年12月:加入PyTorch生态系统
- 2025年:PyTorch基金会扩展为伞形基金会时,vLLM成为顶级项目(与PyTorch平级)
合作机制与技术协同
持续集成测试:
- vLLM每个commit对PyTorch最新nightly版本进行测试
- PyTorch版本发布前进行完整vLLM测试,修复兼容性问题作为发布前置条件
- vLLM依赖的PyTorch特性纳入PyTorch CI,保证未来代码不破坏这些特性
技术协同基础:
- 硬件厂商通常先支持PyTorch
- 在PyTorch基础上增加算子、模块后接入vLLM
- PyTorch提供关键的枢纽结构地位
具体案例:
- Blackwell适配:推动PyTorch默认发布版本升级至CUDA 12.8(Blackwell需要CUDA 12.8+)
生产部署:
- 与Meta内部PyTorch团队合作
- 将vLLM部署到Meta内部production use case,服务大量用户
合作伙伴:
- Google Cloud、NVIDIA GTC大会
- AMD发布会、Kubernetes社区
未来活动
- PyTorch Conference 2025(2025年10月):将有5场关于vLLM的报告
最新技术特性
混合模型(Hybrid Model)支持
背景:
- 模型上下文越来越长
- 为提高效率,避免使用完整Full Attention
- 采用少量Full Attention + Sliding Window/Linear Attention/Sparse Attention混合方案
技术挑战:
- 显存管理复杂
- 需支持Prefill Caching、Chunk Prefill、MTP Speculative Decoding等
解决方案:
- Hybrid Memory Manager:已默认启用
- 对混合架构模型支持非常有效
- 关键应用:高效支持千问3 Next(2025年9月刚发布)
KV Connector
功能:
- 提供灵活接口,方便其他组件与vLLM内部KV Cache交互
应用场景:
- 不同instance之间KV Cache共享
- PD分离功能
- 与LM Cache、Dynamo等系统集成
- KV Cache持久化存储到磁盘、NFS、S3等RDMA存储
- 降低推理成本
基于Torch Compile的通用优化
核心问题:
- vLLM支持众多模型、硬件和特性,面临组合爆炸问题
- 无法为每个case单独维护
解决方案:
- 使用Torch Compile编译器优化
- 抓取计算图后,将优化功能实现为编译pass
- 适配所有模型,新模型自动获得优化功能
应用案例:Sequence Parallel
- 作为Tensor Parallel的进一步优化
- 通过编译pass实现,无需修改每个模型文件
易用性改进:
- 功能复杂度增加,命令参数调整仍在优化中
分层CUDA Graph
技术方案:
- 保留attention部分灵活性
- 兼容其他部分效率
性能表现:
- 大模型:与完整CUDA Graph性能相当
- 小模型:略慢
统一框架:
- 完整CUDA Graph是分层CUDA Graph的特例
- 同时支持Full CUDA Graph和Piecewise CUDA Graph
- Decode阶段跑Full CUDA Graph,Prefill阶段跑Piecewise CUDA Graph
支持模型:
- FlashAttention-3、Flex Attention等支持Full CUDA Graph的模型
影响范围:
- 推理框架:vLLM
- 训练框架:Megatron等也采用类似技术
- 研究场景:Sparse Attention研究者通过插件修改attention,无需考虑CUDA Graph兼容性
Decode Context Parallel(DCP)
背景问题:
- 模型越来越大,但KV Cache越来越小
- DeepSeek MLA结构只有1个KV head
- 传统Tensor Parallel(TP)效率低,需重复保存KV Cache
技术方案:
- 与阅站面洪超同学合作
- 将KV Cache交替存储在TP Rank的GPU中
- 充分利用GPU存储空间
使用方式:
- 在--tp参数后加--dcp参数
- 例如:--dcp 8直接获得8倍KV Cache
性能收益:
- 2-3倍吞吐提升
- 特别适合RL、Offline Data Processing等需要大量KV Cache的场景
优化方向:
- Offline场景需进一步优化TTFT(Time To First Token)
Weight Update优化
合作方:Kimi团队王维骁同学
成果:
- 半分钟内更新万亿级参数
- 适用于强化学习场景
Sleep Mode
发布时间:已推出大半年(截至2025年9月,宣传较少)
应用场景:
- Serverless场景
- 资源共享场景(如后训练RL的训练和推理共用GPU)
- 一个GPU上运行多个Service
工作机制:
- 临时卸载Weight,清空KV Cache
- 模型进入睡眠模式
- 通过特殊请求唤醒模型
- 避免长时间加载
技术特点:
- 利用CUDA底层驱动功能
- 对上层应用透明
- 与其他功能兼容性好
In-flight Batch优化
灵感来源:NanoFlow
技术方案:
- 当前batch执行时,同时prepare下一个batch的调度
- 两个in-flight batch并行
性能收益:
- 中小模型:约10%性能提升
优化进展:
- Model execution和prepare input尚未完全overlap
- 正在优化与Speculative Decoding、Structured Output的兼容性
- 目标:常用场景下GPU利用率达到100%
用户体验优化
安装方式
多种安装选项:
- Docker
- Wheel安装
预编译(Precompiled)功能
背景:
- 大部分用户不需要修改kernel
- 只需修改Python代码
使用方式:
- 设置环境变量:VLLM_USE_PRECOMPILED=1
- 直接从预编译Wheel获取编译好的so文件
- 只需安装Python代码
优势:
- 安装更便捷
- 正在推广到更广泛场景
Wheels发布机制
发布网站:wheels.vllm.ai
快速响应流程:
1. 新模型发布(如Kimi K2)
2. 第一时间向vLLM提交PR
3. vLLM merge PR后约30分钟
4. Wheel上传到网站
5. 用户可通过precompiled方式使用最新版本
优势:
- 模型发布与vLLM版本发布解耦
- 用户可在模型发布后30分钟-1小时内使用
- vLLM版本发布更从容
质量保障与性能监控
测试体系
测试规模:
- 每个commit经过大量测试
- 与PyTorch团队合作
性能监控:
- 利用PyTorch性能监控基础设施
- 使用PyTorch社区工具
- 跟踪主流模型性能
- 快速定位性能问题的commit
资源投入
CI成本:
- 截至2025年9月前数月:每月约5万美元(仅CI机器成本)
- 不包括人力开销
赞助支持:
- 国内外云厂商
- 科研机构
- 提供大量计算资源支持
社区建设
贡献者规模
总体数据:
- 超过1,500名贡献者(提交过代码)
- 40多名committer
贡献者来源:
研究机构:
- UC Berkeley
- 清华大学
- 香港科技大学
硬件厂商:
- NVIDIA
- AMD
- Google
- 华为
- Intel
大规模用户:
- Red Hat
- Meta
- Hugging Face
- AnyScale
模型厂商:
- 千问
- Mistral
其他:
- 热爱开源的技术贡献者
社区活动
2024年8月国内Meetup:
- 北京、上海、深圳三场
- 场场人数饱满
GopherCon 2025:
- 婉拒workshop,让社区先消化8月内容
- 2025年10月可能继续举办
技术讨论生态
社区定位:
- 不仅是开发和优化vLLM
- 大模型推理相关技术讨论的发源地
技术合作案例:
Hugging Face:
- 研究大模型推理中保持绝对输出稳定性
NVIDIA:
- 以vLLM为样例,调试illegal memory access等基础问题
Google工程师:
- 撰写详细的vLLM internal技术细节介绍
项目愿景与目标
核心目标
演讲者尤凯超表示:"我们想要构建一个又快又好用的大模型推理引擎。"
实现路径
- 不是几个人或几十人能完成的目标
- 构建大模型推理技术社区
- 汇聚关心、支持、使用这些技术的公司和个体
- 共建生态,共同推进vLLM进步
交流渠道
开发平台
- GitHub:主要开发平台
沟通渠道
- Slack:国外用户主要使用
- 微信群:国内用户主要使用
- vLLM小助手:可搜索加微信,加入技术讨论群
宣传平台
- 知乎
- 小红书
- 微信公众号
文档资源
- 官方文档
- Ask AI机器人:可交流技术细节
总结
vLLM项目在两年多时间内从学术论文发展成为大模型推理领域的标杆项目,其成功得益于:
- 技术创新:PageAttention、Continuous Batching等核心技术,以及持续的优化创新
- 生态开放:广泛的模型、硬件支持,灵活的插件机制
- 深度集成:与PyTorch基金会的紧密合作
- 社区驱动:超过1,500名贡献者的共同努力
- 用户友好:简化安装、快速响应新模型、丰富的文档支持
项目将继续秉承"又快又好用"的理念,通过社区共建推动大模型推理技术的发展。
评审反馈
总体评价
总结内容全面详实,结构清晰,准确捕捉了演讲的核心信息。但存在少量术语错误、时间信息不准确,以及部分内容组织可优化的问题。
具体问题及建议
- 事实错误:标题日期错误
- 问题:标题显示"2025-11-10",但转录文本提到"去年十月份"、"今年"、"PyTorch Conference 2025(10月)"等信息,结合上下文判断应为2025年9月左右的演讲
-
修改建议:将标题日期修正为"2025-09-XX"或删除具体日期,改为"2025年"
-
术语错误:VLM vs vLLM
- 问题:转录文本中多处"VLM"实为语音识别错误,应为"vLLM"(小写v,双L大写)
-
修改建议:全文统一使用"vLLM"(这是项目的正确名称)
-
术语错误:WLM
- 问题:转录文本中"WLM"应为"vLLM"
-
修改建议:将所有"WLM"替换为"vLLM"
-
术语错误:GopherCon vs GOSIM
- 问题:标题中"GOSIM开源创新汇",但转录文本中多次提到"GopherCon"
-
修改建议:核实会议名称,统一使用正确名称
-
术语错误:框架名称
- 问题:"worl"应为"RLHF"或其他强化学习框架;"defy"疑似"Dify"
-
修改建议:根据上下文修正为准确的框架名称
-
术语错误:存储系统
- 问题:"三 F S"应为"NFS"(Network File System)或"S3"
-
修改建议:修正为正确的存储系统名称
-
时间信息不准确
- 问题:"过去1-2个月"发布的模型列表,但未明确具体时间基准
-
修改建议:添加"截至2025年9月"等时间限定词
-
内容组织:重复信息
- 问题:"PyTorch基金会"部分与"与PyTorch的协同"部分有内容重叠
-
修改建议:合并相关内容,避免重复
-
格式规范:引用标注
- 问题:核心目标引用未标注出处
-
修改建议:明确标注为演讲者原话
-
遗漏信息:具体数据
- 问题:演讲中提到"排名第二,仅次于PyTorch",但未说明是哪个排名榜单
- 修改建议:补充"在蚂蚁开源报告中"的上下文
-
术语错误:硬件名称
- 问题:"叉八六"应为"x86"
- 修改建议:使用标准术语"x86"
-
内容准确性:会议时间
- 问题:"PyTorch Conference 2025(10月)"需确认是2024年10月还是2025年10月
- 修改建议:根据演讲时间(2025年9月左右)推断应为"2025年10月"
优化方向
-
统一术语规范:全文检查并统一所有技术术语的大小写和拼写,特别是vLLM、PyTorch、CUDA等核心术语
-
补充时间上下文:在涉及"最近"、"近期"等模糊时间表述时,补充具体时间范围(如"截至2025年9月")
-
精简重复内容:合并"PyTorch集成"相关的多个章节,避免信息重复,提高可读性