當大型模型開始負責處理 Mac 上的私人檔案與應用程式，本地推論速度就不再只是開發者實驗的指標。Perplexity 開源嘅 pplx-garden 入面，Lily 以工具項目形式處理 Apple Silicon 上 Qwen3.6-35B-A3B 的推論，目標係令提示詞處理及文字生成更快，並透過 OpenAI-compatible HTTP API 串接聊天流程。
Lily 唔似 MLX-LM 般追求支援多款模型，而係集中服務 Qwen3.6-35B-A3B：Rust runtime 負責載入 checkpoint、管理 session state 同生成迴圈，自訂 Metal kernels 就處理模型特定運算。呢種單一進程、模型與 runtime 共同協調嘅做法，減少通用 kernel 帶來嘅額外調度，亦避開 PyTorch 和 MLX execution path。
pplx-garden 不只是 Mac 本地推論工具。fabric-lib 提供 RDMA TransferEngine，同時涵蓋 P2P MoE dispatch 與 combine kernel；pplx-unigram 則係針對 Unigram tokenizer 嘅 CPU encoder。相關內容亦包括 trillion-parameter model 喺 AWS EFA 上嘅部署，以及 RL post-training 權重轉移、分離式 prefill 和 decode 等系統研究，顯示儲存庫涵蓋由裝置端推論到分散式 LLM infrastructure 嘅多個瓶頸。
適合需要喺 Mac 處理敏感資料、又希望保留本地生成能力嘅開發者及研究團隊；需要 RDMA、MoE 溝通或 tokenizer 優化嘅系統工程人員亦可參考相關元件。現有資料集中講述 Lily 分別量度 prefill throughput 同 decode throughput。
重點摘要：
– Lily 專為 Apple Silicon 與 Qwen3.6-35B-A3B 設計，支援 OpenAI-compatible HTTP API。
– 以 Rust runtime 配合自訂 Metal kernels，分開處理 prefill 同 decode。
– 不經 PyTorch 或 MLX execution path，代價係模型及硬件支援範圍較專門。
– fabric-lib 同 p2p-all-to-all 面向 RDMA、MoE dispatch 與 combine 等分散式推論問題。
– 效能應按裝置、上下文及生成負載實測，不能只依賴官方定位作比較。
