本週的 GitHub 熱門專案呈現出一條相當清晰的主線，就是「把尖端大模型塞進手邊既有硬體」。隨著 Moonshot AI 釋出 2.78 兆參數的 Kimi K3 開放權重，社群在短短兩週內就長出三套截然不同的推論引擎，分別以純 C 實作、NVMe 權重串流與極致記憶體壓縮的路線，試圖讓原本需要整櫃 GPU 才能載入的模型，在單台工作站甚至單顆 CPU 上跑起來。另一條主線則是 AI 資安研究工具的產品化，OpenAI 推出官方資安掃描 CLI，開源社群也同步端出可自架的漏洞研究平台。此外，文件轉換管線與多人代理工作平台的成熟，也顯示開源生態正在補齊 AI 落地的最後一哩路。
CyberQ 彙整了本週值得關注的八個重點專案如下。
兆級參數的開放權重模型 MoonshotAI/Kimi-K3
專案連結：https://github.com/MoonshotAI/Kimi-K3
Moonshot AI 以「Open Frontier Intelligence」為定位釋出的 Kimi K3，是本週整個開源生態熱門的焦點之一。這個 MoE 架構模型擁有 2.78 兆參數，官方發佈的權重檔案佔用約 1.42 TB 空間，規模已經超越多數企業自建機房的單機承載能力。真正值得注意的並非模型本身的評測分數，而是它在開放權重之後所引發的連鎖效應。當一個尖端等級的模型不再被 API 圍牆鎖住，社群立刻把火力集中在推論工程上，短時間內就出現多套針對消費級硬體最佳化的執行方案。對企業而言，這意味著地端部署尖端模型的技術門檻正在快速下降，資料主權與模型能力之間的取捨空間，比過去寬鬆許多。
把儲存視為推論階層的純 C 引擎 JustVugg/colibri
專案連結：https://github.com/JustVugg/colibri
Colibrì 以「Tiny engine, immense model」為口號，主張把儲存裝置、系統記憶體與顯示卡記憶體視為單一的推論階層，也就是所謂的 AI 記憶體多層化（AI memory multitiering）。它以純 C 撰寫且不依賴任何推論框架，目前已支援 GLM-5.2（744B）、Inkling（975B）、Kimi K3（2.8T）、DeepSeek V4 Flash（284B）與 OLMoE（7B）等五個模型家族，每個模型對應單一 C 檔案，並共用同一套 coli chat、coli serve 與 coli web 前端。這個設計思路對於已經建置高速儲存架構的環境特別有意義，因為推論效能的瓶頸從「顯示卡記憶體夠不夠」轉移到「儲存 I/O 夠不夠快」，讓 NVMe 陣列與高速網路儲存的投資，第一次能夠直接轉換為模型執行能力。專案同時提供繁體中文說明文件，對台灣使用者相當友善。
權重感知的串流推論引擎 sqliteai/waste
專案連結：https://github.com/sqliteai/waste
WASTE 全名為 Weight-Aware Streaming Tensor Engine，是一套以 C 撰寫、可嵌入且無第三方執行期依賴的推論引擎。它的核心策略是將模型主幹常駐於記憶體，僅把被啟動的專家（expert）從磁碟串流讀入，並以剩餘記憶體作為有界的專家快取。官方實測顯示，完整的 2.78 兆參數 Kimi K3 可在一台 64 GB 記憶體的 MacBook Pro 上執行，速度約為每秒 0.6 個 token，轉換後的 WASTE 容器檔案約 982 GB。專案明確強調這是完整模型而非蒸餾或剪枝版本，這一點在評估地端部署品質時相當關鍵。專案團隊也坦承程式碼主要由大型語言模型撰寫，人類負責構想、假設、優先順序與決策，這種開發模式本身就值得資訊部門觀察。對於已經建置 NVMe 儲存池的環境而言，WASTE 提供了一條相當務實的驗證路徑。
單顆 CPU 執行兆級模型 FareedKhan-dev/kimi-k3-in-c
專案連結：https://github.com/FareedKhan-dev/kimi-k3-in-c
Colibrì 與 WASTE 展示的是工程可行性，這個專案展示的則是極限。作者以可攜式 C99 實作 Kimi K3 推論，整個引擎僅 176 KB，不使用 BLAS、不依賴任何框架、也不需要 GPU，實測峰值常駐記憶體僅 8.24 GB，而磁碟上的檢查點檔案則有 1.56 TB。換句話說，一台完全沒有加速卡的一般伺服器，理論上就能得到與大型叢集相同的模型輸出結果，差別僅在於速度。這項成果的意義在於徹底切斷了「模型規模」與「硬體門檻」之間的必然關聯，對於預算受限的研究單位、離線環境或高度敏感的內網部署場景，提供了一個過去難以想像的選項。專案採用 Apache-2.0 授權，商業評估上的顧慮也相對較低。
官方推出的資安掃描工具鏈 openai/codex-security
專案連結：https://github.com/openai/codex-security
OpenAI 推出的 Codex Security 是一套用於發現、驗證與修復程式碼安全漏洞的 CLI 與 TypeScript SDK。它支援深度掃描模式、可自訂掃描提示詞檔案，並能設定平行工作程序與子代理數量，設計上明顯是針對可整合進 CI/CD 管線的自動化情境。值得注意的是，部分資安請求與受保護的掃描結果需要透過 Trusted Access for Cyber 申請權限才能取得，這反映出模型供應商在攻擊性資安能力上採取的分級管控策略。此外，工具也支援切換至其他推論供應商，避免完全綁定單一模型。對於正在建立安全開發生命週期的團隊，這類官方工具的出現，代表 AI 輔助的原始碼安全審查已經從實驗階段進入可導入評估階段。
可自架的 AI 漏洞研究平台 Kritt-ai/open-kritt
專案連結：https://github.com/Kritt-ai/open-kritt
open·kritt 定位為開源、可自架的資安與漏洞研究平台，核心能力是編排多個 AI 代理進行程式碼分析，並將分析結果轉換為去重複化、可排序的發現清單，同時提供可設定的驗證與資訊強化流程。相較於直接把整份原始碼丟給模型的粗略做法，它建立了一套工作流程建構機制，讓研究人員能明確定義分析範圍、驗證條件與輸出格式，大幅降低誤報帶來的人力耗損。專案採用 AGPL-3.0 授權並提供完整文件與研究論文，自架特性也讓內部原始碼不必離開組織邊界，這對於受法規約束的產業相當重要。open·kritt 與 Codex Security 形成的商業與開源對照組，正是本週資安領域最值得觀察的動態。
毫秒級的文件轉 Markdown 管線 firecrawl/anydoc
專案連結：https://github.com/firecrawl/anydoc
anydoc 是 Firecrawl 以 Rust 撰寫的文件轉換函式庫，能將 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV 與 PDF 轉換為乾淨的 GitHub-Flavored Markdown，官方宣稱轉換耗時為個位數毫秒等級，並提供 Node.js、Python 與 WebAssembly 綁定。在 RAG 與代理式工作流程中，文件前處理往往是最容易被低估卻最常出問題的環節，格式不一致、表格結構破碎與編碼錯亂都會直接汙染後續的檢索品質。anydoc 的價值在於不論輸入何種格式，輸出結果都保持一致。專案同時以 Agent Skill 形式發佈，可直接掛載到現有的代理工具鏈。瀏覽器示範頁面透過 WebAssembly 在本地完成轉換，檔案不會離開使用者裝置，對於處理內部機敏文件的情境是相當實用的設計。
為團隊而生的多人代理工作平台 yc-software/qm
專案連結：https://github.com/yc-software/qm
QM 將自己定位為「multiplayer agent harness」，也就是可供整個團隊共用的代理工作平台，同時支援 Slack 與網頁介面。它的設計前提是：多數代理工具都以個人助理的模式打造，硬要擴展到整間公司就會迅速失控。QM 的做法是讓每位成員擁有獨立的工作空間，各自持有專屬的記憶、檔案、金鑰檢視範圍、權限、排程任務與持久化沙箱，同時又能在頻道、群組訊息與專案中協同作業。管理端則可設定組織層級的資安態勢，以及允許使用的 harness 與模型清單。更重要的是，Pi、OpenCode、Codex 與 Claude Code 都能驅動同一套核心，讓部署不至於綁定單一供應商。對於正在思考如何把 AI 代理正式納入內部流程、又必須兼顧權限治理與稽核要求的資訊單位，這個架構思路值得參考。
趨勢總結
CyberQ 綜觀本週 GitHub 熱門專案，最具指標意義的變化在於推論工程的典範轉移。當 Colibrì、WASTE 與 kimi-k3-in-c 不約而同地把儲存裝置納入記憶體階層，「顯示卡記憶體容量決定模型上限」這個沿用多年的假設已被正式挑戰，取而代之的是儲存頻寬、快取命中率與 I/O 排程等更接近傳統系統工程的課題。這對於長期投資高速儲存與網路架構的組織是明確的利多，過去閒置的基礎設施能力，正在轉化為實質的 AI 執行能力。
在資安層面，官方工具與開源平台同時到位，代表 AI 輔助的漏洞研究已具備進入正式流程的條件，但供應商對攻擊性能力的分級管控也提醒我們，這類工具的取得與使用本身就需要納入治理規範。而 anydoc 與 QM 所補上的文件管線與權限治理，則是多數組織在導入代理式工作流程時最容易忽略、卻最先踩雷的兩塊拼圖。
刊期異動預告
自下一期起，GitHub 趨勢周報將調整刊出時間，由原本的週一改為每週五發佈。此調整是為了讓統計區間更貼近完整的工作週，避免週末的專案動態被切分到不同期別，也讓讀者能在週末之前掌握該週的開源生態全貌。相關的 AI 趨勢週報與其他固定專欄刊期不受影響，仍依原排程刊出。
我們下一期週五再見。
