橫跨大西洋11小時，中國開發者用Mac跑Llama 70 B？評論區吵翻了

新智元報道

編輯：Aeneas

【新智元導讀】一位中國開發者，在橫跨大西洋的航程中，在飛機上用 MacBook 本地跑 Llama 70B，整整 11 小時沒有網絡，帖子瞬間在X上爆火！但是隨后，越來越多網友發現，這故事不太對啊？

一位中國開發者，在橫跨大西洋的 11 小時航程中，拒絕了 25 美元的機上網絡，卻在萬米高空完成了一整套復雜的客戶項目交付？

沒有 Cloud API，沒有 Anthropic，沒有 OpenAI，甚至沒有一格信號。

只有一臺 MacBook Pro M4、一段自己寫的編排腳本，以及Llama 70B這個本地AI模型，然后就把項目跑通了？

舷窗外是白云與藍天，沒有 WiFi；小桌板上是一臺 MacBook，終端開著兩個窗口，本地運行著一個推理服務器

因為太過炸裂，這個帖子一經發出，就在技術社區傳開了。

本地推理的時代，真的來了？

在萬米高空，

用MacBook跑Llama 70B

據說，故事的主角是一位中國開發者。

在飛往大洋彼岸的靠窗座位上，他打開64GB內存的MacBook Pro，面對的是堆積如山的客戶任務隊列。

接下來整整11個小時，都沒有網絡。

換做普通人，此刻已經乖乖掏出信用卡，支付那昂貴且延遲極高的 25 美元機上 Wi-Fi。

但他選擇了另一條路：本地推理。

他啟動了通過llama.cpp運行的Llama 3.3 70B。

生成速度 71 tokens/秒，上下文約 60,000 tokens，內存占用 48.6 GiB / 64 GiB，起飛時電池剩余 3 小時 21 分鐘。

為了讓這個龐然大物在64GB內存的機器上跑起來，他甚至為自己編寫了一個「離線編排器」腳本。

最令人拍案叫絕的，是他給AI下達的系統提示詞。

你是一個運行在單臺 MacBook 上的離線編排器。沒有網絡。你唯一的資源是 /Users/dev/work 下的本地文件、localhost:8080 的 Llama 70B 推理服務，以及 3 小時 21 分鐘的電池預算。

處理 /Users/dev/work/queue.jsonl 中的任務隊列（每行一個客戶任務）。對每個任務：起草 → 運行本地評估 → 保存產物到 /Users/dev/work/done/。每 12 個任務保存一次上下文檢查點，以便更換電池后恢復。僅在隊列為空或電池低于 5% 時停止。

因此，這個系統完全清楚自己所處的困境。

它知道自己未來 11 小時與世隔絕，知道內存和電池是有限的奢侈品，甚至知道在飛機降落前，它必須獨自處理所有的邏輯。

系統在一個循環中運行：從任務隊列中取出一個任務，進行推理處理，保存生成結果，寫入檢查點。一個接一個，就這樣持續執行。

只有當電量低于 5% 時，調度器才會自動暫停，等待筆記本切換到備用移動電源，然后從上一次的檢查點繼續運行。

飛行過程中，系統日志里寫下了這樣的內容：

「已保存上下文檢查點 8 / 12（pos_min = 488，pos_max = 50118，大小 = 62.813 MiB）」

「已恢復上下文檢查點（pos_min = 488，pos_max = 50118）」

「提示處理進度：n_tokens = 50 / 60,818」

「任務 37016 完成 | 處理速度 = 71 tokens/s → 輸出至 /Users/dev/work/done/proposal_westside.md」

有人驚呼：這是我過去一年里見過的最干凈利落的離線 AI 工作流程！

11 小時航程，WiFi 花費為 0，當飛機輪子觸碰跑道的那一刻，他合上電腦，所有的客戶提案已經整整齊齊地躺在done/文件夾里。

系統不再是一個只會復讀的復讀機，而是一個具備資源意識的管理者。

這正是「Self-aware Computing」最迷人的地方。

網友打假：

技術神話，還是「賽博爽文」？

不過，文章在社區瘋傳后，很快引來了技術極客們的質疑。

資深開發者們紛紛掏出計算器，開始瘋狂「對線」。

第一刀：內存與權重的「不可能三角」

Llama 3.3 70B 如果以 BF16（半精度）運行，光模型權重就需要約140GB內存。要在 64GB 的 MacBook 上跑起來，簡直就像把大象塞進冰箱。

64GB 內存大概率只能跑 4-bit 量化版本，算上 60k 的上下文 KV Cache，內存占用至少也要 40GB+，BF16 絕無可能。

非要說的話，要在64GB上跑70B，只有一條路——量化。4-bit量化后模型約35GB，加上KV緩存和系統開銷，勉強能塞進去。

但量化版本和BF16是兩回事，精度、推理質量都會打折扣。

帖子里寫的是「bf16」?？雌饋?，這個細節要么是不懂，要么是故意的。

第二刀：71 tokens/s 的「神仙速度」

帖子聲稱生成速度71 tokens/s。

根據 M4 芯片的實際表現，本地運行 70B 規模的模型，生成速度通常在 5-12 tokens/s 之間。

71 tokens/s 是什么概念？這幾乎是頂級 H100 集群的響應速度。

「這個速度可能是 8B 模型或者是某種極致的投機采樣，70B 跑出這個速度，MacBook 怕是要起火?！?/p>

評論區一位用戶直接亮出自己的實測數據：M5 Max 128GB（注意，128GB，是帖子里設備內存的兩倍），跑同款模型量化版llama.cpp，實測12.8 tokens/s。

更高端的硬件，跑更輕的量化版本，速度反而只有帖子聲稱的五分之一，因此，原帖中說的速度幾乎不可能實現。

第三刀：11小時續航

帖子中提到的「更換電池」引發了老用戶的集體懷舊：現代 MacBook Pro 都是一體化設計，所謂的「換電池」，大概率是切換到了大功率的備用充電寶（如百瓦快充移動電源）。

MacBook Pro M4 Max官方標稱續航約18小時，那是輕度使用。持續滿載跑70B推理，GPU和內存全程拉滿，實際續航會大幅縮水。

雖然帖子里提到「切換到備用充電寶后恢復」——但跨大西洋航班經濟艙的USB口功率通常只有7.5W到18W，而M4 Max滿載功耗超過40W。

因此，續航11小時這個說法幾乎站不住腳。

故事是假的，但范式轉向是真的

面對質疑，我們需要剝開數據的水份，看清這件事背后真正令科技圈高潮的原因。

長期以來，我們已經習慣了「云端成癮」。

沒有 GPT-4 的 API，很多開發者甚至不知道該如何寫代碼；沒有網絡，AI 就變成了一個啞巴。

現在，本地推理，確實在發生一場靜悄悄的革命。

2024年，在筆記本上跑7B模型還需要各種技巧。

2026年，M4 Mac上跑70B量化版已經是日常操作。雖然速度不快，大概10來個tokens/s，但已經能用。

真實的使用場景不是「飛機上交付完整項目」這種聽起來很爽的敘事，而是一些更樸素的東西，比如離線環境下的文檔問答，隱私敏感場景下不想把數據傳上云等等。

這些場景不性感，但實用。

現在，llama.cpp的mlx后端已經針對Apple Silicon做了深度優化，Ollama也把部署門檻壓到了一條命令。

即便 71 tokens/s 的速度存疑，BF16 的精度可能有夸張，但這種「在孤島上建立文明」的技術浪漫主義，才是最牛的。

未來，最頂尖的開發者或許不再是那個最會調優云端 Prompt 的人，而是那個能在資源枯竭、完全離線的極端環境下，手搓出一個「自感知、自循環」AI 系統的人。

下一次坐飛機，你準備好帶上你的「數字大腦」了嗎？

參考資料：

https://x.com/servasyy_ai/status/2050098091789828376