如果你手頭正好有三臺(tái)吃灰的 NUC又每天都在用 Claude Code 處理編碼任務(wù)看到“Yeschef: Claude Code dispatches work to Ollama on my LAN (627 tok/s on 3 NUCs)”這個(gè)標(biāo)題很難不心動(dòng)。我第一次看到這個(gè)實(shí)驗(yàn)時(shí)第一反應(yīng)不是“真快”而是“這件事值得拆開看”Claude Code 的任務(wù)調(diào)度在跑Ollama 的本地推理也在跑中間多了一層叫 Yeschef 的適配層把兩者連起來。這篇文章想把這件事講透包括它解決了什么問題、復(fù)現(xiàn)時(shí)要注意什么以及這個(gè)方案真正適合誰。我的主判斷很簡(jiǎn)單Yeschef 這類方案最重要的意義不是把 627 tok/s 當(dāng)作一道漂亮的成績(jī)而是把 Claude Code 從“只能連中心化服務(wù)”的工作流擴(kuò)展成“可以調(diào)度到局域網(wǎng)多節(jié)點(diǎn)”的本地化實(shí)驗(yàn)。它真正改變的不是單次推理速度而是工作流的部署邊界。1. 為什么本地多機(jī)推理不是“性能焦慮”而是工作流邊界問題很多人看到“3 臺(tái) NUC”“627 tok/s”這種數(shù)字第一反應(yīng)是比速度。如果你的目標(biāo)只是比較本地模型和云端模型誰跑得快那大概率會(huì)失望。因?yàn)楸镜匦∧Ｐ偷膯未紊赡芰徒?jīng)過大規(guī)模訓(xùn)練和優(yōu)化的云端模型不在一個(gè)量級(jí)。這個(gè)實(shí)驗(yàn)真正有意思的地方是它把 Claude Code 這種原本依賴外部服務(wù)的工具引入到了一個(gè)完全可控的局域網(wǎng)環(huán)境里。1.1 單機(jī)跑本地模型問題出在哪里先聊單機(jī) Ollama。過去半年里身邊越來越多同事開始在個(gè)人電腦上跑 Ollama用來做代碼補(bǔ)全、文本摘要、本地知識(shí)庫測(cè)試。單機(jī)的價(jià)值很清楚模型文件在本地?cái)?shù)據(jù)不出機(jī)器不需要為每次請(qǐng)求按 token 付費(fèi)斷網(wǎng)環(huán)境下也能繼續(xù)跑。但單機(jī)有幾個(gè)天然限制。第一是資源池有限。ollama run qwen2.5:7b這類模型單機(jī)跑起來沒問題可一旦你同時(shí)開編輯器插件、瀏覽器、編譯任務(wù)顯存和內(nèi)存馬上吃緊。模型要反復(fù)加載、卸載第一次請(qǐng)求往往要等好幾秒。第二是并發(fā)能力弱。Ollama 默認(rèn)會(huì)按需加載模型同一臺(tái)機(jī)器上同時(shí)來多個(gè)請(qǐng)求時(shí)經(jīng)常出現(xiàn)排隊(duì)。你用 Claude Code 生成代碼時(shí)如果中途又發(fā)起一個(gè)解釋請(qǐng)求體驗(yàn)就會(huì)明顯下降。第三是模型切換成本高。跑 7B 模型剛合適換 14B 就要考慮量化換 32B 基本就只能用 CPU 或者超大內(nèi)存。單機(jī)不是不能跑而是“可擴(kuò)展性”很差。1.2 從“單機(jī)可用”到“局域網(wǎng)可用”發(fā)生了什么變化當(dāng)你要把模型能力真正放進(jìn)日常工具鏈而不是只做一次技術(shù)演示時(shí)單機(jī)就不再是效率問題而是工作流問題。Claude Code 這類工具在工作時(shí)會(huì)持續(xù)發(fā)起多次請(qǐng)求讀文件、生成代碼、調(diào)用工具、回填上下文、解釋報(bào)錯(cuò)。這些請(qǐng)求不是一次性結(jié)束的而是一條又一條的對(duì)話輪次。如果每一條請(qǐng)求都要在本地排隊(duì)等模型加載整個(gè)開發(fā)節(jié)奏就會(huì)被拖垮。把任務(wù)分發(fā)到局域網(wǎng)里的多臺(tái)機(jī)器解決的其實(shí)是這個(gè)問題把“一臺(tái)機(jī)器既要跑模型又要跑工具鏈”變成“工具鏈在這臺(tái)機(jī)器上運(yùn)行推理任務(wù)拆給那幾臺(tái)機(jī)器并行處理”。你不需要一臺(tái)性能怪獸而是把已有的幾臺(tái)普通機(jī)器變成一個(gè)可以調(diào)度的推理池。這也是為什么 Yeschef 這類適配層值得寫一篇長(zhǎng)文。它不是簡(jiǎn)單地把 Ollama 包裝成一個(gè) API而是讓 Claude Code 在發(fā)起請(qǐng)求時(shí)能根據(jù)局域網(wǎng)里的節(jié)點(diǎn)狀態(tài)把任務(wù)分給合適的機(jī)器。2. Yeschef 的關(guān)鍵不是 627 tok/s而是把 Claude Code 的請(qǐng)求搬回局域網(wǎng)先說清楚 Yeschef 在標(biāo)題里的角色。它不是一個(gè)模型也不是 Ollama 的替代品。從命名和實(shí)驗(yàn)描述看它更像一個(gè)位于 Claude Code 和 Ollama 之間的調(diào)度層或適配層。Claude Code 產(chǎn)生請(qǐng)求Yeschef 負(fù)責(zé)決定把請(qǐng)求轉(zhuǎn)發(fā)給局域網(wǎng)里的哪一臺(tái) Ollama然后把生成結(jié)果返回給 Claude Code。2.1 適配層到底適配了什么Claude Code 原生設(shè)計(jì)是連接 Anthropic 的云端接口。它有一套自己的請(qǐng)求格式、鑒權(quán)方式和流式返回協(xié)議。要讓請(qǐng)求落到局域網(wǎng)里的 Ollama不能直接把兩個(gè)進(jìn)程硬接在一起中間必須有一個(gè)“翻譯官”。這個(gè)翻譯官通常要處理四件事端點(diǎn)轉(zhuǎn)換把 Claude Code 默認(rèn)要訪問的地址改成局域網(wǎng)內(nèi)的本地服務(wù)地址。鑒權(quán)處理Claude Code 會(huì)帶一個(gè) token本地 Ollama 通常不需要復(fù)雜的云端鑒權(quán)適配層要接住這個(gè) token 并放行。請(qǐng)求與響應(yīng)格式轉(zhuǎn)換Claude Code 發(fā)送的請(qǐng)求體里有模型名、消息列表、工具定義、上下文等字段Ollama 的 API 格式不完全一樣需要把字段映射過去。錯(cuò)誤與重試云端接口失敗時(shí)會(huì)有明確的返回碼本地多機(jī)環(huán)境下還要額外處理“這臺(tái)機(jī)器模型沒加載”“那臺(tái)機(jī)器顯存不足”“請(qǐng)求超時(shí)”等狀態(tài)。所以 Yeschef 這個(gè)項(xiàng)目真正的工作量不在推理本身而在協(xié)議轉(zhuǎn)換和任務(wù)調(diào)度。2.2 一次請(qǐng)求的完整路徑Claude Code、適配層、Ollama我用一次代碼生成來解釋完整路徑。第一步Claude Code 準(zhǔn)備發(fā)起一個(gè)請(qǐng)求。它會(huì)把當(dāng)前對(duì)話上下文、用戶指令、文件內(nèi)容打包發(fā)給配置好的 API 地址。如果環(huán)境變量指向了本地適配層請(qǐng)求就會(huì)先到局域網(wǎng)里的調(diào)度服務(wù)。第二步適配層收到請(qǐng)求后根據(jù)可用的 Ollama 節(jié)點(diǎn)列表選擇一個(gè)最合適的節(jié)點(diǎn)。常見的調(diào)度策略包括輪詢、按響應(yīng)時(shí)間選擇、按當(dāng)前負(fù)載選擇。在實(shí)驗(yàn)環(huán)境里可能還會(huì)把不同模型固定調(diào)度到不同機(jī)器。第三步Ollama 節(jié)點(diǎn)執(zhí)行推理流式返回 token。適配層一邊接收 token一邊按照 Claude Code 期望的流式格式重新包裝再返回給 Claude Code。第四步Claude Code 正常解析響應(yīng)繼續(xù)下一步工具調(diào)用。這個(gè)鏈路里最容易被低估的是第二步的調(diào)度。如果只是隨機(jī)選一臺(tái)機(jī)器多機(jī)部署的意義就很小。真正有價(jià)值的調(diào)度要能知道每臺(tái)機(jī)器當(dāng)前是否空閑、模型是否已經(jīng)加載、上次響應(yīng)時(shí)間是多少。否則可能所有請(qǐng)求都集中到同一臺(tái)機(jī)器另外兩臺(tái)閑著。2.3 627 tok/s 最合理的讀法627 tok/s 這個(gè)數(shù)字可以有幾種不同解讀。它可能是指三臺(tái) NUC 在某個(gè)并發(fā)壓力下整個(gè)局域網(wǎng)服務(wù)觀測(cè)到的聚合輸出速度也可能是指某一次請(qǐng)求的流式輸出速度。兩種讀法差別很大。如果是聚合速度它說明的是集群吞吐能力也就是“單位時(shí)間內(nèi)所有節(jié)點(diǎn)加起來能產(chǎn)生多少 token”。這個(gè)數(shù)字對(duì)多機(jī)調(diào)度的意義更大因?yàn)樗苯臃从诚到y(tǒng)能否把請(qǐng)求分散到多臺(tái)機(jī)器。如果只是單請(qǐng)求速度那 627 tok/s 只說明某一臺(tái) NUC 上的某個(gè)模型跑得不錯(cuò)和“多機(jī)”沒有直接關(guān)系。從通常的多機(jī)推理實(shí)驗(yàn)來看我傾向于把 627 tok/s 理解為一個(gè)多節(jié)點(diǎn)聚合后的觀測(cè)值。但這里要提醒一句這個(gè)數(shù)字依賴具體模型、量化級(jí)別、上下文長(zhǎng)度、并發(fā)數(shù)以及 NUC 的硬件配置。不要把它當(dāng)成一個(gè)通用基準(zhǔn)更不要以為任何三臺(tái) NUC 都能跑到這個(gè)數(shù)。讀法含義對(duì)實(shí)驗(yàn)的參考價(jià)值聚合吞吐多節(jié)點(diǎn)并發(fā)輸出的總 token 速率體現(xiàn)集群整體調(diào)度能力單請(qǐng)求生成速率單個(gè)請(qǐng)求流式輸出速度體現(xiàn)單機(jī)模型推理效率首 token 延遲從發(fā)出請(qǐng)求到收到第一個(gè) token 的時(shí)間體現(xiàn)交互體驗(yàn)和排隊(duì)情況多機(jī)聚合吞吐并不是簡(jiǎn)單地把單機(jī)速度相加。調(diào)度開銷、節(jié)點(diǎn)空閑差異、模型加載時(shí)間、網(wǎng)絡(luò)傳輸延遲都會(huì)吃掉一部分理論峰值。你能穩(wěn)定復(fù)現(xiàn)的通常要約等于“單機(jī)吞吐 × 節(jié)點(diǎn)數(shù) × 調(diào)度效率系數(shù)”而不是單機(jī)吞吐 × 節(jié)點(diǎn)數(shù)。3. 復(fù)現(xiàn)實(shí)驗(yàn)先準(zhǔn)備三塊拼圖如果你想在自己的局域網(wǎng)里復(fù)現(xiàn)一個(gè)類似的實(shí)驗(yàn)不用一開始就盯著 627 tok/s先把下面三塊拼圖拼好。每一塊缺失后面的性能都無從談起。3.1 硬件、網(wǎng)絡(luò)和系統(tǒng)的選擇硬件方面NUC 只是標(biāo)題里的一個(gè)選項(xiàng)不代表必須用 NUC。任何幾臺(tái)內(nèi)存和磁盤足夠的 x86 小主機(jī)、舊臺(tái)式機(jī)、迷你服務(wù)器都可以。關(guān)鍵不在品牌而在內(nèi)存大小、顯存或者顯卡型號(hào)。跑 Ollama 時(shí)模型需要常駐內(nèi)存或顯存內(nèi)存越大能同時(shí)跑的模型越多。網(wǎng)絡(luò)方面最穩(wěn)的方案是有線網(wǎng)絡(luò)。如果三臺(tái)機(jī)器都走 WiFi尤其是 USB 無線網(wǎng)卡容易出現(xiàn)驅(qū)動(dòng)不穩(wěn)定、延遲抖動(dòng)、吞吐忽高忽低。實(shí)驗(yàn)時(shí)建議把三臺(tái)機(jī)器接到同一個(gè)交換機(jī)或路由器 LAN 口避免無線干擾。系統(tǒng)方面Ollama 對(duì) Linux 支持最直接Windows 和 macOS 也能跑。但多機(jī)調(diào)度通常要監(jiān)聽端口、訪問服務(wù)、寫日志Linux 會(huì)更省事。這里沒有哪套系統(tǒng)絕對(duì)更好關(guān)鍵是你自己能不能維護(hù)。3.2 Ollama 安裝、模型拉取和版本確認(rèn)Ollama 的安裝整體是簡(jiǎn)單的。在 Linux 上常見做法是把官方安裝腳本拉下來執(zhí)行Windows 和 macOS 有安裝包。但安裝腳本的下載速度有時(shí)候很慢尤其是在網(wǎng)絡(luò)環(huán)境不理想時(shí)。如果你遇到“ollama 下載太慢了”先不要慌。正常處理順序是確認(rèn)當(dāng)前網(wǎng)絡(luò)環(huán)境能否訪問 Ollama 官方下載地址。檢查系統(tǒng)是否有 DNS 或防火墻策略問題。如果確實(shí)慢可以使用你所在地區(qū)可訪問的鏡像源或者讓網(wǎng)管托管安裝包再內(nèi)網(wǎng)分發(fā)。注意不要為了追求“快”隨便使用不明來源的腳本。安裝包一旦被篡改后面所有模型請(qǐng)求都可能存在問題。安全比節(jié)省幾分鐘重要得多。安裝完成后先做兩件事ollama serve ollama list第一條命令確保服務(wù)在后臺(tái)運(yùn)行第二條命令查看當(dāng)前已經(jīng)拉取了哪些模型。如果ollama list是空的接下來拉取一個(gè)實(shí)驗(yàn)用的小模型。比如ollama pull qwen2.5:7b這里先選擇 7B 左右的量化模型是因?yàn)樗菀自诙嗯_(tái)普通機(jī)器上運(yùn)行。不要一上來就拉取超大模型否則你可能花半天下載最后發(fā)現(xiàn)內(nèi)存不夠。3.3 讓 Claude Code 指向本地端點(diǎn)的通用思路Claude Code 原生并不認(rèn)識(shí) Ollama。要讓請(qǐng)求進(jìn)入局域網(wǎng)常見做法是設(shè)置環(huán)境變量把 Claude Code 的 API 基礎(chǔ)地址指向本地適配層。注意不同版本的 Claude Code 對(duì)環(huán)境變量名和本地接入方式可能不同。落地前先確認(rèn)你安裝的版本支持哪些配置項(xiàng)。一個(gè)通用的示意如下export ANTHROPIC_BASE_URLhttp://你的本地適配層地址:端口 export ANTHROPIC_AUTH_TOKENlocal-test-token這里的“本地適配層地址”可以是 yeschef 服務(wù)所在機(jī)器的 IP也可以是一個(gè)內(nèi)網(wǎng)域名。關(guān)鍵是先確保 Claude Code 的請(qǐng)求真的到達(dá)了適配層而不是仍然發(fā)往云端。如果這一層沒有跑通后面所有性能測(cè)試都沒有意義。我建議先用最簡(jiǎn)單的方式驗(yàn)證手動(dòng)發(fā)起一次非常短的請(qǐng)求讓 Claude Code 只回復(fù)一句話然后查看適配層日志里有沒有收到請(qǐng)求。4. 從單機(jī)基線到多機(jī)并發(fā)一個(gè)務(wù)實(shí)的壓測(cè)路徑當(dāng)你把三塊拼圖拼好后不要急著上并發(fā)。正確順序是先建立單機(jī)基線再測(cè)網(wǎng)絡(luò)最后做多機(jī)聚合。這個(gè)順序能幫你快速定位問題到底出在模型、網(wǎng)絡(luò)還是調(diào)度層。4.1 第一步先測(cè)單機(jī)不要直接上集群在任意一臺(tái) NUC 上單獨(dú)測(cè) Ollama 的響應(yīng)情況。最簡(jiǎn)單的測(cè)試方式ollama run qwen2.5:7b 用一句話解釋什么是 HTTP 503觀察三個(gè)指標(biāo)首 token 等待時(shí)間模型是否已經(jīng)加載。完整回復(fù)速度每秒輸出多少個(gè) token。運(yùn)行時(shí)資源占用CPU、內(nèi)存、顯存分別多少。如果單機(jī)請(qǐng)求都要等十幾秒才出來不要怪調(diào)度層問題在你的模型過大、量化級(jí)別不合適或者機(jī)器本身資源不足。先換更小的模型或者調(diào)整 Ollama 的并發(fā)參數(shù)。4.2 第二步測(cè)網(wǎng)絡(luò)而不是只看帶寬局域網(wǎng)內(nèi)多機(jī)通信很多人只關(guān)心帶寬。但 Claude Code 這種工具請(qǐng)求是高頻、小包、流式返回的。它更在意的是延遲和穩(wěn)定性。實(shí)測(cè)時(shí)可以在兩臺(tái)機(jī)器之間互 ping觀察是否有持續(xù)丟包。還要確認(rèn)端口是否可達(dá)。Ollama 默認(rèn)監(jiān)聽 11434如果你的適配層在另一臺(tái)機(jī)器需要確保防火墻允許內(nèi)網(wǎng)訪問這個(gè)端口。很多“請(qǐng)求超時(shí)”問題不是模型慢而是根本連不上。你還可以用 curl 直接測(cè)遠(yuǎn)端 Ollama 的 APIcurl http://另一臺(tái)機(jī)器IP:11434/api/generate \ -d {model:qwen2.5:7b,prompt:你好}如果這一步都不通后面接 Claude Code 大概率也是失敗。4.3 第三步多機(jī)聚合并發(fā)的觀察指標(biāo)到了這一步才開始真正壓測(cè)多機(jī)。重點(diǎn)不是追求一個(gè)數(shù)字而是觀察系統(tǒng)在并發(fā)下的行為。建議先設(shè)置一個(gè)很低的并發(fā)數(shù)比如 2 個(gè)并發(fā)請(qǐng)求看三臺(tái)機(jī)器是否都有請(qǐng)求到達(dá)。然后逐步增加到 4、8、16。每次增加后記錄響應(yīng)成功率平均首 token 延遲每秒輸出 token 數(shù)有沒有請(qǐng)求排隊(duì)、超時(shí)或被丟棄你很快會(huì)發(fā)現(xiàn)多機(jī)聚合吞吐不是一條直線上升的曲線。當(dāng)調(diào)度層成為瓶頸或者某一臺(tái)機(jī)器負(fù)載過高時(shí)吞吐會(huì)趨于平緩甚至下降。這不是模型出了問題而是調(diào)度策略和資源分配到了邊界。5. 實(shí)際踩坑清單下載、版本、超時(shí)、亂碼和并發(fā)本地化部署最難的不是跑通而是把那些看起來很小、實(shí)際非常耽誤時(shí)間的問題一個(gè)個(gè)排查掉。這里列幾個(gè)我在類似實(shí)驗(yàn)里經(jīng)常遇到的坑。5.1 下載慢和安裝源先確認(rèn)網(wǎng)絡(luò)環(huán)境再談加速“ollama 下載太慢了”是一個(gè)非常普遍的現(xiàn)象。除了模型文件本身很大之外也可能是安裝腳本下載源不穩(wěn)定。我的建議是先確認(rèn)最基礎(chǔ)的事情。DNS 解析是否正常內(nèi)網(wǎng)是否有安全策略限制了外網(wǎng)下載目標(biāo)存儲(chǔ)盤是否是機(jī)械硬盤。很多時(shí)候下載慢是磁盤寫入速度跟不上而不是網(wǎng)絡(luò)速度不夠。如果你在安裝階段就把時(shí)間耗光了后面實(shí)驗(yàn)容易產(chǎn)生“趕緊跑完”的急躁心態(tài)。遇到下載慢換一個(gè)時(shí)間再試或者找一臺(tái)網(wǎng)絡(luò)環(huán)境更穩(wěn)定的機(jī)器下好模型文件再拷貝都是可行辦法。5.2 模型名、版本和 529先看日志再猜原因模型名不匹配是很隱蔽的坑。比如你本地拉取的模型叫qwen2.5:7b但適配層配置里寫的卻是另一個(gè)名字Claude Code 就會(huì)報(bào)出類似“is not a model this version recognizes”的錯(cuò)誤。表面上看是版本不支持實(shí)際是模型名、路由配置和適配層版本三者不匹配。我還見過 HTTP 529 錯(cuò)誤。529 通常表示上游服務(wù)過載。放在本地多機(jī)場(chǎng)景里最常見的原因是并發(fā)請(qǐng)求同時(shí)打到同一臺(tái)機(jī)器導(dǎo)致 Ollama 處理不過來。排查時(shí)要先看這一段時(shí)間內(nèi)各節(jié)點(diǎn)負(fù)載而不是急著調(diào)超時(shí)。排查這類問題我只用一條原則先看日志再猜原因。5.3 超時(shí)和亂碼從輸入端和適配層一起排查把 Ollama 接入 Dify 這類平臺(tái)時(shí)很多人遇到過“模型處理超時(shí)”。這通常不是因?yàn)槟Ｐ捅旧砺巧舷挛奶L(zhǎng)導(dǎo)致請(qǐng)求處理時(shí)間超過了平臺(tái)默認(rèn)超時(shí)時(shí)間。本地模型對(duì)超長(zhǎng)上下文的處理要比想象中吃力。解決辦法不是簡(jiǎn)單地調(diào)大超時(shí)而是先縮短上下文或者限制對(duì)話輪數(shù)。“Ollama 調(diào)用亂碼”也是一個(gè)高頻問題。亂碼的根源不一定在模型可能出在請(qǐng)求編碼、響應(yīng)解碼或者適配層把流式數(shù)據(jù)切錯(cuò)了位置。排查時(shí)先看原始請(qǐng)求里的中文是否正常再看 Ollama 返回的原始 JSON 是否正常最后再看 Claude Code 收到的是什么。逐層確認(rèn)比反復(fù)換模型有效。5.4 一個(gè)通用排查鏈路遇到問題按這個(gè)順序排查先看現(xiàn)象是超時(shí)、卡住、無輸出、輸出異常還是速度變慢再看輸入模型名、上下文長(zhǎng)度、文件路徑、消息格式、編碼是否正常。再看環(huán)境Ollama 版本、Claude Code 版本、依賴版本、端口、防火墻、局域網(wǎng)連通性。再看參數(shù)并發(fā)數(shù)、批量數(shù)、超時(shí)時(shí)間、上下文長(zhǎng)度、量化級(jí)別。最后看工具邊界這個(gè)版本的適配層是否支持你要用的模型和功能。不要一上來就重裝。多機(jī)分發(fā)涉及多個(gè)組件重裝只會(huì)讓問題更難定位。6. 本地推理多機(jī)分發(fā)一個(gè)五步驗(yàn)證框架這類實(shí)驗(yàn)很容易變成“調(diào)一次參數(shù)、看一次輸出、再調(diào)一次參數(shù)”的無限循環(huán)。為了避免這一點(diǎn)我沉淀了一個(gè)五步驗(yàn)證框架你可以直接套用。6.1 五步法概述第一步單點(diǎn)跑通。確保一臺(tái)機(jī)器上的 Ollama 能正常完成請(qǐng)求。 第二步單機(jī)基線。測(cè)出這臺(tái)機(jī)器在目標(biāo)模型下的真實(shí)吞吐和延遲。 第三步跨節(jié)點(diǎn)調(diào)度。讓適配層能把請(qǐng)求分別發(fā)到不同機(jī)器并確認(rèn)每臺(tái)機(jī)器都有輸出。 第四步并發(fā)壓測(cè)。逐步增加并發(fā)請(qǐng)求觀察聚合吞吐和錯(cuò)誤率。 第五步穩(wěn)定運(yùn)行。跑一段時(shí)間觀察是否有偶發(fā)超時(shí)、內(nèi)存泄漏或節(jié)點(diǎn)失聯(lián)。6.2 每步要回答的問題第一步要回答輸入輸出格式對(duì)不對(duì)模型能不能正常加載 第二步要回答這臺(tái)機(jī)器當(dāng)前能跑多快瓶頸在 CPU、內(nèi)存還是 GPU 第三步要回答請(qǐng)求是不是真的分散到了所有節(jié)點(diǎn)有沒有節(jié)點(diǎn)一直收不到請(qǐng)求 第四步要回答并發(fā)上去后系統(tǒng)是變快、變慢還是開始報(bào)錯(cuò) 第五步要回答長(zhǎng)時(shí)間運(yùn)行后結(jié)果是否穩(wěn)定日志是否完整節(jié)點(diǎn)掉線后能不能自動(dòng)恢復(fù)6.3 判斷標(biāo)準(zhǔn)什么時(shí)候可以繼續(xù)什么時(shí)候該停如果單點(diǎn)跑不通不要繼續(xù)做多機(jī)。如果單機(jī)基線只有個(gè)位數(shù) tok/s多機(jī)聚合也不會(huì)突然變成幾百 tok/s。如果第四步發(fā)現(xiàn)并發(fā)一上去就大量超時(shí)先別急著加機(jī)器?？赡苁钦{(diào)度策略、模型加載策略或網(wǎng)絡(luò)配置出了問題。多機(jī)并不是變快的萬能藥它只是把瓶頸從“單機(jī)算力”移動(dòng)到了“調(diào)度和通信”上。如果第五步無法穩(wěn)定運(yùn)行這個(gè)方案只適合短期實(shí)驗(yàn)不適合作為日常工具鏈的一部分。7. 適用邊界它適合學(xué)習(xí)、實(shí)驗(yàn)和隱私場(chǎng)景但不等于生產(chǎn)替代本地多機(jī)分發(fā)有很多讓人興奮的地方但興奮之余要分清適用邊界。它不是一個(gè)“上可替代云端、下可跑生成任務(wù)”的萬能方案。7.1 哪些場(chǎng)景真的值得用如果你有隱私敏感的數(shù)據(jù)不希望它們離開自己的網(wǎng)絡(luò)這個(gè)方案很有價(jià)值。所有請(qǐng)求都在局域網(wǎng)內(nèi)完成數(shù)據(jù)不會(huì)經(jīng)過第三方服務(wù)。如果你所在的環(huán)境網(wǎng)絡(luò)不穩(wěn)定或者需要離線辦公本地多機(jī)也能保證基本可用。如果你主要用 Claude Code 做一些模板生成、代碼解釋、文檔整理任務(wù)對(duì)模型能力要求不是頂層本地小模型是可以接受的。三臺(tái) NUC 的聚合吞吐對(duì)這類任務(wù)來說通常夠用。如果你本身就在研究本地模型部署、任務(wù)調(diào)度、協(xié)議適配這個(gè)方案是一個(gè)很好的學(xué)習(xí)項(xiàng)目。它能讓你理解一條請(qǐng)求從工具鏈到推理節(jié)點(diǎn)的完整鏈路這種理解比任何單一工具教程都重要。7.2 哪些場(chǎng)景不建議硬上如果你需要的是代碼生成的高準(zhǔn)確率、復(fù)雜工具調(diào)用、超長(zhǎng)上下文理解本地小模型大概率達(dá)不到云端大模型的水平。這不是調(diào)度層的錯(cuò)而是模型本身的局限。如果你的業(yè)務(wù)需要嚴(yán)格的并發(fā)一致性、任務(wù)追蹤和審計(jì)本地多機(jī)適配層還不夠成熟。它可能沒有完善的隊(duì)列、持久化和冪等機(jī)制。這時(shí)候硬上會(huì)在運(yùn)維階段付出更多代價(jià)。如果你的團(tuán)隊(duì)沒有運(yùn)維基礎(chǔ)只是為了“快”而搭一套多機(jī)推理集群不劃算。多機(jī)意味著多一份維護(hù)模型版本、適配層版本、網(wǎng)絡(luò)問題、日志收集每一項(xiàng)都是成本。7.3 長(zhǎng)期維護(hù)成本很多人在實(shí)驗(yàn)階段被 627 tok/s 吸引但很少想長(zhǎng)期維護(hù)的問題。三臺(tái) NUC 意味著三套系統(tǒng)要打補(bǔ)丁、三個(gè)模型文件要更新、一個(gè)適配層要升級(jí)。只要其中一個(gè)節(jié)點(diǎn)掉線調(diào)度策略就不得不變化。如果你只是個(gè)人使用能接受偶爾手動(dòng)重啟服務(wù)那沒問題。如果你想把它變成團(tuán)隊(duì)工具至少還要補(bǔ)上監(jiān)控、日志告警、模型版本管理和節(jié)點(diǎn)健康檢查。沒有這些實(shí)驗(yàn)永遠(yuǎn)是實(shí)驗(yàn)。8. 回到最初627 tok/s 的啟示是什么現(xiàn)在再回到標(biāo)題里的 627 tok/s。我反而覺得這個(gè)數(shù)字不是最重要的。真正重要的是它展示了 Claude Code 這類工具可以被重新定向到你自己擁有的計(jì)算資源上。你可以用適配層把請(qǐng)求調(diào)度到局域網(wǎng)里的多臺(tái)機(jī)器讓它們像一個(gè)小型推理池一樣工作。這個(gè)過程本身已經(jīng)比單次速度更有價(jià)值。如果你也想復(fù)現(xiàn)類似實(shí)驗(yàn)我建議你先不要追求 627 tok/s。先花一個(gè)小時(shí)把一臺(tái)機(jī)器上的 Ollama 跑通再花一個(gè)小時(shí)接上適配層讓 Claude Code 發(fā)出第一條真正被本地模型處理的請(qǐng)求。然后慢慢擴(kuò)展到第二臺(tái)、第三臺(tái)。你會(huì)經(jīng)歷很多次排錯(cuò)但也會(huì)真正理解多機(jī)調(diào)度的底層邏輯。本地推理和多機(jī)分發(fā)這件事正在從“極客玩具”變成“可用的技術(shù)方案”。它的邊界很清楚不能替代云端大模型的能力但可以在隱私、離線、成本和可控性上實(shí)實(shí)在在解決問題。這個(gè)方向值得長(zhǎng)期關(guān)注因?yàn)楣ぷ髁鞯娜肟诤屯评矸?wù)解耦之后你能組合出很多新的使用方式。而 Yeschef 這類項(xiàng)目恰好是這個(gè)方向上的一塊有意思的拼圖。