560B模型1M上下文，缓存只要10.6GB

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