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