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

Tiel MTP 配置档比较

状态：已测量的本地快照 最近审阅：2026-09-19 负责人：AX Code 维护者 范围：原生 Tiel MTP 配置档测量与托管 AX Code 验收

AX Code 现在为默认 Tiel Coder 包选择 auto 推测配置档，同时保持 MTP 激活为 required。Cyber-Tiel 保留 agentic：它的 auto 候选在真实读取工具探测中失败，表现为重复输出以及随后的并发限制错误。这让引擎可以使用其模型专属的草稿门。先前的通用 agentic 配置档用 0.80 覆盖了该门。原生比较在两种已测量工作负载上改善了 Tiel 解码，并在更长输入上改善了 Cyber-Tiel；Cyber-Tiel 的短输入结果略有回退。更高的原生吞吐并没有为该候选确立可用的工具行为。

这些是在一台 128 GiB 的 Apple M3 Max 上对 AX Engine 原生阶段的直接测量，不是 AX Code 任务吞吐。最初的 AX Engine 与 MTPLX 对比报告 仍然是 9 月 19 日 M3 Max 的历史基线。当前排名是 9 月 20 日的四机活动。本次配置档实验没有重跑 MTPLX，因此它更早的 92–96 tokens/s 结果不得当作同时对比。

确认结果

速率单位为 tokens/s，每一项都是三次未缓存的 256 token 补全的中位数。模型加载和 64 token 预热被排除。主机上还有其他桌面应用在运行；这是一份小型本地快照，不是受控的热学或耐久研究。

只有 Tiel 的 auto 配置档被采纳。Cyber-Tiel 的 auto 数字仍然是实验证据，不是其出厂默认。读取工具失败阻止了晋升，即使更长输入的阶段速率有所改善；这并不能确定是该配置档单独造成了失败。尽管预填充配置相同，预填充仍然波动。绝对速率也与更早的报告不同，因此没有用那份历史基线来计算这些增益。

全部 24 个确认请求都报告了活动 MTP、正数的已接受草稿、零个直接回退步骤，以及零个被复用的输入 token。引擎报告了其采样精确路由代码（ax_mtp_correctness_mode=2）；该运行时分类并不是独立的数值或质量认证。

脱敏输入、阶段计数器、全部确认与试点回执，以及托管/工具验收 随本报告一起提供。

单变量试点

每个情形一次初步试验，在重复比较之前隔离该门。不要把这些试点与确认试验合并。

在上下文试点中，显式的零门和 auto 请求产生了相同的输出 token 以及草稿/接受计数。auto 请求的回滚计时器从 1.061 秒降到 0.055 秒，其草稿计时器从 0.718 秒降到 0.130 秒。然而，验证周期从 78 增加到 111，验证求值仍约为 2.26 秒。因此总解码改善远小于任一计时器的缩短。这些计数器描述的是不同的执行路径；它们不是对未来加速的独立、可相加估计。

另外两次随机草稿试点，分别有和没有 0.6 的草稿温度覆盖，报告了 未激活的 MTP、255 个直接回退步骤，以及没有草稿。引擎的保护选择了直接回退路由。它们的原始回执被保留，并被明确排除在活动 MTP 比较之外。AX Code 不采纳这些覆盖，也不绕过该保护。

复现与范围

请使用与 原始测量方法 相同的引擎构建、钉住的快照、提示 token、采样参数和启动命令，只把 --speculation-profile agentic 改为 --speculation-profile auto。确认请求没有额外的 MTP 环境覆盖。前缀缓存用 AX_MLX_PREFIX_CACHE_MAX_ENTRIES=0 禁用。原生解码公式仍然是 (output_tokens - 1) / native_decode_seconds；预填充是未缓存的输入 token 数除以原生预填充秒数。

该引擎是 51137c71a6794964d52c32c95e275c0923ed8d0b 的优化源码构建，MLX 0.32.2，服务器 SHA-256 为 1fbe7fc50ea16448f98350616273214c0475bffb3ef509fceb3f8849163e97f5。被测试的 Homebrew 7.4.0 二进制早于所需的 Tiel 命名空间加载器修复，尽管这份源码构建也报告 7.4.0。没有替换任何已安装的二进制或用户配置。

确认顺序是 Tiel/自动、Tiel/代理式、Cyber-Tiel/代理式、Cyber-Tiel/自动。每次启动先接受一次 64 token 预热，然后是三次短输入和三次上下文试验。一次只运行一个推理后端；编译和测试套件被排除在计时试验之外。调度器宽度保持 2,048，上下文 32,768，最大输出预算 8,192，最大并发 1。真实托管的 AX Code 仍保留其现有的 8,192 调度器宽度，因此阶段表并不能确立其完整的客户端吞吐。

默认变更只适用于确切的 AutomatosX Tiel Coder 仓库及其别名。Cyber-Tiel 保留其先前的 agentic 配置档。显式的启动配置档覆盖仍然优先。稠密 Qwen3.8 的实验环境与前缀几何仍然分开；两者都不会应用到 Tiel。历史或无法识别的模型保留其先前配置档。云、CLI、私有 GPU 和 AX Trust 提供商的行为不变。

托管与工具验收

单独的隔离源码运行会行使默认 Tiel 激活和显式 Cyber-Tiel 激活、实时的必需/活动 MTP、AX Code 的 read 工具，以及托管关闭。带 auto 的 Tiel 完成了读取并返回了正确标记，但附加了文字和一个代码围栏，而不是只返回文件内容。带 auto 的 Cyber-Tiel 重复其预期动作却没有完成读取，触发了输出循环防护，在随后的重试上收到并发限制 429 响应，并在约 81 秒后带着错误退出。保留的 agentic 对照复现了同样的重复输出，并在约 84 秒后失败。因此这次任务失败并不只限于 auto；保留旧配置档并不声称能修复 Cyber-Tiel。两次失败都与一份单独的禁用缓存诊断一起保留在 JSON 回执中。这些检查与吞吐计时分开，也不认证一般的编码质量。

禁用缓存的 Cyber-Tiel 诊断使用 agentic，只额外加入了 AX_MLX_PREFIX_CACHE_MAX_ENTRIES=0。它成功退出，但没有调用 read，并错误地声称非空夹具是空的。因此仅有进程成功并不能满足任务验收。这份诊断没有被采纳为变通办法。

全部四台托管服务器在准入期间都报告了必需/活动 MTP，并成功停止。新配置档仅对这里所示的有界 Tiel 验收合格。Cyber-Tiel 仍然可选，但其托管读取任务的可靠性尚未解决。先前的直接服务器读取成功并不能确立与托管激活的等价；调度器宽度、缓存配置、先前请求和提示上下文在这些探测之间并不相同。

范围变更之后的验证：11,390 项确定性测试通过，17 项跳过；208 项 SDK 测试和 259 项脚本测试通过（94 项脚本测试跳过）。生成的 SDK 产物包含两个选定的模型别名，并且在第二次构建上字节稳定。递归类型检查和仓库结构检查通过。原生阶段审计验证了全部 24 份确认回执，并保留了合格与被拒绝的试点。