预填充只走前半程：小米 MiMo-V3 架构剧透，给银行大模型长上下文划出三条线
核心摘要
- Agent 的长上下文账单不在生成环节，而在预填充：银行场景尤其如此
- 效率层可以用近似换成本，控制层必须全量计算、逐条可举证
- 预填充计算量、KV Cache 占用、端到端时延是三把尺子，口径绝不能混用
- 长上下文同步拉长的是敏感数据驻留时间，KV Cache 本身就是数据留存
Agent 的长上下文账单不在生成环节，而在预填充：银行场景尤其如此
效率层可以用近似换成本，控制层必须全量计算、逐条可举证
预填充计算量、KV Cache 占用、端到端时延是三把尺子，口径绝不能混用
长上下文同步拉长的是敏感数据驻留时间，KV Cache 本身就是数据留存
素材说明：本文触发素材为微信公众号“量子位”（QbitAI）发布的文章《罗福莉剧透小米MiMo v3架构：模型还没影，论文全说了》（2026-09-24，作者署名“闻乐”），文中引述的架构细节、参数量、计算量与缓存数据，均转引自该报道及其所引论文（arXiv:2609.26368）与罗福莉社交账号公开表述（UNTRUSTED，未经独立核实）。本文未对论文原文与实测数据进行逐条复核，所引百分比与倍数关系以该报道口径为准。文中关于银行业场景、成本模型与治理动作的分析，为作者基于公开信息的整理，不构成技术选型或合规意见。涉及监管文件的表述来自公开信息（见“事实来源”），同样未经独立核实。
2026 年 9 月，小米 MiMo-V2.6 刚发布，罗福莉就把 MiMo-V3 的架构方向讲了出去。国内技术媒体的报道标题很直白：模型还没影，论文全说了。
对多数读者来说，这是一条常规的模型架构新闻。但对正在推进大模型落地的银行技术负责人来说，这篇报道里有三个数字值得抄下来贴在工位上：
- 在 80B 总参数、每 token 约激活 3B 参数的 MoE 配置下，到 100 万 token 上下文，新架构 HySparse2 的预填充计算量约为对照方案 Hybrid SWA 的 1/5.02；
- KV Cache 占用从 12.09GB 降至 2.69GB，约缩小 4.5 倍（FP8 缓存口径）；
- 采用预填充与生成分开部署时，预填充节点只需放前 25 层（模型共 49 层），所需模型内存接近减半。
这三条不是“性能跑分”，而是成本结构。而银行做大模型，卡住脖子的从来不是通用知识问答，是成本结构。
本文不讨论小米的技术优劣，只做一件事：把这篇架构报道拆成银行能用的三样东西——一套分层方法、一套口径纪律、一个粒度标尺，以及一份能落到机房和立项书里的行动清单。
一、先把架构读薄：HySparse2 到底动了几处
媒体报道的核心信息可以压缩成三句话，每句话背后都是一个工程取舍。
| # | 技术动作 | 报道中的关键表述（转引） | 工程含义 |
|---|---|---|---|
| 1 | 预填充提前退出 | 模型被划为前后两段：前段 self-decoder（全注意力＋滑动窗口注意力），后段 cross-decoder（全注意力＋稀疏注意力）；两段之间由 KV Bridging 只连接全注意力层，长输入走完前段即可停止预填充 | 把“长输入必须逐层跑完整个模型”改成“长输入只跑前半程”，直接砍掉预填充阶段一半以上的层开销 |
| 2 | 两级 KV 共享 | KV Bridging 让后段全注意力层从前段对应层隐藏状态生成 K、V；KV Reuse 让稀疏层复用同一混合模块中全注意力层的 KV Cache 与 token 选择结果 | 缓存复用从“同层内”扩展到“跨层”，是 KV Cache 从 12.09GB 降到 2.69GB 的结构性原因 |
| 3 | 选择粒度降到 token | 上一代按 64-token 的“块”挑选内容，块内只要少量内容相关就要整块占用预算；新架构改为按单个 token 挑选，配置为挑选 1024 个全局 token，并**强制保留最近 128 个 token** | 有限的注意力预算花在真正相关的位置上，而不是被整块稀释 |
报道给出的量化结果如下（均为转引，未经独立核实）：
| 维度 | 数值（转引报道口径） | 备注 |
|---|---|---|
| 模型配置 | 80B 总参数 / 每 token 约激活 3B（MoE） | 与主流中等规模生产模型同档 |
| 预填充计算量（100 万 token） | 约为 Hybrid SWA 的 1/5.02；比上一代 HySparse 降低约 2.92 倍 | **是计算量，不是响应速度** |
| KV Cache（FP8） | 2.69GB（HySparse2）/ 6.72GB（HySparse）/ 12.09GB（Hybrid SWA） | 相对 Hybrid SWA 约缩小 4.5 倍 |
| 层数与部署 | 共 49 层；预填充节点只需前 25 层及相关投影模块，内存接近减半；该配置下预填充阶段执行全注意力的仅 1 层 | 支撑“预填充与生成分开部署” |
| 长上下文检索（256k） | RULER-v2：58.45 / 32.61 / 35.74 | 依次为 HySparse2、上一代、对照 |
| 平均检索成绩 | MRCR-v2 与 RULER-v2 分别比上一代高 11.30 与 19.81 个百分点 | 按测试长度取平均 |
| token 级 vs 块级（32k 及以下） | RULER-v2 +6.57pp、MRCR-v2 +8.14pp、GraphWalks +5.55pp | 消融实验，其他条件一致 |
一个有意思的观察：报道提到，在预训练后的普通知识、推理与代码项目上，新架构的成绩“有升有降，整体与对照模型大致可比”，优势主要出现在长上下文。这条信息量很大——换架构解决的是长上下文的经济性问题，不是通用智力的智力问题。
二、为什么这篇架构新闻值得银行技术负责人逐字读
定义因为银行大模型最容易踩的坑，恰好就是这篇报道要解决的问题：多轮工具调用 + 超长工具返回。
银行没有多少场景是“用户问一句话、模型答一段话”。真实的负载是这样的：模型先调一个接口拿客户基本信息，再调一个接口取近三年流水，再读一份征信报告，再翻一段内部制度，再对照一条监管条款——每一步模型自己生成的指令可能只有几十个 token，但工具返回的材料动辄上万字。而且这些材料每一轮都要重新进入上下文：轮次越往后，历史越长，预填充成本越高。
| 银行典型场景 | 单轮输入特征 | 主要成本项 | 对架构的诉求 |
|---|---|---|---|
| 信贷调查报告生成 | 财报＋流水＋征信＋影像 OCR 文本，数万字起 | 预填充 | 提前退出、跨层缓存复用 |
| 反洗钱与可疑交易分析 | 长期交易流水＋名单＋历史案例＋规则库 | 预填充＋KV 驻留 | token 级证据定位，能接上早期线索 |
| 合规条款比对 | 监管条文＋内部制度＋产品说明书，多文档交叉 | 预填充 | 长上下文精度而非吞吐 |
| 审计底稿回溯 | 跨季度多轮工具调用，材料持续追加 | KV 驻留＋检索 | 跨轮次线索接续、可回放 |
| 智能客服与运营工单 | 多轮对话＋知识库＋工单历史 | 生成＋并发 | 单卡并发数、响应时延 |
- 预填充计算量降到约五分之一，意味着同一批卡能处理的“材料总量”上升约五倍，或者同一份材料的处理时间显著下降；
- KV Cache 从 12GB 降到 2.7GB，意味着同一张卡上的并发会话数可以上去，长会话不至于一开就吃满显存；
- 预填充节点只需前半段层数，意味着“把最贵的卡留给生成、把便宜的卡或存量卡留给预填充”这种混合部署第一次在架构上变得合理。
对一家总分行两级部署、机房条件参差、显卡型号不统一的银行来说，第三条的现实价值可能比前两条加起来还大。
三、框架一：效率层与控制层的二分
这是本文提出的第一个分析框架。
定义：把大模型的推理链路拆成两类环节。效率层指可以用近似、稀疏、缓存复用、量化等一切手段换成本的部分；控制层指必须全量计算、结果可复现、过程可举证的部分。前者越省越好，后者一分钱都不能省。
这个二分不是本文发明的审美偏好，它恰好是 HySparse2 架构本身的表达方式：新架构并没有把全注意力全部撤掉——“团队认为，少量全注意力层既有助于维持模型能力，也能用完整的注意力分数，帮后面的稀疏层选出值得看的 token”。全注意力层就是这套架构里的控制层：数量少、成本高、但决定其余部分的正确性。
对应到银行，控制层与控制点应当明确包括：
| 层次 | 允许的手段 | 银行侧的对应内容 | 为什么不可让渡 |
|---|---|---|---|
| 效率层 | 稀疏注意力、KV 复用、量化、缓存、批处理 | 材料通读、摘要生成、初稿撰写、要点抽取、相似案例召回 | 错了可以重来，成本敏感度最高 |
| 控制层 | 全量计算、规则硬约束、白名单强制注入、双路校验 | 限额校验、名单命中、禁止性条款、监管最新口径、人工复核触发、结论落章 | 错了就是一笔责任，没有“重来”的机会 |
四、框架二：三把尺子，口径绝不能混用
这是本文提出的第二个框架，专治采购与立项阶段最常见的对话事故。
定义：大模型长上下文的“省”，可以量在三把完全不同的尺子上——计算量、显存、时延，它们不是同一个指标，也不成固定比例。
| 尺子 | 量的是什么 | 常见误用 | 银行应当采用的验收口径 |
|---|---|---|---|
| 预填充计算量（FLOPs） | 处理输入所需的算力总量 | 把它当成“速度提升 N 倍”对外宣传 | 用于算力规划与扩容测算；**不得**等同于响应时延承诺 |
| KV Cache 占用（GB） | 每个长会话常驻显存 | 忽略并发数、忽略上下文长度口径 | 折算为“单卡可支撑的长会话并发数”，进入单位成本模型 |
| 端到端时延与任务成功率 | 用户真实感知与结论正确性 | 用实验室短输入测试代替场景化测试 | **唯一可以对外承诺的指标**，必须以业务场景实测为准 |
把这句话翻译成采购条款就是：供应商给出“计算量下降 X 倍、缓存下降 Y 倍”时，验收方应当同时索取（1）端到端时延基线，（2）同硬件同并发条件下的对比数据，（3）以本行业务材料构造的长上下文评测集结果。三项缺一项，这个“倍数”在立项书里就不能作为效益依据。
至于评测集，报道中出现的 RULER-v2、MRCR-v2、GraphWalks 是通用学术基准，银行不能直接照抄。可迁移的是评测思路：把本行的制度问答、跨轮证据接续、条款级引用准确率、长材料摘要事实一致性做成固定题集，每次选型或升级都跑一遍。这件事的投入不大，但它是把“架构叙事”翻译成“本行账本”的唯一通道。
五、框架三：证据粒度阶梯
这是第三个框架，也是本文认为被技术报道盖住、但银行最该抄走的一点。
定义：把检索与引用按粒度分为四级——文档级 → 段落级 → 条款级 → 字段级（对应到模型侧，就是 token 级）。粒度越细，可举证强度越高，但同时越依赖选择算法本身的正确性。
HySparse2 最本质的改动之一，是把选择单位从 64-token 的“块”降到单个 token。报道给出的理由是：一个 64-token 的块里只有少量内容相关时，整块也要占用选择预算，在跨越多轮工具调用的 Agent 任务中，检索精度不足的问题会变得突出。
| 粒度 | 检索单位 | 可举证强度 | 银行适用场景 |
|---|---|---|---|
| 文档级 | 一整份文件 | 低——只能说明“看过这份文件” | 材料盘点、范围初筛 |
| 段落级 | 一个自然段 | 中——能定位大致位置 | 摘要生成、会议纪要 |
| 条款级 | 一条制度/监管条款 | 高——可支撑业务解释 | 合规比对、制度问答、授信依据 |
| 字段级 | 单个数据项或表单项 | 最高——可直接进审计底稿 | 征信要素核验、流水异常定位 |
但框架三必须配一条警告：粒度越细，对选择算法的依赖越强。 如果模型告诉你的只是“答案来自这份文件”，你还可以人工翻一遍；如果模型告诉你“答案来自这三个 token”，而你无法回放它是怎么选出这三个 token 的，那么举证责任就从“说服我这段材料支持这个结论”，变成了“说服我你的选择器没漏掉关键材料”。前者是业务问题，后者是技术黑箱问题——银行更需要能回答前者。
所以粒度阶梯的正确用法，不是一味追求最细，而是：结论引用要细到可核，选择过程要留痕可回放。
六、两个容易被架构叙事盖掉的银行风险
技术报道讨论的是效率，银行必须在效率之外看两件事。
6.1 KV Cache 驻留，就是敏感数据驻留
这是长上下文最容易被忽略的副作用。
主流叙事把 KV Cache 当成一个纯粹的性能参数——“缓存小了，并发高了”。但 KV Cache 里放的不是日志，是之前所有轮次的输入内容：客户身份信息、账号与流水、征信明细、内部评级、甚至制度原文。上下文越长、缓存复用越激进的架构，意味着这些内容在显存或推理缓存中存活的时间越长、被后续请求复用的机会越多。
换句话说：长上下文不只是把上下文窗口拉长了，它也把敏感数据的驻留期同步拉长了。
架构新闻不会讨论这件事，但银行的治理框架必须讨论。可落地的动作至少有四项：
- 给上下文设 TTL：像管理数据留存期限一样管理缓存生命周期，会话结束即清退，不做跨会话复用；
- 缓存不落盘、不跨池：预填充与生成分离部署后，两级节点之间的中间状态传输要有明确的加密与不留存要求；
- 按敏感级分池：客户级敏感材料与公开制度文档不共用同一个缓存池，避免侧信道式的相互污染；
- 留痕与可审计：谁在什么时候把哪类材料送进了上下文、缓存驻留了多久，应当可查——这与公开监管文件强调的“谁使用、谁负责”方向一致（该监管表述见“事实来源”，转引自公开信息，未经独立核实）。
6.2 稀疏选择的相关性，不等于合规要求的相关性
第二个风险更隐蔽。
稀疏注意力的挑选逻辑是统计意义上的相关性——哪些位置与当前任务最相关，就给它注意力预算。而银行的合规要求不是相关性，是必须性：限额、名单、禁止性条款、最新监管口径，哪怕与当前问题在统计上不相关，也必须被看到。
报道中提到的一个细节值得单独拎出来：新架构强制保留最近 128 个 token。这是一个聪明的工程妥协——保证眼前刚收到的工具结果不被漏掉。但它的性质要看清：这是效率机制，不是合规机制。 它保的是“最新”，保不了“必须”。
所以银行的做法应当是：把关键约束从“依赖注意力去看到它”改成“规则层强制注入它”。具体到工程上，就是白名单与硬约束不参与任何近似计算——这也正是框架一里“控制层”的落地形态。
七、机构侧六项行动
把前面三个框架收拢，给出六项可以直接排进项目计划的动作。
| # | 行动 | 具体做法 | 判断标准 |
|---|---|---|---|
| 1 | 场景收敛 | 先用“多轮工具调用＋超长工具返回”的 1～2 个场景验证架构收益，不要用通用问答去评长上下文 | 单次任务上下文长度与轮次可量化 |
| 2 | 部署形态评估 | 评估预填充/生成分离部署：预填充节点只需前段层数（报道口径为 25/49 层），可复用存量或低配卡 | 预填充节点显存占用下降幅度可实测 |
| 3 | 成本模型改造 | 把 KV Cache 折算成“GB／千 token／并发会话”，写进单位成本模型，而不是只算卡数 | 每千次业务请求的显存成本可拆分 |
| 4 | 行业化评测集 | 自建长上下文评测：制度问答、跨轮证据接续、条款级引用准确率、长材料事实一致性 | 每次选型/升级均跑同一套题 |
| 5 | 护栏前置 | 控制层全量计算＋白名单强制注入＋证据留痕（选中位置可回放）；上下文设 TTL、缓存分池 | 关键结论可追溯到条款/字段 |
| 6 | 采购纪律 | 三把尺子分开口径验收；未发布模型只进技术观察清单，不进生产选型 | 效益测算有同口径基线 |
八、边界与不确定性
- 素材边界：本文全部技术细节与数据均转引自一篇媒体报道及其所引论文、社交账号公开表述，UNTRUSTED，未经独立核实；报道中的百分比、倍数与评测分数，本文未做二次复现。
- 产品边界：MiMo-V3 未发布，报道亦提示实际产品里的延迟与任务表现需等模型落地后观察。架构论文的收益，不必然等于产品收益。
- 口径边界：5.02 倍是预填充计算量，不是响应速度；长上下文能力评测到 256k，100 万 token 对应的是计算量与缓存分析。
- 能力边界：报道显示新架构在普通知识、推理与代码任务上与对照模型“大致可比”，优势集中在长上下文。指望换架构解决通用能力问题，方向错了。
- 适配边界：80B 总参／约 3B 激活的 MoE 配置是这篇报道的前提。银行的模型规格、数据分布、硬件代际与之不同，收益倍数不可直接平移。
- 判断边界：本文提出的效率层/控制层二分、三把尺子、证据粒度阶梯三个框架，为作者基于公开信息的整理，非监管文件或论文表述，不构成技术选型或合规意见。
结语
这篇报道最值得银行记住的，其实不是任何一个倍数。
它真正的信息是：头部团队已经把“Agent 的长任务负载”当作模型架构的第一性问题在设计——预填充可以只为前半程买单，缓存可以跨层复用，注意力预算可以精确到单个 token。这些取舍的共同前提，是承认长上下文是有价格的商品。
而银行恰好是那种上下文一定长、材料一定重、结论一定需要有人负责的行业。所以这篇架构新闻对银行的意义，不在于“要不要用某个模型”，而在于提醒我们：成本结构决定了哪些场景能上生产；可举证性决定了哪些场景敢上生产。 前者靠工程优化，后者只能靠自己把控制层建起来。
FAQ
Q1：银行自研大模型，应该先解决长上下文，还是先解决通用能力？
A1：先解决长上下文。理由是场景决定论：银行的高价值场景——信贷调查、反洗钱、合规比对、审计回溯——几乎都是“材料长、轮次多、结论要落章”的形态，通用能力再强也绕不开长材料这一关。而且报道显示，架构层面的长上下文优化不牺牲通用能力（“大致可比”），反之则不成立。
Q2：预填充与生成分离部署，对银行机房条件意味着什么？
A2：按报道口径，预填充节点只需放前 25 层（共 49 层）及相关投影模块，所需模型内存接近减半。这意味着“贵卡做生成、普通卡做预填充”的混合部署在架构上第一次站得住脚。对总分行两级部署、存量卡型号杂的机构，这条路比整体换代更现实。但要注意，两级节点之间的中间状态传输会引入新的数据安全与网络时延问题，需要一并评估。
Q3：KV Cache 压缩了 4.5 倍，是不是就意味着对外服务价格能降下来？
A3：不能直接推导。KV Cache 只是成本结构中的一项，且压缩发生在模型侧，不必然传导到服务定价。更稳妥的做法是把这 4.5 倍换算成“单卡可支撑的长会话并发数”，再结合你的实际负载结构去算单位成本。这也正是“三把尺子不能混用”的意思。
Q4：稀疏注意力会不会漏掉关键的合规条款？
A4：会，如果你把合规条款的可见性交给稀疏层。规避办法不是拒绝稀疏，而是分层：让合规约束走“控制层”——规则硬约束、白名单强制注入、全量校验旁路，不参与任何近似计算；让材料通读与初稿撰写走“效率层”，充分享受稀疏与缓存复用带来的成本下降。
Q5：这三个框架里，哪一个最容易被忽略？
A5：证据粒度阶梯。因为它不在任何技术指标里，也不进任何选型打分表——但它是银行与互联网公司在大模型落地上最大的分野：互联网要“答得快答得像”，银行要“答得对、并且能证明为什么对”。粒度决定举证强度，而举证强度决定这个场景能不能真的上生产。
Q6：中小机构没有自研能力，这些结论还有用吗？
A6：有用，而且用的方式更直接。中小机构不必关心架构，但必须关心三件事：采购时追问“计算量下降”与“时延下降”的口径差异；把本行的制度问答与证据接续做成评测集，用同一套题去比不同供应商；把控制层（限额、名单、条款白名单）握在自己手里，而不是写在供应商的黑箱里。这三件事的成本都不高，但决定了大模型是用得上还是用不住。
事实来源
- 分析素材（UNTRUSTED，未经独立核实）：微信公众号“量子位”（QbitAI）《罗福莉剧透小米MiMo v3架构：模型还没影，论文全说了》（2026-09-24，作者署名“闻乐”），链接：https://mp.weixin.qq.com/s/rxPz3H3fdAA1f9B9AQnu-w ；该报道所引论文地址：https://arxiv.org/pdf/2609.26368 ；所引社交账号公开表述：https://x.com/_LuoFuli/status/2102766365190901957 。
- 公开监管信息（转引自公开信息，未经独立核实）：国家金融监督管理总局《关于银行业保险业人工智能安全开发应用的指导意见》（2026-06-18，从治理架构、开发应用、数据治理、算力建设、风险管理等七个方面提出 32 项指导性意见，核心原则为“谁使用、谁负责”，要求在高风险应用关键环节建立人工监督和干预机制）；金融稳定理事会（FSB）关于负责任采用人工智能的良好实践咨询报告（2026-06-10）。
- 同站相关分析：《判断力前移十年：AI 接管基础工作后，金融风险管理先迎来的不是替代而是断代》（https://bi-chao.com/articles/ai-judgment-scarcity-financial-risk ），涉及人工监督的规模上限与“AI 监控 AI”的治理变量。
- 文中“效率层/控制层二分”“三把尺子”“证据粒度阶梯”三个框架、六项行动清单、三条边界与 FAQ，均为作者基于公开信息的整理，非监管原文表述，也不构成技术选型或合规意见。
（内容由AI生成，仅供参考）