←新闻详情

The New Stack更新于 10月25日 21:29

评估整个推理栈,而不只是开源模型基准测试

Assess the entire inference stack — not just open model benchmarks

AI 导读

Nebius 应用 AI 高级副总裁 Ryan Hanrui Wang 指出,公开基准测试只反映模型的最优表现,无法说明生产环境中智能体能否准确完成任务,因此应结合内部基准和 harness 评估整个推理栈。Nebius 以约 6.43 亿美元收购推理优化初创公司 Eigen AI,并通过 Token Factory 平台提供推理服务。他建议用大模型作参照扫描多个模型寻找规模甜点,例如客服任务 10B 参数可能已足够,100B 甚至 1T 参数带来的精度提升很小。

正文 · AI 翻译

令人印象深刻的基准测试结果本应让工程师能够轻松选择正确的开放模型,以实现他们被指派开发的目标。然而,事实并非如此。

基准测试表明的是开放模型的最优性能,但在生产环境中,模型必须能够反复稳定工作。挑战在于,在生产环境中还有其他因素至关重要,例如提供给模型的信息及其准确性。因此,基准测试无法告诉工程师他们正在开发的 AI 是否能准确完成任务,甚至无法说明它能否完成任务。这对于长周期 AI 任务尤为重要。

AI 云服务提供商 Nebius 应用 AI 高级副总裁 Ryan Hanrui Wang 告诉 The New Stack,重要的是将行业基准测试与内部基准测试和 harness 结合起来衡量开放模型,以确保获得组织所需的推理结果。他表示,这家总部位于荷兰阿姆斯特丹的公司始终与客户合作这样做。

Wang 是在 Nebius 收购 Eigen AI 时加入该公司的。Eigen AI 是他联合创立并担任 CEO 的推理优化初创公司,该收购于 5 月宣布,交易金额约为 6.43 亿美元;Nebius 通过其 Token Factory 平台销售推理服务。

“客户通常有自己的基准测试,因此我们可以使用他们的智能体工作流及其追踪记录,来了解我们能够达到的成功水平。我们始终与他们紧密合作来定义基准测试。”

Wang 接着补充道:“公开基准测试可能无法覆盖工程师希望推理在实际生产环境中完成的多领域任务。”他表示,这可能导致智能体任务与推理调用的真实成本不匹配。“工作流并未经过基准测试设计的检验。需要有上下文学习。”

因此,工程师和组织不应花太多时间选择开放模型;他们应该着眼于整个推理栈。模型选择应取决于工程师是需要低成本、灵活的开放模型栈,还是需要用于推理的前沿模型。

对于需要更低成本的人,Wang 表示 Nebius 会评估 Kimi 和 DeepSeek 等开放模型,以及更轻量的“flash”模型,以判断它们能否满足推理准确性需求,以及是否需要进行微调。

那些希望获得更高准确性和质量的人,通常会将范围缩小到两三个大型开放模型,然后对其进行微调以提高准确性。Wang 表示,开放模型选择只是第一步;选择之后,他们需要确保长上下文任务和缓存输入能够交付预期结果。

推理与后训练

在后训练中,Wang 表示组织会使用自己的数据来提高准确性和任务适配度,而服务层、量化、批处理、缓存和内核优化则驱动推理速度。此外,工程师应为生产流量开发缓存系统,确保针对工作负载最大化命中率,使重复输入命中缓存,而不是被重新计算。

“另一个重要因素是吞吐量,即在一定时间跨度内生成多少 token 的衡量指标,因为这是与交互性之间的主要权衡,”Wang 补充道。工程师需要在更好的利用率和更便宜的 token 与可接受的交互性——即每用户速度——之间取得平衡。

正确处理并发可确保组织有效使用开放模型;这对工程师来说是一种精细的平衡术。如果计算资源未被充分利用,token 成本就会很高。但高利用率伴随并发增加,可能会降低最终用户的每秒 token 速度。

工程师还需要关注尾部延迟,而不仅仅是平均值。“P95 和 P99 是每用户 token 速度和首 token 时间(TTFT)的重要指标;对我们的一些客户来说,他们需要等待的时间必须低于五秒,”Wang 表示。一个系统可能平均响应时间很好,但如果每二十个请求中就有一个卡住,它仍然可能不可用。

为准确性建模

工程师在考虑基准测试结果和准确性时需要谨慎。基准测试可能测试数学问题的推理能力,但如果工程师正在为客户支持开发 AI 智能体,而高情商(EQ)更重要,那么这种测试就不太有用。“因此,不同基准测试与实际生产之间存在错位,”Wang 表示。

关于每个成功任务的成本,Wang 表示工程师必须记住,如果模型不准确,便宜的 token 就毫无用处。

工程师需要考虑 AI 将执行的端到端流程。这使工程师能够为 AI 任务选择规模合适的开放模型。Wang 举了一个专用助手智能体的例子,Nebius 收集了 6,000 条追踪记录来优化一个小模型,将准确性提高了 11%,同时执行的工具调用减少了 22%。

他提出这一点,是因为它反驳了“越大越好”的倾向,但通过增加模型规模获得的准确性提升会递减。“对于这类任务,通常存在一个临界点,”Wang 表示。对于客户支持这样的任务,他说,100 亿参数可能就足够了,而 1000 亿甚至 1 万亿参数带来的准确性提升微乎其微。“我们想做的是找到最佳平衡点。”

工程师可以将大型模型作为参照点,然后用其组织数据调整推理,以找到适合该任务且具有正确准确性和规模的开放模型。

“我们通常会扫描多个模型,以最大的模型作为参照,来判断模型规模的甜点在哪里,”Wang 表示。“对于复杂的任务,我们可以将复杂任务拆解为更小的子任务,与客户一起工作,从而连接工作流,然后就可以使用更小的模型。”

Wang 将这一过程描述为分工,并引用了著名经济学家亚当·斯密。

这种方法体现了 AI 工程成熟的过程。与技术和工程史上的每个领域一样,最初的淘金热追求的是越大越好。随着工程逐渐成熟,重点转向结果和工程卓越性,因此也转向与懂得如何实现这些目标的合作伙伴合作。

有时这意味着更大的模型;另一些时候,小型细分开发才是最佳选择。

文章《评估整个推理栈——而不只是开源模型基准测试》首发于 The New Stack。

来源

The New Stack