WASTE 推論引擎：在消費者硬體上執行 Kimi K3 2.78T

WASTE（Weight-Aware Streaming Tensor Engine）使得在消費者硬體上執行前沿規模模型成為可能，特別是 2.78 兆參數的 Kimi K3，透過直接從 NVMe 儲存裝置串流已啟用的權重。它允許 Kimi K3 在僅有 29.05 GB 記憶體的機器上運行，並在 64 GB 的 MacBook Pro 上達到約每秒 0.5 個 token 的解碼速度。

架構：NVMe 串流與權重管理

WASTE 透過將磁碟視為模型 Mixture of Experts（MoE）權重的主要儲存空間，僅將模型主幹保留在記憶體中，克服了消費者硬體的記憶體限制。

權重感知串流

由於 Mixture of Experts 模型在每個 token 只會啟用少量參數（K3 約為 4%），WASTE 只會從磁碟串流每個 token 所需的專家。為了減少 I/O 開銷，模型會被轉換成 .waste 容器，且每個專家記錄皆以 4 KiB 對齊。此布局確保路由至專家時僅需一次 pread 操作，並使用 F_NOCACHE（macOS）、O_DIRECT（Linux）或 FILE_FLAG_NO_BUFFERING（Windows）繞過作業系統頁面快取，以防止核心嘗試快取兆級模型。

殘差向量量化（RVQ）

為了降低磁碟佔用空間與 I/O 帶寬需求，專家以三階段的殘差向量量化方式儲存，量化率為每個權重 3.00 位元。引擎直接在這些量化權重上執行算術運算，而不需要實體化完整矩陣，將每個專家列的運算縮減為三次表格讀取與兩次加法。

記憶體預算與「快取底線」

WASTE 利用剩餘的 RAM 作為受限的專家快取。引擎會識別一個「快取底線」——即容納單一 token 工作集所需的最小 RAM（K3 為 17.0 GB）。

• 低於底線： 快取命中率為 0%，因為專家在下一個 token 請求之前就已被驅逐。
• 高於底線： 命中率急速上升，提升吞吐量。
• 分頁上限： 若 RAM 預算設定過高（例如在 64 GB 機器上設定為 58 GB），作業系統會將專家快取分頁至磁碟，導致效能大幅下降（從 0.32 tok/s 降至 0.04 tok/s）。

為避免此情況，WASTE 會自動計算一個低於實體 RAM 七分之八的預算，並以完整工作集為單位遞減，以最大化效能且不觸發作業系統分頁。

效能基準

基準測試在配備 64 GB 記憶體與內建 NVMe SSD 的 MacBook Pro M5 Pro 上執行。

Kimi K3（2.78T 參數）

指標	數值
最小記憶體	29.05 GB (at 4K context)
容器大小	982 GiB
解碼速度	0.49–0.54 tok/s
常駐主幹	27.28 GB
每 Token 讀取	17.0 GB
視覺塔	15.7 s for 1024-patch image

Kimi-Linear（48B 參數）

指標	數值
最小記憶體	1.87 GB
容器大小	19 GB
解碼速度	10.7 tok/s

技術實作細節

線性注意力與 KV 快取最佳化

K3 採用混合注意力機制（Kimi Delta Attention 與門控多頭潛在注意力）。WASTE 將 kv_b_proj 吸收到 query 與 output 中，使 KV 快取大小縮減 53 倍。在 4K 上下文下，快取需求從 11.25 GB 降至 0.21 GB，讓受限硬體上能使用顯著更長的上下文視窗。

引擎規格

• 語言： 使用 C11 編寫，無第三方執行時相依性（僅 libc 與 pthreads）。
• 可嵌入性： 引擎以函式庫 (libwaste.a) 形式提供，包含 26 個公開函式，能完整嵌入其他應用程式。
• 多模態支援： 包含 401M ViT（27 層）用於影像處理。影像會被轉換為嵌入向量，並在 MoE 層中作為文字 token 處理。
• 平台支援： 支援 macOS（ARM64）、Linux（ARM64/x86_64）以及 Windows（x86_64 via MinGW-w64）。

社群見解與反駁

雖然在筆記型電腦上執行 2.78T 模型的技術成就相當顯著，社群討論卻指出了多項實務上的權衡：

"在 0.5t/s 且每秒從 SSD 讀取大量 GB 的情況下……我在想如果目標是 500GiB 或 250GiB 的模型，這是否真的實用..."

批評者指出每秒 0.5 個 token 的速度對實務使用而言極為緩慢，尤其是像 K3 這類常常產生大量文字的「思考」模型。其他人則提到相較於 GPU 叢集，每個 token 的能源成本較高，且需要巨大的儲存空間（1 TB），成為許多消費者使用的門檻。