10 月 22 日讯飞 1024 开发者节上，星火 X2.6 端云一体大模型正式亮相，官方反复强调的一个点是”全国产算力训练”。发布会热闹归热闹，但对普通开发者来说，真正值得动手的是同场开源的端侧模型 Spark-X2.6-4B：Apache 2.0 协议、Hugging Face 直接提供 GGUF 权重、Ollama 也有官方镜像。我在 16GB 内存 的 M4 MacBook 上把它完整跑了一遍，结论先给：这次 4B 级模型是真的能当日常工具用，不像上周我测的 24B MoE 只能算技术验证。不过官方宣传的三档思考（none/low/high），在 llama.cpp 里的实际行为和文档说的不太一样，有两个坑值得你知道。
它是什么，凭什么值得关注
先交代背景。星火 X2.6 云端旗舰是 293B-A30B 的 MoE 架构，上下文拉到 1M，输入定价限时 0.9 元/百万 tokens——这些是云端的事，普通开发者短期内更关心的其实是端侧这颗小的。Spark-X2.6-4B 与上一代 X2.5-4B 架构完全相同，能力提升全部来自后训练。官方给的跑分提升幅度不小：BFCL-V4 从 65.1 涨到 71.8，SWE Verified 从 41.6 涨到 62.8，BrowseComp 从 40.9 涨到 53.1（以上为官方自评数据，我没有复现跑分环境）。
跑分之外有两点对我这种”想在自己电脑上跑个本地模型干活”的人更实际：一是 llama.cpp 在 9 月 6 日就已加入 Spark 架构（Spark2_5ForCausalLM）原生支持，所以 X2.6-4B 可以直接用现成的 llama.cpp 跑，不需要等社区适配；二是它提供了 GGUF 量化版本，Q4_K_M 只有 3.3GB。
对比一下我之前测过的端侧模型就能看出定位差异：LFM2.5-24B-A2B 在 16GB Mac 上踩满内存坑，纯 CPU 只有 2.3 tokens/s；MiniCPM5-2B 够轻但能力有限。Spark-X2.6-4B 正好卡在中间——足够小到轻松放下，又比 2B 级模型在 Agent 和代码任务上能打。
五分钟跑起来：下载到出第一个回答
我的环境：MacBook Pro（Apple M4，16GB 内存），llama.cpp 0.5.0（Homebrew 版），macOS 26.5。以下命令你可以直接照抄。
下载 Q4_K_M 权重（3.3GB，我实测 7 分 12 秒下完）：
curl -L -o Spark-X2.6-4B-Q4_K_M.gguf \
"https://huggingface.co/XHToken/Spark-X2.6-4B-GGUF/resolve/main/Spark-X2.6-4B-Q4_K_M.gguf"
# 启动服务：全量 GPU offload + 开启 jinja 模板（工具调用必须 --jinja）
llama-server -m Spark-X2.6-4B-Q4_K_M.gguf \
--port 8849 -c 8192 --jinja -ngl 99实测加载只用了 3.4 秒（-ngl 99 全量 offload 到 Metal），服务起来后常驻内存约 4.16GB（RSS 实测值）。对比上次 24B 模型连默认 offload 都 Metal OOM 的场面，4B 在 16GB 机器上确实是绰绰有余。如果你没用过 llama.cpp，可以从这篇本地部署大模型的入门指南看起。
用 OpenAI 兼容接口调用（Python 标准库即可，无需装 SDK）：
import json, urllib.request
body = {
"model": "spark",
"max_tokens": 300,
# 关键：关闭思考要用 enable_thinking，不是 thinking: "none"
"chat_template_kwargs": {"enable_thinking": False},
"messages": [{"role": "user", "content": "用一句话解释MoE为什么省算力"}],
}
req = urllib.request.Request(
"http://127.0.0.1:8849/v1/chat/completions",
json.dumps(body).encode(),
{"Content-Type": "application/json"},
)
with urllib.request.urlopen(req) as r:
d = json.loads(r.read())
print(d["choices"][0]["message"]["content"])实测这条请求 2.83 秒返回、81 个 tokens，回答准确干净。关思考模式下长文生成的解码速度稳定在 约 30 tokens/s（连续 5 组测试 29.6–30.6 tokens/s），这个速度读起来是流畅的，不卡顿。
坑一：thinking: "none" 根本关不掉思考
这是本次实测最大的反转。官方文档说模型有三档思考：none / low / high，看起来传 "thinking": "none" 就该关掉。我在 llama.cpp 0.5.0 下实测，传 {"thinking": "none"} 模型照样思考——同一个”一句话解释 MoE”的问题，reasoning_content 产出 649 到 1125 字符，400 个 max_tokens 全被思维链吃光，finish_reason=length，正文一个字都没输出。
真正有效的关法是另一个参数名：{"enable_thinking": false}，这才是模型 chat template 里实际识别的开关。改完立即生效，2.83 秒拿到完整回答。这个坑的根源是 chat template 的参数名和官方文档描述的三档位没对齐，至少在 llama.cpp 的 jinja 渲染路径上是这样的。Ollama 镜像路径我没有实测（本机未装 Ollama），不排除那边行为不同。
坑二：low 档不比 high 省事，思考预算完全不可预测
第二坑更反直觉。我用”9.11 和 9.9 哪个大”这道经典题分别测了 high 和 low 两档，各给 800 tokens 预算：
- high 档：思考 222 字符，257 个 tokens 收尾，答对（9.9 更大，理由正确）；
- low 档：思考 1831 字符——比 high 想了 8 倍还多，800 个 tokens 全部耗尽，
finish_reason=length，正文为空。
也就是说在 llama.cpp 路径下，low/high 档位标签并不对应可靠的思考预算，同一个问题 low 可能想得比 high 多得多。实操建议：只要开着思考，max_tokens 请给到 800 起步，别按”低档=短思考”的直觉省预算，否则你会拿到一个 content 为空的响应还不知道为什么。顺带说一句，X2.6-4B 在 high 档下把 9.11/9.9 这道题做对了，4B 级别里这个数学认真度算是超预期。
工具调用：一次通过
端侧模型做 Agent 的底线是工具调用不能翻车。我注册了一个 get_weather 函数，问”合肥今天天气怎么样”：
finish_reason: tool_calls（1.80 秒）
tool_calls: [{"name": "get_weather", "arguments": "{\"city\": \"合肥\"}"}]一次通过，函数名和参数 JSON 全部合规，参数正确填了中文城市名。--jinja 必须加，这是 llama.cpp 里启用模型自带工具调用模板的前提。如果你在搭本地 Agent 服务，可以参考这篇 OpenAI Agents API 的对照实践。
要不要用它？我的判断
建议用的场景：16GB 内存设备上的日常问答、文档摘要、简单的工具调用 Agent 原型。3.3GB 权重 + 4GB 常驻内存 + 30 tokens/s，这三项加起来是”可以一直挂着”的水平，这是 24B 级模型在同等内存下给不了的。
不建议的场景：复杂多步推理和长程 Agent 任务。官方跑分虽然亮，但 4B 的推理上限摆在那里；我实测中 low 档连预算都控制不好，长程任务的稳定性需要你自己压测。另外”自研推理框架效率高于 Ollama”是讯飞发布会上的说法，我本次没有装 Ollama 做对照，这一条未实测，需人工确认——但 llama.cpp 下 30 tokens/s 的实际体感已经够用了。
最后给个下载渠道参考：国内网络建议走 ModelScope（官方仓库标注为国内推荐源），Hugging Face 直链我实测 7 分钟下完 3.3GB。模型卡片和完整运行文档在官方 GitHub 仓库，GGUF 权重页，云端 API 和网页试用在讯飞星火官网。想搭建完整的本地推理环境的，这篇 Open Dots 自托管方案可以接着看。