机器之心的 RSS 预览

为什么95%的智能体都部署失败了？这个圆桌讨论出了一些常见陷阱

2025-10-28 17:36:00

选自Motive Notes

作者：Oana Olteanu

机器之心编译

「95% 的 AI 智能体在生产环境中部署时都失败了。」在硅谷近期的一个圆桌论坛中，有位嘉宾给出了这样一个数字。

这个论坛由 EntreConnect（一个企业家、投资者社区）组织，来自 Uber、WisdomAI、EvenUp 和 Datastrato 的工程师及 ML 负责人参与了讨论。他们认为，多数 AI 智能体之所以部署时失败，不是因为模型不够智能，而是因为围绕它们的基础框架、上下文工程、安全性和记忆设计尚未成熟。

EntreConnect组织的论坛「Beyond the Prompt: AI Inference x Context Engineering with Uber, Wisdom AI, EvenUp and Datastrato」

他们进一步指出，真正的差距在于上下文工程，「大多数创始人以为自己在构建 AI 产品，实际上他们在构建的是上下文选择系统。」成功的团队不是在优化提示词，而是在构建语义层、元数据过滤、特征选择和上下文可观察性。正如论坛上的一个比喻所说：「基础模型是土壤，上下文才是种子。」

当然，技术挑战还不是全部。即便系统在功能上表现完美，如果无法追溯输出来源、无法遵守权限控制、无法让用户真正信任它处理敏感数据，部署依然会失败。一位与会者分享了他妻子拒绝使用特斯拉自动驾驶的故事 —— 不是因为它不好用，而是因为缺乏信任。这个问题同样存在于企业 AI 智能体中。成功部署的那 5% 智能体都有一个共同点：人机协作设计，让 AI 扮演助手而非自主决策者。

这篇文章由论坛主持人 Oana Olteanu 撰写，深入探讨了这次圆桌论坛的核心洞见：从上下文工程的最佳实践、记忆架构设计、多模型编排，到治理框架和用户体验设计。如果你正在构建 AI 产品、基础设施或智能体系统，这些来自一线工程师的实战经验，或许能帮你避开一些失败陷阱。

上下文工程，不是提示词黑科技

这场讨论中，几位嘉宾不约而同地提到：微调往往并非必要。

在多数场景中，一个构建良好的 RAG（检索增强生成）系统已足够高效 —— 但现实是，绝大多数 RAG 系统都太过粗糙。

它们常见的失败模式包括：

盲目索引一切 → 模型被无用信息淹没
索引太少 → 模型缺乏信号支撑
混合结构化与非结构化数据 → 打破嵌入空间一致性

那么，「高级的上下文工程」究竟长什么样？

上下文层参考资料：https://www.wisdom.ai/ai-for-business-intelligence/semantic-layer

1、面向 LLM 的特征工程

一位嘉宾提出了一个极具启发的框架：

把上下文工程看作 LLM 的原生特征工程（feature engineering）。

选择性上下文剪枝 = 特征选择
上下文验证 = 类型 / 时间 / 模式校验
上下文可观测性 = 追踪哪些输入改善或削弱输出质量
嵌入增强 + 元数据 = 类型化特征 + 条件信号

这意味着：上下文不再是「字符串拼接」，而是一个可测试、可版本化、可审计的数据工件。

2、语义层 + 元数据层的双层结构

一些团队分享了他们的「双层架构」实践：

语义层：负责经典的向量检索
元数据层：基于文档类型、时间戳、访问权限、领域本体等执行过滤

这种设计能在混乱的数据源之间建立秩序（PDF、日志、音频、指标等），确保检索结果不是简单的「相似内容」，而是真正的「相关知识」。

换句话说，它让 AI 能理解语义，也能尊重结构。

3、text-to-SQL 的现实检验

当场上问观众「有谁把 text-to-SQL 做到生产环境里」时，一个举手的都没有。原因不是这个问题小，而是把自然语言稳定、可靠地映射到业务级查询比想象中难得多。自然语言本身模糊、歧义重；企业术语又常常有上下文依赖 ——「营收」「活跃用户」在不同公司、不同团队的定义可能完全不同。

成功的团队不会把数据库 schema 生搬给模型然后指望它猜对。他们做的是工程化的抽象与保护措施，包括：

业务词典与术语映射
受约束的查询模板
执行前的语义校验层

能够随时间提升理解的反馈循环可参见：https://www.wisdom.ai/ai-for-business-intelligence/text-to-sql

为什么「信任」与「治理」是核心问题

安全、权限、数据溯源这些词，在现场被反复提到。

它们不是合规清单上的「打钩项」，而是 AI 系统落地的关键阻力。

垂直领域创业者要注意做到以下几点：

要能追踪哪个输入导致了哪个输出
必须遵守行级、基于角色的访问权限
即使提示词相同，也必须支持用户专属的输出结果

如果两名员工问了同一个问题，AI 的答案应该不同。因为他们的权限不同、上下文不同。没有这样的访问与策略控制，AI 的答案可能「技术上正确」，但「组织上错误」—— 泄露信息、违反合规。

领先团队的做法是：在结构化与非结构化数据的统一目录（metadata catalog）中，嵌入访问策略，在索引和查询阶段同时生效。

信任问题并非技术瓶颈，而是人性瓶颈。一位嘉宾讲了一个故事 —— 他太太拒绝让他开自动驾驶。不是因为它不好用，而是因为她不信任。AI 若要处理金钱、医疗、或安全相关决策，必须先赢得这种信任。那些真正成功的 5% 的系统，都有一个共通点：人机协同（human-in-the-loop）。AI 被设计为助手，而非决策者；能被监督、能被纠正、能被解释。

记忆，不是功能，而是系统结构

每个团队都说想给 AI 加记忆。但真正懂系统的人知道 —— 记忆不是一个 feature，而是一个涉及用户体验、隐私和系统影响的设计决策。

记忆有三个层面：

用户层面：偏好（如图表类型、风格、写作语气）
团队层面：循环查询、仪表盘、运行手册
组织层面：组织知识、政策、先前的决策

大多数初创公司将记忆硬编码到应用逻辑或本地存储中，但顶尖团队会将记忆抽象为一个「上下文层 + 行为层」的组合，可版本化、可复用。

他们的定义是：

语义记忆 + 分类体系 + 运行手册 = 上下文；
用户偏好 = 记忆

记忆即个性化

在应用层面，记忆服务于两个目的：

针对个体用户定制行为：适配其写作风格、偏好格式、领域专长
基于事件和元数据的主动辅助：而非仅仅被动响应聊天

有团队分享了在 Uber 构建对话式 BI 工具的经验。冷启动问题是什么？用户不知道该问什么。解决方案是从用户的历史查询日志中构建记忆，然后推荐相关问题作为对话起点 —— 就像一个记得你上次聊天内容的人。

但问题在于：有用的个性化何时会越界成为令人不安的监控？

一位与会者描述，他向 ChatGPT 询问适合全家观看的电影推荐，结果 ChatGPT 给出了针对他孩子 Claire 和 Brandon 的个性化建议。他不喜欢这个答案，说「你为什么对我的儿子和女儿了解得这么清楚？别碰我的隐私」。

在设计时，你需要考虑：

记忆改善用户体验和 AI 流畅度
但过度个性化很快会侵犯隐私领域
共享记忆可能打破访问控制，除非仔细划定范围

这里缺失一个关键原语：一个安全、可移植的记忆层，可跨应用工作，由用户使用，而非锁定在服务商内部。目前还没人真正解决这个问题。一位与会者说，如果他不做现在的创业项目，这会是他的下一个目标。

多模型推理与编排模式

另一个新兴设计模式是模型编排。

在生产环境中，你不能对所有任务都调用 GPT-4。团队越来越多地基于以下因素运行模型路由逻辑：

任务复杂度
延迟限制
成本敏感度
数据本地化 / 监管要求
查询类型（如摘要 vs 语义搜索 vs 结构化问答）

以下是一些可能的情况：

简单查询 → 本地模型（无网络调用）
结构化查询 → 调用 DSL → SQL 转换器
复杂分析 → 调用 OpenAI/Anthropic/Gemini
兜底或验证 → 双模型冗余（评判者 + 响应者）

这更接近编译器设计而非网页应用路由。你不只是「发送给 LLM」，而是在异构模型、工具和验证之间运行一个决策 DAG（有向无环图）。

为什么这点很重要？如果你的系统随着使用量增长而变得更慢或更贵，这是首先需要重新审视的层面。如果你希望 AI 对用户感觉无缝，路由就不能永远依赖脆弱的手工调优。你需要自适应策略。

有团队分享了他们的方法：简单问题交给小型快速模型，复杂推理任务路由到前沿模型。这里的关键在于：通过追踪哪些查询在哪些模型上能够成功执行，模型选择这一过程本身可以随着时间的推移不断学习优化。

聊天界面究竟何时才适用？

并非每个任务都需要聊天机器人。一位观众直接挑战了这个前提：「我不确定自然语言总是优于图形界面。如果我要叫 Uber，我不想对着手机说话。我只想点、点、点，车就来了。」

的确，不是所有任务都适合自然语言交互。

专家小组的共识是：当对话能降低学习门槛时，它才具备实用价值。

对于商业智能（BI）仪表盘、数据分析这类传统上需要专业知识才能操作的复杂工具，自然语言能降低使用门槛。但一旦用户获得所需答案，通常更倾向于使用图形用户界面控件 —— 比如将饼图切换为柱状图，根本无需额外输入文字。

混合模式的核心逻辑是：

以聊天功能开启零学习门槛的初始操作
提供图形用户界面（GUI）控件用于后续的精准调整与反复优化
允许用户根据具体任务需求和个人使用偏好选择交互模式

一位与会者列举了自然语言处理的两个理想应用场景：

偶发且带有情绪属性的任务，例如客户服务场景 —— 用户此时可能心怀不满，只想倾诉诉求或获取帮助，而非在层层菜单中艰难导航；
探索性、开放式的查询任务，例如「帮我找一处加州附近的爱彼迎房源，要前排位置，能看到海景和蓝天」这类需求复杂且包含上下文信息的场景。

核心洞见在于：我们应当理解人们使用自然语言交互的深层原因，并围绕这一核心意图进行设计，而非将所有交互都强行套入聊天模式。

仍存在的缺口

会上提出了几个尚未得到充分探索的方向，这些都是亟待产品化的核心基础能力：

1、上下文可观测性

哪些输入能持续优化输出效果？哪些类型的上下文会导致模型产生幻觉？如何像测试模型提示词那样测试上下文？目前，大多数团队都在盲目摸索 —— 他们缺乏系统的方法来衡量哪些上下文对模型性能真正有帮助，哪些反而会产生负面影响。

2、可组合记忆

记忆能否归属于用户（而非应用程序），实现可移植性与安全性？同时设置可选的权限层级，以区分组织、团队和个人层面的记忆状态？

这一设计能解决两个核心问题：

用户无需在每个新工具中重新构建自己的上下文信息
隐私与安全性由用户自主掌控，而非受服务商锁定

这是当前技术栈中最关键的缺失的基础能力。

3、领域感知型 DSL

企业用户的需求大多具备结构化和重复性特征。既然如此，我们为何仍执着于将自然语言解析为稳定性极差的结构化查询语言（SQL），而非定义更高级、受约束且安全的领域特定语言（DSL）呢？

有团队提出，与其开发文本到结构化查询语言（text-to-SQL）的工具，不如构建语义化的业务逻辑层，例如「展示第四季度营收」这类需求，应当直接映射到经过验证的计算流程，而非生成原始的结构化查询语言（SQL）代码。

4、延迟感知型用户体验（UX）

一位专家组成员提到了一款记忆增强型聊天机器人，它的响应速度虽慢，却能给用户带来惊喜体验。原因在于：它能基于用户上周的提问内容，给出一系列智能的后续跟进内容。

这一设计为异步、主动式人工智能的用户体验开辟了新可能 —— 其应用场景绝非仅限于聊天功能。试想这样的场景：智能体在你开会前准备好简报、在你打开文档时呈现相关上下文信息，或是在你主动询问前就提醒你数据中出现的异常情况。

核心洞见在于：不同任务对延迟的要求存在差异。一个笑话需要即时响应；而深度分析即便耗时 10 秒也无妨，只要能实时展示进度且体现出智能性即可。

值得持续关注的方向

作者表示，参与完这场专家小组讨论后，她更加坚信：一波基础设施工具浪潮即将到来，包括记忆组件、编排层、上下文可观测性工具等。事后看来，这些工具的出现似乎顺理成章，但如今它们仍处于混乱且尚未解决的状态。

生成式人工智能领域下一个真正的竞争壁垒，不会源于模型访问权限，而将来自以下四个方面：

上下文质量
记忆系统设计
编排可靠性
信任导向型用户体验（Trust UX）

如果你是一名正在开发基础设施、应用程序或智能体的创业者：你的产品路线图中，有多少内容是明确针对这四个方向展开的？

创业者必看：5 个需直面的硬核问题

如果你正在构建上下文系统或智能体，不妨问问自己这 5 个问题：

我的应用程序的上下文预算是多少？（理想的上下文窗口规模为多大？我又在如何优化其中的内容构成？）
我的记忆系统边界在哪里？（哪些记忆归属于用户层面、团队层面以及组织层面？存储位置在哪？用户能否查看这些记忆内容？）
我能追踪输出的溯源信息吗？（当需要调试大语言模型的响应结果时，我能否明确知晓是哪些输入内容导致了该输出？）
我使用的是单一模型还是多个模型？（我是如何根据任务复杂度、延迟要求或成本预算来分配路由请求的？）
用户会愿意将资金或医疗数据托付给我的系统吗？（如果不愿意，我的安全机制或反馈循环中还缺少哪些关键环节？）

原文链接：https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

文章原文

马斯克Grokipedia刚上线就「翻车」？被指照抄维基，中文支持一塌糊涂

2025-10-28 17:36:00

机器之心报道

机器之心编辑部

刚刚，马斯克预热了几个月的 Grokipedia 终于上线了。

简单来说，Grokipedia 是 xAI 于 2025 年 9 月提出的开源百科平台，它的诞生就是为了挑战维基百科。因为在马斯克看来，维基百科不够中立，充满了偏见，而他要做的 Grokipedia 在准确性和中立性方面都要超越前者。

Grokipedia 的「Wikipedia」词条提到了维基百科的偏见问题。

马斯克还强调，Grokipedia 将秉持「开放无障碍」的理念，允许任何 AI 或人类自由调用。不过，这次发布的只是 0.1 版本，马斯克表示，1.0 版本要比这个初始版本强 10 倍。

Grokipedia 是一个 AI 驱动的百科全书，内容由 AI 生成，所有内容都将经过 xAI 驱动的算法系统进行事实核查、偏见检测与逻辑一致性评估。虽然马斯克声称这种做法旨在清除噪音、回归事实，但该做法的有效性颇受质疑 —— 如果维基百科反映了其人类编辑及其来源的偏见，那么人工智能也有同样的问题，即数据本身的偏见。

维基百科上的「Grokipedia」条目，其中多处提到 Grokipedia 存在偏见。

官网显示，Grokipedia 目前有 885279 篇文章可用，和维基百科的数百万篇还有较大差距。

针对准确性问题，Grokipedia 允许用户指出问题，并提供修改建议和相关链接。

部分词条已经有可见的编辑记录。

有人认为，这种编辑模式有利于大家发现一些在词条中长期存在的错误，看起来是有价值的。

有意思的是，针对来势汹汹的 Grokipedia，维基百科的运营方维基媒体基金还发了一份声明。他们表示，「维基百科的知识当下是、未来也永远是人类的成果。来自不同背景的人们通过公开协作与共识共建，打造出一份中立、鲜活的人类认知记录 —— 它既体现了我们的多样性，也承载着集体的好奇心。这类由人类创造的知识，正是人工智能公司生成内容的基础；即便是 Grokipedia，也离不开维基百科的存在。此前已有过多次打造维基百科替代版本的尝试，但这并不会影响我们的工作与使命。」

此外，维基百科本身的角色也在发生变化。最近有文章指出，现在使用维基百科的人正在减少，AI却在增多，因为 AI 工具会直接从它的文章中提取答案。而且，维基百科本身已经使用人工智能工具自动检测不良编辑，避免有人向文章中插入虚假信息、攻击性语言或垃圾信息。该系统不会自行发布或批准编辑，但它会标记可疑的更改，以便人类编辑者能更快地审查。

Grokipedia PK 维基百科

目前许多用户已经分享了使用体验。其中热度最高的帖子之一，对比了 Grokipedia 和维基百科在 George Floyd 词条上的差异，评论区的讨论也相当激烈。

争议点在于 Grokipedia 的导语部分首先提到 George Floyd 是一名有长期犯罪记录的美国男子，而维基百科的导语部分仅写了他被暴力执法致死，其犯罪记录则放在了「个人生活」部分。

博主认为，Grokipedia 不像维基百科那样存在意识形态灌输，但评论区针对这点展开了激烈的争论。

有评论指出，双方都存在偏见，但对 AI 没有采用中立写法提出了疑问。

当然马斯克也不会错过这个热闹。

另外有用户表示，Grokipedia 有词条直接照抄维基百科。

有些词条下方确实写着「改编自维基百科」。

对于这一问题，之前也有人问过马斯克，马斯克的回应是「年底前解决」。

我们也实际体验了 Grokipedia 的当前版本，看看它在产品形态和使用体验上究竟表现如何。

Grokipedia v0.1 的界面设计极为简洁，可供调整的选项仅有深浅模式切换，页面中也完全没有图片。

以前面的 George Floyd 为例，Grokipedia 在这一个词条中详细陈述了 Floyd 的生平经历、Floyd 之死事件、争议和影响等，而维基百科中 Floyd 之死是一个单独的词条，Grokipedia 相对来说阅读体验更流畅。

不过在测试中，我们发现 Grokipedia 在别名识别与实体映射方面的能力仍有待提升。

例如，在维基百科中搜索「P. Diddy」时，系统会自动跳转至艺人本名「Sean John Combs」的词条，实现了同义名的智能关联。

而在 Grokipedia 上，输入「P. Diddy」则无法直接检索到对应页面，只有输入本名「Sean John Combs」才能命中结果。

同样地，搜索马克・吐温的本名「Samuel Clemens」时，也出现了类似的问题。

另外我们发现 Grokipedia 对中文内容的支持存在明显不足。例如，使用中文输入「鲁迅」无法获得任何结果，只有以「Lu Xun」搜索时才能命中相关页面。

而搜索类似「苹果」、「谷歌」的词条，会已读乱回。

最后我们来欣赏一下本次「百科之王」大战的梗图。

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

文章原文

NeurIPS 2025｜VFMTok: Visual Foundation Models驱动的Tokenizer时代来临

2025-10-28 17:36:00

视觉 Tokenizer 的困境与破局

近年来，自回归（Autoregressive, AR）模型在语言生成领域的成功激发了其在图像生成领域的应用，涌现出 DALL-E、Parti、VAR 和 LlamaGen 等代表性工作。这类技术高度依赖于 VQGAN 等视觉 Tokenizer，它负责将高维、冗余的像素空间映射到一个低维、紧凑的离散潜在空间，是决定生成模型上限的基石。

然而，以 VQGAN 为代表的传统 Tokenizer 通常需要从零开始训练，其训练目标由像素级重建损失函数主导，导致其产生的潜在空间：

富含低层细节特征却缺乏高层语义信息：能很好地还原图像细节，但潜在编码本身缺乏高层语义信息。
较高的潜在空间冗余: VAGAN 基于图像块 (patch) 逐一进行量化，而图像中的物体通常是不规则的区域，基于图像块的量化降低了 tokens 的编码效率。
无视结构特性的表征：潜在空间的组织较为混乱，使得生成模型不仅需要更长的训练时间来学习其潜在空间分布，而且往往得借助 CFG（Classifier-Free Guidance, CFG）等技巧来实现高保真度的图像生成，增加了模型推理时间。

与此同时，预训练的视觉基础模型（Visual Foundation Models, VFMs），如 CLIP、DINOv2、SigLIP2 等，在提取丰富语义且可泛化视觉特征方面表现出了强大的能力。这些模型通过自监督或语言监督的方式进行训练，它们能够有效抽象出图像中的高层语义信息，因此这些预训练的视觉基础模型大多应用于图像内容理解任务当中。直接将其应用于图像重建和生成任务上却鲜有人探索。

基于此，香港大学 CVMI Lab 和阶跃星辰 AIGC 团队提出一个大胆假设：原本为视觉理解任务设计的预训练视觉基础模型，其潜在特征是否也能直接作为图像重建与生成的鲁棒结构化表征？

为了验证这一猜想，我们探索了一个基础视觉模型新的应用新方向：用冻结的预训练视觉基础模型构造离散的视觉 Tokenizer，将其应用于图像重建和自回归图像生成任务上。

我们发现，相比于传统的视觉 Tokenizer 模型，视觉基础模型驱动的图像 Tokenizer 在这两项任务上均表现出优异的性能。

论文标题: Vision Foundation Models as Effective Visual Tokenizers for Autoregressive Generation
论文地址: https://arxiv.org/pdf/2507.08441
Huggingface: https://huggingface.co/papers/2507.08441
Github:

https://github.com/CVMI-Lab/VFMTok.git （Vanilla version）

https://github.com/CVMI-Lab/VFMTok-RAR.git （Ultra version）

探索性发现

为了验证视觉基础模型 (VFMs) 能否构造高质量的视觉 Tokenizer，我们首次尝试使用不同的冻结的预训练基础视觉模型 (VFMs) 提取图像特征，将其送入 VQGAN 的编码器中进行端到端训练。训练阶段只有量化器（quantilizer）和解码器中的参数会进行更新，随后用它完成自回归图像生成任务。

实验表明：冻结的视觉基础模型 (VFMs) 提取的图像特征可以直接用于图像重建，且训练好的视觉 Tokenizer 在自回归图像生成任务上的表现优于传统的视觉 Tokenizer 模型。

这一发现凸显了预训练视觉基础模型 (VFMs) 构造高质量视觉 Tokenizer 的巨大潜力。

核心思想

基于我们的探索性发现：冻结的视觉基础模型 (VFMs) 可以直接构造高质量的视觉 Tokenizer 并进行端到端地训练，我们对构造的视觉 Tokenizer 的结构进行进一步的优化 —— 利用视觉基础模型 (VFMs) 提取图像的多层特征 (Multi-level Features Extraction)，这有助于同时捕获图像中的低层细节特征和高层语义信息。

同时，我们注意到现有的量化机制 (quantization) 都是对图像块 (patch) 逐一量化，而图像中物体一般都是形状不规则的，因此我们设计了区域自适应的量化 (Region-Adaptive Quantization) 方案。该方案可以进一步降低潜在特征空间的冗余度，提高视觉 tokens 的利用效率。

此外，因为视觉基础模型的参数是冻结的，因此在重建图像内容的同时，我们也设计了语义特征重建的目标函数 (Semantic Reconstruction Objective)，来提升视觉 Tokenizer 的语义保真度。我们将基于视觉基础模型 (VFMs) 的 Tokenizer 称之为 VFMTok。

VFMTok 架构图

关键技术细节

多层图像特征提取 (Multi-level Features Extraction)

为了同时捕获图像低层细节特征和高层语义信息方便图像重建，VFMTok 采用冻结的预训练的视觉基础模型 (VFMs) 作为编码器提取多层级语义特征。VFMTok 按照等间隔的方式从预训练基础模型 (VFMs) 中提取多层特征 (multi-level features)。

区域自适应量化 (Region-Adaptive Quantization)

为了实现区域自适应量化 (Region-Adaptive Quantization) 机制，VFMTok 通过可学习「锚点查询」（Anchor Queries）结合可变形注意力机制（Deformable Attention）自适应地从多层级特征 (multi-level features) 中进行区域自适应的特征采样 (Region-Adaptive Sampling)。

这种方式能聚焦于采样图像中模式一致的区域。随后，VFMToks 对可学习「锚点查询」（Anchor Queries）进行量化 (quantization)。这种方式可以有效提升 token 的利用效率 —— 用更少的 tokens（256）来表征一张图像。

语义重建目标（Semantic Reconstruction Objective）

因为视觉基础模型在 Tokenizer 的训练阶段参数是冻结的，因此 VFMTok 在重建图像的同时，也会重建冻结的基础模型（VFM）最后一层的语义特征。

为了实现这一点，VFMTok 解码阶段设计了一个共享的轻量级 Vision Transformer（ViT）。这个 ViT 接收区域自适应量化后的 tokens，结合一个可学习的 mask token 以及一组可学习的位置编码（Positional Embedding）作为输入，分别产生用于图像重建和语义重建的特征。共享 ViT 的设计既减少了参数量又保证了语义保真度。其双重目标函数是：

其中是传统的视觉 Tokenizer 使用的一系列常规损失函数，是重建出的 VFM 特征与原始 VFM 特征之间的余弦相似度损失函数。

训练完成后，VFMTok 可以被应用于图像自适应回归任务上，基于 next-token prediction 的方式生成高质量的图像内容。

实验亮点与分析

1.卓越的重建生成质量与效率

大量实验表明，基于视觉基础模型 (VFMs) 构造的视觉 Tokenizer——VFMTok，具备高质量、高效率的图像重建和自回归图像生成能力。

更好的图像重建质量：相较于传统的视觉 Tokenizer，VFMTok 可以用更少的 token 数量（仅用 256 个）实现更优的重建质量（0.89 rFID， 215.4 rIS）和更高的码本利用率 (100%)，超越了之前大部分传统的离散 Tokenizers。

更快的生成训练收敛速度：相比于经典的 VQGAN 这类 Tokenizer，VFMTok 能够显著提升自回归模型训练阶段的收敛速度 —— 训练收敛速度提升了 3 倍。

更好的生成性能：在 ImageNet 256x256 的 class-to-image 生成任务上，VFMTok-1.4B 模型在参数量更少、训练迭代次数更少的情况下，自回归生成性能超越了同类 LlamaGen-3B。此外，在接入更好的自回归图像生成框架 RAR 后，实现了 SOTA 的图像生成性能（gFID: 1.36）。

CFG-free 优越性：值得注意的是，VFMTok 在有无 CFG 的情况下性能几乎一致（gFID: 2.07 vs 2.04），而 LlamaGen 则会从 2.19 急剧恶化至 9.38。这证明了其潜在空间具有极强的语义一致性，无需 CFG 即可实现高保真度的 class-to-image 图像生成，可以进一步减少图像生成时间。

更快的推理速度：由于 tokens 数量减半（256 vs. 576），自回归模型的生成过程长度减半，推理速度因此获得了约 4 倍的提升。

2.消融实验的有力证明

仅使用冻结的 VFM 作为编码器，线性探针准确率（linear probing）就从 VQGAN 的 23.1% 提升至 56.4%。引入区域自适应量化 (Region-Adaptive Quantization) 和语义特征重建 (Semantic Reconstruction Objective) 后，VFMTok 仅用 256 个 Token 就能在重建质量（rFID 0.89 vs 0.95) 上全面超越使用 576 个 Token 的 VQGAN 基线 Tokenizer。

总结与展望

VFMTok 首次证明了冻结的视觉基础模型 (VFMs) 提取的图像特征能有效用于图像重建与生成，同时可以提升 Tokenizer 语义表征能力，使自回归 (AR) 图像生成模型收敛更快，并能实现 CFG-free 的高保真图像合成。VFMTok 提出的区域自适应量化机制，通过有效利用图像区域的固有冗余实现紧凑编码，在减少视觉 token 数量的同时提升性能，实现高效且高质量的自回归图像生成。

大量实验验证了 VFMTok 在图像重建和自回归生成中的有效性，确立了预训练视觉基础模型 (VFMs) 构造高质量、高效率 Tokenizer 的主导地位。

由此可见，利用 VFM 的先验知识是构建高质量潜在空间的必由之路，也是构建下一代 Tokenizer 的关键，这比任何从零开始的正则化或约束都更根本、更有效。预训练视觉基础模型的巨大潜力值得我们在未来深入挖掘，最终可能探索出一个能够有效兼容所有生成模型的、语义丰富、高质高效的「统一 Tokenizer」。

VFMTok 论文与代码均已公开，欢迎感兴趣的同学阅读、复现以及深入讨论。

作者介绍

本文作者主要来自于香港大学 CVMI Lab 和阶跃星辰 AIGC 团队。阶跃星辰 AIGC 团队主要致力于图像生成底模、图像编辑底模、世界模型以及 RL 后训练研究和落地。欢迎志同道合的同学交流和加入，一起为 AIGC 社区贡献力量。

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]

文章原文

大模型优秀大脑齐聚硬核开源聚会，SGLang社区举办国内首次Meetup

2025-10-28 14:29:00

机器之心报道

编辑：冷猫

远在大洋彼岸的 Pytorch Conference 2025 全球开发者峰会已经走向尾声。

作为全世界最具影响力的深度学习开发者社区的重大活动之一，Pytorch Conference 最近收获了相当的关注度，展现了相当的社区活力。

SGLang 同样参加了Pytorch Conference 2025，核心成员Yineng Zhang 在大会做了相关分享。

而在同期的 10月25日，SGLang 联合美团，亚马逊云科技在北京开启了官方社区举办的国内首场Meetup见面会。

向读者们简单介绍下 SGLang。它起源于 RadixAttention，是由非营利组织LMSYS孵化的开源高性能的大语言模型和视觉语言模型推理引擎。它在各种环境中提供低延迟和高吞吐量的推理，从单个 GPU 到大型分布式集群。

SGLang 的核心特性包括：

快速后端 Runtime：提供高效服务，支持 RadixAttention 前缀缓存、零开销 CPU 调度器、预填充 - 解码解耦、推测性解码、连续批处理、分页注意力、张量 / 流水线 / 专家 / 数据并行、结构化输出、分块预填充、量化和多 LoRA 批处理。
广泛模型支持：支持多种生成模型（Llama、Qwen、DeepSeek、Kimi、GLM、GPT、Gemma、Mistral 等）、嵌入模型（e5-mistral、gte、mcdse）和奖励模型（Skywork），并易于扩展以集成新模型。兼容大多数 Hugging Face 模型和 OpenAI API。
广泛的硬件支持：可在 NVIDIA GPU、AMD GPU、Intel Xeon CPU、Google TPUs、华为昇腾 NPU 等硬件上运行。
灵活的前端语言：为 LLM 应用程序提供直观的编程界面，支持链式生成调用、高级提示、控制流、多模态输入、并行处理和外部交互。
活跃的社区：SGLang 是开源项目，并得到充满活力的社区支持，在行业内得到广泛采用，全球范围内为超过 30 万块 GPU 提供支持。

这次见面会虽说是首次举行，但在会场中熙熙攘攘着 SGLang 的社区贡献者，开发者和学者，不乏来自各个知名公司、学校或组织的成员，进行激烈的思维碰撞，充分显现出 SGLang 在国内旺盛的社区活力和发展潜能。

四小时的 Meetup 时间有些紧张，十余位大模型领域的大咖和核心开发者们分享了各自领域的见解，在 SGLang 社区的最新贡献，未来的发展方向，以及采用 SGLang 在不同业务中的应用场景。

可以说是一场高密度的硬核的开源社区的思想碰撞。

无限进步的社区

见面会的开场由硅基流动 CEO 袁进辉进行欢迎致辞。

袁进辉老师真挚的分享了他自己的职业经历，回顾 AI Infra 工程师的职业发展，并且展望未来的 AI 时代机遇，AI infra 大模型推理仍然有很好的机会。

袁进辉老师提到，做算法和做 Infra 有显著的不同：

Algorithm 更依赖创造能力，更依赖灵感，从无到有；而 Infra 更依赖归纳和抽象能力。
Infra 对延迟满足感要求高，聪明人不一定干得了，更需要团队协作。
Infra 有时间累积效应，知道 ldea 也不一定能复现，而 Algorithm 不易形成商业壁垒，窗户纸一旦捅破，天下皆知。

袁进辉老师结合自己的创业经历和深刻的思考，对于创业者，从业者的未来方向产生一些启发。

本次 Meetup 活动的上半场主要集中在 SGLang 推理架构的核心开发者的技术分享上。

SGLang 核心开发者尹良升，介绍了近期 SGLang 的技术进化的里程碑和未来路线规划。

尹良升老师着眼于架构技术进步，深度讲解了 KV Cache 分层缓存，Piecewise CUDA Graph，Spec Decoding 的重叠调度等 SGLang 的最新技术进展，能够实现不同程度的效率和兼容性优化。

在 Roadmap 部分，尹老师主要介绍了对广泛企业的支持，对各类软硬件的拓展兼容和稳定性。

随后，清华大学副教授章明星，以 Mooncake/KTransformers 与 SGLang 近期的合作进展和 2025H2 路标为主题进行了分享。

章明星老师详细讲解了集「快速传输」、「大量存储」和「易用」结合的高性能分布式 KV Cache 存储解决方案 Mooncake 与 SGLang 的 PD 分离技术相结合的工作，取得了良好的性能效果。

章老师介绍，与 SGLang 相整合的 HiCache 技术，通过多层次缓存管理（GPU、CPU、外部存储）与层页混合内存布局，结合重叠预取策略，大幅提升了 SGLang 在多 GPU 场景下的内存利用率与推理吞吐性能。

SGL 与 LLama-Factory 正在通过集成 KTransformers 实现从 CPU/GPU 混合推理到 LoRA 微调的全流程开源生态扩展，使大模型（如 DeepSeek、Kimi K2）在本地和多 GPU 环境下高效运行与微调成为可能。

该部分工作与趋境科技合作进行。

同时，在未来 Mooncake，KTransformers 也会有更多开源整合项目。

亚马逊云科技 EC2 产品解决方案架构师肖萍，以 SGLang 在纯 CPU 环境下的性能与优化研究为题做第三场分享。

肖萍老师讲道，SGLang 在 CPU 上运行适用于小型语言模型服务、传统机器学习任务，以及低成本的 MoE 模型推理；结合了 SGLang 在 CPU 环境下运行的挑战，通过优化调度、缓存复用、量化策略和底层指令级优化来提升性能、降低成本的应对方法。

除此以外，还特别提及了在单个模型，例如 DeepSeek 上的 CPU 优化方法。

上半场的最后，SGLang 量化负责人张鹏，介绍了 SGLang 的量化方案和未来路线。

张鹏老师详细讲解了 SGLang 的量化方案、量化模块和量化粒度相关的技术细节，介绍了 SGLang 目前支持的广泛量化类型，保证量化精度的三类技术方法。

同时，张鹏老师介绍了 SGLang 量化部分近期的工作：实现了 FP4 量化支持，W4AFP8 达成了实现；DeepSeekR1 和 V3 更容易单机部署；多硬件支持，并进行了代码重构工作。

未来的量化路线图聚焦于扩展应用范围、提升灵活性，并引入新型数据格式以进一步优化模型性能与效率。

受限于本文篇幅，我们不对技术细节进行过多的介绍，感兴趣的读者请参阅 SGL Project 相关页面：

https://github.com/sgl-project
https://lmsys.org/blog/

广泛应用实践

见面会的第二部分主要集中在应用和实践方面，展现了 SGLang 在不同场景下的应用现状。

下半场的第一个分享来自百度搜索架构部负责人百度搜索杨文博，主题是 Ernie 4.5 适配与百度搜索的 SGLang 实践。

Ernie 4.5 即文心 4.5 系列开源模型，杨文博老师详细介绍了百度内部对于 Ernie 4.5 模型大规模部署的系统优化方案的实践：在架构、调度、计算和硬件兼容性上全面提升，实现高性能、跨平台的大规模推理部署。

此外，杨文博老师提到，在百度搜索场景中采用 SGLang 开始于 DeepSeek V3 的分布式推理复现，随后广泛应用于 LLM 推理、蒸馏和 RL 训练。搜索架构团队对 SGLang 做了一些例如特定模型优化、小卡优化和调度优化的技术工作。

关于文心 4.5 模型在 SGLang 的适配细节，请参阅：

github.com/sgl-project/sglang/pull/7657

在搜索场景上，腾讯专家工程师曹皓紧接着分享了 SGLang 在微信搜一搜的应用实践。

在微信搜一搜业务体系中，LLM 的应用包括：深度思考，快速回答，视频号前链，深度研究四个主要场景。

曹皓老师提到，搜索业务中的目标是在有限 GPU 下实现高吞吐量与低延迟推理，确保搜索与问答类场景具备「首字快、生成流畅」的用户体验，关注首字速度 TTFT 和生成速度 TPOT 的指标。而 SGL 昂为微信搜一搜提供了高性能的 LLM 推理支持。

曹皓老师详细的讲解了针对生成流畅度，降低 PD 分离的影响；长输入场景下 TTFT 的优化；长耗时流量负载均衡以及 PD 分离规模化部署的相关技术细节和实现流程。

在行业应用场景中，大模型在 NPU 上的适配运行是非常重要的一环。华为大模型优化算法专家秦正达分享了 DeepSeek V3.2 在 NPU 上的适配和优化实践。

在 DeepSeek V3.2 的部署方案上，通过对比 MHA + 稀疏掩码；MHA + 稀疏注意力以及 MQA + 稀疏注意力优化，最终选择了 MQA + 稀疏注意力的部署方案，实现了计算量、显存访问与执行效率的平衡，在长序列推理中显著提升性能与资源利用率。

同时，秦正达老师针对 PreFill 和 Decode 的并行策略进行分析，讲解了在 NPU 上的融合算子和算子优化的相关技术细节。未来规划聚焦在三大方向：低比特量化、KV 缓存下沉与 MegaKernel 并行优化，目标是通过软硬件协同进一步提升长序列推理性能与系统吞吐效率。

机器之心修改

机器之心的 RSS 预览