Dmitri Lerko 的個人部落格，涵蓋 AI 工程、Google Cloud、平台工程。

這篇文章在 Hacker News 上引起關注，獲得超過 100 則留言。我很高興這能激發大家的情感。一如往常，反應相當多元，這正是 HN 上所預期的。請捲動至文末，查看對部分留言的額外回覆。

Cloud Next 盛會非常緊湊。我在當地時間早上 9 點，睡眼惺忪時寫了這篇文章的初稿，當時並未預期會引起多大興趣。鑑於它現在獲得的關注，我給予了它應有的重視：修正了模型細節，增加了更多關於設定的背景資訊，並回覆了最常見的幾點。

我從倫敦飛往拉斯維加斯參加 Google Cloud Next 2026。飛行時間十小時，期間沒有機上 Wi-Fi。我利用這段時間測試了最新的 MacBook 在僅靠本地 LLM 進行工程工作的極限。

一台一週前購入的 MacBook Pro M5 Max，配備 128GB 統一記憶體，40 核心 GPU。

進行有用工作的模型是 qwen/qwen3.6-35b-a3b，透過 LM Studio 運行。

最常見的 100 個 Docker 映像檔、主流程式語言，以及足夠的依賴庫來建構具有豐富視覺化效果的功能網站。

無數的 CLI 工具，其中 opencode、rtk、instantgrep 和 duckdb 是使用最多的。

一個涵蓋 loveholidays 兩年雲端支出的帳單分析工具。底層使用 DuckDB，搭配自訂 UI，用於在標準儀表板無法呈現的維度上切片數據。它揭示了先前難以發現的模式和跨服務關聯。

我對探索這個領域已感興趣一段時間，但始終無法將其優先於我其他職責的紛擾。現在有了 10 小時的空檔、頂級硬體和開源模型，我決定放手一試。

除此之外，我還處理了約 400 萬個 token 的較小任務：重構、CLI 腳手架、文件編寫。對於範圍受限的工作，Qwen 產生的輸出與我平常使用的頂尖模型相當。

這是我最驚訝的部分。不到兩年前，我曾帶著一台 M1 Max 和 64GB 記憶體飛往紐約，當時本地編碼模型幾乎無法使用。它能產生一些聊天回覆，最終也能在數十分鐘後建立一個基本的 Go 檔案，但體驗並不愉快。如今，硬體、模型和代理框架都已大有進步。

電力。在持續負載下，大約每分鐘消耗 1% 的電池電量。即使連接了 60W 的電源，電池電量仍在下降。

散熱。持續 70–80W 的功耗，機身會熱到令人不適。機上的毯子和枕頭雖然拯救了我的膝蓋，卻讓過熱問題更加嚴重。

電池時間線清晰地講述了故事：你可以看到午餐、意外拔掉電源、短暫的「充電小憩」（雙關語）和晚餐。

上下文。超過 10 萬個 token 後，吞吐量和延遲會明顯下降。

迴圈。有幾次提示讓模型進入無限迴圈，需要手動干預才能打破。不確定是 opencode 編排層的問題還是模型本身的問題。

有幫助的方面：每次會話處理一個問題、將長計畫寫入 markdown 以供重新讀取，以及使用 rtk 最小化工具呼叫的開銷。我避免進行壓縮，因為運行起來非常緩慢。

我在飛行期間建構了兩個工具。

powermonitor (powermonitor) - 一個讀取 Mac 電源遙測數據（CPU、GPU、ANE、電源轉接器、電池）的 CLI 工具。我後來推送了一個修復，用於更快地偵測電源轉接器電源來源的變化。

lmstats (lmstats) - 讀取 LM Studio 的遙測數據，並報告一個會話中的 token 吞吐量、延遲分佈和上下文視窗行為。

這裡我沒有使用小桌板。筆記型電腦放在我的腿上，用毯子和枕頭隔絕熱氣，並稍微墊高。人體工學非常糟糕，極度不舒服，但我因為本地 LLM 推理的進步而感到非常興奮，這讓我克服了不適。

兩個工具都遵循我們 loveholidays 在更大規模上應用的相同模式：在採取行動前，先對系統進行儀器化監測。

我打算繼續僅使用本地 LLM 來開發 powermonitor。一些不錯的回饋讓我更有動力繼續這個實驗。有人向我推薦了 mac-adapter，並說 powermonitor 在測試 USB PD 電源方面已經更具功能性。

最初的 LinkedIn 貼文引發了幾個值得深入探討的討論串。

Steve Turner 指出，運行本地模型，成本可見，會讓人更嚴格地審視對雲端模型的請求。這就是應用於 AI 的機械同情心原則——直接接觸熱量、電力和上下文效應，能培養對推理成本高低的直覺。這種直覺會轉移到雲端使用上。

Jackson Oaks 認為，在電池受限的工作負載中，Apple Silicon 的每瓦效能優於 NVIDIA。

英國航空宣稱每座位提供 70W 電力。powermonitor 在去程航班中顯示輸出了 60W。我決定抵達後徹底調查這個差異。

在飯店，我使用兩條不同的線纜，在相同負載下測試了 M5 Max。使用相同的電源轉接器、插座和工作負載。

iPhone 充電線：輸出 60W

MacBook 充電線：輸出 94W

僅僅是線纜的選擇就造成了 34W（36%）的差距。在去程航班中，我以 60W 的功率運行，而電源上限是 70W。

如果你想充分利用充電器，請了解你的線纜。

回程航班將使用正確的線纜進行測試。我預計相較於 70W 的上限，至少會有 16% 的提升，一旦線纜不再是瓶頸，將有更多餘裕。

如果沒有儀器化監測，我不會發現自己誤用 iPhone 充電線的錯誤。

本地推理對於有意義的工程工作子集是可行的：範圍受限的編碼、探索性工具開發，以及與雲端推理相比，成本效益不高的任務。大上下文推理、需要頂尖智慧的代理工作流程，以及高價值任務，仍然屬於雲端的範疇。

次要效應：本地暴露於推理成本，迫使在提示大小、工具呼叫開銷和上下文管理方面採取紀律。這種紀律會轉移到雲端使用上。

使用正確線纜的回程航班。將發布數據。

探索神經引擎驅動的小型 LLM 模型，以了解其有用性、速度和功耗，因為它們應該非常高效。

繼續將 powermonitor 作為一個僅限本地 LLM 的專案，以便我能透過實際程式碼庫觀察工具、模型和硬體的演進。

關於靠窗座位和筆記型電腦尺寸。有一則留言稱 14 英寸筆記型電腦在靠窗座位上很幽閉。實際上筆記型電腦是 16 英寸，這對電池續航和散熱更好，但對可用空間來說則差很多。

關於前方的座位。我選擇了靠窗座位，因為這樣不會被其他人起身打擾，而且你可以掌控至少一半的空間。前方的座位傾斜確實有點問題，但這是波音 787 的 42A 座位，後面沒有座位，所以我可以傾斜而不給別人造成同樣的困擾。

關於人體工學。人體工學非常糟糕。我沒有使用小桌板；筆記型電腦放在腿上，用毯子和枕頭墊著。「暴龍手臂」的描述非常貼切，使用 16 英寸筆記型電腦在經濟艙的感覺就是如此，我可能會更新首圖，因為它很好地捕捉了這種氛圍。豪華經濟艙有側邊的小桌板，那對生產力來說確實不錯。

關於藍牙鍵盤的建議。有些人建議將筆記型電腦放在小桌板上，然後將藍牙鍵盤放在膝蓋下方。這是一個很棒的主意，特別是對於 vim、emacs 或任何鍵盤驅動的編輯器工作流程。另外：這代表了在飛行中編碼的最高級別的投入。

關於另一篇離線編碼飛行文章。我了解到 40,000 feet，這是另一位離線編碼者在 2025 年 9 月發表的文章。自那時以來，變化的速度非常驚人：硬體、模型和框架都取得了進步。

關於這是否 relatable。有一則留言指出，在飛機上使用價值 6,200 歐元的筆記型電腦嘗試本地 LLM，並不那麼 relatable。確實如此。即使產生了約 400 萬個 token，目標也不是省錢，我也沒有聲稱這是主流。我想捕捉的是目前的技術現況：現在已經有可能使用允許在機上使用的硬體，離線完成有意義的實用工作。

在工作中，我使用頂級的 Codex 和 Opus，因為我試圖最大化每單位時間的產出。但這次實驗改變了我對自架 LLM 定位的看法。對於高流量、低關鍵性的使用案例——例如總結數百萬份客戶支援聊天記錄，錯誤的影響很小——本地或自架推理可以保護數據隱私並節省大量 token 成本。這幫助我鞏固了購買 RTX 6000 Pro 的商業論證，並看到了它能走多遠。我很幸運能獲得頂級的 M5 Max，但我打算讓它在未來 4-5 年內承受大量日常和夜間使用，這應該能使其整體物有所值。

關於遠端工作站。Tailscale、mosh 和 tmux 是連接到工作站的絕佳方式。我完全同意。我在家裡有一堆 Mac Mini 24/7 運行，我使用 Tailscale 和 tmux 定期檢查它們。

關於在旅途中工作是缺點而非優點。我同意，如果這是被迫的。這次是我選擇在一個我極度感興趣的領域工作。我可以去看我錯過的電影，或在任天堂上玩薩爾達傳說，但離線編碼對我來說是最有趣的。現代生活很少給我們連續 10 小時的獨處時間；我們與我們所愛的人、同事和社群分享我們的時間。這次飛行是我追隨熱情的自私放縱。

最後一個小提示：看看 Hacker News 的流量。