@no_stp_on_snek: 还有人谈论 mlx-swift-lm 吗？说我在休息一天……清理了鸡舍，锻炼了一下，然后…

X AI KOLs Following 工具
kv-cache-compression mlx swift metal turboquant decode-optimization apple

摘要

作者描述了将 TurboQuant KV-cache 压缩集成到 Apple 的 mlx-swift-lm 中，实现了 2.7 倍压缩，质量与 8-bit 相当，并通过融合 Metal 内核将解码速度提升了 3-4 倍。

还有人谈论 mlx-swift-lm 吗？ 我说我正在休息一天……清理了鸡舍，锻炼了一下，感觉像个正常人大概两个小时。然后我打开笔记本想查一件事。从来都不是一件事。 “休息日”都在把 TurboQuant KV-cache 压缩集成到 Apple 的 mlx-swift-lm 中。 这是一种非对称方案，设计如此。键几乎无法承受压缩（softmax 会放大它们的误差），所以你要保持 K 接近无损，而值几乎可以免费压缩，所以可以大力压缩 V。结果：2.7 倍 KV 压缩，质量与 8-bit 相当，通过 KL 散度与 fp16 缓存在 6 个模型家族（1.7B 到 30B MoE 和 32B）中验证。有实测数据，不是感觉。 有趣的部分是解码速度。第一遍运行速度约为 fp16 的 20%，瓶颈不在于数学计算。而在于每个 token 都要重新实例化整个缓存：全缓存 f32 转换、GQA 张量扩展、17 次 GPU 调度，而 fp16 只需要 3 次。 所以我把我的 llama.cpp 分支的融合单核解码移植到了 Metal 中。在单个 SIMD 并行调度中完成得分、softmax 和内联反量化，K 以其原生基读取一次。解码速度提升了 3 到 4 倍。现在与 fp16 竞争，而 KV 字节只有四分之一。 我一直在慢慢向上游提交一些 Swift 工作。这次是一个较大的 PR。
查看原文
查看缓存全文

缓存时间: 2026/07/16 18:17

还有人聊 mlx-swift-lm 吗？

说好今天休息的……清理了鸡舍，锻炼了身体，过了大约两小时“平衡生活”。然后打开笔记本想看一眼东西。但从来不是只看一眼。

花了这个“休息日”把 TurboQuant KV-cache 压缩集成到 Apple 的 mlx-swift-lm 中。

它在设计上是一种非对称方案。Key 几乎无法容忍压缩（softmax 会放大其误差），因此 K 保持近乎无损；Value 则几乎可以无代价地压缩，所以对 V 进行大力压缩。结果：2.7 倍 KV 压缩，质量与 8-bit 相当，在 6 个模型家族（1.7B 到 30B MoE 和一个 32B）上通过 KL 散度与 fp16 缓存对比验证。基于测量，而非感觉。

有趣的部分是解码速度。第一遍运行速度约为 fp16 的 20%，瓶颈并非计算本身。而是每个 token 都要重新实例化整个缓存：全缓存 f32 类型转换、GQA 张量扩展、17 次 GPU 调度，而 fp16 只需 3 次。

于是我将自己 llama.cpp fork 中的融合单核解码移植到 Metal。score、softmax 和内联反量化在一个 SIMD 并行调度中完成，K 以其原生格式一次性读取。解码速度提升了 3 到 4 倍。现在以四分之一 KV 字节实现与 fp16 相当的性能。

一直在逐渐向上游贡献一些 Swift 改动。这次是一个较大的 PR。

相似文章

@no_stp_on_snek: 如果你想试试，可以在这里找到：

X AI KOLs Following

这是一个 llama.cpp 的分支，集成了 TurboQuant+，用于先进的 KV 缓存和权重量化，支持跨后端内核（Apple Silicon、NVIDIA CUDA、AMD ROCm、Vulkan），并被 LocalAI、Chronara 和 AtomicChat 用于生产环境。

动态KV缓存量化与按需加载mmproj/MTP：我的llama.cpp愿望清单

Reddit r/LocalLLaMA

一位开发者已为llama.cpp实现了一个概念验证的PR，通过HTTP端点添加了动态KV缓存量化功能，允许用户按需重新量化其KV缓存，而无需完全重新加载模型。该帖子还概述了一个愿望清单，包括按需加载mmproj/MTP交换以及用于上下文优化的自动--fit标志。