[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3huaeyf8yscnd":3},{"slug":4,"category":5,"publishedAt":6,"titleZh":7,"titleEn":8,"summaryZh":9,"summaryEn":10,"models":11,"hardwares":12,"bodyZh":16,"bodyEn":17,"sourceName":18,"sourceUrl":19,"updatedAt":20},"llamacpp-b11985-metal-mxfp4-2026-10-30","RUNTIME","2026-10-29T23:09:41.791Z","llama.cpp b11985 纳入 Metal 解码优化：MXFP4 内核变化，不是全模型提速承诺","llama.cpp b11985 brings Metal decode changes, not a universal speedup","10月29日合并的 Metal 改动进入 b11985，涉及 MXFP4 矩阵向量运算、逐元素算子和 GLU。原有PR测试不等于今日新增复现，升级仍需固定模型与参数做A\u002FB。","Metal changes merged October 29 are included in b11985, covering MXFP4 mat-vec, elementwise operations and GLU. Earlier PR tests are not new independent reproductions; upgrades still need controlled A\u002FB testing.",[],[13],{"id":14,"name":15},30,"Apple M3 Ultra","2026年10月29日，llama.cpp 合并 Metal 优化 PR #31075，并在当日17:10 UTC发布的 b11985 中列入这些改动。新事实是代码进入上游构建，不是今天又测出一套更高的速度。该PR早在10月24日创建，原有跑分不能因为合并日期变新，就冒充过去24小时的新测量。\n\n改动集中在单token解码。第一项是 MXFP4 矩阵向量内核：用半精度位操作解码 FP4 值，替代线程组查找表，并以对齐的32位字读取打包数据。发布说明指出，新内核不再使用线程组内存；PR还说明，相关 MoE 专家路径也复用该函数。这是具体格式与算子的实现变化，不是给所有量化档位统一加速。\n\n第二项把连续逐元素运算与按行广播的二元运算，从每线程组一个线程改为最多256线程；第三项让 GLU 的一行拆到多个线程组，避免单行解码时整项运算只落在一个线程组。不同模型是否受益，要看它实际走过哪些算子，不能从“Metal更新”直接推出每台Mac都更快。\n\n原PR附有 M3 Ultra 上的交错A\u002FB与后端算子检查，但那是提交者提供的历史测试，不是本站独立复现，更不是全部Apple芯片的覆盖证明。本站本次只确认合并状态、发布构建与改动内容，不把旧跑分新录为今日实测，也不据此发布显卡或整机排名。\n\n升级建议保留旧二进制、模型文件哈希和启动参数，分别记录提示词读入与输出速度，并复查生成结果。权重量化、KV精度、上下文、批大小和预热方式保持一致；只看一段对话体感，既分不清缓存收益，也无法定位是哪项内核变化起作用。新构建值得测，不等于旧配置必须立刻换。\n\n来源：[b11985发布记录](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb11985)；[PR #31075原文](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F31075)。","On October 29, 2026, llama.cpp merged Metal PR #31075. Build b11985, published at 17:10 UTC that day, includes the changes. The new event is upstream integration, not a newly measured performance result. The PR was opened on October 24; merging it does not turn its earlier benchmark table into measurements from the latest 24-hour window.\n\nThe first change targets MXFP4 matrix-vector operations during single-token decoding. FP4 values are decoded with an fp16 bit trick instead of a threadgroup lookup table, while packed nibbles are loaded as aligned 32-bit words. The release notes say the kernel no longer uses threadgroup memory. The PR also identifies an MoE expert path using the same function. This is a format- and operator-specific implementation change, not a blanket improvement for every quantization.\n\nContiguous unary and row-broadcast binary operations now use up to 256 threads per threadgroup rather than one. GLU rows are split across multiple threadgroups, so a single-row decode no longer assigns the entire operation to one group. Benefits depend on the operators a checkpoint actually exercises; a Metal update alone says nothing conclusive about every Mac.\n\nThe original PR contains interleaved M3 Ultra comparisons and backend tests. Those are earlier measurements supplied by the contributor, not independent AraoAI reproductions or coverage of every Apple chip. This update verifies merge status, release identity and implementation details. We are not importing the old results as fresh measurements or turning them into a hardware ranking.\n\nKeep the previous binary, checkpoint hashes and launch arguments. Measure prompt processing and decoding separately, and inspect outputs. Hold weight quantization, KV precision, context, batch size and warmup procedure constant. A subjective chat impression cannot isolate caching from a kernel change. A new build is a reason to test, not a reason to replace a working setup without comparison.\n\nSources: [b11985 release](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb11985); [original PR #31075](https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Fpull\u002F31075).","llama.cpp release and contributor PR","https:\u002F\u002Fgithub.com\u002Fggml-org\u002Fllama.cpp\u002Freleases\u002Ftag\u002Fb11985","2026-10-29T23:09:41.792Z"]