一、背景：开源大模型两条演进主线的交汇

过去一年，开源大模型的竞争集中在两条主线上。第一条是架构上的稀疏化：借助混合专家（MoE）把总参数推到万亿量级，同时把每个Token的激活参数控制在千亿级，实现“容量大、算力省”。第二条是任务范式上的Agent化：模型的评价标准从单轮问答质量，转向能否在数十轮工具调用、检索与代码执行中稳定完成长程任务。

近期，一个总参数约2.8T、激活参数约104B的开源模型正式开放权重，同时支持百万Token级上下文与原生图文输入，可视为两条主线交汇的代表性样本。本文不对其做产品评价，而是借其公开的技术要素，梳理这一代开源模型的技术范式，并给出工程团队的落地建议。

二、MoE架构：把“知识容量”与“计算成本”解耦

2.1 稀疏激活的基本原理

MoE将Transformer中的前馈层替换为多个并行的“专家”子网络，由路由器为每个Token只挑选少数专家参与计算。以该样本为例：总参数2.8T决定了模型的知识容量上限，而每个Token实际激活的104B参数决定了单次前向的算力与访存开销。两者解耦，是“训练得起大模型、推理得起中等成本”的关键。

2.2 收益与代价

收益方面：

• 同等推理计算量下容量更大，长尾知识与多领域覆盖更好；
• 激活参数固定，推理成本不随总参数线性增长。

代价方面，工程团队必须正视三点：

• 显存墙：全部专家需常驻显存。2.8T参数即使按4-bit存储也约1.4TB，单机无法容纳，必须采用专家并行加多机部署；
• 负载均衡：路由倾斜会造成部分专家过热，需要辅助损失或显式均衡策略约束；
• 通信开销：专家并行引入All-to-All通信，对节点间互联带宽高度敏感。

2.3 对选型的启示

评估MoE模型时，不能只看“总参数”，更要看激活参数、权重体积与最低部署拓扑——它们决定了单条请求的真实成本与硬件门槛。

三、百万Token上下文：稀疏注意力与线性注意力的分层混编

3.1 全注意力的平方瓶颈

标准自注意力对长度为n的序列，计算与显存开销均为O(n²)。百万Token若直接用全注意力推理，KV缓存与注意力矩阵都不可承受。业界通行解法有三类：对KV做潜在压缩、滑动窗口局部注意力、稀疏或线性注意力。

3.2 该样本的组合方案

据公开资料，该模型将一部分注意力层替换为动态稀疏注意力：对每个查询Token，先做轻量打分，从百万级历史Token中动态选出约2048个最相关者参与精确计算，注意力成本从“与全长相关”降为“与选中块大小相关”，同时保留对远处关键信息的精确回溯能力。其余多数层则采用门控Delta规则类线性注意力：以常数大小的循环状态递推历史信息，复杂度O(n)，擅长低成本低延迟地承载长程语义流。

这种“线性注意力占多数、稀疏注意力占少数”的分层混编，本质是分工：线性层负责“记得住”，稀疏层负责“查得准”。对推理侧的直接收益是KV缓存显著缩小、解码吞吐提升，长上下文场景的时延与成本结构被重构。

四、后训练：多领域联合强化学习与思考预算

4.1 联合RL为何重要

预训练给能力，后训练定行为。该模型在基座之上进行了覆盖数百个下游领域的大规模联合强化学习，奖励信号主要来自可验证结果——代码是否通过测试、工具调用是否成功、检索答案是否正确。相比单任务RL，联合训练有两大好处：一是能力正迁移，工具调用与代码修复共享“规划—执行—反馈”结构，互相促进；二是抑制灾难性遗忘，多领域混合采样避免“学一个丢一个”。

4.2 思考预算的三档设计

推理时提供low、high、max三档思考预算，本质是把“推理长度”变成可调参数：low适合分类、抽取等低延迟任务；high覆盖常规代码与文档处理；max面向长程Agent与复杂调试，允许更长的思考链与更多自检。工程上建议在入口层做难度预估并按任务路由，在成本与质量之间取得平衡。

agent-">五、长程Agent的三类主战场与关键工程细节

5.1 代码与软件工程

评测维度覆盖终端操作、代码修复与深度软件工程。落地要点包括：命令与测试在隔离沙箱中执行并将失败信息回喂模型；多文件场景配合仓库检索工具而非整仓塞入上下文；采用“复现—定位—修复—回归”的测试驱动循环。

5.2 3D/CAD生成

通过调用参数化建模工具，把自然语言需求转为可执行建模脚本，再以渲染或几何校验结果回喂修正。此类任务通常“带工具”评测，纯文本模型与工具增强模型的差距在此最为明显。

5.3 知识工作

网页检索要求“生成查询—浏览—筛选—引用”的完整链路；金融研究考验多文档交叉核对与表格推理；办公文档处理则考验对复杂版式与表格的多模态解析。

5.4 一个易被忽视的细节：保留完整历史

该模型明确要求多轮工具调用时保留完整的历史思考与工具调用消息。原因在于：思考链承载了此前的任务规划与中间结论，丢弃会导致重复推理甚至自相矛盾；工具调用与结果的配对关系是模型判断“哪些做过、哪些失败”的依据。因此服务端裁剪上下文时应按轮次而非字符数裁剪，必要时仅对早期工具结果做摘要压缩，保留决策性的思考与调用骨架。

六、MXFP4量化与部署选型

MXFP4是开放微缩浮点格式族中的4-bit方案：一组权重共享一个微缩放因子，用4-bit浮点编码。相比传统INT4，其动态范围更接近浮点，对大模型权重分布更友好，多数场景可省去复杂的校准流程。按2.8T参数估算，权重约1.4TB，加上激活、KV缓存与框架开销，多机集群是基本盘。

该权重已适配支持连续批处理、分页式缓存管理的主流开源推理引擎，并提供与业界主流对话补全协议兼容的API，迁移成本较低。示意请求结构如下：

{
  "model": "<model-id>",
  "messages": [
    {"role": "user", "content": "修复仓库中的失败用例"},
    {"role": "assistant", "reasoning": "……历史思考……"},
    {"role": "tool", "name": "terminal", "content": "……执行结果……"}
  ],
  "reasoning_effort": "max",
  "tools": ["terminal", "web_search", "file_editor"]
}

部署形态上：数据敏感、负载稳定的核心场景适合自建集群，但需具备专家并行与量化推理的运维能力；缺乏大规模算力储备的团队，可选择百度智能云等云平台的模型即服务（MaaS）能力直接调用或托管微调；也可采用混合模式，敏感数据本地推理、通用任务走云端。成本核算应围绕“激活参数×并发×上下文长度”展开，长上下文场景重点关注KV缓存策略的影响。

七、正确读取评测成绩

公开评测涵盖终端操作、代码修复、深度软件工程、网页检索、CAD生成与办公问答等维度。读分数时注意三点：其一，成绩通常在最高思考档位并配合成熟Agent框架取得，更换档位或框架结果会明显不同；其二，不同基准的评分协议（是否带工具、反馈轮次多少）不一致，不宜横向硬比；其三，建议企业从业务日志抽取真实任务自建评测集，固定提示词与工具集做回归式评测，并补充成本与时延维度。

八、许可证与合规

该权重采用专用许可证，而非Apache 2.0或MIT等宽松协议。引入前应重点审查：是否限制商用规模、是否要求署名或标识；二次训练后的模型能否对外提供托管服务；权重许可与配套代码许可是否分离。此外，无论自建还是调用API，都应将内容安全、日志留存与数据合规纳入整体方案。

九、结语

万亿参数MoE、稀疏与线性注意力混编、多领域联合强化学习、MXFP4量化开源，共同勾勒出当前开源大模型的技术合流方向。对企业而言，理性的路径是：以业务场景与成本结构为锚，先建自建评测，再定部署形态，最后把上下文管理与合规审查当作与模型能力同等重要的工程课题。