GLM 5.3 Flash Q4 在 M3 Ultra 上达到 60 token/秒 / 550 token/秒

我一直是矮星的爱好者，非常喜欢 GLM 5.3 Flash，但需要它显著加速才能更好地使用它。在截图中，您可以看到使用该模型在约 200k 深度下的 Claude Code 测试结果，其中包含许多工具调用，平均输出速度超过 38 token/秒。是的，我在标题中提到了 60 token/秒，如果您要求它编写 SQL，您将获得该速度。https://github.com/IngeniousIdiocy/ds4/blob/glm53-m3ultra/README.md#glm53_m3ultra 主要 ds4 以串行方式单流解码 GLM-5.3-Flash，速度约为 M3 Ultra 测量内存带宽的 59%。我们设定了 80% 的目标。主要的权重流内核已经很高效，但中间有数十个小内核，每个都带来延迟成本，而 GPU 大部分时间处于空闲状态。我们将这些工作融合到更大的调度中，并移除了使流水线等待的独立传递。结果：在短上下文下速度从 29 提升到 40 token/秒，在 62k 下从 24 提升到 38 token/秒，每个 token 的 Metal 内核更少，并且达到测量带宽上限的约 81%。然后，我们攻击了在非常长上下文下的剩余减速。该模型的高成本注意力计算在 62k 和 300k 时都基于大约 2,048 个选定位置工作。增长的是在更大历史中查找这些位置的工作。现有实现通过阶段排序和合并越来越大的候选列表，这些阶段很少使用 GPU。我们用并行扫描替代了这一点，在排序小存活列表之前缩小候选范围，原始算法处理模糊情况。这恢复了大约每生成 token 一毫秒的时间。相同的位置被选定，相同的顺序，相同的输出。在 300k 下端到端：原始 21.6 token/秒，我们的 37.4。更深的上下文仍然需要更多搜索成本，但它不会倍增高成本注意力工作。预填充从大约 62k 下的 366 token/秒开始。主要的矩阵内核已经高效，但它们浪费时间重复解包相同的权重、以小块获取数据，并在内核之间传递大型中间结果。我们将更多工作批处理在一起，重用准备好的权重，加宽加载，并合并对相同数据的传递。结果：从 366 提升到 550 token/秒，改进了 50%，使用相同的权重，将整个流水线从芯片测量矩阵乘法上限的约 51% 提升到 72%。冷 62k 处理从大约 170 秒降低到 113 秒。这是每次代理测试工具压缩和重新读取其上下文时的等待时间。服务器运行串行，除非您传递带有 —dflash 的起草文件。起草构建配方在仓库中。起草包含一个带有窗口控制器的准入策略，该策略测量其自身成本与串行速率的对比，并在不划算时退避。推理 token 串行解码。在 32 请求代理会话中，这比串行提高了 +4%。在结构化输出如 SQL 和 JSON 上，提高了 +20% 到 +50%。在散文上，它断开连接，成本约为 1%。输出在每个测试用例上与串行解码字节相同。准确性：在 ds4 用于发布 QA 的 100 提示参考集中，原始平均 NLL 得分为 0.300804（相对于 FP8 参考）。此分支得分为 0.300766，相同的 90/100 首 token 匹配。这里没有任何内容用质量换速度。此分支仅适用于 M3 Ultra，因为其优化依赖于对该特定芯片的详细测量：其双芯片内存行为、系统级缓存、每核心驻留和带宽，以及 Metal 如何在其 80 GPU 核心之间调度调度和线程组。我们正在优化一个模型在一台机器上的实际执行，使用一组权重 (Q4)，并检查预测的内核节省在完整解码或预填充中是否成立。