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