編按：本文綜合整理自 antirez/h3.c GitHub repo 與 Hacker News 討論串（item 49252179），並加入 Siami 編輯部觀點與技術分析。
專案背景開源社群的老朋友 Salvatore Sanfilippo（網名 antirez）在 2026 年 8 月 9 日悄悄推出一個新專案：antirez/h3.c。這個 repo 只有 48 小時的歷史，就已經在 Hacker News 上拿到 83 分與 11 條留言，並累積 439 顆 GitHub stars。任何熟悉開源歷史的人看到 antirez 這個名字都不會陌生——他正是 2009 年創造 Redis 的那個義大利工程師。
h3.c 不是普通的「又多一個 AI 推論框架」。它是用純 C 與 Objective-C 從零重寫 MiniMax H3 影片生成模型的 Apple Silicon 原生推理引擎，目標對標 Apple Metal 4 TensorOps 與 int8 量化。也就是說，antirez 這次選擇直接挑戰 PyTorch + MLX + Diffusers 這條主流路徑，憑一己之力把 33B 參數的影片生成模型壓進 M3 Max / M5 Max 的 GPU 共享記憶體。
技術亮點：為什麼這個 repo 值得認真看
1. 完整的 Metal 原生堆疊
repo 採用「垂直切片」（vertical slices）方式開發，每個 commit 都先求端到端能跑：
h3.c/h3.h—— 主機編排h3_gpu.h/h3_gpu.m/h3_metal.h/h3_metal.m—— Objective-C GPU 橋接h3_shaders.metal—— 205 KB 的 Metal 4 核心（佔整個 repo 最大的單檔）h3_dit.c（130 KB）—— DiT transformer 前向傳遞h3_dit_schedule.c—— 去噪排程h3_text_encoder.c/h3_vision_encoder.c—— Qwen 文本編碼器h3_video_vae.c/h3_audio_vae.c—— 視訊／音訊 VAEh3_video_encoder.c/h3_ffmpeg.c—— 媒體 I/Oh3_safetensors.c/h3_weights.c—— 模型載入h3_cli.c—— 命令列介面h3_terminal.c/linenoise.c—— 互動式 REPL
整套 51 個檔案，包含 main.c 與 Makefile，沒有任何 Python 程式碼。社群反應也很直接：「我人在 M5 Pro 64GB MacBook Pro 上透過 ComfyUI 跑 MiniMax H3 效果很棒，但 9 秒 480x864 的 20 步剪輯要花一個多小時，這個原生引擎能帶來 2-3 倍加速是很值得期待的。」
2. 數據會說話
在 128 GB M5 Max 上，乾淨的端到端圖片＋音訊渲染完成時間為 74.58 秒，內嵌影片＋音訊為 76.99 秒，峰值實體記憶體 40.1 GB，零 swap。完整 50 層、19 步過渡的 512x512 渲染：
- BF16 MPS：36.30 秒
- int8（預設）：25.80 秒
- int8 + QKV 量化：19.32 秒
- 加上 attention-output 投影：再省 4.5-5.5%
所有版本 byte-identical（位元完全相同）於 MLX 參考實作，這是 antirez 強調的最關鍵特性：「不是近似，是一模一樣的輸出」。
3. 記憶體策略是 Apple Silicon 的殺手鐧
33B 參數的 MiniMax H3 模型若以完整 BF16 跑要 66 GB 權重，antirez 的作法：
- 33B transformer / Qwen 編碼器 / 解碼器 分階段載入、從不共存於共享記憶體
- M5 Max 上 37 GiB 權重直接 memory-map from safetensors shards，不複製到共享 buffer
- 一個 token 序列化、權重回收的細節：「DiT 活化緩衝區跟著區塊內生命週期走，QKV 投影 arena 先給 attention heads 用、然後給標準化後的 MLP 輸入，attention-output arena 變 MLP 輸出」
- 結果：512-class 幾何省下 61.25 MiB，864-class 省下 99.63 MiB
HN 留言裡有人直接引用 README 數字說：「總用量 40 GB，所以 96 GB Mac 應該跑得動」，而另一位哀號：「這還是得 128 GB 吧？我這 96 GB 的窮人是不是被擋在門外了？」
速度與品質的可調旋鈕
h3.c 對外提供完整的命令列參數，使用者可即時在「速度 vs. 品質」之間取捨：
| 控制項 | 慢速參考 | 預設 | 積極 | 主要影響 |
|---|---|---|---|---|
| 去噪步數 | --steps 50 | --steps 20 | --steps 4..7 | 命名實際的 denoising pass 數 |
| 整體 denoiser 復用 | --reuse 1 | --reuse 2 | --reuse 3 | 20 步時 20 / 11 / 8 次 fresh DiT 評估 |
| 啟用 DiT 區塊 | --layers 50 | --layers 45 | --layers 40 | 越少區塊 → 越快、越省 |
| 核心復用 | --core-reuse 1 | --core-reuse 4 | --core-reuse 6 | 與 whole-velocity reuse 互斥 |
| Token 縮減 | 關閉 | optional | --token-reduction | 中段區塊合併水平視訊 token |
值得注意的是 antirez 的實驗紀律。例如他測試了 4 步、5 步、6 步、7 步的笑果，最終選用線性基底網格加上單終端點的排程。在 22-frame 紅狐狸測試中，4 步對 29 步參考的 SSIM 為 0.556（surfer 測試 0.547），denoise 時間從 26.4 秒縮到 3.5 秒。此外也有程式設計師層面的細節：--core-reuse 與 --reuse 互斥，--layers 40 與 --reuse 3 同時打開會出現色彩環狀鬼影（chromatic ringing），這是 antirez 親自跑出來並寫進 README 的禁忌組合。
專業音訊：H3 不只是影片
MiniMax H3 的全名是「Multimodal Video Generation Model」，原生支援 32 kHz 立體聲 F32 PCM 與 H.264 視訊同步輸出。antirez 寫的 h3_audio_vae.c 處理 60 KB 的 AudioVAE 後端：
- 原生音訊編碼器在真實雙聲道測試片段上對校正後 MLX oracle 的相對 L2 為 3.59e-6
- 視訊編碼器透過
h3_ffmpeg.c走 concurrent pipes，不產生未壓縮過渡檔 - first/last-frame conditioning 走釋出的視覺 VAE encoder + Qwen3-VL vision tower + three-deepstack multimodal presentation
- 0.999 condition augmentation + fixed condition rows in native DiT
換言之，這不只是一個影片生成器，而是一個 能直接吐出 MP4 + 立體聲音軌 的多模態生成器。
為什麼這件事重要
對 Apple Silicon 社群：長期以來，macOS 上的本地 AI 推理要不是靠 PyTorch + Metal Performance Shaders（MPS）後端，就是靠 MLX 框架。Apple 官方 MLX 團隊沒有針對大型多模態模型做太多客製化，社群主要是透過 ComfyUI 這類 Python 工具鏈接入。antirez 證明了 用 C 從頭寫 Metal 4 推理 pipeline 在品質與效率上都能對標甚至超越 PyTorch 路徑——而且整個專案都是他一個人維護（截至 2026/8/11 只標 2 個 open issues）。
對開源 AI 推理：33B 參數的 H3 模型以「分階段載入」設計在 128 GB M5 Max 上跑出 74.58 秒的完整渲染，這包括聲音生成。這代表 Apple Silicon 對記憶體的處理能力（unified memory）可以被榨到傳統 GPU+CPU 設計難以達成的密度。當 NVIDIA H100 還在 80 GB HBM 上掙扎時，一台 128 GB 的 Mac Studio 已經能跑完整的多模態生成。
對整個社群：HN 上一則留言其實是玩笑話「當你有足夠的錢不用擔心任何事時，就可以回去玩自己的嗜好。他的嗜好正好是寫程式」——但這也點出一個結構性問題：頂尖開源貢獻者往往回到自己的興趣，而非企業 AI roadmap。antirez 沒拿 VC 投資、不接企業委製、寫的是真正從底層重寫的 inference engine，這種「複雜的東西靠興趣驅動」的開發模式在 2026 年的 AI 圈已經是稀有動物。
數據解讀與質疑
1. 那個 74.58 秒其實是特定組合
HN 上一則留言精準點出問題：「那個 74.58 秒其實沒太大意義，因為 it/s 跟總時間高度依賴模式（T2V / I2V / REF2V）、解析度（0.4、0.6MP 等）、長度（5-15 秒）。」對使用者來說，這個 benchmark 給的是 M5 Max 的「天花板」數字，實際工作中速度可能差上 3-5 倍。
2. 128 GB 是真正的入場券
對於多數 Mac 用戶來說，128 GB M5 Max 售價約 5,800 美元（Mac Studio 滿配），這個價位已經接近 NVIDIA RTX 6000 Ada 一張專業卡的價格。換言之，這不是拿 MacBook Air 就能跑的東西。對於沒有 M5 Max 的人，社群已有 GGUF 量化（Q5_K_M 用 city96 ComfyUI-GGUF custom node）當退路。
3. 完整 repo 只有 48 小時歷史
這代表幾件事：
- 沒有大型開源社群審查過（除了 antirez 自己）
- 沒有 benchmark 對照組（PyTorch + MLX、ComfyUI、diffusers）
- int8 量化可能仍有未發現的數值偏差（雖然 README 強調 byte-identical）對生產環境，這個專案還不到能上 production 的階段。但作為研究實作與 Apple Silicon 推論的最佳實踐展示，它已經極具參考價值。
antirez 是誰？為什麼大家都在看
Salvatore Sanfilippo 在 2009 年創造 Redis 時才 32 歲。他把這個 in-memory key-value store 從個人 side project 推動成為全球前 10 大資料庫系統。2014 年他進入 Redis Labs（後改名），2020 年宣布「Redis 冒險結束」正式離開日常維護。2024 年底他短暫回歸 Redis 社群（InfoQ 報導），2026 年這個 h3.c 是他最新作品的展現。他的開發風格有幾個特色：
- 垂直切片：每個 commit 都先有可運行的端到端
- 不引入複雜依賴：Redis 編譯只需要
make，h3.c 也是 - 從「興味」出發：他自己說「嗜好是寫程式」這次的 h3.c 從專案結構到命名（h3.c、h3_host.c、h3_dit.c、h3_audio_vae.c）都看得出他一貫的「好品味」：把複雜的東西拆成 51 個小檔案，每個做一件事做好。
結論
antirez/h3.c 不是下一個 Stable Diffusion WebUI，也不是另一個 LoRA 訓練框架。它是 一個程式設計師用 C 重新發明了大型 AI 推理的方式，證明 Apple Silicon 在 2026 年確實有能力承擔 33B 規模的多模態模型，並且可以做到 byte-identical 於主流參考實作的水準。對於 96 GB 或 64 GB Mac 用戶，這個專案目前還跑不動完整 BF16 路徑。但 Q5_K_M 量化 + int8 路徑已經在 64 GB 上可運行，速度上看是 ComfyUI 的 2-3 倍。整個社群都在盯著這個 repo，「I’m totally following this」是 HN 留言的高頻句。如果 antirez 繼續維護下去，2026 年的本地 AI 推理生態可能會出現一個完全繞過 PyTorch 的分支。
延伸閱讀
- antirez/h3.c GitHub repository
- Hacker News 討論串（item 49252179）
- MiniMax H3 GGUF 量化版（社群 hack）
- PipeNetwork/minimax-h3-mlx — 另一個 MLX 實作
- antirez 個人部落格 — 看 Redis 創作者的其他作品
網友熱門留言 (6)