百度这次没在比谁更大，而是把「总参」和「激活参」两笔账分开摆上了桌。ERNIE 5.5 Flash Preview 总参 280B、每个 token 只激活 14B，这笔买卖值不值，得看它落在什么场景里。
一句话：MoE 的效率账
据官方发布，ERNIE 5.5 Flash Preview 总参 280B，每个 token 只激活 14B，走的是混合专家（MoE）路线。MoE 把大模型拆成许多专家，每个 token 只被路由到其中一小部分，激活参因此远小于总参。这两个数字常被混着念，其实是两本账。
划重点：总参决定模型的容量与显存占用，激活参决定每次推理要烧多少算力。280B 是仓库的面积，14B 是每次进出仓库搬的货；面积不够放不下货，搬货太勤又费人工。路由选得准，14B 也能覆盖很宽的任务面；选不准，省下的算力就变成答错的代价。
说白了，部署方要为一整个 280B 的权重付显存，推理时却只按 14B 的规模算钱，比例是二十比一。省下来的算力是真的，省不掉的显存也是真的；对按 token 计费的 API，激活参低意味着单价有下探空间，对自建部署，显存则是一道一次性门槛。
我的判断是，这类模型的性价比不在「单卡能不能跑」，而在服务端能不能把 280B 的显存摊到足够多的并发上。并发上不去，省下的算力费会被显存占用吃回去，账面上便宜、账单上不便宜。小团队拿它做实验可以，拿它做主力得先把并发模型算清楚。
榜单上的 1668 分
据 Arena 榜单，ERNIE 5.5 Flash Preview 在 Code Arena: WebDev 上拿到 1668 分的趋势分，排在开源模型第二位。同榜的 DeepSeek-V4.1-Flash (Max) 为 1664 分，Kimi K3 (Max) 为 1658 分。
划重点：Qwen3.8-Max 的 1670 分比它高 2 分，DeepSeek 低 4 分，Kimi 低 10 分，几个数字挤在十几分的区间里。Code Arena 的分数由众包对战胜率折算，考的是 WebDev 这类前端任务，不是通用编码的正确率。
说白了，投票有噪声，2 分到 10 分的差距落在噪声区间内，撑不起「谁更强」的排序。它能说明的是这款模型站进了第一梯队，不能说明它比旁边几位都强；今天的分和下周的分也未必一样。榜单的样本还在滚动，投票的人也在换。
我的判断是，1668 分最大的价值是「进候选名单」，不是「下结论」。真要选型的人，看到分数该做的是去跑自己的题，而不是当场拍板。把它当参考系，不当判决书，这个位置才用得对。
一兆上下文意味着什么
据官方发布，这款模型的上下文窗口是 1M token，即 100 万 token，生成速度超过 200 tokens/s。对开发者来说，一整个中小型代码库、一份几百页的规范文档，可以一次性塞进去。做代码补全、仓库级问答的团队，等于省掉了切片与检索的一层工程。
实际用起来，长上下文的价值不在「能塞多少」，而在「塞进去之后还找不找得到」。上下文越长，注意力越容易被稀释，中段信息的召回往往会掉，放在开头的约束和放在中段的约束，未必被同等对待。这是长上下文模型共同的老问题，不是这一家独有。
代价也很直接：输入越长，预填充的算力与费用越高，首 token 延迟跟着涨。一份 100 万 token 的输入要完整过一遍，账单和等待都按这个长度算；200 tokens/s 说的是生成速度，不含读入的时间。按量计费时，长输入的单价通常另算，别只盯着生成侧的报价。
我的判断是，1M 是卖点也是账单。评估这类模型时，该测的是「把关键信息放在长文档中段，它还能不能准确引用」，而不是「它能不能吃下 1M」。这两件事差一个字，账单差很多。
开源时间表和它的心思
据官方开源计划，权重会以 Apache 2.0 协议在 11 月 25 日之前开放。先发 Preview 占住榜单，再开权重拉开发者，这个顺序不是随手排的。11 月下旬这个节点也有讲究，留出了让 Preview 跑完一轮口碑的时间。
Preview 阶段先把分数打出去，等于用榜单做了一轮预热；等讨论度起来再放权重，开发者装进本地的那一刻，已经带着「开源第二」的印象。这是发布节奏，不是技术路线的差异。
Apache 2.0 给的是宽松的使用权，商用、修改、再分发都不设卡。但协议管的是代码怎么用，不管模型好不好用；权重开放不等于服务承诺，也不等于文档、工具链和长期维护一起到位。拿到权重只是起点，跑通推理、调好吞吐，都是后面的活。
我的判断是，这个时间表留了后手。Preview 的名字本身就说明规格还可能调，正式版放开之前，现在看到的 280B 与 14B 未必是最终交付的那一组数字。等权重真正落地，再按落地的那份规格算账。
但这里有个前提
榜单是路标，不是终点。1668 分能让你把它放进候选名单，却回答不了三个更实际的问题：你的任务它做得好不好，你的机器装不装得下 280B 的权重，你的长文档它引用得准不准。这三个问题，投票的人替不了你回答。
这几个问题，榜单一个都不测。它不测成本，不测延迟，不测上下文变长之后的衰减，也不测它在你的私有数据上表现如何。分数高只说明它在别人的题上讨人喜欢，不说明它在你的题上靠得住。
工程选型的规矩没变：拿自己的题、自己的数据、自己的延迟预算去压测，跑出来的数字才算数。别人的榜单只告诉你「值得一试」，不告诉你「就该选它」。试完再决定，顺序别反。
百度把参数摊开，等于把选择权也摊开了；接不接，得回到你自己的账本上算。路标指了方向，走不走得通，要看你脚下这条路。
