Chitu 赤兔：以 chitu.run 單檔啟動與異構算力適配為核心的推理框架
High-performance inference framework for large language models, focusing on efficiency, flexibility, and availability.
秒懂
- 它是什麼？
- 赤兔把部署入口收斂成一個 chitu.run 可執行檔，並把適配範圍鋪到 NVIDIA、昇騰、沐曦、海光、摩爾執行緒等硬體。它的價值在硬體覆蓋與部署形態，風險則在文件深度與長期維護承諾。
- 適合誰用？
- 如果你手上是昇騰 910B、沐曦、海光或摩爾執行緒這類非 NVIDIA 卡，又需要 PD 分離或多實例的部署形態，赤兔值得進入試用名單，先從 Releases 的 Assets 下載 chitu.run，對照 docs/zh/DEVELOPMENT.md 與 SUPPORTED_MODELS.md 確認你的模型與卡型是否在列。若你只要在單一 NVIDIA 卡上跑一個主流模型、且重視社群範例數量與第三方整合生態，赤兔目前的文件與社群規模不佔優勢，改用 vLLM 或 SGLang 的摩擦會更小。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 6 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
赤兔要解的是「同一份模型跑在多種國產與 NVIDIA 卡上」這件事
多數推理框架的預設路徑是 NVIDIA GPU，算子、量化與並行策略都繞著 CUDA 生態設計。企業採購時若手上已經有昇騰、沐曦、海光或摩爾執行緒的機器，通常得自己補算子、改通訊層，或退回 CPU 推論。赤兔把這件事當成主線任務，README 的里程碑列出 v0.4.0 適配昇騰、NVIDIA、沐曦、海光，v0.5.1 再適配摩爾執行緒，v0.3.5 提供昇騰 910B 的完整原生支援。它的目標讀者是需要在異構機房裡部署大模型的團隊，而不是只有單一 A100 或 H100 叢集的實驗室。
另一條線是部署形態的伸縮。README 把「全場景可伸縮」寫成從純 CPU、單 GPU 到叢集部署，v0.2.2 加入 CPU+GPU 異構混合推理，並宣稱可單卡推理 DeepSeek-R1 671B。這個組合對顯存不足但記憶體充足的機器有意義，代價是 CPU 與 GPU 之間的資料搬移會壓低吞吐。赤兔沒有把這條路徑包裝成等價替代，讀者也不該把它當成免費的顯存擴充。
chitu.run 把多節點與 PD 分離收進單一執行檔
v0.6.0 的里程碑寫得很直接：新增 chitu.run 可執行檔，單檔即可啟動多結點、多實例、PD 分離等複雜任務。這是赤兔在部署層最明顯的設計選擇。傳統做法是先用 pip 安裝框架，再寫一份啟動腳本，把張量並行度、節點位址、prefill 與 decode 的角色分工逐項配置；赤兔把這些收斂到一個可執行檔，並要求使用者從 Releases 的 Assets 頁面下載，而不是走套件管理器。
PD 分離（prefill 與 decode 拆到不同實例）本身不是新概念，差別在於赤兔把它列為 chitu.run 的一級啟動情境，與多節點、多實例並列。README 沒有在這一層展開參數細節，實際的旗標與設定鍵要回到 docs/zh/DEVELOPMENT.md。這種「入口極簡、細節外移」的做法讓首次啟動變快，卻也讓排查變得依賴文件：當 chitu.run 啟動失敗時，錯誤訊息能否指向具體的節點或角色，決定了這個設計是省事還是繞路。
量化路徑：FP4 與 FP8 的線上轉換是它早期的主要賣點
從 v0.1.0 起，赤兔就在處理 DeepSeek-R1 671B 的精度轉換：v0.1.0 提供 FP8 線上轉 BF16 的高效算子，v0.3.0 新增 FP4 線上轉 FP8、BF16 的高效算子，並對應 NVIDIA 的 DeepSeek-R1-FP4 量化版本。這條路線的實際意義是，使用者不必先把權重離線轉成框架偏好的格式，可以在載入階段完成轉換。
代價是啟動時間與峰值記憶體。線上轉換意味著載入時要多做一輪運算，模型越大越明顯，671B 這個量級的啟動成本不會是零。README 只說明有這些算子，沒有給出轉換耗時或額外記憶體佔用的數字，這部分需要自行量測。另一個容易被忽略的點是精度：FP4 轉 FP8 再轉 BF16 的鏈路中，每一步都可能引入誤差，赤兔把它描述為「高效算子實現」，但沒有在 README 層級說明精度損失的邊界。對精度敏感的任務，這是要自己驗證的項目。
模型覆蓋與硬體覆蓋是兩張不同的清單
README 提到支援 DeepSeek、Qwen、GLM、Kimi 等模型，並指向 docs/zh/SUPPORTED_MODELS.md 取得完整清單。這裡有個容易誤讀的地方：硬體適配與模型支援是兩份獨立的清單，兩者的交集才是你能用的組合。v0.3.9 特別標注「首發支持華為昇騰 910B 推理部署智譜 GLM-4.5 MoE 模型」，這種把特定卡型與特定模型綁在一起公告的寫法，說明適配工作確實是逐組合推進的。
所以看到「適配昇騰」不等於「你要的模型在昇騰上跑得動」。選型時應該先鎖定模型，再核對該模型在目標卡型上是否有對應的支援紀錄，而不是反過來。這一點在國產卡上尤其重要，因為算子覆蓋通常比 CUDA 路徑薄，MoE 架構又比稠密模型更容易踩到缺口。
安裝路徑與你該先讀的兩份文件
README 的安裝段落很短，建議使用 chitu.run 部署，並明確要求從 GitHub Releases 的 Assets 頁面下載，而不是 pip。完整說明則指向 docs/zh/DEVELOPMENT.md。這個安排意味著版本管理由你自己負責：升級時要重新下載對應版本的執行檔，並確認它與你的驅動、CUDA 或 CANN 版本相容。
目前的版本節奏可以從 Releases 看出：v0.5.6 在 2026 年 5 月 21 日、v0.5.7 在 6 月 4 日、v0.6.0 在 7 月 2 日，大約每兩到四週一個小版本。這種頻率對跟隨者是好消息，對已經上線的服務則是負擔：每次升級都要重新驗證模型輸出與延遲表現。專案最後一次推送時間為 2026 年 9 月 9 日，儲存庫未封存，維護仍在進行，但 README 也寫明受制於團隊成員精力，無法保證及時解決所有使用者問題，並提供 solution@chitu.ai 作為技術服務窗口。這句話應該被當成維護模式的說明，而不是客套話。
限制與不適用的場景
最直接的限制來自 README 自己：專案無法保證及時回應所有使用者的問題。對照 vLLM 或 SGLang 這類有大量第三方教學、託管服務與社群範例的專案，赤兔的公開資料明顯較薄。README 把效能數據指向 docs/zh/PERFORMANCE.md，並提醒數據與硬體配置、軟體版本、測試負載相關，多次測試結果可能存在波動。這個提醒合理，但也意味著你很難從公開資料直接推斷自己環境的表現。
其次是 CPU+GPU 混合推理這條路徑。它讓單卡跑 671B 成為可能，但 CPU 與 GPU 之間的頻寬是硬約束，適合的是低併發、對延遲不敏感的場景。若你的服務要承接穩定併發流量，這條路徑的吞吐不會接近純 GPU 部署。最後，chitu.run 以二進位形式分發，好處是環境依賴少，代價是你無法像安裝 Python 套件那樣直接檢視或修補原始碼；遇到問題時，能動的手主要是換版本、看文件、提 issue，或走技術服務管道。對需要自行打補丁的團隊，這是一個實質的取捨。
與 vLLM 的取捨：生態廣度對比硬體覆蓋
README 的致謝段落列出 DeepSeek、FlashAttention、FlashInfer、KTransformers、llama.cpp、SGLang、TensorRT-LLM、vLLM，並說明從這些專案學習並複用了部分函式。赤兔與 vLLM 的差異不在於誰的算子更快，而在於優先順序：vLLM 的預設路徑是 NVIDIA 生態，PagedAttention 與後續的排程機制在 CUDA 上最成熟，第三方整合與部署範例也最多；赤兔則把資源投在國產卡的適配與 chitu.run 這種部署入口的收斂上。
如果你的機器是清一色 NVIDIA，且團隊已經熟悉 vLLM 的取樣參數與部署腳本，換到赤兔的收益主要落在 PD 分離與多實例的啟動便利性，其他面向未必有明顯改善。反過來說，如果機房裡混著昇騰 910B、沐曦、海光與摩爾執行緒，vLLM 在這些卡上的支援需要逐項確認，赤兔的適配清單反而是它最實在的資產。這是一個按硬體組成決定的選擇，不是按框架名氣決定的選擇。
授權與升級成本
專案採用 Apache License v2.0，倉庫內另有 LICENSES/ 目錄收錄複用程式碼片段的授權資訊，third_party/ 目錄則包含遵循其他開源授權的第三方子模組，各自附有授權檔案。Apache-2.0 的專利授權與修改再散布條款對企業相對友善，但第三方子模組的授權不一定相同，若你要把赤兔打包進自家產品，需要逐項確認 third_party/ 與 LICENSES/ 下的條款，這部分請洽法務，本文不構成法律意見。
升級成本主要來自版本節奏與分發方式。從 v0.5.6 到 v0.6.0 大約六週，其中 v0.6.0 引入了 chitu.run 這個新的啟動入口，屬於會改變部署腳本的變動。由於安裝走 Releases 下載而非套件管理器，建議在內部保存每個已驗證版本的執行檔與對應的 DEVELOPMENT.md 快照，升級時先在小流量環境比對輸出與延遲，再推廣到正式服務。這個流程不需要新工具，只需要把版本號與執行檔一起納入版控。
編輯結論
如果你手上是昇騰 910B、沐曦、海光或摩爾執行緒這類非 NVIDIA 卡，又需要 PD 分離或多實例的部署形態，赤兔值得進入試用名單，先從 Releases 的 Assets 下載 chitu.run，對照 docs/zh/DEVELOPMENT.md 與 SUPPORTED_MODELS.md 確認你的模型與卡型是否在列。若你只要在單一 NVIDIA 卡上跑一個主流模型、且重視社群範例數量與第三方整合生態，赤兔目前的文件與社群規模不佔優勢，改用 vLLM 或 SGLang 的摩擦會更小。動手前先驗證三件事：你的模型是否出現在 SUPPORTED_MODELS.md、你的卡型是否在已公告的適配清單內、以及 chitu.run 在該版本是否涵蓋你要的 PD 分離或 CPU+GPU 混合模式。這三項只要有一項落空，後續調優都無從開始。
社群筆記