在大型语言模型领域，参数规模的扩张与推理成本之间的矛盾始终是工程实践的核心挑战。Liquid AI 近期发布的 LFM2-24B-A2B 给出了一个颇具参考价值的答卷：这个拥有 24B 总参数的稀疏 MoE（Mixture of Experts）模型，通过仅 2.3B 活跃参数的前向传播路径，在标准笔记本硬件上实现了可用的推理性能。从架构搜索到部署策略，该模型的设计思路对关注边缘 AI 落地的团队具有较强的借鉴意义。
LFM2 混合架构的底层设计
理解 LFM2-24B-A2B 的扩展逻辑，需要先回顾 LFM2 系列的底层架构选择。与传统 Transformer 不同，LFM2 采用了一种硬件感知的混合设计：高效的门控短卷积块（gated short convolution blocks）与少量的分组查询注意力（Grouped Query Attention, GQA）块交替排列。这一架构并非凭空设计，而是通过硬件在环的架构搜索（hardware-in-the-loop architecture search）得出 —— 团队在真实硬件上测量不同配置的推理延迟与内存占用，最终选定了卷积与注意力约 3:1 的配比方案。
这种设计的核心优势在于 prefill（预填充）与 decode（解码）阶段的双重效率。短卷积块擅长捕获局部上下文模式，计算开销远低于标准注意力层；GQA 则在保持多头注意力表达能力的同时，将键值缓存的内存占用大幅压缩。对于需要在 CPU 或集成显卡上运行 24B 参数模型的场景，这一架构选择直接决定了模型是否具备现实部署的可行性。
从 8B 到 24B 的扩展路径
LFM2-24B-A2B 并非从头设计，而是基于已有的 LFM2-8B-A1B 向上扩展。扩展策略可以归纳为两个维度的加法：深度与专家数量。具体而言，模型从 8B 版本的 24 层堆叠增至 40 层，MoE 块中的专家数量从 32 个翻倍至 64 个，同时保持 top-4 路由策略不变。隐藏层维度维持在 2048，注意力配置与 8B 版本一致。
值得注意的是，活跃参数的增速远低于总参数的增速。24B 版本的总参数约为 8B 版本的 3 倍（24B 对 8.3B），但活跃参数仅从 1.5B 增至 2.3B，增长约 1.5 倍。这一差异源于每个专家的中间维度被压缩 —— 从 8B 版本的 1792 降至 1536，以在更深的模型中容纳更多专家而不突破活跃参数预算。前两层保持全密集连接以确保训练稳定性，注意力层占总层数的比例维持在约 25%（10/40），从而继承 LFM2 系列快速 prefill 的核心特性。
这种扩展思路的本质是在模型容量（总参数）与推理成本（活跃参数）之间刻意制造不对称：模型可以学习更丰富、更细粒度的专业知识，但每次前向传播只需激活一小部分路径。对比同级别的 MoE 竞品 —— 如 Qwen3-30B-A3B（30.5B 总参数，3.3B 活跃）和 gpt-oss-20b（21B 总参数，3.6B 活跃）——LFM2-24B-A2B 在活跃参数维度上更为紧凑，这直接转化为更低的推理延迟和更少的内存带宽消耗。
基准测试与效率验证
Liquid AI 公布的基准测试覆盖了从 350M 到 24B 的完整 LFM2 家族，横跨近 100 倍的参数规模。在 GPQA Diamond、MMLU-Pro、IFEval、IFBench、GSM8K 和 MATH-500 等标准评测集上，质量指标随总参数规模的对数线性增长，未在小模型阶段出现明显的性能天花板。这一观察表明 LFM2 的混合架构在扩展过程中保持了相对可预测的 scaling law，而非依赖特定的 trick 或 overfitting。
更具实际参考价值的是部署效率的对比。在 AMD Ryzen AI Max+ 395（集成显卡，32GB 统一内存）上，使用 llama.cpp 运行 Q4_K_M 量化版本的 LFM2-24B-A2B，解码吞吐量在 128K 上下文长度下仍可达到数十 tokens/s 的水平。对比同级别的 MoE 模型，LFM2-24B-A2B 在 decode 阶段的优势尤为明显 —— 这与其卷积块占主导的架构设计高度相关。
在数据中心场景下，单张 H100 SXM5 GPU 配合 vLLM 部署时，LFM2-24B-A2B 在 1024 并发请求的连续批处理测试中达到约 26.8K tokens/s 的总吞吐能力（输入 1024 tokens，输出 512 tokens），超过了 Qwen3-30B-A3B 和 gpt-oss-20b 的同类测试结果。吞吐量的优势主要来自两个因素：GQA 显著降低了键值状态的内存占用，使更大批次的 prefill-decode 交织成为可能；较少的活跃参数意味着每次推理的计算密度更低，在内存带宽受限的场景下更容易跑满算力。
部署生态与工程现实
一个模型能否真正落地，生态支持往往与技术指标同样重要。LFM2-24B-A2B 在发布时即实现了主流推理框架的 day-zero 支持：llama.cpp、vLLM 和 SGLang 均提供原生支持。在量化选项方面，GGUF 格式提供了从 Q4_0 到 Q8_0 以及 F16 的完整覆盖，其中 Q4_K_M 是针对混合架构优化的量化方案，在压缩率与输出质量之间取得了较好平衡。
模型设计时明确瞄准了 32GB RAM 的部署边界。这一约束意味着它可以在配备集成显卡的主流消费级笔记本电脑（如 MacBook Pro 32GB 版本或 Windows AI PC）上运行，而不仅仅局限于数据中心或高配工作站。Liquid AI 同时在推进 NPU 方向的适配工作，目标是将 MoE 模型的推理能力进一步下沉到移动设备和边缘硬件 —— 当活跃参数控制在 2B 左右时，这一目标在功耗和延迟上具备一定的可行性。
Scaling 的工程启示
LFM2-24B-A2B 的扩展路径提供了一个具体的案例：在保持推理成本可控的前提下，通过增加总参数而非活跃参数来提升模型容量。核心工程权衡在于：更深的层数赋予模型更强的表示能力，更多的专家提供更细粒度的路由选择，但活跃路径的宽度决定了实际部署的硬件门槛。对于希望在边缘设备上运行大规模模型的团队，这一策略的关键参数可归纳为：活跃参数预算（建议控制在 2-3B 以内以适配消费级硬件）、总参数与活跃参数的比例（3:1 到 10:1 的稀疏度在当前硬件上性价比较高）、注意力与卷积的配比（1:3 左右的配置在 prefill/decode 效率上较为均衡）。
该模型当前基于 17T tokens 的预训练 checkpoint 发布，官方预告将在预训练完成后推出 LFM2.5-24B-A2B 版本，届时将加入额外的后训练和强化学习改进。对于关注前沿模型架构演进和边缘部署实践的工程师，持续跟踪这一产品线的后续迭代将有助于把握高效大模型的发展趋势。
资料来源：Liquid AI 官方博客（LFM2-24B-A2B: Scaling Up the LFM2 Architecture）