Cognitora
Cognitora · 程式設計
Cognitora 是一套開源的推論協作平台，能把多個大型語言模型引擎協調成單一分散式叢集。它不會取代你的引擎，而是架在 vLLM、SGLang、llama.cpp、MLX 以及任何相容 OpenAI 的伺服器之上，接著把請求送往正確 KV 快取已經所在的節點。它的目標族群是自行運行 GPU 的團隊，從桌面上兩三台機器到混雜的資料中心機隊都涵蓋，並以六個靜態執行檔的形式發布，一行 curl 就能安裝。
關於 Cognitora
Cognitora 是什麼
Cognitora 是自架的 LLM 推論協作控制層。你保留自己已經信任的引擎，把難處理的部分交給 Cognitora：跨多台機器的路由、快取放置、健康狀態、電力與可觀測性。專案以 Rust 撰寫，定位為 NVIDIA Dynamo 這類協作器的直接替代方案，引擎涵蓋範圍更廣，部署策略也以裸機優先。六個執行檔。一個控制層。
它解決的主要問題是碎片化。一支機隊最後往往在不同硬體上跑著不同引擎，而單純的負載平衡器即使某台機器已經握有相關快取，仍會把請求送到隨機節點。Cognitora 加入 KV 感知路由，讓請求落在記憶體所在之處。這能減少重複的 prefill 工作，並讓尾端延遲維持穩定。它也會追蹤每 token 能耗，這是多數協作器忽略的細節。
把它想成一個永遠不會把你綁死在 vLLM 上的 vLLM 協作器。最需要事先評估的限制是規模。Cognitora 坦白說明，它的強項是異質、節能且維運負擔輕的推論，而非 NVL72 等級的超大型部署，部分進階的分層快取與拓撲功能也還在開發藍圖上。如果你今天就需要請求的即時遷移或 GPU 對 GPU 的權重串流，較重的技術堆疊可能更合適。對其他人來說，輕量正是重點。
開始使用
- 在 Linux 上用單一 curl 指令安裝執行檔，若你在 macOS 則用 cargo 從原始碼建置。
- 用
cgn-ctl pki bootstrap初始化本機 PKI 檔案，再決定是否要求 mTLS。 - 用
cgn-ctl key create簽發一把權限受限的 API 金鑰。 - 寫一份簡短的
cognitora.toml，為叢集命名、指向你的模型，並設定路由器的 HTTP 與 gRPC 連接埠。 - 啟動
cgn-router，把引擎驅動指向真實後端，再用 OpenAI SDK 查詢，確認 token 能端到端串流。
產品資訊
快速了解 Cognitora 的定價、支援平台與效能。
適合對象
這項工具最適合的使用者、任務與情境。
使用者
- ML 平台工程師：已經在運行 GPU 機隊，想要單一控制層而非自製排程器的人，前提是他們對設定檔與 systemd 不陌生。
- 新創基礎架構團隊：負擔不起專職協作小組，卻仍需要在幾台機器之間做到 KV 感知路由的小型團隊。
- 硬體混雜的研究實驗室：同時並用 NVIDIA 與 Apple Silicon 的團隊，因為 Cognitora 把兩者都當成第一級節點。
任務
- 讓同一個模型跑在多個引擎上：你可以在 vLLM、SGLang 與 llama.cpp 上提供同一個模型，讓路由器把流量放到快取還熱的節點。
- 降低 prefill 成本：KV 感知路由會把重複請求送到已持有情境的節點，於是你不再重算同一個提示。
- 追蹤每 token 電力：內建儀表板會回報機隊電力與每 token 能耗，當電費是實打實的支出時特別有用。
- 快速架起示範叢集：假引擎煙霧測試能在單一主機上，約五分鐘內從零進展到 token 串流。
情境
- 16 節點的混雜機隊滿載運作：專案自身的範例同時運行 H100、H200、A100、MI300X、L40S 與 A10 顯示卡，供應五個模型。
- 桌面規模的實驗：兩三台 DGX Spark、AMD 主機或 Mac Studio 放在同一個機架上，不需要 Kubernetes。
- 正式環境的 Kubernetes 部署：想要 Cognitora 管理 pod 而非 systemd 單元時，再加入 operator。
- prefill 與 decode 分離：想把同一批 GPU 榨出更多效能時，把兩個階段拆到不同的資源池。
主要功能
引擎無關的協作
Cognitora 不取代你的推論引擎，而是把多個引擎協調成一個叢集。任何提供 OpenAI HTTP 介面的後端都能加入，專案也內建 vLLM、SGLang、llama.cpp、MLX 與 TensorRT-LLM 的驅動。混雜硬體是常態。這代表你可以讓跑 vLLM 的 NVIDIA 節點與跑 MLX 的 Mac Studio 並存，並仍把它們視為同一支機隊。
KV 感知路由
路由器會追蹤 KV 快取所在位置，據此放置每個請求。如果某個節點已經持有重複提示的情境，請求就送往那裡，而不會在別處觸發全新的 prefill。整個訣竅就在這裡。為什麼重要？對帶有冗長共用系統提示的聊天與代理工作負載來說，這是最能直接減少無謂算力的功能。而且省下來的量累積得很快。
prefill 與 decode 分離
Cognitora 的架構核心，就是把 prefill 與 decode 拆到不同的資源池。你可以讓部分機器專門處理提示，其他機器專門生成 token，再讓路由器與 KV 快取在兩者之間搬遷工作。把階段拆開。專案也支援跨 RAM 與 SSD 的多層 KV 儲存，以容納更大的快取。
裸機優先部署
整套系統以六個靜態執行檔安裝，只需一行 curl，並在 systemd 下運行，流程中沒有 Python 控制層。這就是裸機 LLM 叢集的一句話寫照。只有當你真的想要 pod 層級的協作時，才需要加入 Kubernetes operator，因此兩台桌機也是正當的目標。
零相依的機隊儀表板
儲存庫內附一個獨立的儀表板，是單一靜態 HTML 檔，直接讀取 Prometheus 的 /metrics 端點。它會顯示即時每秒請求數、每秒 token 數、延遲與 TTFT 百分位、佇列深度、各節點狀態、KV 快取使用率、機隊電力與每 token 能耗。不用 Grafana。不用後端。
節能排程
Cognitora 把電力納入放置決策，並回報整支機隊的每 token 能耗。在混雜的 GPU 組合上，這讓維運者看出哪些節點的每瓦 token 產出最多，並把工作導向那些節點。電力就是錢。當電費是你自己付的時候，這點很重要。
開源且可檢視
專案在 GitHub 上以活躍的儲存庫持續開發，因此每一個路由決策、驅動與設定選項都能公開檢視。它能當成完全開源的推論伺服器使用。無法把推論流量送往封閉第三方服務的團隊，可以讀程式碼、分支它，並把整個控制層當成自架 AI 機隊來運行。
優缺點
優點
- 引擎無關的設計讓你保留現有的 vLLM、SGLang 或 llama.cpp 環境，不必重寫。
- KV 感知路由減少重複的 prefill 工作，反映在更低的成本與更穩定的尾端延遲上。
- 裸機優先的安裝讓兩台機器的配置變得實際可行，而不是 Kubernetes 產品的降級示範。
- 內建儀表板涵蓋延遲、每秒 token 數、KV 使用率與每 token 能耗，無需額外工具。
- 以 Rust 撰寫且沒有 Python 控制層，執行時的足跡因此保持精簡。
缺點
- 原生分層區塊管理器與拓撲感知的整批排程等進階功能尚未到位，因此 NVL72 等級的超大型機隊需要另一套技術堆疊。
- 安裝流程預設你熟悉設定檔、PKI 初始化與 systemd，這把非技術使用者排除在外。
- macOS 只能透過從原始碼建置運作，因此多數 Mac 使用者無法用一行安裝指令。
- TensorRT-LLM 支援目前仍是沒有預設配方的 spawn 驅動，這條路需要更多手動處理。
常見問題
Cognitora 把多個 LLM 推論引擎協調成單一分散式叢集。你可以用它跨節點路由請求、把工作放到 KV 快取已所在之處，並從單一控制層觀察整支 GPU 機隊的健康狀態與耗電。
相關內容
探索與 Cognitora 相關的工具、技能與文章。
Cognitora 替代方案
Forefront
Forefront · 程式設計Forefront 是一個用來打造開源 AI 的網頁平台。你可以用自己的資料微調主流的開源語言模型、評估它們的表現，再透過 API 執行，或匯出後自行架設。想要封閉式平台的便利、卻堅持要自己擁有模型與資料的開發者，就是這裡的目標客群。
Startkit
StartKit.AI · 程式設計Startkit 是一套用來打造 AI SaaS 與 AI 包裝產品的樣板。可以把它想成一個 AI 新創樣板，把枯燥的部分都先接好了：驗證、Stripe 與 Lemon Squeezy 付款、用量限制、交易型電子郵件，以及一套能與 OpenAI、Anthropic、Groq 或 Llama 溝通的 AI API 啟動套件。你複製儲存庫、設定價格，然後專心在產品中使用者真正願意付費的部分。它建構於 React 與 Tailwind 之上的 Next.js，所以大部分的樣板程式碼對你來說並不陌生。
Testim
Tricentis · 程式設計Testim 是專為網頁、行動與 Salesforce 應用程式打造的 AI 測試自動化平台，用來建立並執行端到端測試。它靠機器學習在介面變動時維持測試穩定，團隊因此少花時間修補壞掉的定位器。對於一款今天就能開始使用的自動化測試工具來說，這表現不算差。你透過在瀏覽器錄製動作來建立測試，需要更多控制時再補上 JavaScript。對忙碌的 QA 團隊來說，這是個可靠的選擇。