百度 ERNIE 5.5 Flash Preview 发布：280B 稀疏模型仅激活14B参数

摘要：百度推出 ERNIE 5.5 Flash Preview，总参数量280B、每个 token 仅激活约14B参数，定位为兼顾代码与智能体任务的高吞吐稀疏模型。社区汇总的 Agentic Coding 指数由12项编码基准构成，其中Terminal-Bench v4.0与DeepSWE v1.1合计占31%，显示其优势集中在终端操作和软件工程任务。不过，现有材料未披露权重许可、推理框架支持、上下文长度、量化效果及完整实测数据；该指数也不等同于综合 Agent 能力，部署选型仍需核验官方报告和独立基准。

---

核心发布

百度 ERNIE 5.5 Flash Preview 将总参数量控制在280B，同时把每个 token 的激活参数压至约14B，激活比例约为5%。这意味着它更接近典型的稀疏 MoE 模型：每个 token 只经过部分专家，而不是把280B参数全部激活。若官方架构确为 MoE，其目标就是在共享通用能力的同时降低每个 token 的矩阵乘计算量，并把更大的总容量用于容纳专业化知识。

现有社区材料没有给出专家数量、路由粒度、共享专家配置或注意力实现，因此不能仅凭“14B Active”推导其真实吞吐。MoE 的实际成本不只取决于激活参数，还包括路由开销、专家权重驻留显存、All-to-All 通信以及小 batch 下的利用率下降。

编码与智能体能力

社区发布的榜单截图显示，ERNIE 5.5 Flash Preview 在一项“Agentic Coding”聚合指数中表现突出。该指数完全由编码和软件工程任务构成，其权重分布为：Terminal-Bench v4.0 占16%，DeepSWE v1.1 占15%，FrontierCode 2.0 占11%，Code Migration 占9%，Terminal-Bench v2.1 占8.5%，SRE-Bench 占8%，SWE-bench Pro 占7.5%，Code Arena Elo 占6.5%，Program-Bench 占6%，Vibe Code Bench v1.1 占5.5%，SciCode 占4%，LiveCodeBench v6 占3%。

其中，Terminal-Bench v4.0 与 DeepSWE v1.1 合计占31%，因此该成绩对终端任务、仓库级问题解决和智能体软件工程能力的依赖较强。FrontierCode、代码迁移和 SRE-Bench 又进一步覆盖生成、跨仓库修改与运维场景。不过，原始帖子没有列出模型在各单项基准上的分数、置信区间、重复运行次数或失败案例，无法复算最终聚合名次。

评测应如何解读

该指数不是综合 Agent 评测，也不能直接等同于模型完成真实软件工程任务的成功率。它虽然覆盖12项编码相关基准，但不同测试测量的是不同能力：Terminal-Bench 强调终端环境中的任务完成，DeepSWE 与 SWE-bench Pro 关注真实仓库修改，Code Arena Elo 带有主观对战属性，LiveCodeBench 更偏向持续更新的编程题。因此，总分更适合用作筛选信号，而不是模型能力公式。

聚合榜单还容易受到基准污染、数据泄漏和题目适配影响。社区截图若没有给出评测日期、提示词模板、采样次数、工具配置、pass@k 计算方式和原始输出，就无法判断成绩是否可复现。尤其对于终端智能体，是否允许多轮重试、是否提供仓库历史、执行器超时和重试预算，都可能显著改变结果。

工程权衡

参数效率不等于部署效率。 280B 总参数即使采用4-bit量化，裸权重仍约需140GB理论存储空间；若采用8-bit，则约为280GB，还未计入量化比例尺、元数据、KV Cache和运行时开销。因此，单张消费级GPU或常规工作站并不适合直接承载该模型。其现实部署方向更可能是多GPU专家并行、跨节点切分，或由云平台托管。

MoE 的瓶颈会从计算转向通信。 若采用细粒度专家路由，每个 token 都要经历 token dispatch、专家计算和 combine；在多节点环境中，All-to-All 可能成为延迟主因。增加专家并行度虽然可以容纳更多权重，却也会提高跨卡流量和网络拥塞。批量大小、专家容量因子、路由负载不均衡以及 KV Cache 长度，都会影响端到端表现。

高活跃参数不等于低显存。 推理时只计算14B参数可以降低 FLOPs，但280B权重仍需被存储；在实际服务中，显存容量、显存带宽和跨节点拓扑可能比活跃参数量更早成为瓶颈。若上下文窗口较大，KV Cache还会继续推高显存占用。

开发者落地建议

1. 等待官方模型卡、权重许可和服务接口说明，确认是否提供开放权重、允许商业使用，以及是否支持 Function Calling、工具调用与结构化输出。
2. 在自有代码库上复现三类任务：Terminal-Bench 风格的终端操作、真实仓库级 issue 修复、代码迁移；同时保留提示词、容器镜像、工具权限和采样参数。
3. 分别测量首 token 延迟、每 token 延迟、并发吞吐、专家负载均衡和跨节点通信占比，不要只比较激活参数量。
4. 分别测试 FP16/BF16、FP8或INT4量化，确认代码生成正确率、工具调用格式遵循率及长上下文稳定性是否出现明显回退。
5. 将该模型与同代稠密模型、稀疏模型及现有编码智能体基线比较，使用 pass@k、任务成功率和单位任务成本，而不是只依赖单一聚合分。

目前更准确的结论是：ERNIE 5.5 Flash Preview 展示了以约14B激活参数承担高强度编码与智能体任务的潜力，但其真实价值仍取决于权重获取方式、推理框架适配、跨节点效率以及独立复测结果。

---

消息来源：Reddit r/LocalLLaMA (2026-11-12)

—— 完 ——

主题标签： #百度 关注 #ERNIE 5.5 关注 #稀疏MoE 关注 #编码智能体 关注 #模型评测 关注