大模型前沿动态 · Vol.136

端侧装下 35B 的 MoE、24B 只激活 2B、重复片段合成一个 token、KV 跨提示复用：省算力的办法从砍东西换成了认冗余

四条动态分别落在一个层级的冗余上：面壁 MiniCPM-V 4.7 用前瞻专家调度提前备好八成所需专家，把 35B-A3B 的 MoE 塞进手机 3G 内存；Liquid AI 的 LFM2.5-24B-A2B 每 token 只激活 2B，八项工具基准五项领跑；zip2zip++ 用解耦嵌入与尺寸感知 RoPE 把动态词表的质量缺口关掉约一半；KV-Repurpose 把复用单位从精确前缀换成段落，30GB 下命中率 63.9%，前缀缓存 1TB 也只有 17.9%。

大模型 端侧推理 MoE 面壁智能 MiniCPM Liquid AI 多模态大模型 智能体 Token压缩 KV缓存 推理优化 开源模型 量化 长上下文

端侧把 35B 的 MoE 塞进 3G 内存，靠的是提前搬对权重；24B 只激活 2B，让每个推理 token 变便宜；LZW 把重复出现的片段合成一个 token；同一份文档的 KV 换个系统提示也能接着用。省算力的动作从「砍掉什么」换成了「认出什么已经在别处出现过」。

一、MiniCPM-V 4.7：35B 的 MoE 跑进手机，靠的是搬对权重

事件概述：2026 年 10 月 14 日，量子位报道面壁智能与 OpenBMB 开源 MiniCPM-V 4.7，一次性给两个尺寸：35B-A3B 与 1B（实际参数 1.3B）。35B-A3B 是该系列第一个 MoE 模型，总参数 35B、每 token 激活约 3B，报道中的实测场景是 iPhone 17 Pro Max（12GB 内存）断网运行，占用约 3G 内存、解码速度超过 13 tokens/s；未做优化的同一模型约 2 tokens/s，优化后到 8–12 tokens/s。权重已挂在 Hugging Face，GGUF 版本下载量过万。团队称这是首个能在端侧流畅运行又不牺牲性能的开源 MoE 模型。

技术解析：真正卡住端侧 MoE 的不是算力，是内存带宽。35B-A3B 每 token 只算 3B，可路由要等上一层算完才知道叫哪几位专家，手机内存装不下全部专家，大部分只能留在闪存里。过去的两种办法各有代价：用到哪个读哪个，慢到没法对话；给整段对话固定一小组专家，读盘次数少了，能挑的专家也少了。

前瞻专家调度（LES）走的是第三条路。团队观察到相邻两层的输入特征高度相似，于是当前层还在计算时，就把它的路由输入特征送进下一层的路由器，预测下一层要用的专家，后台线程提前把权重从闪存读进内存。测试中这套预测能备好超过 80% 的所需专家，且不需要额外训练。预测只管搬运和计算顺序，每个 token 最终用哪些专家仍由原路由机制决定，没猜中的照常加载照常算。计算顺序也跟着改：已加载到位且被选中的专家先算，其余同步加载。

另一半收益来自权重本身。逐层混合精度量化把专家权重压小，权重重新组织成连续存储布局以减少零散读取。团队另训了配套的 DSpark 草稿模型接入 llama.cpp，在 16GB 内存的 M5 Mac 上解码速度平均再提升 17%；16GB 内存的 iPad Pro M4 上，前瞻专家调度综合带来 5 倍解码提速。视觉侧沿用 LLaVA-UHD v4 的 ViT 内早期压缩，压缩倍率可在 4 倍与 16 倍之间切换，开到 16 倍时 MMBench 从 91.72 降到 90.87、OCRBench 从 91.20 降到 90.40。

分数上，35B-A3B 在 MMBench 91.72、MMStar 80.67、MMMU 80.22、MathVista 88.00、Video-MME 76.40、LongVideoBench 68.90；OmniDocBench v1.6 拿到 94.24，报道称同场另四个模型都在 80 分上下。纯文本侧 CMMLU 90.21、τ2-Bench 84.65。配套的自回放微调（Self-Replay Fine-Tuning）针对的是微调后旧能力回退：微调前先让模型回答一批覆盖原有能力的问题，筛出高质量回答混进新任务数据，回放数据只生成一次，之后学新能力可反复用，成本贴近普通 SFT。

行业影响：内存正在涨价，12GB 已成 AI 手机及格线，旗舰普遍 16GB，部分机型往 24GB 上探。IDC 预计 2026 年中国新一代 AI 手机出货 1.47 亿台、同比增长 31.6%、渗透率首次过半——每卖出两台新机就有一台带端侧 AI。内存越贵，用更少内存跑更大模型这笔账就越划算。竞争焦点也在移动：过去比芯片制程和算力，接下来比模型和推理框架能不能跟硬件配合。面壁和清华提出的密度定律给了一个节奏参照，能力密度约每 3.5 个月翻一番。生态铺得也快，发布当天完成瑞芯微、后摩、Intel、AMD、Arm 的适配，推理侧覆盖 SGLang、vLLM、llama.cpp、Ollama。

相关链接：量子位《iPhone断网跑35B多模态！国产开源新模型，只占3G内存》（2026-10-14 04:55） · 权重 openbmb/MiniCPM-V-4.7-35B-A3B · GGUF 量化版

二、LFM2.5-24B-A2B：24B 里只唤醒 2B，把推理 agent 留在本地

事件概述：Liquid AI 于 2026 年 10 月 13 日在 Hugging Face 发布 LFM2.5-24B-A2B，一个 24B 总参数、每 token 激活 2B 的推理型模型，定位是跑在用户自己硬件上的私有 agent。Base 与指令版权重都已开放。

技术解析：架构沿用 LFM2-24B-A2B：40 层，每个 MoE block 64 个专家、top-4 路由，门控短卷积与 GQA 混合。改动集中在三处——上下文从 32K 拉到 131K，词表通过 in-place 扩展从 65K 翻倍到 128K 以改善非拉丁语分词，预训练规模从约 17T token 提到约 33T。中训再加 2T token（32K 上下文，偏推理、数学、代码、指令遵循与多语）与 300B token（131K 上下文，偏长文本），工具调用与多轮轨迹贯穿两个阶段。

后训练拆成五步：SFT、教师专业化、非 agentic 的 MOPD 蒸馏、agentic 的 MOPD 蒸馏，最后把模型放进 OpenClaw、Hermes Agent、Pi、OpenCode 这些真实 harness 里做 agentic RL。与上一代最大的差别是它成了 reasoning-only 模型，回答前先显式产出思维链。

16 个基准上对比 Qwen3.6-35B-A3B、Gemma-4-26B-A4B-it、Nemotron-3.5-Lightning，它是这组里最小的模型。工具与 agent 类八项中五项领跑或持平：AutomationBench 27.69 对 8.72、5.46、2.61，BFCLv4 65.01 对 65.00，ToolSandbox 80.71 对 75.02，LiveClaw 48.09 对 38.19，τ³-Bench Banking 8.04。三项指令遵循基准 IFEval 96.75、IFBench 74.69、Multi-IF 84.38 全部第一。输的也清楚：GPQA Diamond 74.42 低于 Qwen3.6-35B-A3B 的 83.69，SWE-Bench Verified（OpenCode）51.00 对 66.20，SciCode 32.71 对 37.35，PinchBench 83.18 对 89.93，WebArena Verified 26.75 对 37.62。官方给的建议是知识密集场景配检索或联网搜索。

速度是另一条主线：M5 Max 上 184 tokens/s，Ryzen AI Max+ 395 上 114 tokens/s，官方称最多比次优模型快 1.7 倍且占用内存最少；单张 B300 高并发下输出超过 21K tokens/s。

行业影响：这组对照把「小」这件事讲细了一层。2B 激活参数意味着每个推理 token 都便宜，长链思考能持续烧下去而不必按次计费，agent 从「按调用付费的云端能力」变成「可以一直开着的本地进程」。代价摆在同一张表里——知识与代码类任务上，参数总量的差距没被架构和训练配方抹平。对用户，选型问题变成先分清任务是工具编排还是知识密集；对框架侧，第一天就支持 llama.cpp、MLX、vLLM、SGLang、ONNX 已是发布标配，端侧推理框架的适配速度本身成了竞争力。

相关链接：Liquid AI《Run fast, private agents on-device with LFM2.5-24B-A2B》（2026-10-13） · 权重 LiquidAI/LFM2.5-24B-A2B

三、zip2zip++：动态词表的质量缺口，一半出在设计，一半出在评分

事件概述：arXiv:2610.13605，Saibo Geng、Andrea Gentilini、Xinxian Ma、Nathan Ranchin、Yunzhen Yao、Robert West，2026 年 10 月 9 日提交，10 月 12 日批次公布，代码开源在 github.com/epfl-dlab/zip2zip-plus-plus。论文不改底层预训练模型，只改压缩层与 LZW 编解码器。

技术解析：用 LZW 在推理时动态造词表，能把同一段文本用更少的 token 表示，代价是推理与困惑度变差。作者的判断是这个缺口不是压缩的固有代价，并拆出四个原因：LZW 的合并机制在输入嵌入与输出嵌入之间制造了隐式冲突，一个共享嵌入解不开；把 RoPE 直接套在压缩序列上，忽略了合并后的 token 横跨多个原始位置；某些 token（尤其数字）被合并后对下游准确率伤害不成比例；动态词表引入的切分歧义干扰了标准评测。

对应四味药：解耦输入/输出的动态嵌入层、尺寸感知的 RoPE 定位（end indexing）、支持选择性合并与多视角切分的 LZW 编解码器、恒等初始化的残差超编码器。替换探针给出了几何证据——输出侧超编码器强烈前缀对齐（比率 4.8–6.6），输入侧接近平衡（约 1），原始 BPE 表两端都在 0.71–1.33，说明这种不对称是压缩训练中学出来的，绑在一起的共享嵌入无法两头兼顾。

数字以 Phi-3.5-mini（3.8B）与 Phi-3-medium（14B）为主。压缩率上，LZW 理论最多减少 40% 的 token 用量，实验设 M=4、codebook 4096，实测压缩率约 1.43×。GSM8K 的修复最猛：3.8B 从 0.36 到 0.68（无压缩基线 0.75），14B 从 0.51 到 0.69（无压缩 0.70，差 1 分）。消融里单一最大来源是数字保护，单独就把 GSM8K 从 0.36 拉到 0.61；尺寸感知 RoPE 在困惑度不变的前提下再加 2.7 分。困惑度上 3.8B 的 Wiki 字节级从 1.70 降到 1.66（无压缩 1.58），14B 从 1.58 降到 1.53（无压缩 1.43）。长上下文 RULER 恢复幅度更大，3.8B 的 32K 从 15.2 回到 52.8（无压缩 73.7）。

两个限定要标清楚。缺口只关掉约一半，不是关完：作者自己的拆解是配方关掉约三分之一，余下 1/6 到 1/3 是多视角评分揭示的评分伪影，而非建模失败。负面结果也有——14B 上 HumanEval 从 0.36 掉到 0.31、IFEval 从 0.43 掉到 0.40；追加 200B token 继续预训练拿到最好的困惑度（Wiki 1.63），GSM8K 反而从 0.68 掉到 0.64，作者据此指出困惑度与推理能力会分道扬镳。

行业影响：这条路线和量化、剪枝不是一个思路，它动的是 token 序列本身，模型权重一行不改。对推理服务商，等于在不动模型的前提下拿到一条独立于硬件的加速维度，还能跟现有优化叠加。论文最值钱的地方是把「压缩必然掉质量」这个笼统判断拆成了四条可分别修的具体机制，并顺手指出其中一块掉分是评测口径造成的假象——这提示任何拿动态词表做对比的实验，都得先说清用严格评分还是多视角评分。MATH-500 仍明显低于无压缩基线（3.8B 的 0.24 对 0.36），说明需要多步符号操作的任务还留在缺口里，这条路离质量中性尚有距离。

相关链接：arXiv:2610.13605《zip2zip++: Towards Inference-Time Token Compression with Minimal Quality Loss》 · HTML 全文（含 Table 1–5） · 代码 epfl-dlab/zip2zip-plus-plus

四、KV-Repurpose：同一份文档换个系统提示，KV 还能不能用

事件概述：arXiv:2610.13060，Taiga Ikeda、Daisuke Miyashita、Jun Deguchi，2026 年 10 月 9 日提交，10 月 12 日批次公布。论文给出一个基于 vLLM 的开源 testbed，用来开发和评测超出精确前缀的分段级 KV-cache 复用，代码以 Apache-2.0 释出。

技术解析：线上 serving 的 KV 复用基本只允许精确前缀匹配。可一旦同一篇检索文档出现在不同的系统提示、对话历史或动态元信息之后，前缀就断了，只能重算。KV-Repurpose 把复用单位从整个前缀换成段落，配套做了缓存感知的分段调度、提示构建、容量管理、负载生成与运行时监控。

实验用 GPT-OSS-120B，vLLM v0.20.0 扩展版，单张 H200，KV 存 NVMe SSD，前缀缓存基线是 LMCache。负载取自 LongBench Pro T5.1 的英文文档（8K–128K tokens），按 Zipfian 分布采样 2500 个请求，其中 20% 或 50% 的请求共享一个固定的 datetime 前缀，其余用各自的时间戳。30GB 缓存容量下、20% 配置里，KV-Repurpose 的 token 级命中率是 63.9%，前缀缓存只有 3.3%。给前缀缓存 1TB，这个负载下命中率也只到 17.9%；50% 共享前缀配置下前缀缓存拿到 47.3%。命中率换来的是 p50 与 p95 的 TTFT 双低，上下文超过约 16K tokens 后优势显现；高请求率下前缀缓存先饱和，KV-Repurpose 在多数重载配置里还能撑住更高吞吐。

质量是这篇最诚实的部分。单文档场景几乎不掉：QASPER 的 token 级 F1 是 0.42，重算基线也是 0.42；QMSum 的 ROUGE-L 从 0.20 到 0.19。跨文档推理掉得明显：HotpotQA 0.71 到 0.60，MuSiQue 0.61 到 0.40，2WikiMultihopQA 从 0.80 掉到 0.50。用参考答案筛出相关文档再做一次诊断实验，2WikiMultihopQA 从 0.50 回到 0.57，重算基线是 0.78——能补一部分，补不回来。25 个任务的 LongBench Pro 平均上，重算 0.45、默认 KV-Repurpose 0.43、换成 Opus 3 的系统提示回到 0.45、换成 Haiku 3.5 的提示 0.44。

行业影响：RAG 线上流量的形态，恰恰是前缀缓存最不擅长的那种——文档复用率高，前缀却各不相同。论文给出的数量级对比足够尖锐：30GB 拿到 63.9% 命中，前缀缓存堆到 1TB 也只有 17.9%，靠加容量追不上。把复用边界从前缀放宽到段落，等于把缓存策略从运气好才命中变成可调度。边界也一并划清了：单文档问答与摘要可以直接上，跨文档多跳推理不行，除非先做一轮文档筛选。工程上这给出一条明确的分流规则——按是否需要跨文档推理决定走复用还是走重算，而不是按缓存容量决定。

相关链接：arXiv:2610.13060《KV-Repurpose: A Testbed for Evaluating Non-Prefix KV-Cache Reuse》 · HTML 全文（含 Table 1–3） · 代码 taiga333/eval-kv-repurpose

相关链接