一个 560B 参数的模型，处理 100 万 token 的上下文，KV 缓存只要约10.6 GB。如果 72 层全用潜在注意力，这个数字会是约83 GB。差了将近 8 倍。

Ling-3.1-flash（MIT 许可，560B 总参数、25B 激活参数，权重自 2026-10-13 起挂在 Hugging Face）的做法是：把大部分注意力层换成线性注意力。72 层里，63 层是 Kimi Delta Attention（KDA），只有9 层是门控多头潜在注意力（MLA），比例 7:1。只有这 9 层 MLA 保留随每个 token 增长的缓存。

按公开的 config.json 计算，大约是每 token 10.4 KB缓存，bf16 精度下 100 万 token 序列约 10.6 GB。作为对比，如果全部 72 层都用潜在注意力，约 83 GB。这个全 MLA 数字是假设值，不是已发布的模型。

为什么只留 9 层全注意力？全注意力要为每一层、每一个历史 token 存一份 key 和 value，缓存随上下文线性增长，解码时还要全量读取，长上下文解码因此受带宽限制。线性注意力层则把过去折叠成每个头一个固定大小的状态矩阵，随 token 到达更新，每条序列的内存不随上下文变长。

它的经典弱点是召回：固定状态装不下所有内容的精确副本，纯线性模型在精确检索上吃力。混合架构保留少量全注意力层作为 " 精确查找 " 通道，让线性层承担便宜的 bulk 工作。KDA 来自 Kimi Linear 论文（Kimi 团队，2025-10-30 提交），论文将其描述为对 Gated DeltaNet 的细粒度门控扩展。那篇论文用的是 3:1 的 KDA 对 MLA 比例，报告在 100 万 token 下 KV 缓存最多减少 75%、解码最多快 6 倍。阿里 Qwen3-Next-80B-A3B 采用类似的 3:1 布局。Ling-3.1-flash 把比例推到了 7:1。

算一下每 token 的缓存。MLA 层每层每 token 存一个压缩潜在量，kv_lora_rank 加 qk_rope_head_dim 等于 512 加 64，即 576 个元素，这是 vLLM 和 SGLang 中潜在注意力内核的缓存方式；若服务栈展开 key 和 value，占用会大得多。bf16 缓存每元素 2 字节，FP8 缓存则减半。9 层 MLA 乘 576 乘 2 字节，得到每 token 10,368 字节。

KDA 层的状态是常数项：63 层、每层 64 个头、每头 128 × 128 状态、fp32 精度，合计约264.2 MB，不随上下文增长。这个常数状态不是免费的—— 264 MB 大约等于 25,500 个 token 的 MLA 缓存。低于这个长度，线性层花的比省的多；高于这个长度，线性层开始赢，且差距线性拉大。

三个数字值得记住：

100 万 token 时，混合布局每序列约 10.6 GB，全 MLA 约 82.9 GB，约 7.8 倍差距。略低于朴素的 8 倍（72/9），因为要算上常数 KDA 状态。

32,768 token 时，混合约 0.60 GB，全 MLA 约 2.72 GB。

262,144 token 时，混合约 2.98 GB，全 MLA 约 21.74 GB。

作为量级参照，普通多头注意力会更夸张。config 列出 64 个 key-value 头、192 宽 key、128 宽 value，若 72 层全缓存完整 key 和 value、bf16 精度，约每 token 2.95 MB，100 万 token 就是约 2.9 TB。没人会这么服务，这也说明潜在注意力在混合之前已经是一大步。

对服务意味着什么？模型卡上的 vLLM 配方用张量并行 8、专家并行、前缀缓存、--gpu-memory-utilization 0.85，以及带 3 个推测 token 的 MTP。SGLang 配方面向 8 张 H200（TP8、EP8）和 4 张 GB300（TP4、EP4）。拿 8 张 141 GB 按 0.85 利用率算，减去 573.8 GB 权重，约 385 GB 留给缓存。这忽略了激活、CUDA 图、碎片和 MTP 层，只能当上限看。

这是示意性算术，不是实测吞吐。真实并发取决于多少请求真的跑满长度（多数不会）、前缀缓存命中率和批调度。但方向是稳的：一个每隔几小时压缩一次上下文的长跑 agent，在混合布局下每节点能多扛很多活跃会话。

账本的另一面是：光 FP8 权重就需要官方配方里的 8 张高显存 GPU。长上下文下缓存不再是内存大头，权重接过了这个位置。这也是量化成为下一个战场的原因。

社区反应不慢。2026-10-19 在 Hugging Face 模型 API 搜索 "Ling-3.1-flash"，除官方仓库外返回 13 个仓库，创建于 2026-10-14 至 2026-10-17 之间，格式包括 GGUF 构建（如 bartowski/Ling-3.1-flash-GGUF）、EXL3 构建（如 turboderp/Ling-3.1-flash-exl3）和 NVFP4 变体。第三方报道（如 AlphaSignal）描述了一种 MXFP4 与块 FP8 混合配方，把权重从 534 GB 压到 292 GB，用于 4 卡 Hopper 服务。该配方的精度保持数据没有找到，292 GB 只能当作体积声明看。

下载混合模型的社区量化版有两个实际提醒：

量化者必须理解 KDA 层。线性注意力状态和门控对精度敏感。官方 config 把 router、gate 和若干注意力投影排除在 FP8 转换之外（见 modules_to_not_convert）。忽略这份清单的量化，可能以短困惑度测试看不出的方式劣化质量。

信任任何量化前，先在自己的数据上跑长上下文检索测试。短基准不会压到那 9 层承担精确召回的全注意力层。

怎么判断混合架构适不适合你的负载？看四点：

上下文画像。若 p95 请求低于 25K token，常数 KDA 状态会吃掉节省，常规模型可能更简单。长 agent 会话和文档流水线才是混合架构划算的地方。

召回敏感度。需要从很远的位置精确引用字符串的任务（代码引用、合同条款）依赖全注意力层，要测。

引擎支持。vLLM 配方需要专门分支和 --mamba-cache-mode align，说明线性状态按循环模型状态管理。前缀缓存在状态型层上的行为与 KV 缓存不同，要在自己的流量里验证缓存命中率。

硬件预算。先算权重（FP8 573.8 GB），再算缓存，最后留余量。

还有两个细节值得标出来。模型卡宣传 100 万 token 窗口，而 config 仍写着 262,144 个位置且没有 RoPE 缩放条目。这不一定是 bug（服务栈可以覆盖），但在向用户承诺 100 万之前，先确认你的引擎实际分配了多少。另外，模型卡正文列了 Terminal-Bench 4.0、SWE-bench Pro、GDPVal-AA V2.1 等基准名称，但数字在图片里。厂商数字在有人复现之前，就按厂商数字对待。

7:1 相比 3:1 是否损失召回质量，是社区要在长上下文检索测试上回答的经验问题，配置算术解决不了。趋势本身很清楚：每一代都把更多层移向常数内存的线性注意力，靠更少、更宽的全注意力层兜住精确召回。