11月12日，百度在世界大会2026上发布文心5.5 Flash Preview。按官方发布页的说法，这是此前发布的Flash Base模型的首个后训练版本，总参数2800亿，每个词元激活140亿参数，支持最长100万词元上下文，定位在编程、3D建模、知识工作与内容创作四类任务。模型API已在千帆平台上线，权重将在11月25日前以Apache 2.0协议开源。
2800亿总参数配140亿激活参数，比例正好是二十比一。这个结构决定了推理成本的计算方式：显存要装下全部专家，算力只按激活部分结算。对使用者来说，能跑多快取决于激活路径，能不能装下取决于总参数，两者分离之后，模型可以同时做到"参数够大"和"解码够快"。
官方给出的说法是兼顾智能水平与推理效率，在多项基准测试中取得有竞争力的得分，同时保持解码速度。具体提到的是Terminal-Bench与AutomationBench两项，前者测终端环境下的任务执行，后者测自动化流程，都属于长链路任务而不是单轮问答。这两个基准的共同点是容错率低，中间任何一步跑偏，最终结果就作废。
100万词元上下文在这个尺寸上不算常见。上下文长度直接决定模型能不能一次性读完一整个代码仓库或者一份完整的规格文档，也决定了长程任务里它需不需要反复回读。对智能体类应用来说，上下文长度往往比单轮推理能力更影响能不能用。
官方演示里最具体的一个案例叫《云岫行》，一款用虚幻引擎5.8制作的第三人称武侠游戏，场景设定在张家界的石峰与崖顶古寺之间。根据发布页的说明，模型在一次连续11小时的编码任务中，把跨越多代虚幻引擎的素材合并进同一个UE 5.8工程，并用C++写完整个游戏。
真正值得注意的是它处理问题的方式。作为纯文本模型，它看不到运行画面，于是把试玩中发现的缺陷转写成可测量的代码测试：人物悬空、跑动方向不一致、相机错位，每一个都被拆成能在测试里断言的条件。测试用例越补越全，迭代就靠这些断言推动，直到开发目标全部达成。
这个做法把"看不见"从缺陷变成了约束条件。人类开发者靠眼睛发现问题，再动手改；模型靠测试定义问题，再动手改。前者快但不可复现，后者慢但每一步都留下证据。对于要交付给别人的工程，后者的价值在协作环节更明显。
第二个演示是一批移动端小游戏，官方称接近100款，覆盖弹幕射击、Roguelike、塔防、竞速、卡牌RPG、城市建设、物理解谜和互动小说等类型，视频里展示了其中24款。输入是完整的游戏设计文档，输出是包含玩法、内容、美术和音效的可运行成品。
这些作品在工程上有一个共性：多数把游戏规则与画面表现分开，规则部分跑确定性模拟。好处是可以用机器人试玩、状态空间搜索和关卡回放来自动检查每一关是否可通关、数值是否平衡。这种设计不是模型发明的，但它能被模型稳定复现，说明训练数据里这类工程范式占了相当比重。
演示中提到的外部素材包括用Z-image、Animagine XL、FLUX.2和Stable Diffusion XL生成的图片，以及Quaternius、Kenney等CC0素材包。官方在每一件作品旁标注了来源，这个细节说明展示的是"模型在智能体框架内完成的任务"，而不是模型单独从零画出所有素材。
发布页明确列出对虚幻引擎、Unity和Godot三大引擎的深度适配，重点是让模型理解不同引擎的开发范式、工具与工作流。为了做到这一点，百度构建了专项训练数据与配套评估体系，强化方向包括游戏机制实现、核心逻辑编排、运行状态管理与资源管线处理。
引擎适配这件事的难度被低估了。同样一个"角色跳跃"，在虚幻里是蓝图与C++的配合，在Unity里是组件与脚本的组织，在Godot里是节点树的挂载方式。模型如果只学到通用编程语法，写出来的代码在每个引擎里都会显得别扭，运行起来处处报错。所谓适配，学的是各家的习惯写法。
从工程角度看，这批能力更接近"能接手别人写了一半的项目"，而不是"能写出漂亮的示例代码"。前者需要读懂既有结构、遵守既有约定、在不破坏其他模块的前提下改动，这正是长程任务的真实形态。
发布页写明权重将在11月25日前开源，协议是Apache 2.0。这个协议允许商用、允许修改、允许再分发，对希望把模型部署在自有环境里的团队来说，条款比"开放权重但限制商用"宽松得多。
时间点的选择也有讲究。先上API、后放权重，中间留出大约两周，这段时间足够让开发者用接口验证能力，也足够让百度收集一轮真实调用的反馈。对开源模型来说，权重放出去之后就很难再调整默认行为，先跑一段托管服务是常见的做法。
2800亿参数按Apache 2.0放出来，部署门槛不低。按常见的半精度估算，仅权重就需要超过500GB显存，即便做4比特量化也要一百多GB，单机八卡勉强能跑。这意味着真正会用它的，是自有算力的企业、云服务商和做二次分发的团队，而不是个人开发者。
同一场大会上，百度还发布了文心闪电深度思考模型与文心一镜微表情大模型，三款模型同步上线千帆平台。加上此前推出的模型交易平台词元所，官方披露的数据是入驻供应资源超过100个，日均调用次数突破5000万，日均调用词元超过7000亿。
把这些放在一起看，百度在做的是一件分工明确的事：基础模型负责能力上限，应用模型负责具体场景，交易平台负责把不同来源的模型摆到同一个货架上，并用指纹比对、能力测试、性能与可用性抽检给供应方建立信用评级。这套结构解决的问题是选型成本，而不是模型本身强不强。
140亿激活参数的定位也因此清楚了。它不追求榜单第一，追求的是在一张卡上跑得动、在长任务里不中断、在批量调用时账单可控。对这个尺寸的模型来说，能不能被放进日常生产流程，比某项基准高两个点重要得多。