树莓派也能跑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 参数量粗算量化档位约占用说明BF16仓库原版~17.9GB需 24GB 级设备端侧不现实Q8_0~9.1GB质量损失最小需 12GB 级设备Q4_K_M~5.1GB端侧甜点档4-8GB 设备可承载Q3_K / Q2_K~3.4 / ~2.8GB纯 CPU 树莓派的极限档配合8 层全注意力的结构长上下文的 KV 开销也被压缩按 8 个 full_attention 层 × 4 个 KV head × 256 head_dim 计算约 32KB/tokenFP16 估算8K 上下文约 256MB、32K 上下文约 1GB——在线性注意力层不随序列增长的前提下这个预算在树莓派 8GB 内存里是付得起的。三、硬件与准备三条路线的配置清单先说结论没有官方最低配置承诺社区公开情报给出的实测基准是 4GB 显存设备稳定推理RTX 3050 4G / RTX 3060以及树莓派 外接 GPU 的组合且官方明确做了 GGUF 量化适配与 llama.cpp 深度协同。据此可以把部署路线分为三档路线 A树莓派 5 纯 CPU8GB RAM 起步权重用 Q3_K / Q2_K 级量化约 3-4GB加载后系统剩余内存需支撑 KV 与运行时适合离线批处理、定时任务、隐私敏感的单机场景速度满足能跑但不足以支撑实时交互式对话磁盘建议 64GB 起步BF16 全量就占 17.9GB若还要存放原始权重再加一倍务必用 USB3.0 外接 SSD 或 NVMe 转接microSD 的随机读写会显著拖慢 mmap 加载系统用 64 位 Raspberry Pi OS 或 Ubuntu Serverllama.cpp 编译依赖 cmake / gcc。路线 B树莓派 5 外接 GPU推荐通过 PCIe 转接卡挂一张 4-8GB 显存的 GPU社区实测覆盖 RTX 3050 4G 与 RTX 3060权重用 Q4_K_M约 5.1GB全部层 offload 到 GPU8GB 树莓派内存专职 KV cache 与系统这是社区实测中4GB 显存稳定推理对应的典型形态也是树莓派场景下最接近可交互速度的组合。路线 C二手迷你主机 / 旧笔记本 独显RTX 3060 12GB 或 3050 4GQ8_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 模式协议基准Qwen3.5-9BNeoHorse-1-9BΔtau²-Bench88.0490.822.78PinchBench74.5582.257.70BFCL v464.8867.432.55QwenClawBench44.0448.734.69VitaBench31.2542.2511.00HumanEval92.6898.175.49十基准平均65.6069.043.44这套数字证明9B 有效参数的 Agent 能力不是宣传话术工具调用BFCL v4、Agent 闭环tau²-Bench、指令遵循均有可查的增量。但它是在全精度权重 SGLang thinking 模式temperature1.0、top_p0.95、enable_thinkingtrue下测得的端侧量化复测会有浮动属于正常现象。社区实测数字来源公开技术解析文章4GB 显存设备上稳定推理RTX 3050 4G / RTX 3060 / 树莓派 外接 GPU单位显存吞吐密度较同硬件下的 30B 级模型提升约 2.3 倍llama.cpp 原生部署兼容 Windows 与树莓派等边缘设备。这些数字可作为选型依据但建议到手后用自己的 Prompt 集复测一遍。可由仓库配置直接推算的账本来源config.json前文已列——BF16 全量约 17.9GBQ4_K_M 约 5.1GBQ8_0 约 9.1GBKV 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 兼容协议。采样参数不要照抄官方评测官方temperature1.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考