為什麼大家一直在做 .cpp？從 llama.cpp、CrispASR、stable-diffusion.cpp、trellis.cpp 到 KoboldCpp 看原生本機 AI 家族

• llama.cpp GitHub repo
• CrispASR GitHub repo
• stable-diffusion.cpp GitHub repo
• trellis.cpp GitHub repo
• KoboldCpp GitHub repo

最近在 Threads 上看到一段貼文，角度切得很精準：

免Py/Docker系列，原生家族又多一員。

這次是2D轉3D，原生CPP組件才是王道，目前已經有五個組件了。

llamacpp，主要語言模型，向量嵌入。

crispasr，TTS/STT，聲音系列。

SDCPP，擴散模型。

TrellisCPP，2D轉3D。

Koboldcpp，混合圖像、音樂、語言。

這段討論最有趣的點不在於列出這幾個專案，而是反映出一個趨勢：許多原本極度依賴 Python 工具鏈的 AI 能力，正加速往 xxx.cpp 的路線收攏。

單看這些專案，它們各自處理不同的任務：

• llama.cpp：語言模型推論、GGUF 格式、本機推論與 API 伺服器
• CrispASR：自動語音辨識（ASR）與語音合成（TTS）的 runtime
• stable-diffusion.cpp：影像生成與編輯
• trellis.cpp：2D 影像生成 3D 模型
• KoboldCpp：將語言、圖像與語音等能力整合，提供完整的本地進入點

但把這些專案串聯起來，我們會發現一個更龐大的輪廓：原生本機的 AI 組件生態已逐漸成形，逐步補齊了語言、聲音、影像、3D 資產乃至多模態入口的拼圖。

先講結論：.cpp 的價值不只是效能，而是部署邊界的重塑

一般人看到 .cpp 結尾的專案，直覺反應通常是：

• 執行速度比 Python 快
• 極度依賴本機硬體資源
• 開發與使用門檻較高

這些看法固然沒錯，但如果把焦點只放在「速度快」，就很容易忽略這波技術轉移的本質。

這批專案真正的核心價值，在於將 AI 能力限縮並封裝成無 Python 執行期依賴（runtime dependency）、便於本機部署、且能輕易嵌入既有產品或工作流的原生組件。

儘管各個 repo 的實作細節相異，但它們共享相同的設計哲學：

1. 移除執行期的 Python 依賴。
2. 封裝為單一執行檔（single binary）、CLI、獨立伺服器或桌面應用程式。
3. 確保資料完全保留在本機端。
4. 允許開發者自由嵌入工作流，擺脫雲端平台的綁定。

因此，這篇文章的目的不單是介紹 trellis.cpp，而是想藉由這幾個專案，探討本地端 .cpp 生態的成長動機與架構定位。

這五個 .cpp 專案的架構定位

在評估這些專案之前，需要先釐清它們在技術棧中各自扮演的角色。

1. llama.cpp：本地 AI 生態的地基

在所有成員中，llama.cpp 無疑是整個生態的技術地基。

• repo：ggml-org/llama.cpp
• 建立時間：2023-03-10
• stars：約 121,230
• 授權：MIT
• README 載明：LLM inference in C/C++

如今的 llama.cpp 已大幅超越早期單純在終端機運作的範疇，README 中隨處可見其生態擴展：

• llama-cli 與 llama-server
• 主流的 GGUF 格式
• 相容 OpenAI 的 API 伺服器
• WebGPU 與瀏覽器端的支援
• 多模態模型支援

它確立了本地端 .cpp 專案的標準範本：專注於本機推論、定義統一量化格式、提供單一執行檔或函式庫，並讓下游開發者能輕鬆為其套上 UI、API 或包裝成應用程式。後續許多本機 AI 專案即使沒有直接繼承其程式碼，也都依循著相似的產品架構。

2. CrispASR：收斂語音技術的 C++ Runtime 樞紐

CrispASR 的定位是將繁雜的語音處理整合成單一執行期環境。

• repo：CrispStrobe/CrispASR
• 建立時間：2026-03-29
• stars：約 467
• 授權：MIT
• 最新 release：v0.8.20，發佈於 2026-07-21

README 開頭即宣告其設計目標：

• One C++ binary
• 43 ASR backends
• 48 TTS engines
• zero Python dependencies

它並非單純的 Whisper 封裝，而是提供了一套完整的語音處理樞紐，涵蓋語音辨識（ASR）、語音合成（TTS）、文本翻譯、語音對齊（forced alignment）以及 WebAssembly 編譯。

這項嘗試解決了過往語音工具鏈零碎化的痛點。以往 Whisper、TTS 與對齊工具各自獨立，各擁一套複雜的 Python 依賴；CrispASR 則嘗試將這些分散的語音能力收攏至單一的 C++ runtime。

3. stable-diffusion.cpp：擴散模型的本機原生組件

stable-diffusion.cpp 的發展軌跡早已超出最初的 Stable Diffusion 範疇。

• repo：leejet/stable-diffusion.cpp
• 建立時間：2023-08-13
• stars：約 6,562
• 授權：MIT
• 最新 release：master-782-b290693，發佈於 2026-07-16

README 的定位十分直接：

Diffusion model(SD,Flux,Wan,Qwen Image,Z-Image,...) inference in pure C/C++

該專案持續跟進最新的模型架構，目前已支援 SD1.x/2.x、SDXL、Flux、Wan 與 Qwen Image 等，並內建網頁 UI。

如果說 llama.cpp 負責語言模型的本地原生化，stable-diffusion.cpp 便是影像生成領域的對應實作。這也解釋了為何 trellis.cpp 會在其文件中提到，可搭配 stable-diffusion.cpp 生成前置圖像，再串接後續的 3D 生成管線。

4. trellis.cpp：將 2D 轉 3D 納入原生管線

作為這次討論的焦點，trellis.cpp 的出現填補了本地端資產生成的重要缺口。

• repo：pwilkin/trellis.cpp
• 建立時間：2026-06-28
• stars：約 202
• 最新 release：v0.5.3，發佈於 2026-07-21
• GitHub metadata 的 license 目前為 null

README 的規格描述相當明確：

• TRELLIS.2-4B image-to-3D pipeline
• all in native C++/GGML
• no Python at runtime
• 提供 trellis-server 與 Trellis Studio

這個專案的實質意義，在於將原本高度依賴研究環境與 PyTorch/Python 工具鏈的 2D 轉 3D 技術，成功移植到本機原生執行環境中。同時，它也提供常駐的 HTTP 伺服器、桌面應用程式、下載腳本與權重預覽工具，大幅降低了技術整合的門檻。

5. KoboldCpp：本地多模態整合與應用入口

與前述專案相比，KoboldCpp 的性質更偏向應用端的整合。

• repo：LostRuins/koboldcpp
• 建立時間：2023-03-16
• stars：約 11,131
• 授權：AGPL-3.0
• 最新 release：v1.117.1，發佈於 2026-07-09

README 開頭指明了其設計定位：

• 它是 single self-contained distributable（單一獨立分發包）
• 基於 llama.cpp（builds off llama.cpp）並進行大量擴充

它不再只是單純的 LLM 介面，而是打包了文字生成、影像生成/編輯、語音辨識與合成、音樂生成、視覺模型、MCP 伺服器支援以及各類相容 API。

相較於專注在推論底層的 llama.cpp，KoboldCpp 扮演的角色是將這些零散的本地端能力封裝成一個開箱即用、功能齊全的應用程式入口。

為什麼 .cpp 路線能持續擴張：五個實質優勢

這類原生專案之所以能獲得社群青睞，背後有其核心的工程價值。

1. 擺脫 Python 依賴，大幅簡化部署環境

傳統 AI 專案最難處理的往往不是模型本身，而是繁雜的執行環境：不同版本的 Python、CUDA 與 PyTorch 版本的相容性、容易衝突的 pip 套件等。.cpp 路線將推論主幹收攏為單一執行檔、靜態庫或獨立伺服器，移除了執行期的 Python 環境要求，使軟體分發變得乾淨許多。

2. 便於封裝為可控的本機服務

觀察這五個專案，會發現它們都具備明確的服務化傾向（例如 llama-server、trellis-server 等）。這意謂著它們的設計目標不僅是 CLI 工具，而是要成為能被其他應用程式、Agent 或工作流呼叫的本地後端服務。

3. 保障資料隱私與控制權

當語言模型、語音處理、圖像生成與 3D 轉換全部改在本地端執行時，使用者的提示詞、音訊和影像資料便無須上傳至第三方雲端平台。對於重視資安、網路延遲與資料合規性的場景而言，這是極為關鍵的考量。

4. 提升可攜性，無須綁定容器技術

雖然 Docker 能解決環境問題，但 .cpp 專案追求的是更直接的可攜性。藉由單一執行檔或獨立分發包的形式，開發者無須安裝 Docker 或配置複雜的容器環境，就能直接將 AI能力交付給終端使用者。

5. 組件原生化，促進本機生態鏈的串聯

當各個領域的 AI 工具都具備了本機執行檔或輕量伺服器的特性時，彼此之間的串接與組合難度將大幅降低。例如，開發者可以先用 stable-diffusion.cpp 產生影像，隨即送入 trellis.cpp 轉為 3D 模型，再透過 llama.cpp 進行邏輯控制，並以 CrispASR 處理語音互動。這種純本地的 AI 工具鏈組合，在以往是難以想像的。

原生 C++ 路線面臨的限制與挑戰

儘管優勢顯著，但在評估是否採用這套方案時，也必須權衡其隨之而來的代價。

1. 「免 Python」的定義與邊界

以 trellis.cpp 為例，文件載明的是「執行期免 Python」（no Python at runtime），這並不代表專案的完整開發與訓練工具鏈完全不含 Python。在評估這類專案時，須區分是「推論管線免 Python」還是「整個專案庫皆無 Python」。

2. 依然存在高硬體與模型權重需求

移除 Python 執行期只能精簡環境依賴，並不會縮小模型本身的檔案體積。例如 trellis.cpp 在安裝時仍需下載約 16.5 GB 的權重檔，本機端依然需要配置相應的 GPU 資源，這並非輕量化的軟體。

3. 一鍵安裝腳本的安全風險

許多專案為了降低門檻而推行一鍵安裝指令（例如透過 curl 管道執行 shell 腳本）。這類便利性背後依然存在著供應鏈安全考量，使用者仍須信任安裝腳本、預編譯執行檔以及外部權重來源的安全。

4. 各專案在架構上的層級差異

這五個專案雖常被歸在同一類別討論，但在技術架構上並不對等。llama.cpp 屬於底層推論基底，stable-diffusion.cpp、trellis.cpp 與 CrispASR 屬於單一功能的 runtime，而 KoboldCpp 則屬於應用整合層。在規劃系統架構時，不應將它們視為互為替代的同質組件。

總結

簡而言之，這波 .cpp 生態的崛起並非單純出於對 C++ 語言的偏好，而是社群試圖將過去散落在 Python 腳本、雲端 API 與學術論文中的 AI 能力，重塑為更容易本機部署、打包且可自由嵌入工作流的原生軟體組件。

當語言、聲音、影像、3D 生成乃至多模態入口都逐漸具備了原生組件，未來的關注焦點將不僅是單一專案的效能提升，而是這些本機端組件如何更流暢地協同運作，建構出完整的本地 AI 應用生態。

參考資料

1. ggml-org/llama.cpp GitHub metadata 與 README
2. CrispStrobe/CrispASR GitHub metadata 與 README
3. leejet/stable-diffusion.cpp GitHub metadata 與 README
4. pwilkin/trellis.cpp GitHub metadata 與 README
5. LostRuins/koboldcpp GitHub metadata 與 README