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