Baseten VibeQwen 基准测试最多比 vLLM 快 90%，但有一个前提

Baseten 表示，其 VibeQwen 引擎在 Claude Code 针对一项严格限定的部署进行一周优化后，性能最多比 vLLM 高出 90%。Baseten VibeQwen 基准测试将 Qwen-3.6-35B-A3B、NVFP4 权重与单块 NVIDIA B200 GPU 配合使用。

这一结果听起来像是对最成熟的开源推理引擎的直接胜利。但更恰当的理解是，它挑战了这些引擎的设计优先级。VibeQwen 针对一种模型、加速器、精度格式和工作负载进行了优化，而 vLLM 支持广泛且不断变化的部署环境。

这项实验也改变了编码代理的角色。Claude Code 并非只是提出零散的 CUDA 内核建议。根据 Baseten 的说法，它组装出一个可运行的推理引擎，部署候选方案，测量生产端点，检查准确性，并进行了大约一周的迭代。

这些醒目的数字仍是 Baseten 自己的基准测试结果。VibeQwen 尚未接受广泛的独立测试，且所报告的 90% 优势出现在有利于推测解码的重复性结构化文本上。更重要的问题是，这种高度专用、由代理驱动的过程能否成为可重复的工程实践，而不只是令人印象深刻的实验室成果。

Baseten VibeQwen 基准测试实际测量了什么

Baseten 最强的结果来自一个范围狭窄、经过明确优化的配置，并非 vLLM 的通用替代方案。

Baseten 工程师 Shawn Rushefsky 于 2026 年 10 月 2 日发布了这项实验。他的推理基准测试介绍了一款为 Qwen-3.6-35B-A3B 生成的引擎，采用 NVFP4 精度并运行在一块 B200 加速器上。

NVFP4 是一种四位浮点格式，旨在减少内存传输并加速兼容 NVIDIA 硬件上的计算。这一精度选择很重要，因为推理速度高度依赖于模型、量化格式、GPU 架构和可用内核。

Baseten 将生成的引擎命名为 VibeQwen。该公司将其与经过调优的 vLLM 0.25.1 部署进行了比较，两者使用相同的单块 B200 硬件。

据称，在单流、适合推测器的文本上，VibeQwen 每秒生成 1,792 个输出 token。在相同的已报告测试条件下，vLLM 部署每秒生成 943 个输出 token。

这一差异形成了性能提升 90% 的标题数字。“适合推测器”指的是重复性或结构化的输出，在这类输出中，推测解码器可以提出多个可能的 token，再并行进行验证。

首个 token 时间，即 TTFT，从 vLLM 的 28 毫秒降至 VibeQwen 的 12 毫秒。TTFT 衡量的是提交请求与收到第一个生成 token 之间的延迟。

Baseten 将这一变化描述为提升了 2.33 倍。更低的延迟对交互式助手、代码补全和语音界面尤为重要，因为用户会立即注意到最初的停顿。

据称，VibeQwen 在更高流量下也保持领先。在并发数为 32 时，一个副本每秒生成 10,307 个输出 token，而 vLLM 为 6,030 个。

这意味着总输出吞吐量高出 71%。这一结果表明，该引擎的优势并不限于孤立的单用户测试，尽管测试仅覆盖了一个已报告的并发级别。

此次比较使用了 vLLM 0.25.1，Baseten 称其在实验开始时为当前版本。该项目的发布历史显示，该版本是一个包含两项针对性错误修复的补丁版本。

Baseten 并未声称每种模型、提示词分布或 GPU 都会带来相同的优势幅度。已发布的结果仅涉及这一特定的模型、硬件和工作负载组合。

这一差异应当决定买方如何解读这些数字。针对特定文本的 90% 领先幅度，是优化空间的有意义证据，但并不意味着通用 AI 服务的性能普遍提升了 90%。

因此，这项基准测试改变了竞争问题。团队如今必须考虑：对于稳定、高吞吐量的工作负载，广泛兼容的运行时是否仍然是最佳终点。

为什么编码代理能够找到如此大的优化空间

推理优化很适合编码代理，因为速度、输出质量和硬件行为都能通过可测量的反馈进行测试。

Baseten 借鉴了 MetaInfer 的思路。MetaInfer 是一个实验性系统，将 LLM 视为推理软件的编译器。该系统并非为每种环境维护一个引擎，而是围绕明确的运行时约束生成紧凑的软件。

MetaInfer 项目将编码代理与一个契约知识库结合起来。该知识库记录约束、测试、有效模式，以及从失败尝试中获得的经验。

代理可以提出一种实现方案，将其编译，执行正确性测试套件，测量性能，并修改代码。每次循环返回的信号都比许多普通软件任务更清晰。

例如，视觉重设计部分依赖于人类判断。推理引擎则提供延迟、吞吐量、GPU 利用率、内存消耗和输出准确性等硬性指标。

这种明确性使长期优化成为现实。代理无需说服审查者某个候选方案感觉更快；它必须在满足预定义正确性门槛的同时，击败数值基线。

Baseten 通过 SSH 向 Claude Code 提供了 MetaInfer 材料、模型权重和一台 B200 工作站。它还提供了全精度模型作为准确性预言机，即用于检查输出质量的可信参考。

最初的目标颇具挑战性。Baseten 要求代理在性能指标上比 vLLM 快 20%，同时不能损失相对于 NVFP4 基线的准确性。

Claude Code 可以在 Baseten 上部署候选方案，并对每个端点运行 AIPerf。AIPerf 是一种工作负载生成器，用于测量已部署模型服务的行为，而不只是为孤立内核计时。

Rushefsky 表示，该过程持续了大约一周。它消耗了约 17 亿个 token，其中绝大多数为缓存输入，并使用了约 200 个 B200 小时。

据称，该引擎在最初几天内就达到了与 vLLM 持平的水平。Baseten 允许系统继续搜索，最终得到了更大的优势幅度。

人工监督并未消失。Rushefsky 偶尔会在系统过度聚焦于某一种流量形态时重新引导它。

当拟议改动改变数值输出时，Claude Code 也会暂停。Baseten 最终接受了与其 NVFP4 参考实现之间的细微差异，前提是相对于 BF16 模型的整体准确性至少同样出色。

BF16 即 bfloat16，其数值范围和精度都高于四位格式。与 BF16 实现进行比较，可以揭示量化或内核改动是否损害模型质量。

这些控制措施说明，这不只是一次延长版的代码生成提示。Baseten 构建了一个环境，使代理能够行动、观察结果、保留有用知识，并在接受高风险改动前面对关卡约束。

这项实验还借鉴了开源实现。Baseten 允许代理检查 vLLM 和 TensorRT-LLM，并在适当情况下使用预优化内核。

这一选择使该项目与生产工程更相关，但作为无辅助算法创新的证据则较弱。VibeQwen 代表的是代理主导的集成与专用化，结合了现有组件和新编写组件。

结果仍然值得关注。工程师长期以来一直使用性能分析器、基准测试和自动调优系统。在这里，据称 LLM 协调了内核、引擎逻辑、服务行为、部署和验证等环节的决策。

专用引擎正在给通用运行时施压

核心竞争并非 VibeQwen 与 vLLM 作为产品之间的较量，而是专用化与通用性两种工程策略之间的较量。

vLLM、SGLang 和 TensorRT-LLM 解决的是广泛的兼容性问题。它们必须支持众多架构、量化格式、加速器、批处理模式、API 和运营需求。

这种广度具有巨大的实际价值。团队无需先围绕每个特殊层、内核或服务模式构建运行时，就能部署新模型。

但它也带来了抽象层。调度器、模型运行器、兼容层、回退路径和可配置内核增加了分支，而单一用途的引擎可能会将其消除。

MetaInfer 的论点是，这些抽象层会留下未被利用的性能空间。一旦部署变得稳定，代理就可以围绕其确切约束对引擎进行专用化。

VibeQwen 面向运行在 B200 上、采用 NVFP4 的 Qwen-3.6-35B-A3B。它不需要为无关模型或旧款加速器保留优雅的执行路径。

专用引擎可以融合那些始终同时发生的操作。它可以移除不服务于所选工作负载的转换、内存传输、运行时检查和通用接口。

Baseten 早前的内核优化工作说明了可搜索的空间。其代理据称将模型级性能分析与扩散模型和语言模型上的逐内核实验结合起来。

在这些项目中，有效的改动包括预打包常量缩放值、融合归一化与量化，以及移除中间内存操作。这些技术能在不改变模型预期计算的情况下减少工作量。

VibeQwen 实验将这一思路扩展到了完整的服务栈。生产端点涉及的不只是快速矩阵乘法。

请求必须通过 API 进入，经过调度和批处理，执行模型内核，流式传输 token，并共享有限的 GPU 内存。只优化一个内核，可能无法触及主要瓶颈。

编码代理可以研究这些层之间的交互。它还可以不知疲倦地运行多项实验，也不会执着于某个手工设计的实现。

这种压力并不意味着通用引擎已经过时。相反，它可能改变这些引擎在部署生命周期中的位置。

团队可能先从 vLLM 开始，因为它提供兼容性、持续维护和熟悉的服务接口。一旦流量变得可预测，代理就可以为该生产配置生成专用分支。

通用引擎仍将作为参考和后备方案。自定义引擎则将处理那些节省的延迟或增加的吞吐量足以证明其维护负担合理的工作负载。

这类似于基于性能剖析的编译，但优化目标还包括应用行为和服务基础设施。代理会在源代码、内核、运行时配置和部署决策之间进行搜索。

这种方法还可能加大对成熟引擎开放更多专用化接口的压力。模块化运行时可以让代理优化选定路径，而无需替换整个服务系统。

vLLM 并未停滞不前。其发布版本会定期改变模型运行器、推测解码、量化支持和硬件路径。

因此，Baseten VibeQwen 基准测试应被视为一场动态竞争中的快照。基线可以改进，而来自 VibeQwen 的可复用发现最终可能进入更广泛的运行时。

持久的变化在于战略层面。对于有价值的工作负载而言，通用性能不再必然是优化的最终阶段。

90% 的说法存在重要边界

这一基准测试足够可信，值得进一步研究，但其范围过窄且依赖自述，尚不足以支持普遍性的性能结论。

最大的顾虑在于工作负载选择。Baseten 表示，90% 的结果来自重复性强、结构化且适合其推测器的文本。

推测解码通过提出多个未来 token 候选并同时验证来加速生成。其效果取决于这些候选与目标模型实际会生成的内容相符的频率。

结构化代码、模板和重复数据可能带来较高的接受率。开放式散文、罕见语言、创意写作或快速变化的上下文，表现则可能不同。

Baseten 报告称，VibeQwen 在其测试的每一种流量模式中均处于领先地位。然而，公开摘要未提供足够细粒度的数据，无法重建每种提示词分布和接受率。

该基准测试也来自开发并托管该引擎的公司。尚无独立机构在相同硬件和模型权重下复现 VibeQwen 的结果。

这并不意味着这些测量无效。只是，在代码、测试夹具或第三方结果支持直接复现之前，相关表述应限定为“Baseten 表示”。

准确性标准同样需要谨慎对待。Baseten 最初要求相较于 NVFP4 参考实现不损失准确性。

在优化过程中，团队允许出现微小的数值差异，前提是相较于 BF16 基线的整体准确性至少不下降。这是合理的工程折中，但需要细致到任务层面的评估。

平均分数可能掩盖特定领域中的性能退化。企业需要测试覆盖自身的提示词、工具调用、结构化输出、安全行为和长上下文工作负载。

运行可靠性则是另一项悬而未决的问题。一次基准测试无法衡量数月生产运行中的升级、格式错误请求、分词器变化、驱动更新或罕见序列长度。

通用引擎的可信度部分来自广泛使用。更大的贡献者和客户群体会发现并修复更多边缘情况。

自定义引擎则将责任集中起来。同样是那些消除开销的专门化措施，也可能对形状、批次、精度或硬件行为形成脆弱假设。

开发成本同样重要，即使不标注公开价格。VibeQwen 据称消耗了约 200 个 B200 小时和 17 亿个模型 token。

对于规模大且持续存在的工作负载，这些投入可能是合理的。但如果模型每周都在变化，或流量规模过小、无法收回工程投入，其吸引力便会降低。

实验的迭代预算也使直接比较变得复杂。vLLM 必须将开发工作分配给众多用户、模型和设备。

Claude Code 则花了一周时间优化一个目标。因此，VibeQwen 的领先既展示了集中投入的价值，也展示了代理编写软件的优越性。

Baseten 的第二项实验为复用提供了令人鼓舞但不完整的证据。该公司将其扩展后的知识库应用于一个 SAM 3.1 图像分割服务器。

这个名为 Sammie 的系统据称在一张 H100 上每秒处理 91 张图像。Baseten 表示，在数天时间和约 2 亿个 token 后，这比 Meta 的参考服务器高出 50%。

模型、GPU、架构和基线都与 VibeQwen 不同。Baseten 还指出，实验缺少对照组。

因此，Sammie 表明累积知识可能有所帮助，但并未隔离知识库本身的贡献。更快的完成速度也可能源于更容易的工作负载或其他流程差异。

最稳妥的解读既不是否定，也不是庆祝。VibeQwen 发出了一个严肃信号：编程代理能够协调整体系统层面的深度优化。

但它尚未证明，企业可以按需生成可靠的自定义引擎，在模型更新中持续维护它们，并稳定击败由专家维护的运行时。

为何这一结果的意义超出单个 Qwen 部署

更大的机会在于一种部署流程：在模型、硬件和流量模式明确后，优化才正式开始。

传统推理框架必须在尚不了解每位用户精确工作负载时作出设计决策。由代理构建的引擎则颠倒了这一顺序。

它们从部署事实出发。这些事实可能包括选定模型、预期提示词长度、输出分布、并发目标、精度要求和加速器类型。

企业代码助手便是一个有用的例子。其输出通常包含语法、缩进、常见库调用以及重复出现的项目约定。

这种规律性可以支持推测解码。较低的 TTFT 也会提升内联代码补全的交互体验。

语音系统的优先级不同。如果首个 token 能迅速到达，且生成速度足够稳定以保证自然语音，它可能接受较低的总吞吐量。

批量摘要服务则可能更看重整体吞吐量。当数千份文档具有可预测的输入和输出范围时，它可以容忍更慢的首个 token。

通用运行时必须兼顾三者。专用引擎则只需为其中一种优化。

这种方法可能让模型选择更具弹性。一个曾无法满足延迟目标的模型，可能在针对工作负载进行优化后变得可行。

这种可能性会影响基础设施采购方和应用团队。模型质量比较往往假设，服务软件已经挖掘了绝大部分可用性能。

VibeQwen 对这一假设提出了挑战。运行时选择可能显著改变在固定硬件上，哪个模型能提供最佳质量、响应速度和容量。

这对混合专家模型尤其重要。Qwen-3.6-35B-A3B 每个 token 仅激活其总参数集的一部分，因此呈现出独特的路由和内存行为。

了解确切专家布局和量化方案的运行时，可以针对这些模式进行优化。通用引擎则必须保留面向其他架构的执行路径。

Baseten 已经通过推测解码探索过另一条路径。其 DFlash implementation 据称通过并行预测多个 token，提升了 Qwen3-8B 的性能。

此前的工作需要针对特定模型进行训练和实现。VibeQwen 则强调由代理围绕现有模型和量化权重协调整体优化。

这两种方法可以汇合。优化代理可以在草稿模型、内核融合、缓存、批处理和内存布局变更之间作出选择。

这种广泛搜索很有价值，因为瓶颈会随工作负载而变化。提升解码速度后，调度器开销、网络延迟或预处理可能暴露为下一个限制因素。

可复用知识库或许会成为最重要的资产。成功的内核固然重要，但被记录下来的失败可以避免未来代理重复昂贵的实验。

不断扩充的硬件约束与验证规则库，能够减少构建每个新引擎所需的工作量。Baseten 的 Sammie 测试是观察这一效应的早期尝试。

如果复用效果得到提升，优化就不再像定制咨询项目，而开始类似于生产 AI 服务的自动化编译阶段。

这一转变需要严谨的记录。团队必须保留基准测试输入、编译器版本、驱动、内核、模型哈希、准确性测试套件和部署配置。

否则，一个快速结果会变成无法复现的产物。代理或许知道自己如何取得该分数，但组织无法安全地复现或审计它。

这正是人类工程仍然处于核心地位的原因。开发者需要定义有意义的目标、防止基准测试投机、选择验证数据，并决定哪些性能与质量之间的权衡可以接受。

VibeQwen 并未消除这一责任。它让编程代理能够在工程师定义边界之后，搜索更大的实现空间。

三个信号将决定代理构建的引擎能否持久存在

下一项考验是能否在不同工作负载、生命周期变化和独立环境中复现，而不是再创造一项孤立纪录。

第一个信号是可复现的 VibeQwen 软件包。独立团队需要获得足够的代码、配置、提示词数据和评估逻辑，以重新运行比较。

复现应覆盖普通散文、代码、结构化输出、多种语言、长上下文和不同并发水平，同时还应报告推测接受率。

广泛适用的结果将强化 Baseten 的论点：专门化挖掘了持久的性能余量。若优势大幅缩小，则意味着这一头条结果仅适用于有利流量。

第二个信号是在变化中存活。模型提供商会修订权重、分词器、量化方案和服务要求。

NVIDIA 也会更新编译器、驱动、库和 GPU 世代。一款有用的自定义引擎必须能吸收这些变化，而无需再花一周进行脆弱的重建。

应关注代理将 VibeQwen 移植到另一版本 Qwen 或不同加速器的速度。比较还应包括人工审查时间、计算预算，以及部署后发现的性能退化。

快速且可靠的迁移将支持知识库能够累积价值这一观点。反复依赖人工救援则意味着，自定义引擎仍是昂贵的专家项目。

第三个信号是通用运行时的回应。vLLM、SGLang 和 TensorRT-LLM 可以采用新的内核、专门化接口或自动调优技术。

一旦维护者理解相关执行路径，VibeQwen 的部分收益可能进入共享引擎。这会缩小直接的基准差距，同时验证基础优化工作的价值。

更深入的回应将使用户能够在受维护的运行时中生成专用执行计划。这种混合模式可以保留兼容性，同时为固定部署消除开销。

最终胜者可能既不是完全生成的引擎，也不是完全通用的引擎。它可能是一个具备代理控制专门化边界和强大回退路径的通用框架。

对开发者而言，眼下的教训很实际：应将推理软件视为可测量的组件，而不是模型权重外一层可随意替换的包装。

在选择优化目标前，记录提示词和输出分布。使用接近生产环境的请求，测试 TTFT、输出 token 延迟、吞吐量、内存、准确性和长尾表现。

对于企业采购方，应询问供应商的基准测试优化了什么，又排除了什么。单一的峰值吞吐量数字，几乎无法说明交互延迟、质量、可移植性或运维成本。

还应询问报告中的增益是否能在多样化数据上持续存在。Baseten VibeQwen 基准测试最有价值的作用，是开启一次审慎评估，而不是终结它。

这一实验提供了自主系统工程的引人注目的缩影。它也显示出，代理为何需要精心设计的测试和由人类定义的边界。

未来一到三个月将揭示 VibeQwen 能否实现可复现、可移植和可维护。哪一种结果最可能改变你的部署计划：独立复现、快速模型迁移，还是在 vLLM 内部实现类似的专门化？