部署全程實錄)
樹莓派也能跑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é)、阿里巴巴等機構(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可擴展至 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ù)、隱私敏感的單機場景速度滿足能跑但不足以支撐實時交互式對話磁盤建議 64GB 起步BF16 全量就占 17.9GB若還要存放原始權(quán)重再加一倍務(wù)必用 USB3.0 外接 SSD 或 NVMe 轉(zhuǎn)接microSD 的隨機讀寫會顯著拖慢 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二手迷你主機 / 舊筆記本 獨顯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è)單機交互建議降溫度、收緊 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é)、阿里巴巴等機構(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可擴展至 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ù)、隱私敏感的單機場景速度滿足能跑但不足以支撐實時交互式對話磁盤建議 64GB 起步BF16 全量就占 17.9GB若還要存放原始權(quán)重再加一倍務(wù)必用 USB3.0 外接 SSD 或 NVMe 轉(zhuǎn)接microSD 的隨機讀寫會顯著拖慢 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二手迷你主機 / 舊筆記本 獨顯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è)單機交互建議降溫度、收緊 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），僅供參考