解析】Deltafin如何在M1 Max上運(yùn)行2.8T參數(shù)模型)
文章目錄Kimi K3極限部署技術(shù)解析Deltafin如何在M1 Max上運(yùn)行2.8T參數(shù)模型一、引言二、為什么 2.8T 參數(shù)通常裝不進(jìn) M1 Max2.1 Kimi K3 的“大”與“稀疏”同時(shí)存在2.2 權(quán)重規(guī)模決定傳統(tǒng)加載方式失效三、縱向演進(jìn)本地推理從模型壓縮走向權(quán)重流式化四、核心機(jī)制把 1.56TB 權(quán)重拆成主干與專家池4.1 兩類權(quán)重兩種訪問規(guī)律4.2 完整數(shù)據(jù)路徑五、逐 token 執(zhí)行從路由到下一詞5.1 一次前向推理發(fā)生了什么5.2 為什么 KDA 對筆記本部署格外重要六、從 20 分鐘到 14.6 秒優(yōu)化的重點(diǎn)不是算力6.1 I/O 優(yōu)化決定主要增益6.2 計(jì)算側(cè)把解量化融合進(jìn)乘法6.3 無損 n-gram 推測解碼七、0.0687 token/s 是怎樣測出來的7.1 測試條件決定數(shù)字含義7.2 結(jié)果應(yīng)拆成四個(gè)數(shù)字看7.3 瓶頸已經(jīng)從計(jì)算轉(zhuǎn)到 SSD八、Full 與 Stream兩種模式不是同一種“本地”8.1 容量換時(shí)間還是網(wǎng)絡(luò)換容量8.2 安裝與命令行運(yùn)行九、橫向?qū)Ρ菵eltafin 不是本地高性能推理引擎9.1 五條路線解決的是不同問題9.2 Deltafin 的真正生態(tài)位十、限制、風(fēng)險(xiǎn)與復(fù)現(xiàn)邊界10.1 它還不是聊天產(chǎn)品10.2 SSD、散熱和可用空間10.3 軟件成熟度與許可證十一、橫縱交匯模型規(guī)模的邊界正在從容量變成數(shù)據(jù)編排十二、總結(jié)十三、參考資料Kimi K3極限部署技術(shù)解析Deltafin如何在M1 Max上運(yùn)行2.8T參數(shù)模型一、引言親愛的朋友們創(chuàng)作不容易若對您有幫助的話請點(diǎn)贊收藏加關(guān)注哦您的關(guān)注是我持續(xù)創(chuàng)作的動力謝謝大家有問題請私信或聯(lián)系郵箱jasonai.fngmail.com一臺配備 64GB 統(tǒng)一內(nèi)存的 M1 Max能不能運(yùn)行一個(gè)總參數(shù)量達(dá)到 2.8T、權(quán)重文件約 1.56TB 的大模型按傳統(tǒng)部署思路答案顯然是否定的。即使使用 4bit 權(quán)重Kimi K3 的完整文件仍是這臺機(jī)器內(nèi)存容量的 24 倍左右更不用說運(yùn)行時(shí)狀態(tài)、激活值和操作系統(tǒng)還要繼續(xù)占用空間。但 2026 年 7 月 29 日剛剛公開的研究項(xiàng)目Deltafin給出了另一種答案不要求模型常駐內(nèi)存而是讓權(quán)重像數(shù)據(jù)庫頁一樣按層、按專家從 SSD 流入計(jì)算設(shè)備。項(xiàng)目維護(hù)者在一臺 10 核 CPU、32 核 GPU、64GB 統(tǒng)一內(nèi)存和內(nèi)置 NVMe 的 M1 Max 上測得0.0687 token/s 的穩(wěn)態(tài)解碼中位數(shù)即每個(gè) token 約 14.6 秒。它比項(xiàng)目最早約 20 分鐘生成一個(gè) token 的版本快了約 82 倍也確實(shí)生成了完整 Kimi K3 的正確輸出。但標(biāo)題里的“運(yùn)行”必須準(zhǔn)確理解說法是否準(zhǔn)確原因Kimi K3 可以在 64GB M1 Max 上執(zhí)行完整前向推理是Deltafin 按需讀取完整模型的主干和路由專家2.8T 參數(shù)被裝進(jìn)了 64GB 內(nèi)存否約 1.56TB 權(quán)重主要保存在 SSD運(yùn)行時(shí)逐層流入0.0687 token/s 已達(dá)到實(shí)用聊天速度否約 4.1 token/分鐘100 token 約需 24 分鐘Full 模式屬于離線本地推理是初次下載完成后推理無需聯(lián)網(wǎng)但需要約 1.7TB 磁盤Stream 模式也完全離線否未緩存專家要通過 HTTP Range 持續(xù)從 Hugging Face 獲取Deltafin 的價(jià)值不在于把 Kimi K3 變成一款日常聊天軟件而在于證明了一件更基礎(chǔ)的事當(dāng)模型采用極稀疏 MoE 架構(gòu)時(shí)單機(jī)內(nèi)存容量不再是能否推理的絕對邊界存儲帶寬、權(quán)重布局與調(diào)度策略可以成為新的“模型內(nèi)存”。本文將從 K3 架構(gòu)、權(quán)重拆分、逐 token 數(shù)據(jù)路徑、I/O 與 Metal 優(yōu)化、基準(zhǔn)口徑、部署實(shí)踐和橫向路線七個(gè)方面拆解這一實(shí)驗(yàn)。二、為什么 2.8T 參數(shù)通常裝不進(jìn) M1 Max2.1 Kimi K3 的“大”與“稀疏”同時(shí)存在Kimi K3 是月之暗面發(fā)布的原生多模態(tài) Agent 模型。根據(jù)官方模型卡和config.json其文本主干具有 93 層、896 個(gè)路由專家和 104B 激活參數(shù)并使用 Kimi Delta AttentionKDA與 Gated MLA 混合注意力。架構(gòu)參數(shù)Kimi K3 官方配置對本地推理的影響總參數(shù)量2.8T完整權(quán)重規(guī)模遠(yuǎn)超消費(fèi)級內(nèi)存每 token 激活參數(shù)104B計(jì)算路徑稀疏但不代表只需保存 104B 權(quán)重主干層數(shù)93 層每個(gè) token 都要依次經(jīng)過全部層注意力組成69 層 KDA 24 層 Gated MLAKDA 小狀態(tài)有利于長上下文解碼MoE 層1 個(gè) Dense 層 92 個(gè) MoE 層絕大多數(shù)層可以只讀被選中的專家路由專家每層 896 個(gè)選擇 16 個(gè)每層只觸碰約 1.79% 的路由專家共享專家2 個(gè)屬于每次都要經(jīng)過的主干路徑隱藏維度/注意力頭7168 / 96決定常駐主干和計(jì)算緩沖區(qū)規(guī)模上下文長度1,048,576 tokenKDA 降低部分層的狀態(tài)成本但不消除長 Prefill 開銷原生量化MXFP4 權(quán)重、MXFP8 激活的量化感知訓(xùn)練為低位專家計(jì)算提供了較好的權(quán)重基礎(chǔ)MoE 最容易引起的誤解是把“104B 激活參數(shù)”理解成“運(yùn)行時(shí)只需要 104B 參數(shù)的內(nèi)存”。實(shí)際上路由器要根據(jù)不同 token 選擇不同專家完整的 896 個(gè)專家仍然必須存在于某個(gè)地方。傳統(tǒng)推理引擎通常把它們放在多塊 GPU 或大容量統(tǒng)一內(nèi)存里Deltafin 則把這個(gè)“某個(gè)地方”改成了本地 SSD 或遠(yuǎn)程 CDN。2.2 權(quán)重規(guī)模決定傳統(tǒng)加載方式失效Kimi K3 權(quán)重由 96 個(gè) Safetensors 分片組成合計(jì)約 1.56TB。若直接調(diào)用常規(guī)模型加載器進(jìn)程通常會嘗試創(chuàng)建完整參數(shù)對象再把權(quán)重映射到 CPU、GPU 或統(tǒng)一內(nèi)存。這條路徑在 64GB 機(jī)器上沒有優(yōu)化余地不是慢而是根本無法完成常駐。Deltafin 因此不追求“把模型壓縮到內(nèi)存里”而是改變執(zhí)行模型只在設(shè)備上保留當(dāng)前計(jì)算所需的層模板、遞歸狀態(tài)和緩沖區(qū)把每個(gè) token 都會訪問的非路由權(quán)重視為resident spine常駐主干把 82,432 個(gè)路由專家視為可獨(dú)立尋址的數(shù)據(jù)塊每層路由完成后只讀取 Top-16 專家的原始字節(jié)跨度當(dāng)前層算完即復(fù)用緩沖區(qū)而不是為 93 層各建一套完整參數(shù)對象。這里的“resident”是邏輯角色不代表主干始終全部留在 RAM。M1 Max 參考配置中的 int8 主干約 53GB 至 60GB再加上程序、狀態(tài)、緩存和專家數(shù)據(jù)64GB 仍然不夠。Deltafin 會逐層重讀主干并依賴操作系統(tǒng)頁緩存保留能留下的部分。三、縱向演進(jìn)本地推理從模型壓縮走向權(quán)重流式化本地大模型的常見路線是通過 GGUF、低比特量化、內(nèi)存映射和 GPU Offload讓“已經(jīng)能放入內(nèi)存”的模型運(yùn)行得更快。模型從 7B 增長到 70B、數(shù)百 B 后這條路線仍然有效但它始終受一個(gè)前提約束至少要有足夠的 RAM、顯存或統(tǒng)一內(nèi)存容納大部分權(quán)重。MoE 改變了問題?？倕?shù)可以非常大但單個(gè) token 只訪問少量專家于是“完整保存”與“當(dāng)次參與計(jì)算”第一次出現(xiàn)了數(shù)量級差距。只要權(quán)重文件能夠隨機(jī)尋址系統(tǒng)就可以把沒有被選中的絕大多數(shù)專家留在磁盤。階段代表路線核心思想剩余瓶頸量化常駐llama.cpp / GGUF 等用 8bit、4bit 等格式降低完整模型內(nèi)存模型總權(quán)重仍需大體可容納CPU/GPU 分層GPU Offload、混合推理熱計(jì)算放 GPU其余權(quán)重放系統(tǒng)內(nèi)存仍受 RAM 容量和總線帶寬限制MoE 專家流式化colibri、ds4 / DwarfStar只從 SSD 讀取路由命中的專家隨機(jī) I/O、預(yù)取命中率和主干常駐成為關(guān)鍵超大模型流式實(shí)驗(yàn)Deltafin把 2.8T K3 拆成主干與 82,432 個(gè)專家跨度每 token 近 79GB 邏輯讀取速度受 SSD 主導(dǎo)Deltafin 并非憑空發(fā)明這條路線。項(xiàng)目 README 明確致謝 colibri 的路由預(yù)取、專家固定和 macOS 緩存控制經(jīng)驗(yàn)也借鑒 ds4 的零拷貝專家緩沖、選擇感知緩存淘汰與“先正確、再提速”方法。它的新貢獻(xiàn)是把這些思想適配到 Kimi K3 的特殊形狀、MXFP4 權(quán)重和 KDA/MLA 混合主干上并給出一條能夠在消費(fèi)級工作站跑通的完整工程路徑。時(shí)間維度也值得注意GitHub API 顯示 Deltafin 倉庫創(chuàng)建于2026 年 7 月 28 日7 月 29 日才正式公開主要代碼截至當(dāng)日還沒有 Release。也就是說本文討論的是一個(gè)極新的研究原型不應(yīng)把當(dāng)前兼容性、性能或接口當(dāng)作穩(wěn)定產(chǎn)品承諾。四、核心機(jī)制把 1.56TB 權(quán)重拆成主干與專家池4.1 兩類權(quán)重兩種訪問規(guī)律Deltafin 觀察到K3 權(quán)重可以按每個(gè) token 是否必經(jīng)分成兩部分權(quán)重區(qū)域規(guī)模訪問方式主要內(nèi)容Resident spine約 114GB BF16轉(zhuǎn)換后約 53GB 至 60GB int8每 token、每層都要讀取Attention、共享專家、Latent 投影、Embedding、輸出頭等Routed experts約 1.45TB每個(gè) MoE 層只讀取 Top-1692 層 × 896 個(gè)即 82,432 個(gè)路由專家對于主干Deltafin 用 int8 將逐 token I/O 約減半再采用雙緩沖按層搬運(yùn)。對于專家項(xiàng)目不轉(zhuǎn)換整個(gè)模型容器而是記錄每個(gè)專家在原 Safetensors 分片中的字節(jié)位置。一個(gè)專家的 6 個(gè)張量恰好連續(xù)約 17.55MB因此可以合并成一次范圍讀取。單 token 的專家數(shù)據(jù)量可以直接估算16 experts/layer x 92 MoE layers x 17.55 MB/expert 25,833.6 MB about 25.8 GB/token再加上約 53GB int8 主干單 token 的邏輯數(shù)據(jù)路徑約為53 GB resident spine 25.8 GB routed experts about 78.8 GB/token這是根據(jù) README 數(shù)據(jù)得到的近似值不等于每個(gè) token 都會對 SSD 產(chǎn)生 78.8GB 的物理讀取更不等于寫入量。頁緩存、預(yù)取和專家復(fù)用會降低部分物理 I/O緩存未命中、內(nèi)存壓力和系統(tǒng)后臺活動則會讓實(shí)際時(shí)延波動。4.2 完整數(shù)據(jù)路徑Initial setup | v -------------------------------- | Kimi K3: 96 Safetensors shards| | about 1.56 TB, MXFP4 experts | ------------------------------- | index tensor byte spans | --------------------------- | | v v ---------------------- -------------------------- | Resident spine | | 82,432 routed experts | | 114 GB BF16 | | about 1.45 TB | | - 53-60 GB int8 | | local SSD or HTTP cache | --------------------- ------------------------- | | | double-buffered | router Top-16 | layer stream | x 92 layers ---------------------------- v ------------------------ | One 93-layer pass | | 69 KDA 24 Gated MLA | | MPS Metal / CPU SIMD | ----------------------- | v logits - next token | repeat the path這張圖解釋了為什么 64GB 可以“運(yùn)行”2.8T 參數(shù)也解釋了速度為什么只有 0.0687 token/s容量問題被轉(zhuǎn)化成了帶寬問題。模型每生成一個(gè) token都要重新走完 93 層并搬運(yùn)數(shù)十 GB 數(shù)據(jù)SSD 不再只是加載模型的介質(zhì)而成了推理主路徑的一部分。五、逐 token 執(zhí)行從路由到下一詞5.1 一次前向推理發(fā)生了什么以已經(jīng)完成 Prefill、正在生成下一個(gè) token 為例Deltafin 的執(zhí)行過程可以概括為后臺線程讀取下一層的 int8 主干權(quán)重前臺繼續(xù)計(jì)算當(dāng)前層KDA 或 Gated MLA 完成注意力與歸一化得到進(jìn)入 MoE 的隱藏狀態(tài)路由器從 896 個(gè)專家中選出 16 個(gè)線程池用并行pread讀取 16 個(gè)專家的連續(xù)原始字節(jié)Metal 或 CPU 原生內(nèi)核在解量化 MXFP4 的同時(shí)執(zhí)行 GEMV加上兩個(gè)共享專家結(jié)果進(jìn)入下一層93 層結(jié)束后用壓縮的 int8 輸出頭計(jì)算 logits貪心選擇下一 token更新 KDA 遞歸狀態(tài)和 MLA KV Cache使用本 token 的專家選擇嘗試預(yù)取下一 token 可能復(fù)用的專家。K3 共有 69 個(gè) KDA 層和 24 個(gè) MLA 層。若為每層建立一套完整設(shè)備對象分配器開銷和設(shè)備內(nèi)存會迅速失控。Deltafin 只維護(hù)兩組持久模板一組對應(yīng) KDA 張量形狀一組對應(yīng) MLA 張量形狀每到一層再通過copy_()把該層權(quán)重送入模板緩沖區(qū)。5.2 為什么 KDA 對筆記本部署格外重要標(biāo)準(zhǔn)全注意力在逐 token 解碼時(shí)需要持續(xù)保存并讀取歷史 KV Cache。Kimi K3 的 69 個(gè) KDA 層使用固定大小遞歸狀態(tài)不隨上下文長度線性膨脹只有 24 個(gè) Gated MLA 層保留顯式 KV。這并不能讓百萬上下文在 64GB 機(jī)器上免費(fèi)運(yùn)行但它避免了 93 層全部采用全注意力時(shí)更嚴(yán)重的緩存壓力。K3 官方建模代碼依賴 CUDA 環(huán)境下的 FLA 內(nèi)核語義。Deltafin 沒有重新實(shí)現(xiàn)整個(gè)模型而是懶加載 Moonshot 官方建模代碼并用純 PyTorch 的 KDA Shim 替代 CUDA-only 路徑。項(xiàng)目報(bào)告分塊執(zhí)行與逐步執(zhí)行可在約1e-9量級一致使 MPS、CUDA 或 CPU 可以承擔(dān)常駐主干而路由專家由 Metal 或原生 CPU MXFP4 內(nèi)核計(jì)算。六、從 20 分鐘到 14.6 秒優(yōu)化的重點(diǎn)不是算力6.1 I/O 優(yōu)化決定主要增益Deltafin 第一版約 20 分鐘才能生成一個(gè) token。最終獲得約 82 倍改善核心不是讓 M1 Max 完成 2.8T 次密集矩陣運(yùn)算而是讓它不讀取無關(guān)專家并把必須讀取的數(shù)據(jù)盡可能順序化、并行化和緩存友好化。優(yōu)化具體做法維護(hù)者測得的效果或意義專家合并讀取每個(gè)專家的 6 個(gè)連續(xù)張量合成一次 17.55MB Range Request相比逐張量請求約快 6.4 倍Raw-span 緩存緩存原分片字節(jié)不再封裝、解析新容器降低緩存命中后的軟件開銷并行pread16 個(gè)專家由線程池一起讀取macOS 冷讀從 mmap 缺頁的 0.87GB/s 提升到約 6.85GB/sF_NOCACHE專家流量繞開 Darwin 文件緩存污染防止約 25.8GB/token 的專家讀取驅(qū)逐主干頁緩存雙緩沖主干當(dāng)前層計(jì)算時(shí)后臺加載下一層隱藏一部分層間 I/O 等待上一 token 預(yù)取按上次路由結(jié)果預(yù)取下一次專家去重留出集上的專家選擇復(fù)用約 31%這里最反直覺的是F_NOCACHE通常讀取文件希望盡量進(jìn)入頁緩存但專家訪問稀疏且流量巨大盲目緩存會把每 token 都要使用的主干擠出去。Deltafin 因此把專家視為一次性流量把寶貴緩存留給復(fù)用更穩(wěn)定的 spine。6.2 計(jì)算側(cè)把解量化融合進(jìn)乘法MXFP4 能顯著縮小專家文件卻不能直接交給普通 BF16 矩陣乘法。若先把專家完整解量化再執(zhí)行 GEMV不僅增加臨時(shí)內(nèi)存還要多走一遍內(nèi)存帶寬。Deltafin 的原生內(nèi)核在讀取 4bit 權(quán)重后立即解碼并參與乘法平臺主干/注意力路由專家 MoEApple Silicon macOSPyTorch MPSMetal或原生 CPU 備選NVIDIA LinuxCUDA當(dāng)前仍為原生 CPU MXFP4尚無原生 CUDA MoE 內(nèi)核Linux aarch64CPUNEON MXFP4Linux x86-64CPUAVX2/FMA或兼容路徑Apple 路徑還使用自定義 Metal 內(nèi)核融合 int8 到 FP32、行縮放和復(fù)制。README 報(bào)告該步驟從每層 118ms 降至 21ms并在測試張量上保持 bit-exact。壓縮 int8 輸出頭則避免每個(gè) token 展開 4.7GB FP32 Head維護(hù)者的平衡 A/B 測試中它讓穩(wěn)態(tài)解碼中位數(shù)提高 17.3%。這些都是特定 M1 Max、特定代碼版本的實(shí)測不應(yīng)直接外推到所有 Mac。6.3 無損 n-gram 推測解碼當(dāng)生成文本出現(xiàn)重復(fù)片段時(shí)Deltafin 從已經(jīng)出現(xiàn)的后綴中免費(fèi)提出 n-gram 草稿再用一次雙位置前向驗(yàn)證。若草稿正確一次昂貴的數(shù)據(jù)路徑可以接受兩個(gè) token若錯(cuò)誤則通過不可變狀態(tài)引用回滾不復(fù)制約 475MB 狀態(tài)。與常見“小模型起草、大模型驗(yàn)證”不同這里沒有額外 Draft Model。項(xiàng)目聲稱其測試中的接受結(jié)果與逐 token 貪心序列完全一致因此屬于無損優(yōu)化。但收益取決于文本重復(fù)度不是每個(gè) token 都能加速。七、0.0687 token/s 是怎樣測出來的7.1 測試條件決定數(shù)字含義Deltafin README 給出的參考值來自維護(hù)者的一臺機(jī)器而不是第三方統(tǒng)一評測條件參考配置機(jī)器M1 Max10 核 CPU、32 核 GPU、64GB 統(tǒng)一內(nèi)存、內(nèi)置 NVMe模型模式Full本地安裝完整專家池主干/輸出頭int8 spine packed int8 output headMoE 后端Metal數(shù)值路徑Exact FP32 numerics關(guān)閉近似模式解碼Greedy關(guān)閉路由 TracePromptThe capital of France is5 token校驗(yàn)輸出Paris. The3 token樣本6 次完整模型運(yùn)行采用平衡 ABBA/BAAB Campaign穩(wěn)態(tài)口徑丟棄第一個(gè) Decode Step再計(jì)算后續(xù)解碼速度丟棄第一個(gè) Decode Step 很重要首步會受到進(jìn)程預(yù)熱、緩存狀態(tài)和初始化的影響。穩(wěn)態(tài)結(jié)果描述的是“模型已經(jīng)開始生成后后續(xù) token 有多快”不能拿它代替用戶從提交請求到看到第一個(gè)字的端到端延遲。7.2 結(jié)果應(yīng)拆成四個(gè)數(shù)字看指標(biāo)當(dāng)前 M1 Max 中位數(shù)波動范圍/說明Prefill / 首 token28.0 秒24.9 至 37.9 秒輸入只有 5 token穩(wěn)態(tài) Decode0.0687 token/s即 14.6 秒/token6 次運(yùn)行范圍 0.0503 至 0.0779 token/s3 token 模型時(shí)間56.5 秒包含首步與后續(xù)解碼新進(jìn)程完整墻鐘時(shí)間64.1 秒還包含進(jìn)程啟動和初始化換算成更直觀的體驗(yàn)0.0687 token/s x 60 s about 4.1 token/min 100 token / 0.0687 token/s about 1,456 s about 24.3 min因此它足以驗(yàn)證模型、研究路由和測試流式推理卻不適合正常聊天。K3 默認(rèn)包含思考過程一次完整回答很容易達(dá)到數(shù)百或數(shù)千 token即使 Prefill 很短生成也可能持續(xù)數(shù)小時(shí)。7.3 瓶頸已經(jīng)從計(jì)算轉(zhuǎn)到 SSDREADME 給出的一次代表性 Profile 約為主干讀取等待 5 秒、專家讀取 4.3 秒、主干傳輸與解量化 3 秒、注意力和歸一化 2 秒、專家矩陣乘約 1 秒。各階段存在流水重疊近似值不能機(jī)械相加但方向十分明確數(shù)據(jù)搬運(yùn)遠(yuǎn)大于 MoE 算術(shù)本身。主干約 53GB每個(gè) token 都要重讀項(xiàng)目觀測到該訪問模式約 7GB/s理論上僅這一路徑就要約 7.5 秒。更多 RAM 能保留更多主干頁和專家緩存更快 SSD 能縮短冷讀在這類工作負(fù)載中升級存儲與內(nèi)存往往比增加 GPU 算力更直接。八、Full 與 Stream兩種模式不是同一種“本地”8.1 容量換時(shí)間還是網(wǎng)絡(luò)換容量維度--full完整模式--stream流式模式磁盤需求約 1.7TB約 215GB 起步緩存持續(xù)增長初次下載約 5 至 10 小時(shí)可斷點(diǎn)續(xù)傳約 30 分鐘推理網(wǎng)絡(luò)下載后無需網(wǎng)絡(luò)持續(xù)需要 Hugging Face 或鏡像未緩存專家速度M1 Max 中位數(shù)約 14.6 秒/token約 3 分鐘以上/token適用目的穩(wěn)定復(fù)現(xiàn)、離線研究、性能測試低門檻嘗試、逐步建立專家緩存Full 模式仍不等于“模型全部在內(nèi)存中”只是把完整權(quán)重放到了本地 SSD。Stream 模式則把 Hugging Face CDN 視為更慢的遠(yuǎn)程存儲路由命中本地沒有的專家時(shí)用一次 HTTP Range 拉取約 17.55MB 原始跨度再寫入磁盤緩存。對 Chat CompletionStream 模式尤其不友好。聊天模板本身可超過 60 個(gè) Prompt Token而 Prefill 會讓多位置、多層路由觸碰大量專家緩存較空時(shí)單次請求可能花數(shù)小時(shí)下載。因此想復(fù)現(xiàn) 0.0687 token/s必須使用 Full 模式而不是只完成 215GB 的流式安裝。8.2 安裝與命令行運(yùn)行環(huán)境要求包括 Python 3.12、PyTorch、Xcode Command Line Tools以及至少約 1.7TB 可用空間。官方 README 的基本流程如下gitclone https://github.com/gavamedia/deltafin.gitcddeltafin python3-mvenv venv ./venv/bin/pipinstalltorch numpy safetensors tiktoken ml_dtypes blobfile\transformers4.56.2einops tokenizers python3 tools/build_native.py ./venv/bin/python tools/setup_k3.py--full完成安裝后可以運(yùn)行與基準(zhǔn)相同的原始補(bǔ)全文本./venv/bin/python tools/kimi_run.py\--promptThe capital of France is\--max-new16也可以啟動 OpenAI 兼容服務(wù)./venv/bin/python tools/serve_openai.py--port8000fromopenaiimportOpenAI clientOpenAI(base_urlhttp://127.0.0.1:8000/v1,api_keynone,timeout7200.0,)responseclient.chat.completions.create(modeldeltafin-kimi-k3,messages[{role:user,content:Explain mixture of experts.}],)print(response.choices[0].message.content)服務(wù)實(shí)現(xiàn)了/v1/chat/completions、/v1/completions和/v1/models也支持流式響應(yīng)。但兼容的是接口形狀不是完整采樣語義當(dāng)前只支持貪心解碼temperature與top_p雖會被接受卻被忽略同時(shí)只能處理一個(gè)請求第二個(gè)并發(fā)請求會得到 HTTP 429每個(gè)新請求還會建立新的 KV 與狀態(tài)緩存。九、橫向?qū)Ρ菵eltafin 不是本地高性能推理引擎9.1 五條路線解決的是不同問題路線主要目標(biāo)權(quán)重放在哪里優(yōu)勢主要代價(jià)Deltafin在小內(nèi)存工作站跑通完整 K3SSD 為主當(dāng)前層進(jìn)入 MPS/CPU64GB M1 Max 可驗(yàn)證 2.8T 模型Full 可離線約 14.6 秒/token需約 1.7TB SSDvLLM/SGLang/TokenSpeed官方推薦的高吞吐 K3 部署大容量多卡加速器內(nèi)存面向服務(wù)吞吐、并發(fā)和標(biāo)準(zhǔn)推理工作流硬件與運(yùn)維門檻遠(yuǎn)高于單臺 Macllama.cpp 類量化常駐消費(fèi)級設(shè)備高效運(yùn)行可容納模型RAM/統(tǒng)一內(nèi)存為主可部分 Offload工具成熟、交互速度更實(shí)用對 1.56TB K3 仍受總?cè)萘肯拗芻olibri / ds4研究 MoE 專家流式與緩存RAM SSD 分層提供專家預(yù)取、固定、淘汰和零拷貝經(jīng)驗(yàn)?zāi)Ｐ瓦m配、質(zhì)量驗(yàn)證和性能依賴實(shí)現(xiàn)Kimi 云 API直接使用 K3 能力云端集群無需下載 1.7TB響應(yīng)和并發(fā)更實(shí)用數(shù)據(jù)、成本、網(wǎng)絡(luò)和服務(wù)依賴由云端決定這張表沒有一個(gè)“全面獲勝者”。想研究 K3 的實(shí)際權(quán)重、路由分布或極限單機(jī)部署Deltafin 提供了此前缺少的入口想每天使用 K3云 API 更合理擁有多機(jī)多卡資源并追求吞吐則應(yīng)優(yōu)先使用官方模型卡推薦的 vLLM、SGLang 或 TokenSpeed。9.2 Deltafin 的真正生態(tài)位主流本地推理項(xiàng)目優(yōu)化的是“如何讓一個(gè)放得下的模型跑得更快”Deltafin 解決的是“如何讓一個(gè)完全放不下的稀疏模型先跑起來”。兩者的目標(biāo)函數(shù)不同Conventional local inference: fit the model - minimize latency - maximize throughput Deltafin: preserve the full model - make one exact token possible - then reduce I/O這也解釋了項(xiàng)目為何強(qiáng)調(diào)精確貪心輸出、Exact FP32 Numerics 和可回滾推測解碼。對存在性證明而言若為了速度隨意減少 Top-K 或使用不可控近似雖然 token 變快卻無法確認(rèn)運(yùn)行的還是不是同一個(gè)模型。Deltafin 提供K3_MOE_TOP_K和K3_APPROX等實(shí)驗(yàn)開關(guān)但參考基準(zhǔn)沒有用這些損失質(zhì)量的捷徑。十、限制、風(fēng)險(xiǎn)與復(fù)現(xiàn)邊界10.1 它還不是聊天產(chǎn)品限制實(shí)際影響穩(wěn)態(tài)僅 4.1 token/分鐘一段正?；卮鹂赡艿却龓资昼姷綌?shù)小時(shí)長 Prompt Prefill 昂貴Agent 系統(tǒng)提示、代碼倉庫和聊天模板會顯著放大首字延遲單請求串行無法作為多人并發(fā)服務(wù)自動化工具需處理 429僅貪心解碼不能通過temperature、top_p獲得常見采樣多樣性請求狀態(tài)不復(fù)用每次請求建立新的 KV/KDA 狀態(tài)重復(fù)長前綴成本高質(zhì)量評測仍有限當(dāng)前主要驗(yàn)證確定性 token 與數(shù)值路徑不是完整能力回歸基準(zhǔn)維護(hù)者自己把 Deltafin 稱為 research artifact 和 existence proof。這種定位是誠實(shí)的它證明的是“能夠執(zhí)行”而不是“適合交互”。10.2 SSD、散熱和可用空間Full 模式約占 1.7TB已經(jīng)超過很多 Mac 的全部內(nèi)置容量外接 SSD 是否能達(dá)到相同速度還取決于接口、控制器、文件系統(tǒng)和隨機(jī)讀取表現(xiàn)。持續(xù)數(shù)十 GB/token 的邏輯讀取可能引起 SSD 溫度上升和降速需要在長時(shí)間實(shí)驗(yàn)中監(jiān)控溫度與吞吐。讀流量不能簡單等同于 NAND 寫入壽命。Full 模式推理主要是讀取Stream 模式緩存未命中專家時(shí)才會產(chǎn)生額外寫入。實(shí)際物理 I/O 還受頁緩存、預(yù)取和復(fù)用影響因此不能從 78.8GB 邏輯路徑直接推導(dǎo)硬盤壽命。10.3 軟件成熟度與許可證截至 2026 年 7 月 29 日項(xiàng)目剛公開約一天、沒有正式 ReleaseLinux 與 CUDA 路徑也還在擴(kuò)展驗(yàn)證。復(fù)現(xiàn)前應(yīng)固定 Commit而不是只記錄main分支PyTorch、Metal 與操作系統(tǒng)升級也可能改變算子支持和性能。Deltafin 自身代碼使用 MIT License但 Kimi K3 權(quán)重和官方建模代碼遵循獨(dú)立的Kimi K3 License不能因?yàn)橥鈱蛹虞d器是 MIT 就忽略模型許可證。Deltafin 也明確聲明與 Moonshot AI 沒有關(guān)聯(lián)。下載 1.56TB 模型前還應(yīng)核對來源、剩余空間、網(wǎng)絡(luò)費(fèi)用和目標(biāo)用途是否符合許可要求。十一、橫縱交匯模型規(guī)模的邊界正在從容量變成數(shù)據(jù)編排縱向看本地推理先依賴量化縮小模型再依賴 CPU/GPU 分層擴(kuò)大可用內(nèi)存如今開始進(jìn)一步把 SSD 和網(wǎng)絡(luò)納入逐 token 權(quán)重層級。Deltafin 的出現(xiàn)不是說明“磁盤可以替代 GPU”而是說明 MoE 的條件計(jì)算為更激進(jìn)的存儲分層留下了結(jié)構(gòu)性機(jī)會。橫向看Deltafin 不會在速度上取代云 API、多卡 vLLM 或能常駐內(nèi)存的 llama.cpp 模型。它的優(yōu)勢只在一個(gè)非常窄、卻有研究價(jià)值的區(qū)域保留完整超大 MoE 模型在遠(yuǎn)低于模型權(quán)重規(guī)模的內(nèi)存中完成可驗(yàn)證推理。未來性能提升更可能來自以下方向而不是單純增加 GPU 核心方向?yàn)槭裁从行枰?yàn)證的問題更大內(nèi)存讓 53GB int8 主干和更多專家停留在頁緩存內(nèi)存容量增加能否穩(wěn)定轉(zhuǎn)化為物理讀取下降更快 NVMe直接縮短主干與專家讀取隨機(jī)讀取、散熱和文件系統(tǒng)是否成為新瓶頸更聰明的路由預(yù)取利用相鄰 token 專家選擇相關(guān)性31% 復(fù)用能否用模型預(yù)測進(jìn)一步提高原生 CUDA MXFP4 MoE避免 NVIDIA 路徑的 CPU 專家計(jì)算數(shù)據(jù)搬運(yùn)是否會抵消 GPU 算術(shù)收益主干進(jìn)一步壓縮每 token 必讀區(qū)域每減少 1GB 都有持續(xù)收益質(zhì)量損失如何用完整 NLL/任務(wù)基準(zhǔn)衡量原生執(zhí)行引擎減少 Python、分配器與框架調(diào)度開銷在 I/O 主導(dǎo)后軟件常數(shù)還能貢獻(xiàn)多少最重要的判斷是2.8T 不再天然意味著“必須先擁有能容納 2.8T 權(quán)重的內(nèi)存”但也不意味著容量約束消失了。Deltafin 只是把硬邊界改造成一條很慢的數(shù)據(jù)通道。只有當(dāng)緩存、預(yù)取、量化與存儲帶寬共同進(jìn)步這條通道才可能從實(shí)驗(yàn)走向工具。十二、總結(jié)維度核心結(jié)論為什么能跑K3 每層只激活 16/896 個(gè)路由專家Deltafin 無需同時(shí)載入 2.8T 參數(shù)如何存放約 53GB 至 60GB int8 主干逐層讀取約 1.45TB 專家池留在 SSD 或 CDN數(shù)據(jù)成本每 token 讀取約 25.8GB 專家連同主干約形成 78.8GB 邏輯路徑主要優(yōu)化合并范圍讀取、并行pread、F_NOCACHE、雙緩沖、路由預(yù)取、融合 MXFP4 GEMV實(shí)測速度維護(hù)者的 M1 Max Full 模式穩(wěn)態(tài)中位數(shù)為 0.0687 token/s即 14.6 秒/token實(shí)際定位研究原型與存在性證明不是可交互聊天服務(wù)工程意義超大稀疏模型的部署邊界開始由內(nèi)存容量轉(zhuǎn)向權(quán)重布局和存儲調(diào)度Deltafin 最值得記住的不是“一臺 Mac 也能秒跑 2.8T 模型”而是一個(gè)更克制也更重要的結(jié)論一臺 64GB M1 Max 可以在不裁剪 Kimi K3 專家池的前提下依靠 SSD 流式執(zhí)行完整模型代價(jià)是每個(gè) token 仍需約 14.6 秒。它把一個(gè)原本會在加載階段直接失敗的問題變成了可以測量、剖析和持續(xù)優(yōu)化的 I/O 系統(tǒng)問題。對日常用戶這個(gè)速度太慢對本地推理工程而言它已經(jīng)打開了一條值得繼續(xù)探索的路徑。十三、參考資料Deltafin GitHub Repository — gavamediaREADME 與代碼訪問日期2026-07-29Kimi K3 Model Card — Moonshot AI訪問日期2026-07-29Kimi K3 config.json — Moonshot AI訪問日期2026-07-29Kimi K3 License — Moonshot AI訪問日期2026-07-29colibri — JustVuggMoE 專家流式推理項(xiàng)目ds4 / DwarfStar — antirezMoE 磁盤流式推理項(xiàng)目llama.cpp — ggml-org本地量化推理參考項(xiàng)目Kimi Linear: An Expressive, Efficient Attention ArchitectureKDA 與混合線性注意力論文注本文所有 Deltafin 性能數(shù)字均來自項(xiàng)目維護(hù)者截至 2026 年 7 月 29 日公開的參考測試未被本文作者獨(dú)立復(fù)現(xiàn)由這些數(shù)字得到的分鐘數(shù)與約 78.8GB/token 為算術(shù)換算。項(xiàng)目迭代很快后續(xù) Commit、硬件、系統(tǒng)緩存與存儲狀態(tài)都可能改變結(jié)果。 【Kimi K3極限部署技術(shù)解析】Deltafin如何在M1 Max上運(yùn)行2.8T參數(shù)模型
文章目錄Kimi K3極限部署技術(shù)解析Deltafin如何在M1 Max上運(yùn)行2.8T參數(shù)模型一、引言二、為什么 2.8T 參數(shù)通常裝不進(jìn) M1 Max2.1 Kimi K3 的“大”與“稀疏”同時(shí)存在2.2 權(quán)重規(guī)模決定傳統(tǒng)加載方式失效三、縱向演進(jìn)本地推理從模型壓縮走向權(quán)重流式化四、核心機(jī)制把 1.56TB 權(quán)重拆成主干與專家池4.1 兩類權(quán)重兩種訪問規(guī)律4.2 完整數(shù)據(jù)路徑五、逐 token 執(zhí)行從路由到下一詞5.1 一次前向推理發(fā)生了什么5.2 為什么 KDA 對筆記本部署格外重要六、從 20 分鐘到 14.6 秒優(yōu)化的重點(diǎn)不是算力6.1 I/O 優(yōu)化決定主要增益6.2 計(jì)算側(cè)把解量化融合進(jìn)乘法6.3 無損 n-gram 推測解碼七、0.0687 token/s 是怎樣測出來的7.1 測試條件決定數(shù)字含義7.2 結(jié)果應(yīng)拆成四個(gè)數(shù)字看7.3 瓶頸已經(jīng)從計(jì)算轉(zhuǎn)到 SSD八、Full 與 Stream兩種模式不是同一種“本地”8.1 容量換時(shí)間還是網(wǎng)絡(luò)換容量8.2 安裝與命令行運(yùn)行九、橫向?qū)Ρ菵eltafin 不是本地高性能推理引擎9.1 五條路線解決的是不同問題9.2 Deltafin 的真正生態(tài)位十、限制、風(fēng)險(xiǎn)與復(fù)現(xiàn)邊界10.1 它還不是聊天產(chǎn)品10.2 SSD、散熱和可用空間10.3 軟件成熟度與許可證十一、橫縱交匯模型規(guī)模的邊界正在從容量變成數(shù)據(jù)編排十二、總結(jié)十三、參考資料Kimi K3極限部署技術(shù)解析Deltafin如何在M1 Max上運(yùn)行2.8T參數(shù)模型一、引言親愛的朋友們創(chuàng)作不容易若對您有幫助的話請點(diǎn)贊收藏加關(guān)注哦您的關(guān)注是我持續(xù)創(chuàng)作的動力謝謝大家有問題請私信或聯(lián)系郵箱jasonai.fngmail.com一臺配備 64GB 統(tǒng)一內(nèi)存的 M1 Max能不能運(yùn)行一個(gè)總參數(shù)量達(dá)到 2.8T、權(quán)重文件約 1.56TB 的大模型按傳統(tǒng)部署思路答案顯然是否定的。即使使用 4bit 權(quán)重Kimi K3 的完整文件仍是這臺機(jī)器內(nèi)存容量的 24 倍左右更不用說運(yùn)行時(shí)狀態(tài)、激活值和操作系統(tǒng)還要繼續(xù)占用空間。但 2026 年 7 月 29 日剛剛公開的研究項(xiàng)目Deltafin給出了另一種答案不要求模型常駐內(nèi)存而是讓權(quán)重像數(shù)據(jù)庫頁一樣按層、按專家從 SSD 流入計(jì)算設(shè)備。項(xiàng)目維護(hù)者在一臺 10 核 CPU、32 核 GPU、64GB 統(tǒng)一內(nèi)存和內(nèi)置 NVMe 的 M1 Max 上測得0.0687 token/s 的穩(wěn)態(tài)解碼中位數(shù)即每個(gè) token 約 14.6 秒。它比項(xiàng)目最早約 20 分鐘生成一個(gè) token 的版本快了約 82 倍也確實(shí)生成了完整 Kimi K3 的正確輸出。但標(biāo)題里的“運(yùn)行”必須準(zhǔn)確理解說法是否準(zhǔn)確原因Kimi K3 可以在 64GB M1 Max 上執(zhí)行完整前向推理是Deltafin 按需讀取完整模型的主干和路由專家2.8T 參數(shù)被裝進(jìn)了 64GB 內(nèi)存否約 1.56TB 權(quán)重主要保存在 SSD運(yùn)行時(shí)逐層流入0.0687 token/s 已達(dá)到實(shí)用聊天速度否約 4.1 token/分鐘100 token 約需 24 分鐘Full 模式屬于離線本地推理是初次下載完成后推理無需聯(lián)網(wǎng)但需要約 1.7TB 磁盤Stream 模式也完全離線否未緩存專家要通過 HTTP Range 持續(xù)從 Hugging Face 獲取Deltafin 的價(jià)值不在于把 Kimi K3 變成一款日常聊天軟件而在于證明了一件更基礎(chǔ)的事當(dāng)模型采用極稀疏 MoE 架構(gòu)時(shí)單機(jī)內(nèi)存容量不再是能否推理的絕對邊界存儲帶寬、權(quán)重布局與調(diào)度策略可以成為新的“模型內(nèi)存”。本文將從 K3 架構(gòu)、權(quán)重拆分、逐 token 數(shù)據(jù)路徑、I/O 與 Metal 優(yōu)化、基準(zhǔn)口徑、部署實(shí)踐和橫向路線七個(gè)方面拆解這一實(shí)驗(yàn)。二、為什么 2.8T 參數(shù)通常裝不進(jìn) M1 Max2.1 Kimi K3 的“大”與“稀疏”同時(shí)存在Kimi K3 是月之暗面發(fā)布的原生多模態(tài) Agent 模型。根據(jù)官方模型卡和config.json其文本主干具有 93 層、896 個(gè)路由專家和 104B 激活參數(shù)并使用 Kimi Delta AttentionKDA與 Gated MLA 混合注意力。架構(gòu)參數(shù)Kimi K3 官方配置對本地推理的影響總參數(shù)量2.8T完整權(quán)重規(guī)模遠(yuǎn)超消費(fèi)級內(nèi)存每 token 激活參數(shù)104B計(jì)算路徑稀疏但不代表只需保存 104B 權(quán)重主干層數(shù)93 層每個(gè) token 都要依次經(jīng)過全部層注意力組成69 層 KDA 24 層 Gated MLAKDA 小狀態(tài)有利于長上下文解碼MoE 層1 個(gè) Dense 層 92 個(gè) MoE 層絕大多數(shù)層可以只讀被選中的專家路由專家每層 896 個(gè)選擇 16 個(gè)每層只觸碰約 1.79% 的路由專家共享專家2 個(gè)屬于每次都要經(jīng)過的主干路徑隱藏維度/注意力頭7168 / 96決定常駐主干和計(jì)算緩沖區(qū)規(guī)模上下文長度1,048,576 tokenKDA 降低部分層的狀態(tài)成本但不消除長 Prefill 開銷原生量化MXFP4 權(quán)重、MXFP8 激活的量化感知訓(xùn)練為低位專家計(jì)算提供了較好的權(quán)重基礎(chǔ)MoE 最容易引起的誤解是把“104B 激活參數(shù)”理解成“運(yùn)行時(shí)只需要 104B 參數(shù)的內(nèi)存”。實(shí)際上路由器要根據(jù)不同 token 選擇不同專家完整的 896 個(gè)專家仍然必須存在于某個(gè)地方。傳統(tǒng)推理引擎通常把它們放在多塊 GPU 或大容量統(tǒng)一內(nèi)存里Deltafin 則把這個(gè)“某個(gè)地方”改成了本地 SSD 或遠(yuǎn)程 CDN。2.2 權(quán)重規(guī)模決定傳統(tǒng)加載方式失效Kimi K3 權(quán)重由 96 個(gè) Safetensors 分片組成合計(jì)約 1.56TB。若直接調(diào)用常規(guī)模型加載器進(jìn)程通常會嘗試創(chuàng)建完整參數(shù)對象再把權(quán)重映射到 CPU、GPU 或統(tǒng)一內(nèi)存。這條路徑在 64GB 機(jī)器上沒有優(yōu)化余地不是慢而是根本無法完成常駐。Deltafin 因此不追求“把模型壓縮到內(nèi)存里”而是改變執(zhí)行模型只在設(shè)備上保留當(dāng)前計(jì)算所需的層模板、遞歸狀態(tài)和緩沖區(qū)把每個(gè) token 都會訪問的非路由權(quán)重視為resident spine常駐主干把 82,432 個(gè)路由專家視為可獨(dú)立尋址的數(shù)據(jù)塊每層路由完成后只讀取 Top-16 專家的原始字節(jié)跨度當(dāng)前層算完即復(fù)用緩沖區(qū)而不是為 93 層各建一套完整參數(shù)對象。這里的“resident”是邏輯角色不代表主干始終全部留在 RAM。M1 Max 參考配置中的 int8 主干約 53GB 至 60GB再加上程序、狀態(tài)、緩存和專家數(shù)據(jù)64GB 仍然不夠。Deltafin 會逐層重讀主干并依賴操作系統(tǒng)頁緩存保留能留下的部分。三、縱向演進(jìn)本地推理從模型壓縮走向權(quán)重流式化本地大模型的常見路線是通過 GGUF、低比特量化、內(nèi)存映射和 GPU Offload讓“已經(jīng)能放入內(nèi)存”的模型運(yùn)行得更快。模型從 7B 增長到 70B、數(shù)百 B 后這條路線仍然有效但它始終受一個(gè)前提約束至少要有足夠的 RAM、顯存或統(tǒng)一內(nèi)存容納大部分權(quán)重。MoE 改變了問題?？倕?shù)可以非常大但單個(gè) token 只訪問少量專家于是“完整保存”與“當(dāng)次參與計(jì)算”第一次出現(xiàn)了數(shù)量級差距。只要權(quán)重文件能夠隨機(jī)尋址系統(tǒng)就可以把沒有被選中的絕大多數(shù)專家留在磁盤。階段代表路線核心思想剩余瓶頸量化常駐llama.cpp / GGUF 等用 8bit、4bit 等格式降低完整模型內(nèi)存模型總權(quán)重仍需大體可容納CPU/GPU 分層GPU Offload、混合推理熱計(jì)算放 GPU其余權(quán)重放系統(tǒng)內(nèi)存仍受 RAM 容量和總線帶寬限制MoE 專家流式化colibri、ds4 / DwarfStar只從 SSD 讀取路由命中的專家隨機(jī) I/O、預(yù)取命中率和主干常駐成為關(guān)鍵超大模型流式實(shí)驗(yàn)Deltafin把 2.8T K3 拆成主干與 82,432 個(gè)專家跨度每 token 近 79GB 邏輯讀取速度受 SSD 主導(dǎo)Deltafin 并非憑空發(fā)明這條路線。項(xiàng)目 README 明確致謝 colibri 的路由預(yù)取、專家固定和 macOS 緩存控制經(jīng)驗(yàn)也借鑒 ds4 的零拷貝專家緩沖、選擇感知緩存淘汰與“先正確、再提速”方法。它的新貢獻(xiàn)是把這些思想適配到 Kimi K3 的特殊形狀、MXFP4 權(quán)重和 KDA/MLA 混合主干上并給出一條能夠在消費(fèi)級工作站跑通的完整工程路徑。時(shí)間維度也值得注意GitHub API 顯示 Deltafin 倉庫創(chuàng)建于2026 年 7 月 28 日7 月 29 日才正式公開主要代碼截至當(dāng)日還沒有 Release。也就是說本文討論的是一個(gè)極新的研究原型不應(yīng)把當(dāng)前兼容性、性能或接口當(dāng)作穩(wěn)定產(chǎn)品承諾。四、核心機(jī)制把 1.56TB 權(quán)重拆成主干與專家池4.1 兩類權(quán)重兩種訪問規(guī)律Deltafin 觀察到K3 權(quán)重可以按每個(gè) token 是否必經(jīng)分成兩部分權(quán)重區(qū)域規(guī)模訪問方式主要內(nèi)容Resident spine約 114GB BF16轉(zhuǎn)換后約 53GB 至 60GB int8每 token、每層都要讀取Attention、共享專家、Latent 投影、Embedding、輸出頭等Routed experts約 1.45TB每個(gè) MoE 層只讀取 Top-1692 層 × 896 個(gè)即 82,432 個(gè)路由專家對于主干Deltafin 用 int8 將逐 token I/O 約減半再采用雙緩沖按層搬運(yùn)。對于專家項(xiàng)目不轉(zhuǎn)換整個(gè)模型容器而是記錄每個(gè)專家在原 Safetensors 分片中的字節(jié)位置。一個(gè)專家的 6 個(gè)張量恰好連續(xù)約 17.55MB因此可以合并成一次范圍讀取。單 token 的專家數(shù)據(jù)量可以直接估算16 experts/layer x 92 MoE layers x 17.55 MB/expert 25,833.6 MB about 25.8 GB/token再加上約 53GB int8 主干單 token 的邏輯數(shù)據(jù)路徑約為53 GB resident spine 25.8 GB routed experts about 78.8 GB/token這是根據(jù) README 數(shù)據(jù)得到的近似值不等于每個(gè) token 都會對 SSD 產(chǎn)生 78.8GB 的物理讀取更不等于寫入量。頁緩存、預(yù)取和專家復(fù)用會降低部分物理 I/O緩存未命中、內(nèi)存壓力和系統(tǒng)后臺活動則會讓實(shí)際時(shí)延波動。4.2 完整數(shù)據(jù)路徑Initial setup | v -------------------------------- | Kimi K3: 96 Safetensors shards| | about 1.56 TB, MXFP4 experts | ------------------------------- | index tensor byte spans | --------------------------- | | v v ---------------------- -------------------------- | Resident spine | | 82,432 routed experts | | 114 GB BF16 | | about 1.45 TB | | - 53-60 GB int8 | | local SSD or HTTP cache | --------------------- ------------------------- | | | double-buffered | router Top-16 | layer stream | x 92 layers ---------------------------- v ------------------------ | One 93-layer pass | | 69 KDA 24 Gated MLA | | MPS Metal / CPU SIMD | ----------------------- | v logits - next token | repeat the path這張圖解釋了為什么 64GB 可以“運(yùn)行”2.8T 參數(shù)也解釋了速度為什么只有 0.0687 token/s容量問題被轉(zhuǎn)化成了帶寬問題。模型每生成一個(gè) token都要重新走完 93 層并搬運(yùn)數(shù)十 GB 數(shù)據(jù)SSD 不再只是加載模型的介質(zhì)而成了推理主路徑的一部分。五、逐 token 執(zhí)行從路由到下一詞5.1 一次前向推理發(fā)生了什么以已經(jīng)完成 Prefill、正在生成下一個(gè) token 為例Deltafin 的執(zhí)行過程可以概括為后臺線程讀取下一層的 int8 主干權(quán)重前臺繼續(xù)計(jì)算當(dāng)前層KDA 或 Gated MLA 完成注意力與歸一化得到進(jìn)入 MoE 的隱藏狀態(tài)路由器從 896 個(gè)專家中選出 16 個(gè)線程池用并行pread讀取 16 個(gè)專家的連續(xù)原始字節(jié)Metal 或 CPU 原生內(nèi)核在解量化 MXFP4 的同時(shí)執(zhí)行 GEMV加上兩個(gè)共享專家結(jié)果進(jìn)入下一層93 層結(jié)束后用壓縮的 int8 輸出頭計(jì)算 logits貪心選擇下一 token更新 KDA 遞歸狀態(tài)和 MLA KV Cache使用本 token 的專家選擇嘗試預(yù)取下一 token 可能復(fù)用的專家。K3 共有 69 個(gè) KDA 層和 24 個(gè) MLA 層。若為每層建立一套完整設(shè)備對象分配器開銷和設(shè)備內(nèi)存會迅速失控。Deltafin 只維護(hù)兩組持久模板一組對應(yīng) KDA 張量形狀一組對應(yīng) MLA 張量形狀每到一層再通過copy_()把該層權(quán)重送入模板緩沖區(qū)。5.2 為什么 KDA 對筆記本部署格外重要標(biāo)準(zhǔn)全注意力在逐 token 解碼時(shí)需要持續(xù)保存并讀取歷史 KV Cache。Kimi K3 的 69 個(gè) KDA 層使用固定大小遞歸狀態(tài)不隨上下文長度線性膨脹只有 24 個(gè) Gated MLA 層保留顯式 KV。這并不能讓百萬上下文在 64GB 機(jī)器上免費(fèi)運(yùn)行但它避免了 93 層全部采用全注意力時(shí)更嚴(yán)重的緩存壓力。K3 官方建模代碼依賴 CUDA 環(huán)境下的 FLA 內(nèi)核語義。Deltafin 沒有重新實(shí)現(xiàn)整個(gè)模型而是懶加載 Moonshot 官方建模代碼并用純 PyTorch 的 KDA Shim 替代 CUDA-only 路徑。項(xiàng)目報(bào)告分塊執(zhí)行與逐步執(zhí)行可在約1e-9量級一致使 MPS、CUDA 或 CPU 可以承擔(dān)常駐主干而路由專家由 Metal 或原生 CPU MXFP4 內(nèi)核計(jì)算。六、從 20 分鐘到 14.6 秒優(yōu)化的重點(diǎn)不是算力6.1 I/O 優(yōu)化決定主要增益Deltafin 第一版約 20 分鐘才能生成一個(gè) token。最終獲得約 82 倍改善核心不是讓 M1 Max 完成 2.8T 次密集矩陣運(yùn)算而是讓它不讀取無關(guān)專家并把必須讀取的數(shù)據(jù)盡可能順序化、并行化和緩存友好化。優(yōu)化具體做法維護(hù)者測得的效果或意義專家合并讀取每個(gè)專家的 6 個(gè)連續(xù)張量合成一次 17.55MB Range Request相比逐張量請求約快 6.4 倍Raw-span 緩存緩存原分片字節(jié)不再封裝、解析新容器降低緩存命中后的軟件開銷并行pread16 個(gè)專家由線程池一起讀取macOS 冷讀從 mmap 缺頁的 0.87GB/s 提升到約 6.85GB/sF_NOCACHE專家流量繞開 Darwin 文件緩存污染防止約 25.8GB/token 的專家讀取驅(qū)逐主干頁緩存雙緩沖主干當(dāng)前層計(jì)算時(shí)后臺加載下一層隱藏一部分層間 I/O 等待上一 token 預(yù)取按上次路由結(jié)果預(yù)取下一次專家去重留出集上的專家選擇復(fù)用約 31%這里最反直覺的是F_NOCACHE通常讀取文件希望盡量進(jìn)入頁緩存但專家訪問稀疏且流量巨大盲目緩存會把每 token 都要使用的主干擠出去。Deltafin 因此把專家視為一次性流量把寶貴緩存留給復(fù)用更穩(wěn)定的 spine。6.2 計(jì)算側(cè)把解量化融合進(jìn)乘法MXFP4 能顯著縮小專家文件卻不能直接交給普通 BF16 矩陣乘法。若先把專家完整解量化再執(zhí)行 GEMV不僅增加臨時(shí)內(nèi)存還要多走一遍內(nèi)存帶寬。Deltafin 的原生內(nèi)核在讀取 4bit 權(quán)重后立即解碼并參與乘法平臺主干/注意力路由專家 MoEApple Silicon macOSPyTorch MPSMetal或原生 CPU 備選NVIDIA LinuxCUDA當(dāng)前仍為原生 CPU MXFP4尚無原生 CUDA MoE 內(nèi)核Linux aarch64CPUNEON MXFP4Linux x86-64CPUAVX2/FMA或兼容路徑Apple 路徑還使用自定義 Metal 內(nèi)核融合 int8 到 FP32、行縮放和復(fù)制。README 報(bào)告該步驟從每層 118ms 降至 21ms并在測試張量上保持 bit-exact。壓縮 int8 輸出頭則避免每個(gè) token 展開 4.7GB FP32 Head維護(hù)者的平衡 A/B 測試中它讓穩(wěn)態(tài)解碼中位數(shù)提高 17.3%。這些都是特定 M1 Max、特定代碼版本的實(shí)測不應(yīng)直接外推到所有 Mac。6.3 無損 n-gram 推測解碼當(dāng)生成文本出現(xiàn)重復(fù)片段時(shí)Deltafin 從已經(jīng)出現(xiàn)的后綴中免費(fèi)提出 n-gram 草稿再用一次雙位置前向驗(yàn)證。若草稿正確一次昂貴的數(shù)據(jù)路徑可以接受兩個(gè) token若錯(cuò)誤則通過不可變狀態(tài)引用回滾不復(fù)制約 475MB 狀態(tài)。與常見“小模型起草、大模型驗(yàn)證”不同這里沒有額外 Draft Model。項(xiàng)目聲稱其測試中的接受結(jié)果與逐 token 貪心序列完全一致因此屬于無損優(yōu)化。但收益取決于文本重復(fù)度不是每個(gè) token 都能加速。七、0.0687 token/s 是怎樣測出來的7.1 測試條件決定數(shù)字含義Deltafin README 給出的參考值來自維護(hù)者的一臺機(jī)器而不是第三方統(tǒng)一評測條件參考配置機(jī)器M1 Max10 核 CPU、32 核 GPU、64GB 統(tǒng)一內(nèi)存、內(nèi)置 NVMe模型模式Full本地安裝完整專家池主干/輸出頭int8 spine packed int8 output headMoE 后端Metal數(shù)值路徑Exact FP32 numerics關(guān)閉近似模式解碼Greedy關(guān)閉路由 TracePromptThe capital of France is5 token校驗(yàn)輸出Paris. The3 token樣本6 次完整模型運(yùn)行采用平衡 ABBA/BAAB Campaign穩(wěn)態(tài)口徑丟棄第一個(gè) Decode Step再計(jì)算后續(xù)解碼速度丟棄第一個(gè) Decode Step 很重要首步會受到進(jìn)程預(yù)熱、緩存狀態(tài)和初始化的影響。穩(wěn)態(tài)結(jié)果描述的是“模型已經(jīng)開始生成后后續(xù) token 有多快”不能拿它代替用戶從提交請求到看到第一個(gè)字的端到端延遲。7.2 結(jié)果應(yīng)拆成四個(gè)數(shù)字看指標(biāo)當(dāng)前 M1 Max 中位數(shù)波動范圍/說明Prefill / 首 token28.0 秒24.9 至 37.9 秒輸入只有 5 token穩(wěn)態(tài) Decode0.0687 token/s即 14.6 秒/token6 次運(yùn)行范圍 0.0503 至 0.0779 token/s3 token 模型時(shí)間56.5 秒包含首步與后續(xù)解碼新進(jìn)程完整墻鐘時(shí)間64.1 秒還包含進(jìn)程啟動和初始化換算成更直觀的體驗(yàn)0.0687 token/s x 60 s about 4.1 token/min 100 token / 0.0687 token/s about 1,456 s about 24.3 min因此它足以驗(yàn)證模型、研究路由和測試流式推理卻不適合正常聊天。K3 默認(rèn)包含思考過程一次完整回答很容易達(dá)到數(shù)百或數(shù)千 token即使 Prefill 很短生成也可能持續(xù)數(shù)小時(shí)。7.3 瓶頸已經(jīng)從計(jì)算轉(zhuǎn)到 SSDREADME 給出的一次代表性 Profile 約為主干讀取等待 5 秒、專家讀取 4.3 秒、主干傳輸與解量化 3 秒、注意力和歸一化 2 秒、專家矩陣乘約 1 秒。各階段存在流水重疊近似值不能機(jī)械相加但方向十分明確數(shù)據(jù)搬運(yùn)遠(yuǎn)大于 MoE 算術(shù)本身。主干約 53GB每個(gè) token 都要重讀項(xiàng)目觀測到該訪問模式約 7GB/s理論上僅這一路徑就要約 7.5 秒。更多 RAM 能保留更多主干頁和專家緩存更快 SSD 能縮短冷讀在這類工作負(fù)載中升級存儲與內(nèi)存往往比增加 GPU 算力更直接。八、Full 與 Stream兩種模式不是同一種“本地”8.1 容量換時(shí)間還是網(wǎng)絡(luò)換容量維度--full完整模式--stream流式模式磁盤需求約 1.7TB約 215GB 起步緩存持續(xù)增長初次下載約 5 至 10 小時(shí)可斷點(diǎn)續(xù)傳約 30 分鐘推理網(wǎng)絡(luò)下載后無需網(wǎng)絡(luò)持續(xù)需要 Hugging Face 或鏡像未緩存專家速度M1 Max 中位數(shù)約 14.6 秒/token約 3 分鐘以上/token適用目的穩(wěn)定復(fù)現(xiàn)、離線研究、性能測試低門檻嘗試、逐步建立專家緩存Full 模式仍不等于“模型全部在內(nèi)存中”只是把完整權(quán)重放到了本地 SSD。Stream 模式則把 Hugging Face CDN 視為更慢的遠(yuǎn)程存儲路由命中本地沒有的專家時(shí)用一次 HTTP Range 拉取約 17.55MB 原始跨度再寫入磁盤緩存。對 Chat CompletionStream 模式尤其不友好。聊天模板本身可超過 60 個(gè) Prompt Token而 Prefill 會讓多位置、多層路由觸碰大量專家緩存較空時(shí)單次請求可能花數(shù)小時(shí)下載。因此想復(fù)現(xiàn) 0.0687 token/s必須使用 Full 模式而不是只完成 215GB 的流式安裝。8.2 安裝與命令行運(yùn)行環(huán)境要求包括 Python 3.12、PyTorch、Xcode Command Line Tools以及至少約 1.7TB 可用空間。官方 README 的基本流程如下gitclone https://github.com/gavamedia/deltafin.gitcddeltafin python3-mvenv venv ./venv/bin/pipinstalltorch numpy safetensors tiktoken ml_dtypes blobfile\transformers4.56.2einops tokenizers python3 tools/build_native.py ./venv/bin/python tools/setup_k3.py--full完成安裝后可以運(yùn)行與基準(zhǔn)相同的原始補(bǔ)全文本./venv/bin/python tools/kimi_run.py\--promptThe capital of France is\--max-new16也可以啟動 OpenAI 兼容服務(wù)./venv/bin/python tools/serve_openai.py--port8000fromopenaiimportOpenAI clientOpenAI(base_urlhttp://127.0.0.1:8000/v1,api_keynone,timeout7200.0,)responseclient.chat.completions.create(modeldeltafin-kimi-k3,messages[{role:user,content:Explain mixture of experts.}],)print(response.choices[0].message.content)服務(wù)實(shí)現(xiàn)了/v1/chat/completions、/v1/completions和/v1/models也支持流式響應(yīng)。但兼容的是接口形狀不是完整采樣語義當(dāng)前只支持貪心解碼temperature與top_p雖會被接受卻被忽略同時(shí)只能處理一個(gè)請求第二個(gè)并發(fā)請求會得到 HTTP 429每個(gè)新請求還會建立新的 KV 與狀態(tài)緩存。九、橫向?qū)Ρ菵eltafin 不是本地高性能推理引擎9.1 五條路線解決的是不同問題路線主要目標(biāo)權(quán)重放在哪里優(yōu)勢主要代價(jià)Deltafin在小內(nèi)存工作站跑通完整 K3SSD 為主當(dāng)前層進(jìn)入 MPS/CPU64GB M1 Max 可驗(yàn)證 2.8T 模型Full 可離線約 14.6 秒/token需約 1.7TB SSDvLLM/SGLang/TokenSpeed官方推薦的高吞吐 K3 部署大容量多卡加速器內(nèi)存面向服務(wù)吞吐、并發(fā)和標(biāo)準(zhǔn)推理工作流硬件與運(yùn)維門檻遠(yuǎn)高于單臺 Macllama.cpp 類量化常駐消費(fèi)級設(shè)備高效運(yùn)行可容納模型RAM/統(tǒng)一內(nèi)存為主可部分 Offload工具成熟、交互速度更實(shí)用對 1.56TB K3 仍受總?cè)萘肯拗芻olibri / ds4研究 MoE 專家流式與緩存RAM SSD 分層提供專家預(yù)取、固定、淘汰和零拷貝經(jīng)驗(yàn)?zāi)Ｐ瓦m配、質(zhì)量驗(yàn)證和性能依賴實(shí)現(xiàn)Kimi 云 API直接使用 K3 能力云端集群無需下載 1.7TB響應(yīng)和并發(fā)更實(shí)用數(shù)據(jù)、成本、網(wǎng)絡(luò)和服務(wù)依賴由云端決定這張表沒有一個(gè)“全面獲勝者”。想研究 K3 的實(shí)際權(quán)重、路由分布或極限單機(jī)部署Deltafin 提供了此前缺少的入口想每天使用 K3云 API 更合理擁有多機(jī)多卡資源并追求吞吐則應(yīng)優(yōu)先使用官方模型卡推薦的 vLLM、SGLang 或 TokenSpeed。9.2 Deltafin 的真正生態(tài)位主流本地推理項(xiàng)目優(yōu)化的是“如何讓一個(gè)放得下的模型跑得更快”Deltafin 解決的是“如何讓一個(gè)完全放不下的稀疏模型先跑起來”。兩者的目標(biāo)函數(shù)不同Conventional local inference: fit the model - minimize latency - maximize throughput Deltafin: preserve the full model - make one exact token possible - then reduce I/O這也解釋了項(xiàng)目為何強(qiáng)調(diào)精確貪心輸出、Exact FP32 Numerics 和可回滾推測解碼。對存在性證明而言若為了速度隨意減少 Top-K 或使用不可控近似雖然 token 變快卻無法確認(rèn)運(yùn)行的還是不是同一個(gè)模型。Deltafin 提供K3_MOE_TOP_K和K3_APPROX等實(shí)驗(yàn)開關(guān)但參考基準(zhǔn)沒有用這些損失質(zhì)量的捷徑。十、限制、風(fēng)險(xiǎn)與復(fù)現(xiàn)邊界10.1 它還不是聊天產(chǎn)品限制實(shí)際影響穩(wěn)態(tài)僅 4.1 token/分鐘一段正?；卮鹂赡艿却龓资昼姷綌?shù)小時(shí)長 Prompt Prefill 昂貴Agent 系統(tǒng)提示、代碼倉庫和聊天模板會顯著放大首字延遲單請求串行無法作為多人并發(fā)服務(wù)自動化工具需處理 429僅貪心解碼不能通過temperature、top_p獲得常見采樣多樣性請求狀態(tài)不復(fù)用每次請求建立新的 KV/KDA 狀態(tài)重復(fù)長前綴成本高質(zhì)量評測仍有限當(dāng)前主要驗(yàn)證確定性 token 與數(shù)值路徑不是完整能力回歸基準(zhǔn)維護(hù)者自己把 Deltafin 稱為 research artifact 和 existence proof。這種定位是誠實(shí)的它證明的是“能夠執(zhí)行”而不是“適合交互”。10.2 SSD、散熱和可用空間Full 模式約占 1.7TB已經(jīng)超過很多 Mac 的全部內(nèi)置容量外接 SSD 是否能達(dá)到相同速度還取決于接口、控制器、文件系統(tǒng)和隨機(jī)讀取表現(xiàn)。持續(xù)數(shù)十 GB/token 的邏輯讀取可能引起 SSD 溫度上升和降速需要在長時(shí)間實(shí)驗(yàn)中監(jiān)控溫度與吞吐。讀流量不能簡單等同于 NAND 寫入壽命。Full 模式推理主要是讀取Stream 模式緩存未命中專家時(shí)才會產(chǎn)生額外寫入。實(shí)際物理 I/O 還受頁緩存、預(yù)取和復(fù)用影響因此不能從 78.8GB 邏輯路徑直接推導(dǎo)硬盤壽命。10.3 軟件成熟度與許可證截至 2026 年 7 月 29 日項(xiàng)目剛公開約一天、沒有正式 ReleaseLinux 與 CUDA 路徑也還在擴(kuò)展驗(yàn)證。復(fù)現(xiàn)前應(yīng)固定 Commit而不是只記錄main分支PyTorch、Metal 與操作系統(tǒng)升級也可能改變算子支持和性能。Deltafin 自身代碼使用 MIT License但 Kimi K3 權(quán)重和官方建模代碼遵循獨(dú)立的Kimi K3 License不能因?yàn)橥鈱蛹虞d器是 MIT 就忽略模型許可證。Deltafin 也明確聲明與 Moonshot AI 沒有關(guān)聯(lián)。下載 1.56TB 模型前還應(yīng)核對來源、剩余空間、網(wǎng)絡(luò)費(fèi)用和目標(biāo)用途是否符合許可要求。十一、橫縱交匯模型規(guī)模的邊界正在從容量變成數(shù)據(jù)編排縱向看本地推理先依賴量化縮小模型再依賴 CPU/GPU 分層擴(kuò)大可用內(nèi)存如今開始進(jìn)一步把 SSD 和網(wǎng)絡(luò)納入逐 token 權(quán)重層級。Deltafin 的出現(xiàn)不是說明“磁盤可以替代 GPU”而是說明 MoE 的條件計(jì)算為更激進(jìn)的存儲分層留下了結(jié)構(gòu)性機(jī)會。橫向看Deltafin 不會在速度上取代云 API、多卡 vLLM 或能常駐內(nèi)存的 llama.cpp 模型。它的優(yōu)勢只在一個(gè)非常窄、卻有研究價(jià)值的區(qū)域保留完整超大 MoE 模型在遠(yuǎn)低于模型權(quán)重規(guī)模的內(nèi)存中完成可驗(yàn)證推理。未來性能提升更可能來自以下方向而不是單純增加 GPU 核心方向?yàn)槭裁从行枰?yàn)證的問題更大內(nèi)存讓 53GB int8 主干和更多專家停留在頁緩存內(nèi)存容量增加能否穩(wěn)定轉(zhuǎn)化為物理讀取下降更快 NVMe直接縮短主干與專家讀取隨機(jī)讀取、散熱和文件系統(tǒng)是否成為新瓶頸更聰明的路由預(yù)取利用相鄰 token 專家選擇相關(guān)性31% 復(fù)用能否用模型預(yù)測進(jìn)一步提高原生 CUDA MXFP4 MoE避免 NVIDIA 路徑的 CPU 專家計(jì)算數(shù)據(jù)搬運(yùn)是否會抵消 GPU 算術(shù)收益主干進(jìn)一步壓縮每 token 必讀區(qū)域每減少 1GB 都有持續(xù)收益質(zhì)量損失如何用完整 NLL/任務(wù)基準(zhǔn)衡量原生執(zhí)行引擎減少 Python、分配器與框架調(diào)度開銷在 I/O 主導(dǎo)后軟件常數(shù)還能貢獻(xiàn)多少最重要的判斷是2.8T 不再天然意味著“必須先擁有能容納 2.8T 權(quán)重的內(nèi)存”但也不意味著容量約束消失了。Deltafin 只是把硬邊界改造成一條很慢的數(shù)據(jù)通道。只有當(dāng)緩存、預(yù)取、量化與存儲帶寬共同進(jìn)步這條通道才可能從實(shí)驗(yàn)走向工具。十二、總結(jié)維度核心結(jié)論為什么能跑K3 每層只激活 16/896 個(gè)路由專家Deltafin 無需同時(shí)載入 2.8T 參數(shù)如何存放約 53GB 至 60GB int8 主干逐層讀取約 1.45TB 專家池留在 SSD 或 CDN數(shù)據(jù)成本每 token 讀取約 25.8GB 專家連同主干約形成 78.8GB 邏輯路徑主要優(yōu)化合并范圍讀取、并行pread、F_NOCACHE、雙緩沖、路由預(yù)取、融合 MXFP4 GEMV實(shí)測速度維護(hù)者的 M1 Max Full 模式穩(wěn)態(tài)中位數(shù)為 0.0687 token/s即 14.6 秒/token實(shí)際定位研究原型與存在性證明不是可交互聊天服務(wù)工程意義超大稀疏模型的部署邊界開始由內(nèi)存容量轉(zhuǎn)向權(quán)重布局和存儲調(diào)度Deltafin 最值得記住的不是“一臺 Mac 也能秒跑 2.8T 模型”而是一個(gè)更克制也更重要的結(jié)論一臺 64GB M1 Max 可以在不裁剪 Kimi K3 專家池的前提下依靠 SSD 流式執(zhí)行完整模型代價(jià)是每個(gè) token 仍需約 14.6 秒。它把一個(gè)原本會在加載階段直接失敗的問題變成了可以測量、剖析和持續(xù)優(yōu)化的 I/O 系統(tǒng)問題。對日常用戶這個(gè)速度太慢對本地推理工程而言它已經(jīng)打開了一條值得繼續(xù)探索的路徑。十三、參考資料Deltafin GitHub Repository — gavamediaREADME 與代碼訪問日期2026-07-29Kimi K3 Model Card — Moonshot AI訪問日期2026-07-29Kimi K3 config.json — Moonshot AI訪問日期2026-07-29Kimi K3 License — Moonshot AI訪問日期2026-07-29colibri — JustVuggMoE 專家流式推理項(xiàng)目ds4 / DwarfStar — antirezMoE 磁盤流式推理項(xiàng)目llama.cpp — ggml-org本地量化推理參考項(xiàng)目Kimi Linear: An Expressive, Efficient Attention ArchitectureKDA 與混合線性注意力論文注本文所有 Deltafin 性能數(shù)字均來自項(xiàng)目維護(hù)者截至 2026 年 7 月 29 日公開的參考測試未被本文作者獨(dú)立復(fù)現(xiàn)由這些數(shù)字得到的分鐘數(shù)與約 78.8GB/token 為算術(shù)換算。項(xiàng)目迭代很快后續(xù) Commit、硬件、系統(tǒng)緩存與存儲狀態(tài)都可能改變結(jié)果。