← 返回 Siami 首頁

Magnitude (YC S25) 開源自調校推理引擎:宣稱比 llama.cpp 快 2 倍、Apple Silicon 解碼快 92%

▲ 144 💬 72
Magnitude (YC S25) 開源自調校推理引擎:宣稱比 llama.cpp 快 2 倍、Apple Silicon 解碼快 92%

編按:本文綜合整理自 Magnitude GitHub README、Hacker News 討論串、Y Combinator 公司頁 與 AIWeekly 報導,並加入 Siami 編輯部觀點與分析。

Magnitude 在 2026 年 9 月底以 YC S25 身份登上 Hacker News 榜首。截至發稿時,這則「Launch HN」已累積 144 分、72 則留言,並在 HN front page 持續停留超過 12 小時。這家總部位於舊金山、僅 2 人的新創,宣稱用「裝置端即時編譯」這條技術路線,把 open-weight 模型的本地推理速度推到 llama.cpp 的兩倍。


產品核心:為什麼「自調校」這件事值得做

Magnitude 的核心賣點不是新模型,而是**「在你的機器上現場編譯、調校 kernel」**。

傳統推理引擎(llama.cpp、Ollama、LM Studio)的做法是:為「一大類硬體」預編譯通用 kernel,再交給所有人使用。Magnitude 反過來——在模型跑起來之前,先用你這台機器的 CPU、GPU、記憶體拓樸去編譯並調出一份專屬的 kernel。官方說法是:因為硬體特性差異被吃進去,模型解碼(decode)速度在 Apple Silicon(Metal)上比 llama.cpp 快 92%,在 NVIDIA(CUDA)上快 19%,每個 agent 使用的記憶體少 27%。

這套引擎用 Apache 2.0 開源,附 macOS / Windows / Linux 桌面 App,支援 Apple Silicon、NVIDIA、AMD GPU,連純 CPU 都能跑。官方列出的相容 agent 名單包含 Pi、OpenCode、Hermes、Codex、OpenClaw、Claude Code、Oh My Pi、Cline——基本上已經涵蓋 2026 年本地端 agent 生態的主要玩家。其他 agent 只要走 OpenAI 相容 API 也能接入。

對開發者來說,啟動流程被壓到三步:下載桌面 App → 在 Discover 頁選模型 → 在 Connections 頁一鍵串接你已經在用的 agent。CLI 也內建在 App 裡,不需要額外安裝。


為什麼這件事重要

如果這套數字屬實,本地 LLM agent 的瓶頸可能會被重新定義。過去兩年,整個 open-source 生態幾乎都卡在「llama.cpp + Ollama 包一包」這條預編譯路線上,速度差異來自量化策略(Q4、Q5、Q8)與 prefix cache 工程。Magnitude 切入的是一個一直被忽略的維度:kernel 本身可以根據硬體特化。如果裝置端即時編譯(AOT)這條路走得通,推理速度就不再只是「換個更小的量化」,而是可以從底層 kernel 開始贏。

對台灣與中文圈開發者而言,這尤其值得關注——本地 LLM 的硬體組合極度碎片化(從 M1 MacBook 到 4090 工作站都有),通用預編譯 kernel 通常只對少數主流顯卡最佳化。Magnitude 如果能穩定做到「裝置端特化」,在亞洲市場碎片化硬體生態裡會比 llama.cpp 更實用。

另一個訊號是 YC S25 的選題節奏:Magnitude 與 Cactus(同樣 S25,做手機本地推理)代表 YC 在 2026 年押注「本地推理 + agent」這條賽道,把雲端依賴當作創業紅海來對沖。


數據解讀與質疑

官方給的 92% Metal 與 19% CUDA 差距聽起來很戲劇化,但 HN 留言區有兩個常見質疑值得展開。

質疑一:基準選擇。 多位開發者(@sebastienburel、@kmike84)指出,llama.cpp 在 Apple Silicon 上根本不是最快的開源推理路徑——MLX、ds4、omlx、mtplx 在 M 系列 Mac 上通常都比 llama.cpp 快。也就是說,「比 llama.cpp 快 92%」這句話的潛台詞是「我們也許比 MLX 慢」。如果 Magnitude 想真正說服 Apple Silicon 用戶,應該補一組 MLX 對照數字。

質疑二:實測落差。 @herf 實測雙 NVIDIA GPU(16GB+16GB)環境,Magnitude 偵測成 4 張顯卡,並拒絕大多數 >8GB 模型(只跑在 5070ti 上)。即便在 5070ti 上,他測出 llama.cpp 解碼還快 20-30%。這與官方「CUDA 快 19%」的基準不一致——可能是因為官方基準用單卡、單模型,而他的場景是 prefix cache 共用與多 GPU 切換。

質疑三:評測維度。 @lin7c 點出一個更深的問題:agent 推理不是「跑一次問答」,而是多輪對話。早期輪次是 prefill-heavy(巨大 system prompt + 工具 schema),晚期輪次是針對大型 KV cache 的短解碼。第一輪最佳化的配置到第三十輪可能完全失靈。Magnitude 應該公布「per-turn latency across a full trajectory」,而不是單純的 end-to-end 時間。

質疑四:隱私宣稱。 官方說「prompt、檔案、模型都在你的機器上」,但「下載模型」這個動作本身就會連網。如果使用者用 Discover 一鍵下載權重,過程中是否有遙測或使用數據回傳,目前 README 沒明確揭露。對強調「隱私」定位的產品,這塊透明度需要補上。


留言區亮點:開發者真正在問什麼

這次 HN 留言區的品質很高(72 則留言裡有 30+ 是技術深度討論)。除了上面質疑區提到的幾則,其他亮點包括:

  • @lxe:他描述自己用 llama.cpp 開發時,已經開著永久的 codex thread 自動 review PR、研究 MTP / Dflash 等新優化。Magnitude 是第一個讓這個工作流「原生支援」的工具。
  • @aitoolcrux:自調校推理的真正價值在「微進步會複利」——batching、KV-cache reuse、跨數千請求 routing 的小幅優化會累積起來。但難的不是優化本身,而是「衡量每次改動是否真的有效」。
  • @msdz:新 open-weight 模型幾乎每週都出,推理引擎要跟上必須為每個架構寫專屬程式碼。Magnitude 計劃支援到 vLLM / llama.cpp 的覆蓋率是哪個量級?
  • @mncharity:本地推理最痛的點其實是「溫控 / 功耗」——全速跑時筆電底部燙到可以煎蛋,但固定降頻又會非線性掉速。要的是 runtime knob,不是手動加 limit。

這些留言勾勒出本地 agent 推理真實的痛點圖譜:不是「再快一點」,而是「在快、穩、靜、省電之間的權衡」。Magnitude 目前的 benchmark 只展示速度優勢,其他三個維度還沒看到資料。


產品定位與市場脈絡

Magnitude 由 Tom Greenwald 與 Anders Lie 共同創辦,YC 公司頁面顯示團隊僅 2 人、位於舊金山。這個規模說明他們走的是「核心 engine 開源 + 桌面產品商業化」路線——和 llama.cpp 社群版的「純開源」不同,Magnitude 多了一層桌面 App 與 Discover 模型策展作為護城河。

從市場角度看,2026 年本地推理引擎競爭已經進入白熱化。除了 llama.cpp、Ollama、vLLM、LM Studio、MLX 這些既有玩家,YC S25 同期還孵化了 Cactus(手機端推理)——可見 YC 把「本地化 AI」視為下一波基礎設施級別的押注。

對想嘗試 Magnitude 的讀者,官方下載頁提供 macOS / Windows / Linux 三平台安裝檔,但目前仍在早期階段(v0.x 系列),API 與 kernel 調校介面預期會頻繁變動。對需要 production stability 的團隊,建議先在 side project 試水溫,等 v1.0 與穩定 benchmark 公開再評估導入。


常見問題

Magnitude 是什麼? 一個開源、本地端、自調校的 LLM 推理引擎。它在你的機器上即時編譯並調校 kernel,讓模型跑得比通用預編譯的 llama.cpp / Ollama / LM Studio 更快。

要什麼硬體? 任何 Apple Silicon、NVIDIA 或 AMD GPU 都支援,連純 CPU 都能跑。沒有固定最低需求——機器小就跑小模型,記憶體多就跑大模型。

支援哪些作業系統? macOS、Linux、Windows 都有桌面 App。

支援哪些 agent? Pi、OpenCode、Hermes、Codex、OpenClaw、Claude Code、Oh My Pi、Cline 一鍵接入。其他 agent 透過 OpenAI 相容 API 也能用。

真的免費嗎?開源嗎? Apache 2.0 授權,完全開源。Prompt 與模型都留在你的機器上,模型下載完之後不需要網路。沒有 token 費用、沒有雲端依賴。

支援哪些模型? 官方維護一份支援清單(magnitude.dev/models)。他們為最受歡迎的 open-weight 模型家族手寫 kernel,這也是他們能贏通用型引擎的關鍵。


結論

Magnitude 把「裝置端自調校」這條技術路線變成開源專案,並用 YC 與 HN 雙重曝光證明了市場興趣——144 分、72 則留言、front page 停留 12 小時以上,這個成績在 2026 年本地推理引擎類別裡算得上現象級。

但這套基準能不能撐起「取代 llama.cpp」的敘事,目前還有三個未解問題:MLX 對照數字、per-turn trajectory 評測、溫控與功耗資料。在這三個空白被補上之前,Magnitude 比較像是「值得關注的新工具」,而不是「llama.cpp 的直接接班人」。對本地 LLM agent 開發者而言,這是 2026 年第四季最值得 star 的 repo 之一;對企業導入者,建議再等 2-3 個月,看 v1.0 與社群 benchmark 出來再決策。

網友熱門留言 (6)

#1 sebastienburel 0
在 Mac 上要比較的基準應該是 MLX,不是 llama.cpp。llama.cpp 在 Apple Silicon 上根本不是最快的路徑,速度贏 llama.cpp 還是可能比 mlx_lm 慢。你們有那個數字嗎?
#2 kmike84 0
這看起來是個好點子,但贏 llama.cpp 算是低標吧。我在 Mac 上找到的都比 llama.cpp 快很多(ds4、omlx、mtplx 等)。如果真的用本地 LLM 處理實際工作,根本不會用 llama.cpp。
#3 lxe 0
我本地的推理盒上有一個永久開著的 codex thread,會定期去看 llama.cpp 待處理的 PR、研究最新的 MTP、Dflash 還有其他預測或注意力優化、研究最新的模型量化。Magnitude 是第一個真正針對我這個工作流而生的工具。
#4 herf 0
我有兩張 NVIDIA GPU(16GB+16GB),它偵測成 4 張,然後說大部分模型都太大(>8GB?),只跑在一張 5070ti 上。即便用 5070ti,llama.cpp 跑解碼還比 Magnitude 快 20-30%。
#5 thoughtpeddler 0
對 macOS Apple Silicon 用戶來說,Magnitude 跟 Apple 自家 Core AI 的 AOT 編譯優化差別在哪?Core AI 也會把模型最佳化成專屬編譯檔案。
#6 lin7c 0
我想看的評測是「每一輪延遲」而不是 end-to-end 時間。實際 agent 工作負載會在中段翻轉:早期是 prefill-heavy(巨大 system prompt、工具 schema),晚期是針對大型 KV cache 的短解碼。第一輪最佳化配置到第三十輪可能完全失靈。