大模型本地部署人工智能【免费下载链接】K2-Horizon-MoVA-36B-A4B-bf16项目地址https://ai.gitcode.com/hf_mirrors/mlx-community/K2-Horizon-MoVA-36B-A4B-bf16点击查看免费下载想让一个拥有100 个专家的 36B 参数 MoE 大模型在 Mac 上跑得飞快本文带你拆解 K2-Horizon-MoVA-36B-A4B-bf16 的 MLX 移植原理k2_horizon.py 这个不到 26KB 的文件如何把一个 PyTorch 实现翻译成 Apple Silicon 上的 35.3 tok/s 生成速度。无需读一行源码也能看懂读完你会明白 MoE 模型在 Mac 上到底卡在哪里、又被怎么打通的。一、先认识这个模型36B 参数只激活 4BK2-Horizon-MoVA-36B-A4B 是 IFM 出品的稀疏 MoEMixture-of-Experts混合专家模型配置藏在 config.json 里几个关键数字配置项数值通俗解释num_experts100每一层 MoE 有 100 个专家num_experts_per_tok8每个 token 只挑 8 个专家干活mova_num_experts64注意力里的 Value 也有 64 个专家mova_num_experts_per_tok4每个 token 只用其中 4 个num_hidden_layers4848 层前 3 层是普通稠密层后 45 层全是稀疏层max_position_embeddings524288支持 512K 超长上下文 名字里的 A4B 就是36B 总参数、每 token 只激活约 4B的意思——这就是 MoE 的精髓养肥了用瘦了。它还有个独门绝技叫MoVAMixture-of-Values注意力普通 Transformer 的 Value 向量是一次线性投影算出来的而 K2-Horizon 的 Value 来自 64 个价值专家中被路由选中的 4 个。可以说连注意力的 Value 都在玩 MoE——这也是移植难度最大的部分。本仓库是官方模型的未量化 bf16 MLX 版本磁盘占 70 GB需要128 GB 内存的 Mac128GB Mac Studio 实测峰值 75 GB。二、为什么这个仓库自带一份模型代码打开 config.json 会看到一行特殊的字段model_file: k2_horizon.py这是整个仓库的设计关键。mlx-lmMLX 官方的推理工具内置了上百种模型架构但k2_horizon这种MoE MoVA的组合它还没收录。于是作者直接把移植好的模型文件 k2_horizon.py 放进仓库让 mlx-lm 在加载模型时动态读取这个文件作为架构定义。这样做的好处✅ 你pip install -U mlx-lm装到的就是官方原版不需要 patch✅ 代码就在本地愿意的话可以先读一遍再用加载时需要--trust-remote-code参数仓库 README.md 有说明✅ 一旦官方 mlx-lm 原生支持该架构这个文件随时可以退役三、移植核心6 个让100个专家提速的关键点k2_horizon.py 文件头部的注释写得很直白数学完全一样实现方式不同。差异集中在 6 处逐一看1️⃣ gather_mm100 个专家一次内核调用全部算完这是全文最核心的性能优化。PyTorch 原版处理 MoE 的方式是用 Python 循环遍历被选中的专家每次找出哪些 token 派给了这个专家算完再用index_add_原地累加。这种写法依赖原地修改和数据依赖的分支——而 MLX 的惰性计算图里这两样要么很慢、要么根本不可用。MLX 移植版的思路彻底反过来借助 mlx-lm 提供的SwitchGLU/SwitchLinear模块底层是gather_mm内核——把所有 (token, 专家) 配对排成一队一次 kernel 调用把所有选中专家的矩阵乘法打包完成彻底消灭 Python 循环。 类比原版是100 个窗口排队叫号、一次办一个gather_mm是开一条批量流水线一趟全过。2️⃣ sanitize加载权重时把专家叠成一张大表gather_mm有个前提某个专家的所有权重必须存在一个连续的大张量里而不能是 100 个各自独立的小张量原版 PyTorch checkpoint 正是后者。k2_horizon.py 里的Model.sanitize方法约 L588 起在加载 checkpoint 时做了一次性的叠砖mlp.experts.0/1/.../99的 gate/up/down 三组权重 → 堆叠成[100, out, in]的单张量64 个 Value 专家的权重 → 堆叠成[64, out, in]的单张量所以你在磁盘上看到的 15 个分片文件model-00001-of-00015.safetensors等分片清单见 model.safetensors.index.json里专家权重已经是叠好的布局了。3️⃣ 排序小优化批量来时按专家分堆[k2_horizon.py](https://link.gitcode.com/i/e1e4a833727b719645ad3587462085db)的SwitchValueExperts里藏着一个巧妙的阈值当 (token, 专家) 配对数≥ 64比如处理长提示词时先把 token按专家排序再交给gather_mm这样内核读取每个专家的权重时内存访问是连续的带宽利用率更高排序完再按逆序还原。而生成阶段每次只处理 1 个 token配对数不足 64直接跳过排序省下无谓开销。一个if同时优化了预填充和解码两个场景。4️⃣ mx.fast 融合内核RoPE、注意力、RMSNorm 全换芯片直连PyTorch 原实现是一步步的 eager 算子MLX 版全部换成了mx.fast.*融合内核mx.fast.rms_norm归一化一步到位不再拆成平方、均值、开方三步mx.fast.rope旋转位置编码的频率表由内核现场计算省去预建表融合scaled_dot_product_attention原生支持 GQA32 个 Q 头共享 8 个 KV 头不用像原版那样repeat_kv复制 KV 头再算 softmax在 Apple Silicon 的统一内存架构下这些融合内核能显著减少数据在内存与计算单元之间的搬运。5️⃣ fp32 加权求和更准不只是更快原版 PyTorch 在 bf16 下把路由权重转成 bf16、用 bf16 累加专家输出MLX 版则全程在 fp32 里做加权和最后才转回 bf16。副作用只有一个结果比 PyTorch 的 bf16 输出更准一点差异纯粹来自舍入——这是作者用 fp32 逐层对拍验证过的。6️⃣ KV 缓存对齐 mlx-lm 生态缓存和掩码不再用 HuggingFace 的Cache类而是换成 mlx-lm 自己的 KVCache 对象位置编码的偏移量直接从缓存的offset读取。这样mlx_lm.generate、mlx_lm.chat、mlx_lm.server全家族命令开箱即用长对话、多轮上下文都走得通。四、移植后如何自证没算错逐层对拍到 1e-6换框架移植最怕跑起来了但数值悄悄错了。这个移植的验证相当硬核用fp32 真实权重与 IFM 官方 PyTorch 代码modeling_k2_horizon.py逐层对比全部 48 层相对误差 ≤ 1e-6贪心解码带 KV 缓存每个位置预测的 token 完全一致冒烟测试17 * 23→ 391推理正确、澳大利亚首都 → Canberra、多轮服务端对话上下文正确另外几个宁可报错也不算错的防御性设计值得点赞ModelArgs的__post_init__k2_horizon.py L87 起会主动拒绝未移植的 partial RoPE 和滑窗注意力YaRN 参数不符时直接NotImplementedError——fail loudly而不是 silently wrong。五、实测性能128GB Mac 上 35.3 tok/s在Mac Studio M4 Max 128GB上的实测数据引自 README.mdK2-Horizon MLX 版本磁盘峰值内存WikiText-2 困惑度生成速度bf16本仓库70 GB75.0 GB11.36835.3 tok/s8-bit37 GB39.9 GB11.3720.04%51.2 tok/s4-bit25 GB26.5 GB11.5081.2%59.6 tok/s两点实用结论内存bf16 版短提示词峰值 75 GB在 128GB Mac 的默认 Metal 工作集上限内无需sysctl调参。KV 缓存约 192 KB/token128K token 约 24 GB要跑长上下文建议换 8-bit 版。速度MoE 的妙处尽显——bf16 虽然最重但因为每 token 只激活 4B 参数依然能做到 35.3 tok/s量化版更快59.6 tok/s而质量几乎无损可以按自己的内存预算二选一。六、快速上手三步跑起来第 1 步安装/升级 mlx-lmpip install -U mlx-lm第 2 步生成你的第一句话记得带--trust-remote-code新版 mlx-lm 必须加mlx_lm.generate --model mlx-community/K2-Horizon-MoVA-36B-A4B-bf16 --trust-remote-code --prompt Explain mixture-of-experts in two sentences. --max-tokens 2048第 3 步可选用mlx_lm.chat或mlx_lm.server起交互式对话/本地服务参数用法相同。⚠️两个新手常见坑这个模型会先思考再回答回答前会输出一段ifm|think … /ifm|think的推理内容。max_tokens要留足空间不然回答会被思考挤掉。思考力度可用聊天模板 chat_template.jinja 中的reasoning_effort参数调节high默认/medium/low简单问题调低能省不少 token。mlx_lm.server目前不会把思考内容拆分到单独的reasoning字段它会和正文一起出现在content里解析时注意。七、仓库文件速查文件作用k2_horizon.py核心k2_horizon 架构的 MLX 移植实现config.json模型配置含model_file指向移植代码README.md官方说明转换方式、内存需求、基准测试chat_template.jinja对话模板支持reasoning_effort思考力度generation_config.json生成配置BOS/EOS tokenmodel.safetensors.index.json15 个权重分片的索引tokenizer.json / tokenizer_config.json分词器25 万词表写在最后这个仓库的价值不只是又一个模型权重镜像而是给出了一份教科书级的 MLX 移植示范MoE 专家用gather_mm批量化、权重加载时预堆叠、按场景自适应的排序优化、全程 fp32 的数值保守策略、逐层 1e-6 精度对拍——每一招都恰好打在让稀疏大模型吃满 Apple Silicon 统一内存带宽这个靶心上。100 个专家听起来很吓人但在gather_mm和融合内核面前它们不过是同一条流水线上的工序。128GB 的 Mac 已经够你尝鲜这个 512K 上下文的原生 bf16 版本了。赞分享大模型本地部署人工智能【免费下载链接】K2-Horizon-MoVA-36B-A4B-bf16项目地址https://ai.gitcode.com/hf_mirrors/mlx-community/K2-Horizon-MoVA-36B-A4B-bf16点击查看免费下载相关推荐K2-Horizon-MoVA-36B-A4B-oQ4e 在 Apple Silicon 上能跑多快48 TPS 实测与内存占用K2 Horizon MoVA 36B A4B oQ4e 在 Apple Silicon 上能跑多快48 TPS 实测与内存占用 K2 Horizon MoV如何在Mac上快速跑通36B大模型K2-Horizon-MoVA-36B-A4B-4bit五分钟上手指南mlx-lm如何在Mac上快速跑通36B大模型K2 Horizon MoVA 36B A4B 4bit五分钟上手指南mlx lm K2 Horizon MoVA 36人工智能大模型模型量化本地部署开箱K2-Horizon-MoVA-36B-A4B-bf16Apple Silicon上运行36B MoE大模型与512K超长上下文的完整指南开箱K2 Horizon MoVA 36B A4B bf16Apple Silicon上运行36B MoE大模型与512K超长上下文的完整指南 想在 Mac大模型本地部署人工智能上一篇Proton Drive 虚拟化文件浏览器 DriveExplorer无状态组件架构、自定义列与性能实践指南下一篇Flash Diffusion数据管线揭秘WebDataset分片、Mapper与Filter的协作模式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考