导航菜单可进行导航切换有登录入口 [ 登录 ] 还有外观设置。平台-AI 代码创作- [GitHub Copilot借助 AI 编写更优质代码]- [GitHub Copilot 应用从问题到合并实现直接代理]- [MCP 注册表集成外部工具]-开发者工作流程- [Actions自动化任何工作流程]- [Codespaces即时开发环境]- [Issues规划和跟踪工作]- [代码审查管理代码变更]- [代码质量在合并时强制执行质量标准]-应用程序安全- [GitHub 高级安全发现并修复漏洞]- [代码安全在构建过程中保障代码安全]- [密钥保护防患于未然阻止信息泄露]-探索- [为何选择 GitHub]- [文档]- [博客]- [更新日志]- [市场][查看所有功能]解决方案-按公司规模划分- [企业版]- [中小型团队版]- [初创公司版]- [非营利组织版]-按用例划分- [应用现代化]- [DevSecOps]- [DevOps]- [CI/CD]- [查看所有用例]-按行业划分- [医疗保健]- [金融服务]- [制造业]- [政府机构]- [查看所有行业][查看所有解决方案]资源-按主题探索- [AI]- [软件开发]- [DevOps]- [安全]- [查看所有主题]-按类型探索- [客户案例]- [活动与网络研讨会]- [电子书与报告]- [商业洞察]- [GitHub Skills]-支持与服务- [文档]- [客户支持]- [社区论坛]- [信任中心]- [合作伙伴][查看所有资源]开源-社区- [GitHub Sponsors资助开源开发者]-项目- [安全实验室]- [维护者社区]- [加速器]- [GitHub Stars]- [存档计划]-仓库- [主题]- [热门项目]- [集合]企业-企业解决方案- [企业平台由 AI 驱动的开发者平台]-可用插件- [GitHub 高级安全企业级安全功能]- [Copilot for Business企业级 AI 功能]- [高级支持企业级 7×24 小时支持][定价]可进行搜索或跳转搜索代码、仓库、用户、问题、拉取请求等还有搜索语法提示 [搜索语法提示] 。也可提供反馈我们会阅读并重视您的意见还可选择包含电子邮件地址以便联系。保存的搜索使用保存的搜索能更快速地筛选结果要查看所有可用限定符可参阅 [文档] 。有登录 [ 登录 ] 和注册 [ 注册 ] 选项以及外观设置。若在其他标签页或窗口有登录、注销、切换账户操作需 [重新加载] 刷新会话。若加载出现错误[请重新加载此页面] 。[ sqliteai ] /[waste]公开有通知、分叉、加星等操作还有代码、问题、拉取请求、操作、项目、安全与质量、洞察等导航选项。主分支有分支和标签选项 [分支][标签] 可转到文件查看代码还能打开更多操作菜单。文件和文件夹名称名称最后提交信息最后提交日期最新提交历史记录[128 次提交][128 次提交]有多个文件和目录路径如 [.github/workflows] 、 [cli] 等可查看所有文件。仓库文件导航- README- Apache 2.0 许可证WASTE — 加权感知流式张量引擎Kimi K3 — 2.78 万亿参数 — 在消费级笔记本电脑上运行$ waste run ~/models/k3.waste What is the capital of Italy?waste: no --budget, using 46.24 GB of 64.00 GB (expert cache 17.56 GB)The capital of Italy isRome.[16 tokens, 31.09 s, 0.51 tok/s | experts 3357 hit / 20195 miss 14%]WASTE 是用 C 语言编写的可嵌入推理引擎无需第三方运行时依赖它将模型主干存于内存从磁盘流式传输所选专家剩余 RAM 用作有界专家缓存。当前验证案例是完整开放权重 Kimi K3 模型2.78 万亿参数转换为 982 GiB 容器在 64 GB 的 MacBook Pro 上以每秒 0.49 - 0.54 个 token 的速度运行且不是经过蒸馏、剪枝或缩减的变体。模型容器最小 RAM测试速度Kimi K3 2.78T982 GiB29.05 GiB0.49 - 0.54 tok/sKimi-Linear 48B19 GiB1.87 GiB10.7 tok/sWASTE 为该模型和特定约束设计因 K3 无法装入当前主流消费级系统的 RAM它发布时 1.42 TB转换后 982 GB混合专家模型每个 token 约激活自身 4% 参数多数权重闲置只需及时可访问WASTE 将其存磁盘流式传输所需数据剩余 RAM 用于重复使用部分。当前进展该引擎计算结果准确每层与 PyTorch 参考验证最终对数几率误差在 3.6e - 06 以内视觉塔与自身预测误差在 2.3e - 06 以内但速度慢每秒处理半个 token处理上述句子需 30 秒。目前还无公开案例能在消费级机器上从磁盘流式运行如此大规模模型也没找到万亿级 NVMe 流式传输案例671B 级模型通常需 1 TB DDR5 服务器运行。这里是搜索结果非全面调查仓库无参考文献和比较表格更像邀请提供反例。有趣的是整个模型在单台消费级机器可运行后续问题更多是工程实现层面而非可行性层面。优化重点已改变专家读取与算术运算重叠使速度提升约 1.6 倍且已实现减少每个 token 读取字节数和增加内存缓存两个优化方向被放弃一是模型系列路由器无可缩减部分二是买不到能常驻机器内存的缓存。读取操作占解码步骤 55%算术运算占 27%接下来优化方向是用更快磁盘或增加机器 RAM而非调整内核。[docs/EFFICIENCY.md] 记录每个优化方向评估过程。此情况开启新领域前沿规模模型可在无网络连接、无需按 token 计费、数据不出本地机器的情况下运行该格式和引擎并非针对 K3 设计K3 只是最具挑战性案例能以 2.78T 规模流式运行的模型在 48B 规模下运行更轻松。本文档所有数据在发布时提交版本测量错误数据记录在 [docs/LEARNED.md] 而非悄悄修正。命名由来云服务回答每个 token 有账单费用和电力消耗双重代价而这些模型可在办公桌上现有硬件运行WASTE 旨在终结 token 浪费现象首字母缩写词后来确定。所需条件项目要求磁盘用于存储模型转换后的容器需要982 GB空间建议预留 1 TB磁盘用于转换过程另外需要 1.42 TB 的临时空间来存储发布的分片转换完成后可释放RAM打开 K3 模型在 4K 上下文下至少需要29.05 GB本文中的测试数据是在64 GB内存下获得的存储速度容器必须存放在内部 NVMe 磁盘上详见下文编译环境需要 C11 编译器和 make。运行时无需 BLAS、CUDA 或 Python存储大小采用二进制单位与 df 命令和引擎报告方式一致容器大小 982 GiB磁盘厂商通常称 1.05 TB。引擎启动最小 RAM 几乎全用于存储 27.28 GB 常驻主干要获理想吞吐量内存需求更高64 GB 机器上引擎分配 46 GB 预算17.56 GB 用于专家缓存这是测试最佳配置。32 GB 机器理论上可打开模型但会有严重内存分页问题建议 64 GB 为实际最低要求。存储速度很关键每个 token 需要读取 17 GB 专家数据内部 SSD 读取速度 12.78 GB/s 时模型可流畅流式运行USB 外接硬盘读取速度 0.94 GB/s处理同一 token 需要 13 秒所以要将模型转换到内部 NVMe 磁盘外部磁盘仅用于下载。若没有 1 TB 可用空间同样的引擎和格式可运行 Kimi-Linear-48B-A3B-Instruct 模型该模型容器大小19 GB最低 RAM 要求1.87 GB运行速度可达 10.7 tok/s是尝试 WASTE 的不错选择。特点-自包含只有一个 libwaste.a 库文件和一个 waste 二进制文件运行时仅依赖 libc 和 pthreads。-零依赖推理过程无需 BLAS、ONNX 或 Python无需安装额外依赖项tools/ 目录下 Python 脚本用于模型转换和引擎验证不与推理过程同时运行。-完全可嵌入[src/waste.h] 中提供 26 个公共函数用于在内存上限内打开模型、生成结果、保存会话和关闭模型CLI 是该 API 的客户端不涉及私有部分CLI 能完成的任务嵌入宿主也可完成。waste_cfg cfg;waste_cfg_init(cfg);cfg.ram_budget_bytes 46ULL 30; /* 严格的内存上限而非建议值0 表示根据当前机器自动调整 */waste_ctx *ctx;if (waste_open(/path/to/k3.waste, cfg, ctx) ! WASTE_OK) return 1;waste_generate(ctx, ids, n, params, on_token, user);waste_close(ctx);这里路径是转换器生成的容器目录不支持 ~ 缩写这是 shell 的功能。工作原理数据布局决定速度模型会一次性转换为 .waste 容器包含 JSON 清单、常驻主干和每层一个专家库每个专家记录与门控信息按 4 KiB 对齐上下矩阵相邻路由到一个专家只需一次 pread 操作而非三次也无需为每个矩阵寻道算术运算不是瓶颈。读取操作绕过页面缓存macOS 用 F_NOCACHELinux 用 O_DIRECTWindows 用 FILE_FLAG_NO_BUFFERING因容器小于 RAM 时内核会缓存所有数据测得命中率不真实处理 982 GB 模型不适用。每个记录头部读取时会检查确保魔数正确、索引指向专家无误、偏移量合法若专家库截断或拼接生成过程会停止并指出问题记录不使用错误数据计算此检查开销可忽略。记录含 crc32 校验和--verify 选项可开启校验默认关闭开启后每次缓存未命中时对每个记录校验Kimi - Linear 模型约占 5% 开销K3 模型约占 1%复制、下载或存储在不可信磁盘上的容器开启校验有必要自己转换并一直读取的容器通常无需开启。详见 [docs/FORMAT.md]。每个专家权重 3 位存储专家数据采用残差向量量化存储对 8 维向量用 256 个元素码本进行三级量化每个权重占 3.00 位矩阵不实际展开。对于每个 token引擎为每个码本条目和向量位置构建部分点积表之后每个专家行计算只需三次表查找和两次加法操作。主干部分仍用 4 位和 8 位存储该模型仅对专家部分进行量化感知训练主干部分未针对低精度量化训练。曾尝试构建并测试 3 位主干虽缓存预测结果符合预期但吞吐量下降输出结果混乱。缓存下限为一个 token 的工作集这是项目最具参考价值的数据K3 模型每个 token 触及 92 层中 16 个专家需 17.0 GB 数据缓存小于此值为一个 token 缓存的专家数据处理下一个 token 前会被淘汰命中率为零缓存超过此值命中率曲线急剧上升。预算专家缓存命中率解码速度32 GB3.32 GB0%0.31 tok/s46 GB17.32 GB13%0.32 tok/s52 GB23.32 GB27%0.11 - 0.14 tok/s58 GB29.32 GB37%0.04 tok/s以上数据在空闲机器上按顺序测量测量顺序重要52 GB 和 58 GB 测试后机器进入内存分页状态再测 46 GB 速度降至 0.22 - 0.25 tok/s虽命中率和未命中计数与之前测量结果相同但机器状态影响性能且每次运行后机器不完全恢复建议逐步增加内存预算测试。解码速度列数据在预读取功能前测量目前 46 GB 预算下解码速度为 0.51 tok/s而非 0.32 tok/s表格主要展示内存预算与性能关系预读取功能将 I/O 操作隐藏在算术运算后提高各预算下速度但不改变性能曲线形状。内存设计核心目标是使内存使用超过下限因此引擎优先释放 RAM 而非节省。而且存在上限比看起来更近命中率随内存预算增加先上升后下降64 GB 机器上缓存 58 GB 时命中率 37%但引擎速度比 46 GB 时慢八倍引擎未超内存预算但机器无法承受操作系统将专家缓存换出到磁盘“命中” 变成页面错误而非引擎原本管理的磁盘读取操作。所以可用内存窗口窄缓存约 46 GB 时满足一个 token 工作集需求达到 52 GB 时机器出现内存分页问题即使空闲机器运行前有 49 GB 可用内存窗口也易受无关因素影响如从常驻集中移除 1.11 GB 嵌入表并放入缓存会使 58 GB 预算下速度从 0.32 tok/s 降至 0.04 tok/s。因此默认情况下不将内存填满专家缓存达到或超过一个工作集整数倍才有意义超过部分虽提高命中率但使机器更接近内存分页状态引擎自动选择内存预算时逐步减少一个工作集大小直到满足内存八分之七以下且不低于最低要求如 K3 模型需 80.63 GB最低要求 3 倍工作集但笔记本只能获 46 GB 预算最低要求 1 倍工作集其中专家缓存 17.56 GB这是性能曲线峰值无需额外设置参数128 GB 机器可满足 3 倍工作集需求。早期版本尽可能使用所有可用内存此机器设置 27 GB 缓存速度在 0.11 - 0.04 tok/s 之间表明不受控制的缓存不是有效缓存引擎应在操作系统回收内存前停止请求内存。线性注意力和吸收式 KV 缓存K3 的注意力机制采用 3:1 混合模式包括 Kimi Delta Attention携带固定大小循环状态而非不断增长的 KV 缓存和门控多头潜在注意力gated multi - head latent attentionMLA 层缓存 512 维潜在向量而非每个头扩展后的键值对kv_b_proj 操作被吸收到查询和输出中q_nope · (W_kb c) (W_kbᵀ q_nope) · cΣ_s a_s (W_vb c_s) W_vb (Σ_s a_s c_s)这种方式使对数几率误差控制在 1.2e - 05 以内且缓存大小减少 53 倍4K 上下文下缓存大小从 11.25 GB 降至 0.21 GB也使长上下文处理成为可能扩展布局在 128K 个 token 时需 360 GB 缓存潜在向量布局只需 7.2 GB。性能和内存测试环境为 MacBook Pro M5 Pro64 GB 内存容器存储在内部 SSD 上所有数据在发布时提交版本测量。Kimi K3 — 2.78T 参数982 GB 容器项目指标最小 RAM4K 上下文下29.05 GB32K 上下文下 30.54 GB128K 上下文下 35.63 GB1M 上下文下 83.21 GB常驻主干27.28 GB每个 token 读取量17.0 GB通过两个线程预读取与矩阵乘法操作重叠模型加载时间20 秒预填充速度分块处理时为 0.47 tok/s顺序处理时为 0.29 tok/s预读取功能开启前解码速度默认预算下为 0.49 - 0.54 tok/s这是该机器的最佳性能视觉塔处理时间处理 1024 个补丁的图像需要 15.7 秒共 27 层提示中包含图像896x896 图像占用 256 个位置每个位置处理时间为 2.8 秒按文本方式处理最小内存要求主要用于存储常驻主干内存超过约 46 GB 时专家缓存满足一个 token 工作集需求获理想吞吐量达到 52 GB 时机器出现内存分页问题性能急剧下降两界限间额外内存对性能提升无帮助甚至有负面影响此机器上可用内存窗口只有一个预算宽度。视觉塔处理时间不等于图像总处理成本编码 1024 个补丁需 15.7 秒生成的 256 个位置像其他 token 一样经过 92 层混合专家MoE层又需 731 秒图像按相同长度文本计费因此 vision.json 中补丁预算是关键参数将网格大小减半可使提示长度减半。Kimi - Linear — 48B 参数19 GB 容器项目指标最小 RAM1.87 GB解码速度8 GB 预算下为10.7 tok/s缓存命中率为 78%同样的引擎和格式在能轻松装入内存的模型上表现出色展示了 WASTE 在无内存压力时的性能。时间分布在 K3 模型上解码缓存为 17.32 GB 且冷启动前十步命中率为 6.7%新提示开始状态时间分布如下部分占比MoE 层全部82.5%其中专家 I/O53.5%其中专家矩阵乘法20.0%KDA 层14.5%MLA 层2.8%lm_head 层0.2%可用 WASTE_PROFILE 1 WASTE_CACHE_MB 17735 ./test_forward MODEL 1008,10484,318,15383,387 out.bin 5 命令重现结果随缓存变暖I/O 占比下降长时间会话性能优于上述数据但各部分占比排名不变。I/O 操作接近硬件极限每个 token 需读取 17.0 GB 数据速度约 9.9 GB/sSSD 测量速度为 12.78 GB/s降低 I/O 成本唯一方法是减少读取次数即增加缓存、增加 RAM这是目前优化主要方向也是后续步骤侧重内存优化而非算术运算优化的原因。快速开始git clone https://github.com/sqliteai/waste cd wastemake # 生成 libwaste.a, waste, libwastevqmake check # 新克隆的仓库中23 个测试通过11 个跳过无需配置步骤和依赖解析make check 不需要模型它构建小型合成容器并测试引擎跳过的 11 个测试需要克隆仓库中没有的资源如 PyTorch 参考模型、与源分片的往返测试、使用文本驱动 CLI 的测试因合成容器没有分词器以及 K3 模型的测试需要容器和发布版本在磁盘上若两个容器都存在测试套件将包含 36 个测试。转换 Kimi K3 模型转换是唯一需要 Python 的步骤且只需执行一次源模型为 [moonshotai/Kimi - K3]与发布时完全一致包含 96 个 safetensors 分片大小为 1.42 TB无需打补丁# 1. 预检是否可达大小如何是否有足够空间tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry - run# 2. 下载 —— 可断点续传可安全终止和重新运行tools/fetch_weights.sh --dest /Volumes/staging/k3# 3. 转换为容器uv run --with torch --with safetensors python tools/convert.py \ --src /Volumes/staging/k3 \ --out ~/models/k3.waste --jobs 3上述命令将生成 982 GB 的容器本文中的所有数据均基于此容器测量在 M5 Pro 上使用三个进程进行转换大约需要4.7 小时使用纯 PyTorch 编码器需要 23.7 小时详见 [docs/K3.md]目标卷需要约 1.0 TB 的可用空间转换器支持断点续传中断的转换只需重新运行即可继续。下载过程可能会出现问题长时间下载 1.42 TB 的数据可能会遇到连接中断、CDN 5xx 。
WASTE引擎：让2.78万亿参数模型在消费级笔记本运行，速度与内存优化有进展！
发布时间：2026/8/2 17:52:09
导航菜单可进行导航切换有登录入口 [ 登录 ] 还有外观设置。平台-AI 代码创作- [GitHub Copilot借助 AI 编写更优质代码]- [GitHub Copilot 应用从问题到合并实现直接代理]- [MCP 注册表集成外部工具]-开发者工作流程- [Actions自动化任何工作流程]- [Codespaces即时开发环境]- [Issues规划和跟踪工作]- [代码审查管理代码变更]- [代码质量在合并时强制执行质量标准]-应用程序安全- [GitHub 高级安全发现并修复漏洞]- [代码安全在构建过程中保障代码安全]- [密钥保护防患于未然阻止信息泄露]-探索- [为何选择 GitHub]- [文档]- [博客]- [更新日志]- [市场][查看所有功能]解决方案-按公司规模划分- [企业版]- [中小型团队版]- [初创公司版]- [非营利组织版]-按用例划分- [应用现代化]- [DevSecOps]- [DevOps]- [CI/CD]- [查看所有用例]-按行业划分- [医疗保健]- [金融服务]- [制造业]- [政府机构]- [查看所有行业][查看所有解决方案]资源-按主题探索- [AI]- [软件开发]- [DevOps]- [安全]- [查看所有主题]-按类型探索- [客户案例]- [活动与网络研讨会]- [电子书与报告]- [商业洞察]- [GitHub Skills]-支持与服务- [文档]- [客户支持]- [社区论坛]- [信任中心]- [合作伙伴][查看所有资源]开源-社区- [GitHub Sponsors资助开源开发者]-项目- [安全实验室]- [维护者社区]- [加速器]- [GitHub Stars]- [存档计划]-仓库- [主题]- [热门项目]- [集合]企业-企业解决方案- [企业平台由 AI 驱动的开发者平台]-可用插件- [GitHub 高级安全企业级安全功能]- [Copilot for Business企业级 AI 功能]- [高级支持企业级 7×24 小时支持][定价]可进行搜索或跳转搜索代码、仓库、用户、问题、拉取请求等还有搜索语法提示 [搜索语法提示] 。也可提供反馈我们会阅读并重视您的意见还可选择包含电子邮件地址以便联系。保存的搜索使用保存的搜索能更快速地筛选结果要查看所有可用限定符可参阅 [文档] 。有登录 [ 登录 ] 和注册 [ 注册 ] 选项以及外观设置。若在其他标签页或窗口有登录、注销、切换账户操作需 [重新加载] 刷新会话。若加载出现错误[请重新加载此页面] 。[ sqliteai ] /[waste]公开有通知、分叉、加星等操作还有代码、问题、拉取请求、操作、项目、安全与质量、洞察等导航选项。主分支有分支和标签选项 [分支][标签] 可转到文件查看代码还能打开更多操作菜单。文件和文件夹名称名称最后提交信息最后提交日期最新提交历史记录[128 次提交][128 次提交]有多个文件和目录路径如 [.github/workflows] 、 [cli] 等可查看所有文件。仓库文件导航- README- Apache 2.0 许可证WASTE — 加权感知流式张量引擎Kimi K3 — 2.78 万亿参数 — 在消费级笔记本电脑上运行$ waste run ~/models/k3.waste What is the capital of Italy?waste: no --budget, using 46.24 GB of 64.00 GB (expert cache 17.56 GB)The capital of Italy isRome.[16 tokens, 31.09 s, 0.51 tok/s | experts 3357 hit / 20195 miss 14%]WASTE 是用 C 语言编写的可嵌入推理引擎无需第三方运行时依赖它将模型主干存于内存从磁盘流式传输所选专家剩余 RAM 用作有界专家缓存。当前验证案例是完整开放权重 Kimi K3 模型2.78 万亿参数转换为 982 GiB 容器在 64 GB 的 MacBook Pro 上以每秒 0.49 - 0.54 个 token 的速度运行且不是经过蒸馏、剪枝或缩减的变体。模型容器最小 RAM测试速度Kimi K3 2.78T982 GiB29.05 GiB0.49 - 0.54 tok/sKimi-Linear 48B19 GiB1.87 GiB10.7 tok/sWASTE 为该模型和特定约束设计因 K3 无法装入当前主流消费级系统的 RAM它发布时 1.42 TB转换后 982 GB混合专家模型每个 token 约激活自身 4% 参数多数权重闲置只需及时可访问WASTE 将其存磁盘流式传输所需数据剩余 RAM 用于重复使用部分。当前进展该引擎计算结果准确每层与 PyTorch 参考验证最终对数几率误差在 3.6e - 06 以内视觉塔与自身预测误差在 2.3e - 06 以内但速度慢每秒处理半个 token处理上述句子需 30 秒。目前还无公开案例能在消费级机器上从磁盘流式运行如此大规模模型也没找到万亿级 NVMe 流式传输案例671B 级模型通常需 1 TB DDR5 服务器运行。这里是搜索结果非全面调查仓库无参考文献和比较表格更像邀请提供反例。有趣的是整个模型在单台消费级机器可运行后续问题更多是工程实现层面而非可行性层面。优化重点已改变专家读取与算术运算重叠使速度提升约 1.6 倍且已实现减少每个 token 读取字节数和增加内存缓存两个优化方向被放弃一是模型系列路由器无可缩减部分二是买不到能常驻机器内存的缓存。读取操作占解码步骤 55%算术运算占 27%接下来优化方向是用更快磁盘或增加机器 RAM而非调整内核。[docs/EFFICIENCY.md] 记录每个优化方向评估过程。此情况开启新领域前沿规模模型可在无网络连接、无需按 token 计费、数据不出本地机器的情况下运行该格式和引擎并非针对 K3 设计K3 只是最具挑战性案例能以 2.78T 规模流式运行的模型在 48B 规模下运行更轻松。本文档所有数据在发布时提交版本测量错误数据记录在 [docs/LEARNED.md] 而非悄悄修正。命名由来云服务回答每个 token 有账单费用和电力消耗双重代价而这些模型可在办公桌上现有硬件运行WASTE 旨在终结 token 浪费现象首字母缩写词后来确定。所需条件项目要求磁盘用于存储模型转换后的容器需要982 GB空间建议预留 1 TB磁盘用于转换过程另外需要 1.42 TB 的临时空间来存储发布的分片转换完成后可释放RAM打开 K3 模型在 4K 上下文下至少需要29.05 GB本文中的测试数据是在64 GB内存下获得的存储速度容器必须存放在内部 NVMe 磁盘上详见下文编译环境需要 C11 编译器和 make。运行时无需 BLAS、CUDA 或 Python存储大小采用二进制单位与 df 命令和引擎报告方式一致容器大小 982 GiB磁盘厂商通常称 1.05 TB。引擎启动最小 RAM 几乎全用于存储 27.28 GB 常驻主干要获理想吞吐量内存需求更高64 GB 机器上引擎分配 46 GB 预算17.56 GB 用于专家缓存这是测试最佳配置。32 GB 机器理论上可打开模型但会有严重内存分页问题建议 64 GB 为实际最低要求。存储速度很关键每个 token 需要读取 17 GB 专家数据内部 SSD 读取速度 12.78 GB/s 时模型可流畅流式运行USB 外接硬盘读取速度 0.94 GB/s处理同一 token 需要 13 秒所以要将模型转换到内部 NVMe 磁盘外部磁盘仅用于下载。若没有 1 TB 可用空间同样的引擎和格式可运行 Kimi-Linear-48B-A3B-Instruct 模型该模型容器大小19 GB最低 RAM 要求1.87 GB运行速度可达 10.7 tok/s是尝试 WASTE 的不错选择。特点-自包含只有一个 libwaste.a 库文件和一个 waste 二进制文件运行时仅依赖 libc 和 pthreads。-零依赖推理过程无需 BLAS、ONNX 或 Python无需安装额外依赖项tools/ 目录下 Python 脚本用于模型转换和引擎验证不与推理过程同时运行。-完全可嵌入[src/waste.h] 中提供 26 个公共函数用于在内存上限内打开模型、生成结果、保存会话和关闭模型CLI 是该 API 的客户端不涉及私有部分CLI 能完成的任务嵌入宿主也可完成。waste_cfg cfg;waste_cfg_init(cfg);cfg.ram_budget_bytes 46ULL 30; /* 严格的内存上限而非建议值0 表示根据当前机器自动调整 */waste_ctx *ctx;if (waste_open(/path/to/k3.waste, cfg, ctx) ! WASTE_OK) return 1;waste_generate(ctx, ids, n, params, on_token, user);waste_close(ctx);这里路径是转换器生成的容器目录不支持 ~ 缩写这是 shell 的功能。工作原理数据布局决定速度模型会一次性转换为 .waste 容器包含 JSON 清单、常驻主干和每层一个专家库每个专家记录与门控信息按 4 KiB 对齐上下矩阵相邻路由到一个专家只需一次 pread 操作而非三次也无需为每个矩阵寻道算术运算不是瓶颈。读取操作绕过页面缓存macOS 用 F_NOCACHELinux 用 O_DIRECTWindows 用 FILE_FLAG_NO_BUFFERING因容器小于 RAM 时内核会缓存所有数据测得命中率不真实处理 982 GB 模型不适用。每个记录头部读取时会检查确保魔数正确、索引指向专家无误、偏移量合法若专家库截断或拼接生成过程会停止并指出问题记录不使用错误数据计算此检查开销可忽略。记录含 crc32 校验和--verify 选项可开启校验默认关闭开启后每次缓存未命中时对每个记录校验Kimi - Linear 模型约占 5% 开销K3 模型约占 1%复制、下载或存储在不可信磁盘上的容器开启校验有必要自己转换并一直读取的容器通常无需开启。详见 [docs/FORMAT.md]。每个专家权重 3 位存储专家数据采用残差向量量化存储对 8 维向量用 256 个元素码本进行三级量化每个权重占 3.00 位矩阵不实际展开。对于每个 token引擎为每个码本条目和向量位置构建部分点积表之后每个专家行计算只需三次表查找和两次加法操作。主干部分仍用 4 位和 8 位存储该模型仅对专家部分进行量化感知训练主干部分未针对低精度量化训练。曾尝试构建并测试 3 位主干虽缓存预测结果符合预期但吞吐量下降输出结果混乱。缓存下限为一个 token 的工作集这是项目最具参考价值的数据K3 模型每个 token 触及 92 层中 16 个专家需 17.0 GB 数据缓存小于此值为一个 token 缓存的专家数据处理下一个 token 前会被淘汰命中率为零缓存超过此值命中率曲线急剧上升。预算专家缓存命中率解码速度32 GB3.32 GB0%0.31 tok/s46 GB17.32 GB13%0.32 tok/s52 GB23.32 GB27%0.11 - 0.14 tok/s58 GB29.32 GB37%0.04 tok/s以上数据在空闲机器上按顺序测量测量顺序重要52 GB 和 58 GB 测试后机器进入内存分页状态再测 46 GB 速度降至 0.22 - 0.25 tok/s虽命中率和未命中计数与之前测量结果相同但机器状态影响性能且每次运行后机器不完全恢复建议逐步增加内存预算测试。解码速度列数据在预读取功能前测量目前 46 GB 预算下解码速度为 0.51 tok/s而非 0.32 tok/s表格主要展示内存预算与性能关系预读取功能将 I/O 操作隐藏在算术运算后提高各预算下速度但不改变性能曲线形状。内存设计核心目标是使内存使用超过下限因此引擎优先释放 RAM 而非节省。而且存在上限比看起来更近命中率随内存预算增加先上升后下降64 GB 机器上缓存 58 GB 时命中率 37%但引擎速度比 46 GB 时慢八倍引擎未超内存预算但机器无法承受操作系统将专家缓存换出到磁盘“命中” 变成页面错误而非引擎原本管理的磁盘读取操作。所以可用内存窗口窄缓存约 46 GB 时满足一个 token 工作集需求达到 52 GB 时机器出现内存分页问题即使空闲机器运行前有 49 GB 可用内存窗口也易受无关因素影响如从常驻集中移除 1.11 GB 嵌入表并放入缓存会使 58 GB 预算下速度从 0.32 tok/s 降至 0.04 tok/s。因此默认情况下不将内存填满专家缓存达到或超过一个工作集整数倍才有意义超过部分虽提高命中率但使机器更接近内存分页状态引擎自动选择内存预算时逐步减少一个工作集大小直到满足内存八分之七以下且不低于最低要求如 K3 模型需 80.63 GB最低要求 3 倍工作集但笔记本只能获 46 GB 预算最低要求 1 倍工作集其中专家缓存 17.56 GB这是性能曲线峰值无需额外设置参数128 GB 机器可满足 3 倍工作集需求。早期版本尽可能使用所有可用内存此机器设置 27 GB 缓存速度在 0.11 - 0.04 tok/s 之间表明不受控制的缓存不是有效缓存引擎应在操作系统回收内存前停止请求内存。线性注意力和吸收式 KV 缓存K3 的注意力机制采用 3:1 混合模式包括 Kimi Delta Attention携带固定大小循环状态而非不断增长的 KV 缓存和门控多头潜在注意力gated multi - head latent attentionMLA 层缓存 512 维潜在向量而非每个头扩展后的键值对kv_b_proj 操作被吸收到查询和输出中q_nope · (W_kb c) (W_kbᵀ q_nope) · cΣ_s a_s (W_vb c_s) W_vb (Σ_s a_s c_s)这种方式使对数几率误差控制在 1.2e - 05 以内且缓存大小减少 53 倍4K 上下文下缓存大小从 11.25 GB 降至 0.21 GB也使长上下文处理成为可能扩展布局在 128K 个 token 时需 360 GB 缓存潜在向量布局只需 7.2 GB。性能和内存测试环境为 MacBook Pro M5 Pro64 GB 内存容器存储在内部 SSD 上所有数据在发布时提交版本测量。Kimi K3 — 2.78T 参数982 GB 容器项目指标最小 RAM4K 上下文下29.05 GB32K 上下文下 30.54 GB128K 上下文下 35.63 GB1M 上下文下 83.21 GB常驻主干27.28 GB每个 token 读取量17.0 GB通过两个线程预读取与矩阵乘法操作重叠模型加载时间20 秒预填充速度分块处理时为 0.47 tok/s顺序处理时为 0.29 tok/s预读取功能开启前解码速度默认预算下为 0.49 - 0.54 tok/s这是该机器的最佳性能视觉塔处理时间处理 1024 个补丁的图像需要 15.7 秒共 27 层提示中包含图像896x896 图像占用 256 个位置每个位置处理时间为 2.8 秒按文本方式处理最小内存要求主要用于存储常驻主干内存超过约 46 GB 时专家缓存满足一个 token 工作集需求获理想吞吐量达到 52 GB 时机器出现内存分页问题性能急剧下降两界限间额外内存对性能提升无帮助甚至有负面影响此机器上可用内存窗口只有一个预算宽度。视觉塔处理时间不等于图像总处理成本编码 1024 个补丁需 15.7 秒生成的 256 个位置像其他 token 一样经过 92 层混合专家MoE层又需 731 秒图像按相同长度文本计费因此 vision.json 中补丁预算是关键参数将网格大小减半可使提示长度减半。Kimi - Linear — 48B 参数19 GB 容器项目指标最小 RAM1.87 GB解码速度8 GB 预算下为10.7 tok/s缓存命中率为 78%同样的引擎和格式在能轻松装入内存的模型上表现出色展示了 WASTE 在无内存压力时的性能。时间分布在 K3 模型上解码缓存为 17.32 GB 且冷启动前十步命中率为 6.7%新提示开始状态时间分布如下部分占比MoE 层全部82.5%其中专家 I/O53.5%其中专家矩阵乘法20.0%KDA 层14.5%MLA 层2.8%lm_head 层0.2%可用 WASTE_PROFILE 1 WASTE_CACHE_MB 17735 ./test_forward MODEL 1008,10484,318,15383,387 out.bin 5 命令重现结果随缓存变暖I/O 占比下降长时间会话性能优于上述数据但各部分占比排名不变。I/O 操作接近硬件极限每个 token 需读取 17.0 GB 数据速度约 9.9 GB/sSSD 测量速度为 12.78 GB/s降低 I/O 成本唯一方法是减少读取次数即增加缓存、增加 RAM这是目前优化主要方向也是后续步骤侧重内存优化而非算术运算优化的原因。快速开始git clone https://github.com/sqliteai/waste cd wastemake # 生成 libwaste.a, waste, libwastevqmake check # 新克隆的仓库中23 个测试通过11 个跳过无需配置步骤和依赖解析make check 不需要模型它构建小型合成容器并测试引擎跳过的 11 个测试需要克隆仓库中没有的资源如 PyTorch 参考模型、与源分片的往返测试、使用文本驱动 CLI 的测试因合成容器没有分词器以及 K3 模型的测试需要容器和发布版本在磁盘上若两个容器都存在测试套件将包含 36 个测试。转换 Kimi K3 模型转换是唯一需要 Python 的步骤且只需执行一次源模型为 [moonshotai/Kimi - K3]与发布时完全一致包含 96 个 safetensors 分片大小为 1.42 TB无需打补丁# 1. 预检是否可达大小如何是否有足够空间tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry - run# 2. 下载 —— 可断点续传可安全终止和重新运行tools/fetch_weights.sh --dest /Volumes/staging/k3# 3. 转换为容器uv run --with torch --with safetensors python tools/convert.py \ --src /Volumes/staging/k3 \ --out ~/models/k3.waste --jobs 3上述命令将生成 982 GB 的容器本文中的所有数据均基于此容器测量在 M5 Pro 上使用三个进程进行转换大约需要4.7 小时使用纯 PyTorch 编码器需要 23.7 小时详见 [docs/K3.md]目标卷需要约 1.0 TB 的可用空间转换器支持断点续传中断的转换只需重新运行即可继续。下载过程可能会出现问题长时间下载 1.42 TB 的数据可能会遇到连接中断、CDN 5xx 。
)
