LFM2.5-24B-A2B对决Qwen3.6：本地Agent还是编程利器

Liquid AI在10月13日发布了LFM2.5-24B-A2B，这是一款24B参数、激活仅2B的MoE模型，在M5 Max上跑出184 tokens/s的推理速度。它和Qwen3.6-35B-A3B之间的选择，本质上是在问：你更需要一个快速响应的本地Agent，还是一个编程能力更强的代码助手？

两款MoE模型的定位差异

LFM2.5-24B-A2B和Qwen3.6-35B-A3B都采用了MoE（混合专家）架构，但设计哲学截然不同。LFM2.5总参数24B、激活2B，Qwen3.6总参数35B、激活3B左右。Liquid AI明显把筹码押在了推理效率上——184 tokens/s的本地吞吐意味着它能以接近实时的方式驱动Agent循环。

Qwen3.6-35B-A3B则延续了Qwen系列在代码任务上的一贯优势。更大的总参数量给了它更宽的知识覆盖面，在SWE-Bench Verified这个评估真实GitHub issue修复能力的基准上，Qwen3.6取得了领先。

MoE（Mixture of Experts，混合专家）架构的核心思想是把单个稠密前馈网络拆分成多个并行的“专家”子网络，再由一个路由网络根据每个token的语义决定激活其中少数几个。这样一来，模型的总参数量可以做得很大（承载更广的知识），但每次前向推理实际参与计算的参数却很少，从而大幅降低算力与显存带宽开销。文中反复出现的“24B-A2B”“35B-A3B”正是这个逻辑的体现：前一个数字是总参数量，后一个是每个token平均激活的参数量。需要注意的是，激活参数少并不等于能力线性缩水，专家池越大、路由越精准，模型在复杂任务上可调动的知识就越多，这也是Qwen3.6以约3B激活仍能在代码任务上保持优势的原因。

工具调用：LFM2.5的主场

Liquid AI公布的数据显示，LFM2.5-24B-A2B在工具使用类benchmark上击败了Qwen3.6-35B-A3B。这个结果并不让人意外——激活参数少、推理速度快，恰恰是Agent场景最需要的特性。

Agent工作流的核心瓶颈往往不在单次推理的智力上限，而在多轮工具调用的延迟累积。每次调用函数、解析结果、决定下一步，都需要一次完整的前向推理。184 tokens/s的速度让LFM2.5在这类循环中占据天然优势。对于需要频繁调用API、操作文件系统、执行shell命令的本地Agent任务，响应速度直接决定了用户体验的流畅度。

LFM2.5在M5 Max上达到184 tokens/s，意味着它可以在消费级硬件上流畅运行。对于那些希望把Agent部署在本地、避免云端调用成本和隐私风险的开发者来说，这是一个有吸引力的选项。

编程能力：Qwen3.6的护城河

但在SWE-Bench Verified上，Qwen3.6-35B-A3B扳回一局。这个基准测试评估的是模型解决真实开源项目issue的能力，要求模型理解代码库上下文、定位bug、生成正确的补丁。这类任务对模型的代码理解深度和推理链条长度有很高要求。

Qwen系列在代码生成和软件工程任务上的积累在这一轮对比中体现出来。35B的总参数量虽然激活只有3B左右，但专家池更大，在处理复杂代码逻辑时能调动更多知识。对于需要深度理解代码库、进行多文件重构、或者解决刁钻bug的场景，Qwen3.6的优势是结构性的。

SWE-Bench Verified是评价代码模型能力的一个关键基准，它从真实开源项目（如Django、sympy等）中抽取已合并的GitHub issue及其配套测试，要求模型在给定代码库上下文的条件下自主定位问题、修改源码，并让原本失败的测试通过。与只考察函数级补全的HumanEval不同，它更贴近真实软件工程：模型必须理解跨文件的调用关系、遵循项目既有风格，并生成可被仓库接受的补丁。该基准的“Verified”子集由人工筛选，剔除了描述模糊或测试不可靠的样本，因此分数更具参考价值，也更能区分模型在实际开发辅助场景中的实用程度。

怎么选：看你的工作流

这两款模型的对比没有绝对赢家，选择取决于你的具体场景。如果你的日常工作是构建和运行本地Agent——比如自动化脚本编排、浏览器操作、文件管理——LFM2.5-24B-A2B的速度优势会让整个体验顺畅很多。184 tokens/s的吞吐在M5 Max上已经接近交互式响应的阈值。

如果你的核心需求是代码辅助——写新功能、修bug、理解遗留代码——Qwen3.6-35B-A3B在SWE-Bench Verified上的表现说明它更适合这类任务。多花一点推理时间换取更高的代码正确率，对于编程场景是划算的。

一个务实的做法是两者都部署：用LFM2.5驱动日常Agent任务，在处理复杂代码问题时切换到Qwen3.6。两款模型都是开源可本地部署的MoE架构，硬件需求在消费级高端设备范围内。

本地Agent的拐点

LFM2.5-24B-A2B的发布传递了一个信号：小激活参数的MoE模型正在让本地Agent变得实用。24B总参数、2B激活的配置，在保持合理知识容量的同时把推理成本压到了消费级硬件能承受的水平。184 tokens/s不是一个实验室数字，而是M5 Max上的实测结果。

当Agent的响应速度接近人类阅读速度时，本地部署的体验就开始和云端API拉开差距——没有网络延迟、没有按token计费的心理负担、没有数据出境的合规顾虑。LFM2.5在这个方向上迈出了实质性的一步，而Qwen3.6则证明了代码能力仍然需要更大的专家池来支撑。两者服务于不同的需求，共同推动着本地AI工作流的成熟。

tokens/s（每秒生成token数）是衡量推理吞吐的核心指标，它直接决定用户感知的响应速度。作为参照，人类阅读速度约为每秒4–8个英文单词（大致相当于5–10个token），因此当模型的生成速度达到接近或超过这一数量级时，交互体验就从“等待结果”转变为“实时对话”。184 tokens/s意味着生成一段约300 token的回复只需不到两秒。此外，agent场景的瓶颈不在单次生成，而在多轮工具调用的延迟叠加——每一轮“思考—调用—解析—再思考”都要走一次完整前向推理，吞吐越高，整个循环的累计延迟越低，这正是低激活MoE模型在本地Agent中的价值所在。