本页译自英文文档。命令、标识符和示例保持原样。运行时 7.24.4 · SDK 2.6.7。 英文原文
AX Engine 模型选择
状态:生效 范围:当前状态 最近审阅:2026-09-20 负责人:ax-code 运行时
在符合条件的 Apple Silicon Mac 上,AX Code 通过 AX Engine(本地) 只提供这两个开发包。Tiel Coder 是默认;Cyber-Tiel Coder 是备选。
| 模型 | Hugging Face 仓库 | AX Code 选择 |
|---|---|---|
| Tiel Coder 35B A3B MXFP4 MTP 默认包 | 仓库 AutomatosX/AX-Tiel-Coder-35B-A3B-MLX-AXQ-MXFP4-MTP | tiel-coder-35b-axq-mxfp4(默认) |
| Cyber-Tiel Coder 35B A3B MXFP4 MTP 备选包 | 仓库 AutomatosX/AX-Cyber-Tiel-Coder-35B-A3B-MLX-AXQ-MXFP4-MTP | cyber-tiel-coder-35b-axq-mxfp4 |
别名分别固定修订 5ab39b24bfd7f65203be9b7823b1840486f58b6d 和 fe05e871ec69ad9ae8eac01fd285555514ac7daf。两者都使用 mlx 选择器,保留发布者的 MXFP4 包。模型卡把它们描述为开发用重新量化,没有经过认证的质量对等或 MTP 速度主张;选择它们并不确立原生执行或速度改进。
AX Code 捆绑已签名的 AX Engine 7.5.7 发布,其中包含来自提交 51137c71a6794964d52c32c95e275c0923ed8d0b 的 Tiel 附属命名空间加载器修复。较旧的 Homebrew 7.4.0 二进制文件缺少该修复,并以 MlxMtpRequiredButUnavailable 拒绝这些包。保持 MTP 为必需;显式的运行时覆盖也必须包含该修复。原生预填充与解码测量 保留其原始被测构建身份,并不认证较新发布的性能。
Qwen3.8 27B、Ornith、Qwen3-Coder-Next 以及所有其他仓库被排除在新的受管选择和下载之外。每个被选仓库只出现一次。已配置的别名和较旧的缓存修订在发现之后不会增加选项。其他提供方以及单独配置的环回附加接口保留其行为。要运行 AX Engine 自己的密集默认,启动 ax-engine serve qwen3.8-27b:axq 并附加该本地端点;测得的产品路径 MTP 在 Mac mini M4 Pro 64 GB 上为 31.05 tok/s 解码,在 M5 Max 128 GB 上为 76.90 tok/s 解码 / 795.3 tok/s 预填充。这些数字不是 Tiel 完成 tok/s,也不是 AX Code 会话速度。见 Tiel 对等摘要。
检查可用模型
ax-code providers ax-engine models --json
ax-code providers ax-engine models --refresh --json
刷新读取 Hugging Face 元数据,而不下载权重或启动模型。捆绑的元数据可离线工作,并在较旧缓存中缺少所选仓库时加以补充。现有修订不会被静默替换成另一个捆绑修订。选择仍需要有效的源元数据;仓库限制并不确立原生能力。
GET /provider/ax-engine/models 返回正在运行的 CLI 的目录,包括每个模型的确切 ID、仓库、量化、本地状态、内存/磁盘估算和验证状态。外部 GUI 使用此运行时 API。如果它显示较旧的列表,检查它启动的 CLI 及其版本。AX Coder 开发可以用 AX_CODE_BINARY 或 settings.axCodeBinary 选择源码运行时。
准备所选模型
从目录复制确切的模型 ID。默认 Tiel 别名使用 mlx:
ax-code providers ax-engine prepare \
--model tiel-coder-35b-axq-mxfp4 --quantization mlx --download --start
被排除的模型在开始工作之前就会使新的准备、下载和受管激活请求失败。现有模型记录仍可用于状态和清理;被移除的 Qwen3.8、Ornith 和 Qwen3-Coder-Next ID 从不会被重定向到任一 Tiel 产物。移除一个选项不会删除其权重,也不会停止现有服务器。
内存与运行时核验
两个所选别名都使用 65,536 token 上下文、8,192 token 输出限制、估计 64 GiB 内存需求和 32 GiB 下载磁盘预算。这些是 AX Code 的服务限制,不是上游最大上下文。(从最初的 32,768 token 上下文提高:那在输出预留之后只留下 24,576 个可用输入 token,少于固定的 AX Code 智能体系统提示和工具模式所需,因此全新会话永远无法发送第一回合。)
每个内存估算包括权重、附属文件、KV 缓存、缓冲区和主机预留。请用实时目录的适配结果判断当前机器。这些估算不是硬件或模型质量认证。
64 GiB 这个数字是保守的全上下文(64K)规划预算,不是硬下限。对于舒适的受管本地推理机器,我们建议 Apple Silicon M4 Pro 具备 48 GB 或以上统一内存(例如 Mac Mini M4 Pro 48 GB);较小的 Apple Silicon Mac 仍可以从 8 GB 运行 AX Code 本身,配合云/API 模型或更轻的本地运行时。
受管激活之前,AX Code 检查活动 AX Engine 模型的文本和结构化工具契约。verification-required 状态意味着准备已完成,但该实时契约尚未确立。仅仓库名或 MTP 附属文件并不能证明推理、视觉、MTP 加速或多回合编码质量。
会话压缩使用活动模型的上下文/输出预算,并预留输入余量。所选变体保持自己的目录预算;源模型的最大上下文不是受管内存保证。
生命周期和传输细节见 本地引擎架构。
受管 MTP 策略
受管 AX Engine 默认为 required,与所选 MTP 产物匹配。不可用的起草器会使启动失败,而不是静默回退到直接解码。MTP 权重和纯堆叠设置并不确立活动加速。默认 Tiel Coder 包使用 auto 推测配置档,以便 AX Engine 选择模型的起草门,而不是通用 agentic 配置档的 0.80 覆盖。这与 MTP 激活策略分开:auto 调优仍使用 required MTP。旧的、特定于密集 Qwen3.8 的实验环境不应用于这些 MoE 包。测得的收益见 配置档比较。Cyber-Tiel 保留 agentic;两种配置档下的受管读取任务探测都失败了,因此其任务可靠性仍未解决。激活策略保持为 required;引擎必须准入实际的起草器。要显式选择策略,把 provider.ax-engine.options.mtpPolicy 设置在 ax-code.json 中:
{
"provider": {
"ax-engine": {
"options": {
"mtpPolicy": "required"
}
}
}
}
| 策略 | 行为 |
|---|---|
disabled |
使用直接解码;不请求模型起草器。 |
auto |
让 AX Engine 决定模型和路由是否准入 MTP。这不保证激活。 |
required(默认) |
要求已准入的 MTP 起草器;AX Engine 拒绝不可用的起草器,而不是静默回退。 |
当没有设置提供方选项时,AX_ENGINE_MTP_POLICY 提供同样的三个值。自动运行时选择需要 AX Engine 7.5.7 或更新才能强制这些策略,包括默认的 required 策略。显式的 disabled 和 auto 设置仍会覆盖默认值。较旧或未知的二进制文件会在替换正在运行的引擎之前拒绝策略选择;使用受管策略控制之前请升级。没有记录策略的历史状态文件把其已启动策略报告为未知,并在下一次受管启动时被替换。更改策略在下一次受管启动或模型请求时生效,并用不同策略替换现有进程。它不改变模型选择或存储。
ax-code providers ax-engine start --mtp-policy disabled 仅覆盖该次启动的策略。如果后续编码请求应使用同一覆盖,请设置持久的提供方选项。准备/启动 HTTP 正文也接受 mtpPolicy。这些受管设置不会重新配置单独附加的端点。更新源码之后,重启 pnpm run dev 以加载新默认值;已经在运行的开发后端在重启之前保留其已加载的代码。
ax-code providers ax-engine status(或 --json)区分请求的策略、已启动的策略,以及观察到的 active/inactive/unknown 状态。观察使用引擎最新的模型路由指标,而不是模型元数据或历史起草计数。缺少精确模型样本时保持未知,包括第一次观察到的引擎步骤之前;全服务器汇总并不能确立激活。已配置的 required 不会被显示为活动的证明。起草/已接受计数在可用时是驻留引擎的累计值。待处理的策略变更会在状态检查期间报告,而不会因此重启。MTP 激活并不是对特定 token 速率的承诺。
解读本地响应速度
受管 AX Engine 不施加每秒 token 天花板。诸如 50 tok/s 的测量既不是配置的目标,也不是上限:更快的硬件可以更快地产生 token。上下文大小、输出预算和请求并发限制控制的是容量,而不是固定的 token 生成速率。
当前公开的 Tiel 对比 MTPLX 快照是 Tiel 对等摘要 中总结的 2026 年 9 月 20 日原生 API 活动。在 M5 Max 128 GiB 上,受管默认 Tiel 包的完成速度为 194.88 tok/s,包含 TTFT(解码 217.85)。Cyber-Tiel 峰值解码 249.01 tok/s 是备选包,不是默认。这些数字不是 AX Code 会话速度。
在相同的输入长度、输出预算、采样设置和缓存状态下比较测量。短提示解码测量并不能为带有数万上下文 token 的编码会话确立最低速率。复用前缀会减少提示处理;随后的解码仍然会注意该上下文。仅 MTP 激活并不能确立有用的起草接受或固定加速。
调查缓慢回合时,把启动/设置、到首个内容的时间,以及持续生成分开。引擎的 ax_runtime_decode_tok_per_sec 指标是跨请求的指数加权平均,不是当前响应的速率。对该响应使用请求计时和 token 计数,对其 MTP 接受使用计数器增量。流式块可以包含多个 token;把块当作 token 计数会得到错误的速率。
AX Code 最多五分钟复用成功的可执行版本探测。它在每次解析时检查可执行文件可用性,并在启动器或原生服务器文件身份变化时使缓存版本失效。失败的探测仍可重试。这减少重复的设置工作;它不改变模型解码速度。开发后端必须重启才能加载源码变更。