获取 AX Code · 免费文档
AX Code.
zh-CN
English繁體中文简体中文日本語한국어FrançaisDeutschBahasa IndonesiaItalianoPortuguês (Brasil)РусскийEspañolTürkçeTiếng Việt
开始使用

本页译自英文文档。命令、标识符和示例保持原样。运行时 7.24.5 · SDK 2.6.9。 英文原文

本地推理测量：2026 年 9 月 19 日

状态：生效

范围：已测量的诊断快照

最近审阅：2026-09-19

负责人：ax-code 运行时

关于本地前缀修复之后完整的六组合客户端矩阵，见 新的 AX Code/OpenCode 复测。下方的客户端速度仍然是 其原始条件下的历史观察。

这些测量在一台 配备 128 GiB 统一内存的 Apple M3 Max 上调查本地响应延迟与解码速度。它们不是硬件鉴定、模型质量评估，也不是 在任意上下文长度下达到 30–40 tokens/s 的承诺。MTPLX 与 oMLX 的连接说明见 本地运行时指南。

条件与计时

  • AX Code 源码基于 v7.19.3；OpenCode 1.18.31；AX Engine 7.4.0；MTPLX 2.11.3；oMLX 0.6.4 （1d7826185c5b5b69b38b27cbe57d7597b7551fd7，隔离的源码安装）。
  • 一次只运行一个推理后端。默认风扇控制；不声称风扇已开到最大。模型文件位于 SMB 存储。MTPLX 的精确产物运行只把 MTP 边车暂存在 SSD 上，并核验了其 SHA-256。
  • 精确产物重放使用 AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP，修订 4d36d652c21590f6813495351c3baf5fca5b3831。单独的 MTPLX Optimized-Speed 客户端运行使用 Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed。它们是不同的模型包，即使 总文件大小相近；它们的速率不能单独分离出仅由运行时带来的加速。
  • 共同的重放设置：temperature 0.55、top-p 1、top-k 0、seed 0，最多生成 256 个 token。 AX Engine 与 MTPLX 使用活动 MTP 深度 3。运行时内核与推测采样器并不相同。 产物元数据声明深度为 1；这里的深度 3 是显式的运行时实验，不是 对产物认证的延伸，也不是新的默认建议。 AX Engine 在其固定输出的原生重放中忽略了 EOS；MTPLX 与 oMLX 遵循各自的停止规则。
  • 原生解码速率 使用后端解码计数器。交付速率 是 (reported completion tokens - 1) / (last output payload time - first output payload time)； 空事件和保活不算作输出。这些边界并不相同。
  • 首个载荷延迟 包括服务器上的请求准备、缓存恢复/预填充，以及输出之前的任何 缓冲。总 token 数除以整个请求是另一种吞吐度量。 工具调用突发不适合用来估计从首个到最后一个载荷的解码。

例如，同一次 MTPLX 30k 输入重放测得 13.99 原生解码 tokens/s，但 整个请求只有 1.13 tokens/s，因为冷预填充消耗了约 209 秒。 仅有一个很低的整请求数字，并不能确定解码引擎失败。

精确权重的 AX Engine 与 MTPLX 重放

每一对都收到相同的整数输入 token 序列，并发出 256 个 token。下方数值是 单次观察；即使种子相同，生成的 token 身份也可能不同。

输入 AX Engine 原生解码 MTPLX 原生解码 AX Engine 缓存输入 MTPLX 缓存输入
62 个 token 39.12 t/s 39.48 t/s 未报告 0
18,643 个 token 17.49 t/s 20.93 t/s 0 0
30,019 个 token 16.06 t/s 13.99 t/s 29,696 0

MTPLX 对此产物使用其 Sustained 配置档。30k 的 AX Engine 请求是热的，而 MTPLX 是冷的，因此它们的首 token 时间不能确定预填充速度比。30k 输入包含一条 历史步数限制指令，并产生诊断性文字；它不是编码任务验收。 18,643 个 token 的 MTPLX 重放在 256 个 token 之后报告 stop，而不是 length。

短提示显示相近的解码速率。这些运行并不能证明任一后端 普遍更快，也不能证明把 AX Code 切换到另一个后端就能保证固定的加速。

MTPLX Optimized-Speed 上的 AX Code 与 OpenCode

两个客户端都收到相同的用户任务、完整的项目指令，以及四个被允许的工具模式。 该任务要求一个 TypeScript LRU 缓存，并且不执行工具。客户端专有的提示被保留； 录制代理对齐了采样、禁用了思考，并使用 1024 token 的请求/服务器上限。 以下响应正常完成：

客户端 输入 token 输出 token 交付速率 首个载荷 缓存输入
AX Code 36,808 277 23.92 t/s 280.05 s 2,048
OpenCode，第一次 18,703 228 26.82 t/s 122.54 s 0
OpenCode，重复 18,703 228 30.01 t/s 0.018 s 18,703

这些测量早于 AX Code 的本地前缀修复（42908b46a）。AX Code 发送了更多上下文，并 产生了不同的代码。这不是等 token 数的客户端开销对比，也不是前后对比结果。 在另一次重放中只去掉自动扫描的目录映射，把输入减到 30,717， 但观察到的解码只提高了约 2%；去掉目录映射并未被采纳。

单独的 AX Engine 适配器矩阵观察到：AX Code 在 33,225 个输入 token 时交付 9.44–11.56 t/s，OpenCode 在 17,290 时为 12.82–13.00。提示长度、输出内容、缓存状态，以及 256 token 的输出上限都与上方的完整响应表不同；不要把这些合成 成一个后端加速比。

oMLX 结果

oMLX 测试使用精确的 AXQ 产物，以及带 MLX 0.32.0 的隔离安装。全部五项 原生内核导入检查，包括 qwen35_prefill 和 decode_fast，都已通过。显式选择了仅文本加载， 上下文窗口为 65,536，并发为 1。

最初的 Lightning MTP 尝试返回 HTTP 409，因为测试跳过了 oMLX 必需的 导入 MTP 边车 步骤。这是设置错误，不是缺少 AXQuant 支持。AXQuant 已经 提供了规范的 qwen3-next-mtp 契约；当前 Hub 修订 b0784088d4026ca569c5653e6e6243c501ef5fa9 也包括列出 15 个 MTP 张量的 axquant_omlx_compat.json。原始重放快照早于该标注。

关闭 MTP 的基线用原始产物完成：

输入 token 输出 token 原生解码 交付估计 缓存输入
62 256 18.97 t/s 18.90 t/s 0
18,643 256 13.02 t/s 12.97 t/s 0
30,019 256 12.15 t/s 12.10 t/s 0

这些是 关闭 MTP 的结果，不得拿来与开启 MTP 的运行时比较，当作 后端固有速度差异的证据。分词器往返和服务器提示计数与 其他重放后端所用的整数输入一致。

修正后的 MTP 运行在一份单独的可写副本上使用 oMLX 自己的导入器。骨干分片 没有改变。导入器把 language_model. 加到 15 个边车张量名称上；每个张量的 dtype、 shape 和载荷哈希在导入前后都被核验为相等。因此导入文件的哈希 不同，是因为其文件头变了。原始元数据和共享模型快照保持完整。 显式选择 MTP 深度 3，并且按深度的草稿/接受计数确认了实际执行。

输入 token 输出 token MTP 原生解码 交付估计 草稿接受 缓存输入
62 256 31.12 t/s 31.02 t/s 179/195 (91.8%) 0
18,643 256 17.18 t/s 17.13 t/s 177/192 (92.2%) 0
30,019 256 15.19 t/s 15.15 t/s 170/199 (85.4%) 0

短结果确认：导入之后，这个 AXQuant 包可以与 oMLX Lightning MTP 一起工作。 尽管 MTP 处于活动状态，长上下文解码仍然更慢。生成文本、运行时版本、 内核和推测策略都不同，因此不能把所有跨运行时差异都归因于 AX Code。

编码流验收与排除项

本地前缀修复之后，AX Code 在 AX Engine 和 MTPLX 上都完成了一项隔离的只读任务： 读取一个目录和两个 TypeScript 文件，解释队列已满异常，识别容量 7， 并返回一个只在第二个文件中才有的标记。两者都成功退出，并保留了 夹具字节。随后的 AX Engine 调用复用了 11,264 个输入 token；MTPLX 复用了 11,264–12,032。 第一次请求体是相同的，但运行时模板产生了不同的 token 计数。 这验证了工具流和观察到的缓存复用，而不是该补丁带来的固定加速。

新的提供商 ID 也通过了来自源码 CLI 的实时验收：omlx，使用已导入的 AXQ 包和显式的 tool_call: true，以及 mtplx，使用 Optimized-Speed 包且没有已配置的模型 条目。MTPLX 从原生模型列表中发现了它的对话模型和工具能力。两次运行 都完成了两次成功的文件读取，并返回了预期的异常、容量和仅存在于文件中的标记， 且没有更改夹具字节。每次运行的三次请求中，初始的系统/用户前缀保持相同。 oMLX 复用了 8,192 个 token；MTPLX 复用了 11,829 和 12,047 个 token。这些是功能 检查，不是配对的性能运行；不声称有跨运行时的墙钟加速。

更早的、以 256 token 封顶的 AX Code 响应被截断并进入恢复；它们大约 51–58 t/s 的重复输出 速率被排除在全新生成的声称之外。项目指令或工具权限不相等的初始运行 也被排除。Ollama 与 LM Studio 只被检查了请求 构造；不声称它们有生成速率结果。

通用的 62 token 提示作为一份 确切的 oMLX 补全请求 公开。 在检出根目录，导入边车、启用 MTP 并预热模型之后，可以用下面的方式发送它：

curl --no-buffer http://localhost:8000/v1/completions \
  -H 'Content-Type: application/json' \
  --data-binary @docs/data/local-inference-short-request.json

把请求中的模型 ID 改成你的服务器所暴露的 ID。该文件包含已渲染的模板； 请使用补全端点，以免对话模板被第二次套用。确认 62 个提示 token， 并保留最终的用量事件。冷模型加载和预热必须分开报告。

私有项目指令、会话提示、本地路径和身份验证细节不会公布。 脱敏后的测量数据 包含计数、计时、运行时身份和输入哈希，而不是 提示文本。因此，完整的私有上下文重放并不是一份可以独立公开复现的工作负载。 若要做新的比较，请使用相同的模型修订、分词器/模板、输入 ID、输出/停止规则、 采样、MTP 模式、缓存状态、硬件和串行执行；并单独报告完整任务是否成功。

上游契约：MTPLX 服务器与模型指南， oMLX 0.6.4。它们公布的基准使用其他 硬件和工作负载，不能代替这里的测量。