端侧模型还在 128K 里打转？讯飞把 100 万 Token 塞进了 4B 模型

你见过只配背三页台词的话剧演员吗？台词一长，导演就把他叫下来，把剧本撕成八份，让他一份一份背，背完再拼起来演。

过去的端侧大模型，就是这个演员。

128K 上下文——一份 60 页的售后手册，它得切成五段才能看完；一段代码仓库，它看了开头忘了结尾。云端模型动辄百万级上下文，端侧的芯片就那么大，没人觉得这事有解。

直到讯飞把 100 万 Token 塞进了 4B 模型。

一个数字的战争：128K 对 1M

先看同行。Google 最新的端侧模型 Gemma 4 E4B，上下文 128K；Qwen3-4B 原生也就百 K 级。128K 是什么概念？相当于一张海报被裁成八份，模型一次只能看一份。

星火 X2.5-4B 和 1.7B，原生 1M——整整 8 倍。这是目前端侧开源模型里唯一做到的。

为什么别人做不到？因为"上下文"这三个字，是要用显存换的。

KV Cache 数学：为什么没人做端侧 1M

Transformer 每多一个 Token，就要多存一份 Key/Value，这就是 KV Cache。它和上下文长度成正比，是显存的吞金兽。

实测数据摆在这儿：Qwen3-4B 在 128K 上下文时，KV Cache 就要吃掉约 18GB 显存。照这个比例，1M 上下文直接奔着 144GB 去了——端侧设备拿什么扛？

所以各家都卡在"想给长，但给不起"。

星火的解法是混合注意力架构：该全量注意的全量注意，该压缩的压缩，把百万级上下文的 KV Cache 压到端侧能承载的量级。这套路不是没人想过——DeepSeek V4 用 c128a 压缩注意力，把 1M 上下文的 KV Cache 压到了 9.62 GiB。但那是服务器端的玩法；把它做到 4B 小模型里、还能塞进本地设备，讯飞是第一个。

干活，不是聊天

长上下文解决"看得全"，工具调用解决"干得动"。这俩凑齐了，端侧模型才算从"能聊"进化到"能干活"。

三个真实场景，看完你就知道差距在哪：

• 售后手册：把完整手册一次性丢进去，问"购买 10 天后故障、用过第三方耗材，能换货吗"，它能把退换货、故障处理、例外条件跨章节串起来答——这是把文档切碎再问的模型永远做不到的
• 办公：喂一张销售明细表，它自己写脚本做汇总、提取指标、生成 3000 字中文业绩报告，再沿用原格式翻成英文，最后自检排版——全流程本地跑完
• 智能家居：1.7B 在 Domux 测试集上，控制指令端到端执行正确率 90.3%，平均响应 0.85 秒

代码场景更是直接：官方说法是 4B 可以对标参数大 2-3 倍的云端模型，而且代码资产不出本地，能接 DeepSeek Harness、OpenCode、Codex、Pi 这些主流 Harness。

最低配置：你的电脑跑得动吗

模型权重已开源，Apache-2.0 协议，llama.cpp / Ollama / LM Studio 直接部署。给你一张估算表（以官方文档为准）：

代价清醒：先把丑话说在前面

第一，这是讯飞官方自述。90.3% 正确率、对标 2-3 倍参数云端模型，都是自家测试口径，目前还没有第三方复现。模型开源刚一天，社区实测数据几乎为零——别急着全信。

第二，"支持 1M 上下文"和"1M 上下文全程满血跑"是两回事。长上下文下 KV Cache 仍是硬成本，端侧 1M 大概率是"能收进来"，而不是"全程满血推理"。真到 1M 场景，速度会打折。

第三，4B 终究是 4B。百万级记性不代表百万级智力——复杂推理它干不过大模型，这是物理规律，不是优化能解决的。

第四，"唯一"是个有期限的词。Gemma 4 已经把端侧上下文推到 128K，Qwen 端侧系列也在加长，这个身位最多保持一个季度。

趋势判断：端侧的下半场是"小模型干大活"

9 月 7 日，讯飞还要发旗舰版星火 X2.5，主打代码和智能体能力——端侧先铺路，旗舰再收割，这套打法很典型。

端侧 AI 的下半场已经不在"谁跑得动"，而在"谁记得住、谁干得完"。4B 模型的 1M 上下文只是个开始：当"记性"不再是端侧的短板，手机、PC、汽车座舱、机器人，都会变成真正干活的 Agent，而不是只会聊天的玩具。

相关链接：

• GitHub 仓库：https://github.com/XHToken/Spark-X2.5
• Hugging Face：https://huggingface.co/collections/XHToken/spark-x25
• 讯飞星辰 MaaS 平台：https://maas.xfyun.cn/modelSquare