企业官网建设流程全解析

树莓派也能跑：NeoHorse-1-9B 端侧部署全程实录

【免费下载链接】NeoHorse-1-9B项目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B

一个 9B 参数的因果语言模型，通常意味着至少 18GB 的 BF16 权重、一张 24GB 以上的显卡——这是多数人对"9B 大模型"的默认预期。但 NeoHorse-1-9B 让"9B 模型 + 低功耗小板"这个组合第一次在工程上变得合理：它的 32 层网络里只有 8 层是标准全注意力，其余 24 层是线性注意力（类 SSM 状态空间层）；社区公开实测显示它在 4GB 显存设备（RTX 3050 4G、RTX 3060，乃至树莓派 + 外接 GPU）上可以稳定推理，官方报告给出的 tau²-Bench 得分高达 90.82。

本文不做 PPT 式渲染。我会把仓库源码（模型配置、权重索引、分词器、Chat Template）与社区公开实测放在一起交叉验证，完整走一遍"硬件选型 → 量化 → llama.cpp 跑通 → 评测数据核对"的部署闭环，同时明确区分哪些数字来自官方报告、哪些来自社区实测、哪些需要你自己复测。

一、先看这匹马的来历：Agent-Native 模型与端侧布局

据澎湃新闻 2026 年 9 月报道，基元律动（TokenRhythm）联合无问芯穹、清华大学、北京大学、阿里巴巴等机构发布首个 Agent-Native 模型 NeoHorse-1，包含 4B 与 9B 两个版本。基元律动由前华为诺亚方舟实验室主任、盘古大模型负责人王云鹤创办，此前已开源 Routing Harness 系统 OpenSquilla，用于在 Agent 执行任务时选择和组织不同模型；NeoHorse 把这条"路由编排"路线延伸到了模型训练本身——训练语料以 Routing Harness 产生的执行轨迹为核心，保留能力需求预测、路由选择、模型响应、工具调用和环境反馈，经完整性检查与质量评估后用于后训练。

回到本仓库对应的 9B 版本（README.md），关键事实有三个：

• 底座与许可：从 Qwen3.5-9B 经 agentic post-training 而来，Apache-2.0 协议，仅含语言模型权重（text-only，视觉权重未包含），任何二次修改说明都写进了配置与权重索引的元数据中；
• 上下文能力：原生 262,144 token，可扩展至 1,010,000 token；
• 定位：面向文本 Agent harness、工具调用、编码与指令遵循，评测覆盖 Agentic、Coding、Instruction Following 三大类共十个基准。

对端侧部署者而言，最值得关注的其实是 config.json 里那 28 行layer_types——它决定了这台"9B 的马"到底有多省内存。

二、源码里的答案：24 层线性注意力如何改写内存账本

打开 config.json，网络结构一目了然：

"layer_types": [ "linear_attention", "linear_attention", "linear_attention", "full_attention", "linear_attention", ... // 每 4 层出现一次 full_attention ]

32 层中，24 层是linear_attention，只有 8 层是full_attention（第 3、7、11、15、19、23、27、31 层）。再对照 model.safetensors.index.json 中的张量名，linear_attention 层的子模块包含in_proj_qkv、in_proj_z、in_proj_a、in_proj_b、conv1d、dt_bias、A_log、norm、out_proj——这是标准的 Mamba 系状态空间层命名：QKV 线性投影、z 门控、a/b 投影、一维卷积（linear_conv_kernel_dim为 4）、离散时间步长偏置与 A 矩阵对数。

这组配置意味着什么？

KV 状态是"恒定尺寸"的。全注意力层的 KV cache 随序列长度线性增长；而线性注意力层的状态由linear_key_head_dim: 128 × 16个 key head 与linear_value_head_dim: 128 × 32个 value head 决定，是一个固定大小的压缩状态，不随序列变长而膨胀。这正是 9B 模型敢把原生上下文做到 26 万 token 的底气，也是端侧部署最核心的省内存点。

量化视角下的权重账本同样清晰。权重索引标注total_size: 17,907,606,528，即BF16 全量约 17.9GB（约 16.7 GiB），拆成 4 个 safetensors shard。按 9B 参数量粗算：

配合"8 层全注意力"的结构，长上下文的 KV 开销也被压缩：按 8 个 full_attention 层 × 4 个 KV head × 256 head_dim 计算，约 32KB/token（FP16 估算），8K 上下文约 256MB、32K 上下文约 1GB——在线性注意力层不随序列增长的前提下，这个预算在树莓派 8GB 内存里是付得起的。

三、硬件与准备：三条路线的配置清单

先说结论：没有官方"最低配置"承诺，社区公开情报给出的实测基准是 4GB 显存设备稳定推理（RTX 3050 4G / RTX 3060，以及树莓派 + 外接 GPU 的组合），且官方明确做了 GGUF 量化适配与 llama.cpp 深度协同。据此可以把部署路线分为三档：

路线 A：树莓派 5 纯 CPU（8GB RAM 起步）

• 权重用 Q3_K / Q2_K 级量化（约 3-4GB），加载后系统剩余内存需支撑 KV 与运行时；
• 适合离线批处理、定时任务、隐私敏感的单机场景；速度满足"能跑"，但不足以支撑实时交互式对话；
• 磁盘建议 64GB 起步（BF16 全量就占 17.9GB，若还要存放原始权重再加一倍），务必用 USB3.0 外接 SSD 或 NVMe 转接，microSD 的随机读写会显著拖慢 mmap 加载；
• 系统用 64 位 Raspberry Pi OS 或 Ubuntu Server，llama.cpp 编译依赖 cmake / gcc。

路线 B：树莓派 5 + 外接 GPU（推荐）

• 通过 PCIe 转接卡挂一张 4-8GB 显存的 GPU（社区实测覆盖 RTX 3050 4G 与 RTX 3060）；
• 权重用 Q4_K_M（约 5.1GB），全部层 offload 到 GPU，8GB 树莓派内存专职 KV cache 与系统；
• 这是社区实测中"4GB 显存稳定推理"对应的典型形态，也是树莓派场景下最接近可交互速度的组合。

路线 C：二手迷你主机 / 旧笔记本 + 独显

• RTX 3060 12GB 或 3050 4G，Q8_0 档位，内存 16GB 以上；
• 最省心，适合作为"先跑通再下放"的基准环境。

无论哪条路线，都要先想清楚三个数字：权重体积（量化档位决定）、可用 RAM（树莓派 5 只有 4/8GB 两档）、磁盘速度（决定加载时间）。建议先花两分钟算完账再下单硬件。

四、GGUF 量化与推理：从 HF 权重到 llama.cpp 跑通

仓库本身只发布 BF16 safetensors 权重（model-00001-of-00004.safetensors 至 model-00004-of-00004.safetensors），不含 GGUF，因此端侧第一步是量化。完整链路如下：

第 1 步：下载权重到本地。拉取整个仓库（config.json、tokenizer 文件、4 个 shard、chat_template.jinja、model.safetensors.index.json），得到一个标准的 Hugging Face Transformers 目录。MODEL_PATH指向该目录。

第 2 步：转换并量化。用 llama.cpp 的标准转换工具链：先把 safetensors 转成 FP16 GGUF，再用llama-quantize产出目标档位（Q4_K_M / Q8_0）。社区对同系列模型的实测对比（Q4_K_M vs Q8_0）表明：低比特档位在结构化任务上的格式稳定性会明显下滑，Agent/工具调用任务建议 Q8_0，纯对话或低内存场景才退到 Q4_K_M——这个经验对 NeoHorse-1-9B 同样适用。

第 3 步：确认 tokenizer 与模板。tokenizer_config.json 指明Qwen2Tokenizer、词表 248,320、<|im_start|>/<|im_end|>消息包裹；chat_template.jinja 是核心——它完整实现了<tool_call>/<tool_response>工具调用协议与<think>推理标记处理。端侧跑 Agent 场景时，必须让推理框架保留这些特殊 token，否则模型在工具调用链路上会"失忆"。

第 4 步：启动 llama.cpp 服务。以 llama-server 为例：

llama-server -m NeoHorse-1-9B-Q4_K_M.gguf \ -ngl 999 \ # 全层 GPU offload；纯 CPU 时去掉并加 -t 4 -c 8192 \ # 端侧先收敛上下文，不要照搬 262144 --jinja # 启用仓库自带 chat template

启动后即可用 OpenAI 兼容接口验证：

curl http://localhost:8080/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"messages":[{"role":"user","content":"用 Python 写一个返回前 n 个斐波那契数的函数"}]}'

注意一个前提：qwen3_5_text是较新的架构（config.json 中model_type），需使用包含对应架构支持的 llama.cpp 版本，社区情报显示官方已针对 GGUF 与 llama.cpp 做了专门适配。

五、实测数据：官方评测、社区实测与推算账本交叉验证

把三类数字分开看，避免混淆：

官方报告数字（来源：README.md 评测表，SGLang v0.5.17 + thinking 模式协议）：

这套数字证明"9B 有效参数"的 Agent 能力不是宣传话术：工具调用（BFCL v4）、Agent 闭环（tau²-Bench）、指令遵循均有可查的增量。但它是在全精度权重 + SGLang + thinking 模式（temperature=1.0、top_p=0.95、enable_thinking=true）下测得的，端侧量化复测会有浮动，属于正常现象。

社区实测数字（来源：公开技术解析文章）：4GB 显存设备上稳定推理（RTX 3050 4G / RTX 3060 / 树莓派 + 外接 GPU），单位显存吞吐密度较同硬件下的 30B 级模型提升约 2.3 倍；llama.cpp 原生部署，兼容 Windows 与树莓派等边缘设备。这些数字可作为选型依据，但建议到手后用自己的 Prompt 集复测一遍。

可由仓库配置直接推算的账本（来源：config.json）：前文已列——BF16 全量约 17.9GB，Q4_K_M 约 5.1GB，Q8_0 约 9.1GB；KV cache 仅 8 层全注意力随序列增长，约 32KB/token。这是本文唯一"确定"的预算，也是端侧部署的决策基础。

生成质量速览：端侧常见疑问是"9B 在树莓派上是不是只能答短句"。官方协议是 thinking 模式（先产出<think>推理再输出），chat_template.jinja 对推理标记做了精细处理（仅对最后一条用户查询之后的 assistant 回复保留 think 前缀）。实测感受类指标无法从仓库直接获得，建议用 IFEval 类指令遵循样例（官方 89.09 分）和 20-30 条工具调用样例做冒烟测试，重点盯两件事：JSON/XML 格式稳定性、多轮工具调用后是否出现"中间遗忘"。

六、端侧避坑清单

• 上下文先收敛再放开：README 的官方部署示例（SGLang/vLLM）都写--context-length 262144，但端侧务必先降到 8-32K，否则全注意力层 KV 会把 8GB 内存吃穿；实测增量不明显的任务，8K 足够。
• 量化档位与任务类型绑定：对话场景 Q4_K_M 可用；Agent/工具调用场景优先 Q8_0；若只有 4GB 显存且必须跑 Agent 任务，先做好"格式回退 + 重试"的容错层。
• think 标记别丢：llama.cpp 启动时启用--jinja并使用支持 qwen3 系推理解析的版本，否则<think>会被当成正文输出，破坏 OpenAI 兼容协议。
• 采样参数不要照抄官方评测：官方temperature=1.0+ 多种 penalty 是为评测协议服务的；端侧单机交互建议降温度、收紧 top_p，换来格式稳定性。
• 交换分区是最后手段不是常态：树莓派上用 zram 压缩交换可以兜底 OOM，但一旦触发 swap 频繁读写，吞吐会掉一个数量级；优先在"量化档位 × 上下文长度"上做减法。

写在最后

NeoHorse-1-9B 的端侧可行性，本质上是一个架构问题：24 层线性注意力把 9B 模型的推理成本从"24GB 显卡专属"拉到了"4GB 显存 / 树莓派 8GB"的档位，量化再把权重从 17.9GB 压到 5GB 量级。官方评测给了它 Agent 能力的硬数据，社区实测给了它低显存硬件的验证，剩下的——上下文收敛、量化档位、容错设计——是部署者自己要做的工程取舍。

低配设备跑 9B Agent 模型这件事，已经从"能不能"进入了"怎么跑得更稳"的阶段。这份实录里的每一步都可以在仓库源码里找到对应物，也建议你在自己的硬件上把最后那组"速度与质量"的数字补上。

【免费下载链接】NeoHorse-1-9B项目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B