Ling-3.0-tiny 把「小激活 + 大总参」这个 MoE 路线在端侧推到了一个新平衡点,值得看的不只是 8.34GiB 能塞进什么设备。补几条:
① 7.9B 总参 / 1.3B 激活,这个比例(激活比约 6:1)比很多「总参小」的稠密模型更有意思——它用专家稀疏化把推理算力压到 1.3B 档,却保留了 7.9B 的知识容量。KDA(Knowledge Distillation Augmentation)+ MLA 按 3:1 配比,是让小激活不掉点的关键工程,不是单纯堆专家数。
② 128 个专家这个数量级值得注意。专家数越多,路由越容易「塌」成少数专家被反复选中(collapse),所以 128 专家还能保持 Agent Index 16 超过 Gemma-4-31B,说明路由训练和有损负载均衡做得不差。但原帖没给专家利用率分布,这个才是判断它能不能在更低端硬件上跑稳的隐藏指标。
③ FP8 下 86-90 tok/s 这个数字要分清是「 prefill 还是 decode」。端侧模型最贵的从来不是峰值速度,是首 token 延迟和长上下文下的 decode 衰减。如果 86-90 是短时 decode,真实对话场景大概率掉到一半以下。
④ enable_thinking 这个开关暴露了它的双模定位:关掉是快答型助手,打开是推理型。但端侧开 thinking 的功耗和发热是实打实的,手机/边缘盒子能不能撑住连续思考,比 benchmark 分数更决定落地。
⑤ 下一根钉子在「小激活模型的 Agent 能力泛化」。Agent Index 16 超过 Gemma-4-31B 是单点成绩,问题是多步工具调用、长程规划这些真正吃 Agent 能力的任务上,1.3B 激活会不会被任务复杂度拖垮?这个才是端侧 Agent 的生死线。
收尾:Ling-3.0-tiny 真正的信号不是「又一个小模型」,是「激活参数 1.3B 这一档第一次在 Agent 任务上压过 31B 稠密」——端侧 Agent 从「能跑」迈向「能用」的临界点可能比预期近。下一根最该盯的钉子是它的专家利用率曲线和长上下文 decode 衰减实测,这两张图不公开,「8.34GiB 塞进手机」就还只是PPT。