部署全程實錄)
樹莓派也能跑NeoHorse-1-9B 端側(cè)部署全程實錄【免費下載鏈接】NeoHorse-1-9B項目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B一個 9B 參數(shù)的因果語言模型通常意味著至少 18GB 的 BF16 權(quán)重、一張 24GB 以上的顯卡——這是多數(shù)人對9B 大模型的默認(rèn)預(yù)期。但 NeoHorse-1-9B 讓9B 模型 低功耗小板這個組合第一次在工程上變得合理它的 32 層網(wǎng)絡(luò)里只有 8 層是標(biāo)準(zhǔn)全注意力其余 24 層是線性注意力類 SSM 狀態(tài)空間層社區(qū)公開實測顯示它在 4GB 顯存設(shè)備RTX 3050 4G、RTX 3060乃至樹莓派 外接 GPU上可以穩(wěn)定推理官方報告給出的 tau2-Bench 得分高達(dá) 90.82。本文不做 PPT 式渲染。我會把倉庫源碼模型配置、權(quán)重索引、分詞器、Chat Template與社區(qū)公開實測放在一起交叉驗證完整走一遍硬件選型 → 量化 → llama.cpp 跑通 → 評測數(shù)據(jù)核對的部署閉環(huán)同時明確區(qū)分哪些數(shù)字來自官方報告、哪些來自社區(qū)實測、哪些需要你自己復(fù)測。一、先看這匹馬的來歷Agent-Native 模型與端側(cè)布局據(jù)澎湃新聞 2026 年 9 月報道基元律動TokenRhythm聯(lián)合無問芯穹、清華大學(xué)、北京大學(xué)、阿里巴巴等機(jī)構(gòu)發(fā)布首個 Agent-Native 模型 NeoHorse-1包含 4B 與 9B 兩個版本?；蓜佑汕叭A為諾亞方舟實驗室主任、盤古大模型負(fù)責(zé)人王云鶴創(chuàng)辦此前已開源 Routing Harness 系統(tǒng) OpenSquilla用于在 Agent 執(zhí)行任務(wù)時選擇和組織不同模型NeoHorse 把這條路由編排路線延伸到了模型訓(xùn)練本身——訓(xùn)練語料以 Routing Harness 產(chǎn)生的執(zhí)行軌跡為核心保留能力需求預(yù)測、路由選擇、模型響應(yīng)、工具調(diào)用和環(huán)境反饋經(jīng)完整性檢查與質(zhì)量評估后用于后訓(xùn)練。回到本倉庫對應(yīng)的 9B 版本README.md關(guān)鍵事實有三個底座與許可從 Qwen3.5-9B 經(jīng) agentic post-training 而來Apache-2.0 協(xié)議僅含語言模型權(quán)重text-only視覺權(quán)重未包含任何二次修改說明都寫進(jìn)了配置與權(quán)重索引的元數(shù)據(jù)中上下文能力原生 262,144 token可擴(kuò)展至 1,010,000 token定位面向文本 Agent harness、工具調(diào)用、編碼與指令遵循評測覆蓋 Agentic、Coding、Instruction Following 三大類共十個基準(zhǔn)。對端側(cè)部署者而言最值得關(guān)注的其實是 config.json 里那 28 行l(wèi)ayer_types——它決定了這臺9B 的馬到底有多省內(nèi)存。二、源碼里的答案24 層線性注意力如何改寫內(nèi)存賬本打開 config.json網(wǎng)絡(luò)結(jié)構(gòu)一目了然layer_types: [ linear_attention, linear_attention, linear_attention, full_attention, linear_attention, ... // 每 4 層出現(xiàn)一次 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——這是標(biāo)準(zhǔn)的 Mamba 系狀態(tài)空間層命名QKV 線性投影、z 門控、a/b 投影、一維卷積linear_conv_kernel_dim為 4、離散時間步長偏置與 A 矩陣對數(shù)。這組配置意味著什么KV 狀態(tài)是恒定尺寸的。全注意力層的 KV cache 隨序列長度線性增長而線性注意力層的狀態(tài)由linear_key_head_dim: 128 × 16個 key head 與linear_value_head_dim: 128 × 32個 value head 決定是一個固定大小的壓縮狀態(tài)不隨序列變長而膨脹。這正是 9B 模型敢把原生上下文做到 26 萬 token 的底氣也是端側(cè)部署最核心的省內(nèi)存點。量化視角下的權(quán)重賬本同樣清晰。權(quán)重索引標(biāo)注total_size: 17,907,606,528即BF16 全量約 17.9GB約 16.7 GiB拆成 4 個 safetensors shard。按 9B 參數(shù)量粗算量化檔位約占用說明BF16倉庫原版~17.9GB需 24GB 級設(shè)備端側(cè)不現(xiàn)實Q8_0~9.1GB質(zhì)量損失最小需 12GB 級設(shè)備Q4_K_M~5.1GB端側(cè)甜點檔4-8GB 設(shè)備可承載Q3_K / Q2_K~3.4 / ~2.8GB純 CPU 樹莓派的極限檔配合8 層全注意力的結(jié)構(gòu)長上下文的 KV 開銷也被壓縮按 8 個 full_attention 層 × 4 個 KV head × 256 head_dim 計算約 32KB/tokenFP16 估算8K 上下文約 256MB、32K 上下文約 1GB——在線性注意力層不隨序列增長的前提下這個預(yù)算在樹莓派 8GB 內(nèi)存里是付得起的。三、硬件與準(zhǔn)備三條路線的配置清單先說結(jié)論沒有官方最低配置承諾社區(qū)公開情報給出的實測基準(zhǔn)是 4GB 顯存設(shè)備穩(wěn)定推理RTX 3050 4G / RTX 3060以及樹莓派 外接 GPU 的組合且官方明確做了 GGUF 量化適配與 llama.cpp 深度協(xié)同。據(jù)此可以把部署路線分為三檔路線 A樹莓派 5 純 CPU8GB RAM 起步權(quán)重用 Q3_K / Q2_K 級量化約 3-4GB加載后系統(tǒng)剩余內(nèi)存需支撐 KV 與運行時適合離線批處理、定時任務(wù)、隱私敏感的單機(jī)場景速度滿足能跑但不足以支撐實時交互式對話磁盤建議 64GB 起步BF16 全量就占 17.9GB若還要存放原始權(quán)重再加一倍務(wù)必用 USB3.0 外接 SSD 或 NVMe 轉(zhuǎn)接microSD 的隨機(jī)讀寫會顯著拖慢 mmap 加載系統(tǒng)用 64 位 Raspberry Pi OS 或 Ubuntu Serverllama.cpp 編譯依賴 cmake / gcc。路線 B樹莓派 5 外接 GPU推薦通過 PCIe 轉(zhuǎn)接卡掛一張 4-8GB 顯存的 GPU社區(qū)實測覆蓋 RTX 3050 4G 與 RTX 3060權(quán)重用 Q4_K_M約 5.1GB全部層 offload 到 GPU8GB 樹莓派內(nèi)存專職 KV cache 與系統(tǒng)這是社區(qū)實測中4GB 顯存穩(wěn)定推理對應(yīng)的典型形態(tài)也是樹莓派場景下最接近可交互速度的組合。路線 C二手迷你主機(jī) / 舊筆記本 獨顯RTX 3060 12GB 或 3050 4GQ8_0 檔位內(nèi)存 16GB 以上最省心適合作為先跑通再下放的基準(zhǔn)環(huán)境。無論哪條路線都要先想清楚三個數(shù)字權(quán)重體積量化檔位決定、可用 RAM樹莓派 5 只有 4/8GB 兩檔、磁盤速度決定加載時間。建議先花兩分鐘算完賬再下單硬件。四、GGUF 量化與推理從 HF 權(quán)重到 llama.cpp 跑通倉庫本身只發(fā)布 BF16 safetensors 權(quán)重model-00001-of-00004.safetensors 至 model-00004-of-00004.safetensors不含 GGUF因此端側(cè)第一步是量化。完整鏈路如下第 1 步下載權(quán)重到本地。拉取整個倉庫config.json、tokenizer 文件、4 個 shard、chat_template.jinja、model.safetensors.index.json得到一個標(biāo)準(zhǔn)的 Hugging Face Transformers 目錄。MODEL_PATH指向該目錄。第 2 步轉(zhuǎn)換并量化。用 llama.cpp 的標(biāo)準(zhǔn)轉(zhuǎn)換工具鏈先把 safetensors 轉(zhuǎn)成 FP16 GGUF再用llama-quantize產(chǎn)出目標(biāo)檔位Q4_K_M / Q8_0。社區(qū)對同系列模型的實測對比Q4_K_M vs Q8_0表明低比特檔位在結(jié)構(gòu)化任務(wù)上的格式穩(wěn)定性會明顯下滑Agent/工具調(diào)用任務(wù)建議 Q8_0純對話或低內(nèi)存場景才退到 Q4_K_M——這個經(jīng)驗對 NeoHorse-1-9B 同樣適用。第 3 步確認(rèn) tokenizer 與模板。tokenizer_config.json 指明Qwen2Tokenizer、詞表 248,320、|im_start|/|im_end|消息包裹chat_template.jinja 是核心——它完整實現(xiàn)了tool_call/tool_response工具調(diào)用協(xié)議與think推理標(biāo)記處理。端側(cè)跑 Agent 場景時必須讓推理框架保留這些特殊 token否則模型在工具調(diào)用鏈路上會失憶。第 4 步啟動 llama.cpp 服務(wù)。以 llama-server 為例llama-server -m NeoHorse-1-9B-Q4_K_M.gguf \ -ngl 999 \ # 全層 GPU offload純 CPU 時去掉并加 -t 4 -c 8192 \ # 端側(cè)先收斂上下文不要照搬 262144 --jinja # 啟用倉庫自帶 chat template啟動后即可用 OpenAI 兼容接口驗證curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {messages:[{role:user,content:用 Python 寫一個返回前 n 個斐波那契數(shù)的函數(shù)}]}注意一個前提qwen3_5_text是較新的架構(gòu)config.json 中model_type需使用包含對應(yīng)架構(gòu)支持的 llama.cpp 版本社區(qū)情報顯示官方已針對 GGUF 與 llama.cpp 做了專門適配。五、實測數(shù)據(jù)官方評測、社區(qū)實測與推算賬本交叉驗證把三類數(shù)字分開看避免混淆官方報告數(shù)字來源README.md 評測表SGLang v0.5.17 thinking 模式協(xié)議基準(zhǔn)Qwen3.5-9BNeoHorse-1-9BΔtau2-Bench88.0490.822.78PinchBench74.5582.257.70BFCL v464.8867.432.55QwenClawBench44.0448.734.69VitaBench31.2542.2511.00HumanEval92.6898.175.49十基準(zhǔn)平均65.6069.043.44這套數(shù)字證明9B 有效參數(shù)的 Agent 能力不是宣傳話術(shù)工具調(diào)用BFCL v4、Agent 閉環(huán)tau2-Bench、指令遵循均有可查的增量。但它是在全精度權(quán)重 SGLang thinking 模式temperature1.0、top_p0.95、enable_thinkingtrue下測得的端側(cè)量化復(fù)測會有浮動屬于正?，F(xiàn)象。社區(qū)實測數(shù)字來源公開技術(shù)解析文章4GB 顯存設(shè)備上穩(wěn)定推理RTX 3050 4G / RTX 3060 / 樹莓派 外接 GPU單位顯存吞吐密度較同硬件下的 30B 級模型提升約 2.3 倍llama.cpp 原生部署兼容 Windows 與樹莓派等邊緣設(shè)備。這些數(shù)字可作為選型依據(jù)但建議到手后用自己的 Prompt 集復(fù)測一遍?？捎蓚}庫配置直接推算的賬本來源config.json前文已列——BF16 全量約 17.9GBQ4_K_M 約 5.1GBQ8_0 約 9.1GBKV cache 僅 8 層全注意力隨序列增長約 32KB/token。這是本文唯一確定的預(yù)算也是端側(cè)部署的決策基礎(chǔ)。生成質(zhì)量速覽端側(cè)常見疑問是9B 在樹莓派上是不是只能答短句。官方協(xié)議是 thinking 模式先產(chǎn)出think推理再輸出chat_template.jinja 對推理標(biāo)記做了精細(xì)處理僅對最后一條用戶查詢之后的 assistant 回復(fù)保留 think 前綴。實測感受類指標(biāo)無法從倉庫直接獲得建議用 IFEval 類指令遵循樣例官方 89.09 分和 20-30 條工具調(diào)用樣例做冒煙測試重點盯兩件事JSON/XML 格式穩(wěn)定性、多輪工具調(diào)用后是否出現(xiàn)中間遺忘。六、端側(cè)避坑清單上下文先收斂再放開README 的官方部署示例SGLang/vLLM都寫--context-length 262144但端側(cè)務(wù)必先降到 8-32K否則全注意力層 KV 會把 8GB 內(nèi)存吃穿實測增量不明顯的任務(wù)8K 足夠。量化檔位與任務(wù)類型綁定對話場景 Q4_K_M 可用Agent/工具調(diào)用場景優(yōu)先 Q8_0若只有 4GB 顯存且必須跑 Agent 任務(wù)先做好格式回退 重試的容錯層。think 標(biāo)記別丟llama.cpp 啟動時啟用--jinja并使用支持 qwen3 系推理解析的版本否則think會被當(dāng)成正文輸出破壞 OpenAI 兼容協(xié)議。采樣參數(shù)不要照抄官方評測官方temperature1.0 多種 penalty 是為評測協(xié)議服務(wù)的端側(cè)單機(jī)交互建議降溫度、收緊 top_p換來格式穩(wěn)定性。交換分區(qū)是最后手段不是常態(tài)樹莓派上用 zram 壓縮交換可以兜底 OOM但一旦觸發(fā) swap 頻繁讀寫吞吐會掉一個數(shù)量級優(yōu)先在量化檔位 × 上下文長度上做減法。寫在最后NeoHorse-1-9B 的端側(cè)可行性本質(zhì)上是一個架構(gòu)問題24 層線性注意力把 9B 模型的推理成本從24GB 顯卡專屬拉到了4GB 顯存 / 樹莓派 8GB的檔位量化再把權(quán)重從 17.9GB 壓到 5GB 量級。官方評測給了它 Agent 能力的硬數(shù)據(jù)社區(qū)實測給了它低顯存硬件的驗證剩下的——上下文收斂、量化檔位、容錯設(shè)計——是部署者自己要做的工程取舍。低配設(shè)備跑 9B Agent 模型這件事已經(jīng)從能不能進(jìn)入了怎么跑得更穩(wěn)的階段。這份實錄里的每一步都可以在倉庫源碼里找到對應(yīng)物也建議你在自己的硬件上把最后那組速度與質(zhì)量的數(shù)字補上?！久赓M下載鏈接】NeoHorse-1-9B項目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 樹莓派也能跑：NeoHorse-1-9B 端側(cè)部署全程實錄
樹莓派也能跑NeoHorse-1-9B 端側(cè)部署全程實錄【免費下載鏈接】NeoHorse-1-9B項目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B一個 9B 參數(shù)的因果語言模型通常意味著至少 18GB 的 BF16 權(quán)重、一張 24GB 以上的顯卡——這是多數(shù)人對9B 大模型的默認(rèn)預(yù)期。但 NeoHorse-1-9B 讓9B 模型 低功耗小板這個組合第一次在工程上變得合理它的 32 層網(wǎng)絡(luò)里只有 8 層是標(biāo)準(zhǔn)全注意力其余 24 層是線性注意力類 SSM 狀態(tài)空間層社區(qū)公開實測顯示它在 4GB 顯存設(shè)備RTX 3050 4G、RTX 3060乃至樹莓派 外接 GPU上可以穩(wěn)定推理官方報告給出的 tau2-Bench 得分高達(dá) 90.82。本文不做 PPT 式渲染。我會把倉庫源碼模型配置、權(quán)重索引、分詞器、Chat Template與社區(qū)公開實測放在一起交叉驗證完整走一遍硬件選型 → 量化 → llama.cpp 跑通 → 評測數(shù)據(jù)核對的部署閉環(huán)同時明確區(qū)分哪些數(shù)字來自官方報告、哪些來自社區(qū)實測、哪些需要你自己復(fù)測。一、先看這匹馬的來歷Agent-Native 模型與端側(cè)布局據(jù)澎湃新聞 2026 年 9 月報道基元律動TokenRhythm聯(lián)合無問芯穹、清華大學(xué)、北京大學(xué)、阿里巴巴等機(jī)構(gòu)發(fā)布首個 Agent-Native 模型 NeoHorse-1包含 4B 與 9B 兩個版本?；蓜佑汕叭A為諾亞方舟實驗室主任、盤古大模型負(fù)責(zé)人王云鶴創(chuàng)辦此前已開源 Routing Harness 系統(tǒng) OpenSquilla用于在 Agent 執(zhí)行任務(wù)時選擇和組織不同模型NeoHorse 把這條路由編排路線延伸到了模型訓(xùn)練本身——訓(xùn)練語料以 Routing Harness 產(chǎn)生的執(zhí)行軌跡為核心保留能力需求預(yù)測、路由選擇、模型響應(yīng)、工具調(diào)用和環(huán)境反饋經(jīng)完整性檢查與質(zhì)量評估后用于后訓(xùn)練。回到本倉庫對應(yīng)的 9B 版本README.md關(guān)鍵事實有三個底座與許可從 Qwen3.5-9B 經(jīng) agentic post-training 而來Apache-2.0 協(xié)議僅含語言模型權(quán)重text-only視覺權(quán)重未包含任何二次修改說明都寫進(jìn)了配置與權(quán)重索引的元數(shù)據(jù)中上下文能力原生 262,144 token可擴(kuò)展至 1,010,000 token定位面向文本 Agent harness、工具調(diào)用、編碼與指令遵循評測覆蓋 Agentic、Coding、Instruction Following 三大類共十個基準(zhǔn)。對端側(cè)部署者而言最值得關(guān)注的其實是 config.json 里那 28 行l(wèi)ayer_types——它決定了這臺9B 的馬到底有多省內(nèi)存。二、源碼里的答案24 層線性注意力如何改寫內(nèi)存賬本打開 config.json網(wǎng)絡(luò)結(jié)構(gòu)一目了然layer_types: [ linear_attention, linear_attention, linear_attention, full_attention, linear_attention, ... // 每 4 層出現(xiàn)一次 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——這是標(biāo)準(zhǔn)的 Mamba 系狀態(tài)空間層命名QKV 線性投影、z 門控、a/b 投影、一維卷積linear_conv_kernel_dim為 4、離散時間步長偏置與 A 矩陣對數(shù)。這組配置意味著什么KV 狀態(tài)是恒定尺寸的。全注意力層的 KV cache 隨序列長度線性增長而線性注意力層的狀態(tài)由linear_key_head_dim: 128 × 16個 key head 與linear_value_head_dim: 128 × 32個 value head 決定是一個固定大小的壓縮狀態(tài)不隨序列變長而膨脹。這正是 9B 模型敢把原生上下文做到 26 萬 token 的底氣也是端側(cè)部署最核心的省內(nèi)存點。量化視角下的權(quán)重賬本同樣清晰。權(quán)重索引標(biāo)注total_size: 17,907,606,528即BF16 全量約 17.9GB約 16.7 GiB拆成 4 個 safetensors shard。按 9B 參數(shù)量粗算量化檔位約占用說明BF16倉庫原版~17.9GB需 24GB 級設(shè)備端側(cè)不現(xiàn)實Q8_0~9.1GB質(zhì)量損失最小需 12GB 級設(shè)備Q4_K_M~5.1GB端側(cè)甜點檔4-8GB 設(shè)備可承載Q3_K / Q2_K~3.4 / ~2.8GB純 CPU 樹莓派的極限檔配合8 層全注意力的結(jié)構(gòu)長上下文的 KV 開銷也被壓縮按 8 個 full_attention 層 × 4 個 KV head × 256 head_dim 計算約 32KB/tokenFP16 估算8K 上下文約 256MB、32K 上下文約 1GB——在線性注意力層不隨序列增長的前提下這個預(yù)算在樹莓派 8GB 內(nèi)存里是付得起的。三、硬件與準(zhǔn)備三條路線的配置清單先說結(jié)論沒有官方最低配置承諾社區(qū)公開情報給出的實測基準(zhǔn)是 4GB 顯存設(shè)備穩(wěn)定推理RTX 3050 4G / RTX 3060以及樹莓派 外接 GPU 的組合且官方明確做了 GGUF 量化適配與 llama.cpp 深度協(xié)同。據(jù)此可以把部署路線分為三檔路線 A樹莓派 5 純 CPU8GB RAM 起步權(quán)重用 Q3_K / Q2_K 級量化約 3-4GB加載后系統(tǒng)剩余內(nèi)存需支撐 KV 與運行時適合離線批處理、定時任務(wù)、隱私敏感的單機(jī)場景速度滿足能跑但不足以支撐實時交互式對話磁盤建議 64GB 起步BF16 全量就占 17.9GB若還要存放原始權(quán)重再加一倍務(wù)必用 USB3.0 外接 SSD 或 NVMe 轉(zhuǎn)接microSD 的隨機(jī)讀寫會顯著拖慢 mmap 加載系統(tǒng)用 64 位 Raspberry Pi OS 或 Ubuntu Serverllama.cpp 編譯依賴 cmake / gcc。路線 B樹莓派 5 外接 GPU推薦通過 PCIe 轉(zhuǎn)接卡掛一張 4-8GB 顯存的 GPU社區(qū)實測覆蓋 RTX 3050 4G 與 RTX 3060權(quán)重用 Q4_K_M約 5.1GB全部層 offload 到 GPU8GB 樹莓派內(nèi)存專職 KV cache 與系統(tǒng)這是社區(qū)實測中4GB 顯存穩(wěn)定推理對應(yīng)的典型形態(tài)也是樹莓派場景下最接近可交互速度的組合。路線 C二手迷你主機(jī) / 舊筆記本 獨顯RTX 3060 12GB 或 3050 4GQ8_0 檔位內(nèi)存 16GB 以上最省心適合作為先跑通再下放的基準(zhǔn)環(huán)境。無論哪條路線都要先想清楚三個數(shù)字權(quán)重體積量化檔位決定、可用 RAM樹莓派 5 只有 4/8GB 兩檔、磁盤速度決定加載時間。建議先花兩分鐘算完賬再下單硬件。四、GGUF 量化與推理從 HF 權(quán)重到 llama.cpp 跑通倉庫本身只發(fā)布 BF16 safetensors 權(quán)重model-00001-of-00004.safetensors 至 model-00004-of-00004.safetensors不含 GGUF因此端側(cè)第一步是量化。完整鏈路如下第 1 步下載權(quán)重到本地。拉取整個倉庫config.json、tokenizer 文件、4 個 shard、chat_template.jinja、model.safetensors.index.json得到一個標(biāo)準(zhǔn)的 Hugging Face Transformers 目錄。MODEL_PATH指向該目錄。第 2 步轉(zhuǎn)換并量化。用 llama.cpp 的標(biāo)準(zhǔn)轉(zhuǎn)換工具鏈先把 safetensors 轉(zhuǎn)成 FP16 GGUF再用llama-quantize產(chǎn)出目標(biāo)檔位Q4_K_M / Q8_0。社區(qū)對同系列模型的實測對比Q4_K_M vs Q8_0表明低比特檔位在結(jié)構(gòu)化任務(wù)上的格式穩(wěn)定性會明顯下滑Agent/工具調(diào)用任務(wù)建議 Q8_0純對話或低內(nèi)存場景才退到 Q4_K_M——這個經(jīng)驗對 NeoHorse-1-9B 同樣適用。第 3 步確認(rèn) tokenizer 與模板。tokenizer_config.json 指明Qwen2Tokenizer、詞表 248,320、|im_start|/|im_end|消息包裹chat_template.jinja 是核心——它完整實現(xiàn)了tool_call/tool_response工具調(diào)用協(xié)議與think推理標(biāo)記處理。端側(cè)跑 Agent 場景時必須讓推理框架保留這些特殊 token否則模型在工具調(diào)用鏈路上會失憶。第 4 步啟動 llama.cpp 服務(wù)。以 llama-server 為例llama-server -m NeoHorse-1-9B-Q4_K_M.gguf \ -ngl 999 \ # 全層 GPU offload純 CPU 時去掉并加 -t 4 -c 8192 \ # 端側(cè)先收斂上下文不要照搬 262144 --jinja # 啟用倉庫自帶 chat template啟動后即可用 OpenAI 兼容接口驗證curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {messages:[{role:user,content:用 Python 寫一個返回前 n 個斐波那契數(shù)的函數(shù)}]}注意一個前提qwen3_5_text是較新的架構(gòu)config.json 中model_type需使用包含對應(yīng)架構(gòu)支持的 llama.cpp 版本社區(qū)情報顯示官方已針對 GGUF 與 llama.cpp 做了專門適配。五、實測數(shù)據(jù)官方評測、社區(qū)實測與推算賬本交叉驗證把三類數(shù)字分開看避免混淆官方報告數(shù)字來源README.md 評測表SGLang v0.5.17 thinking 模式協(xié)議基準(zhǔn)Qwen3.5-9BNeoHorse-1-9BΔtau2-Bench88.0490.822.78PinchBench74.5582.257.70BFCL v464.8867.432.55QwenClawBench44.0448.734.69VitaBench31.2542.2511.00HumanEval92.6898.175.49十基準(zhǔn)平均65.6069.043.44這套數(shù)字證明9B 有效參數(shù)的 Agent 能力不是宣傳話術(shù)工具調(diào)用BFCL v4、Agent 閉環(huán)tau2-Bench、指令遵循均有可查的增量。但它是在全精度權(quán)重 SGLang thinking 模式temperature1.0、top_p0.95、enable_thinkingtrue下測得的端側(cè)量化復(fù)測會有浮動屬于正?，F(xiàn)象。社區(qū)實測數(shù)字來源公開技術(shù)解析文章4GB 顯存設(shè)備上穩(wěn)定推理RTX 3050 4G / RTX 3060 / 樹莓派 外接 GPU單位顯存吞吐密度較同硬件下的 30B 級模型提升約 2.3 倍llama.cpp 原生部署兼容 Windows 與樹莓派等邊緣設(shè)備。這些數(shù)字可作為選型依據(jù)但建議到手后用自己的 Prompt 集復(fù)測一遍?？捎蓚}庫配置直接推算的賬本來源config.json前文已列——BF16 全量約 17.9GBQ4_K_M 約 5.1GBQ8_0 約 9.1GBKV cache 僅 8 層全注意力隨序列增長約 32KB/token。這是本文唯一確定的預(yù)算也是端側(cè)部署的決策基礎(chǔ)。生成質(zhì)量速覽端側(cè)常見疑問是9B 在樹莓派上是不是只能答短句。官方協(xié)議是 thinking 模式先產(chǎn)出think推理再輸出chat_template.jinja 對推理標(biāo)記做了精細(xì)處理僅對最后一條用戶查詢之后的 assistant 回復(fù)保留 think 前綴。實測感受類指標(biāo)無法從倉庫直接獲得建議用 IFEval 類指令遵循樣例官方 89.09 分和 20-30 條工具調(diào)用樣例做冒煙測試重點盯兩件事JSON/XML 格式穩(wěn)定性、多輪工具調(diào)用后是否出現(xiàn)中間遺忘。六、端側(cè)避坑清單上下文先收斂再放開README 的官方部署示例SGLang/vLLM都寫--context-length 262144但端側(cè)務(wù)必先降到 8-32K否則全注意力層 KV 會把 8GB 內(nèi)存吃穿實測增量不明顯的任務(wù)8K 足夠。量化檔位與任務(wù)類型綁定對話場景 Q4_K_M 可用Agent/工具調(diào)用場景優(yōu)先 Q8_0若只有 4GB 顯存且必須跑 Agent 任務(wù)先做好格式回退 重試的容錯層。think 標(biāo)記別丟llama.cpp 啟動時啟用--jinja并使用支持 qwen3 系推理解析的版本否則think會被當(dāng)成正文輸出破壞 OpenAI 兼容協(xié)議。采樣參數(shù)不要照抄官方評測官方temperature1.0 多種 penalty 是為評測協(xié)議服務(wù)的端側(cè)單機(jī)交互建議降溫度、收緊 top_p換來格式穩(wěn)定性。交換分區(qū)是最后手段不是常態(tài)樹莓派上用 zram 壓縮交換可以兜底 OOM但一旦觸發(fā) swap 頻繁讀寫吞吐會掉一個數(shù)量級優(yōu)先在量化檔位 × 上下文長度上做減法。寫在最后NeoHorse-1-9B 的端側(cè)可行性本質(zhì)上是一個架構(gòu)問題24 層線性注意力把 9B 模型的推理成本從24GB 顯卡專屬拉到了4GB 顯存 / 樹莓派 8GB的檔位量化再把權(quán)重從 17.9GB 壓到 5GB 量級。官方評測給了它 Agent 能力的硬數(shù)據(jù)社區(qū)實測給了它低顯存硬件的驗證剩下的——上下文收斂、量化檔位、容錯設(shè)計——是部署者自己要做的工程取舍。低配設(shè)備跑 9B Agent 模型這件事已經(jīng)從能不能進(jìn)入了怎么跑得更穩(wěn)的階段。這份實錄里的每一步都可以在倉庫源碼里找到對應(yīng)物也建議你在自己的硬件上把最后那組速度與質(zhì)量的數(shù)字補上?！久赓M下載鏈接】NeoHorse-1-9B項目地址: https://ai.gitcode.com/hf_mirrors/TokenRhythm/NeoHorse-1-9B創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考