实测：在机器人控制器 H700 上，把 Qwythos-9B部署成本地 Claude CLI 后端

云端 Claude 的能力很强，尤其是在代码理解、长上下文和工具调用场景里。但对很多机器人、工业控制、边缘智能项目来说，另一个问题同样现实：

长期调用成本高，内网数据不能随便出门，现场环境还不一定有稳定公网。

所以这次我们做了一个更贴近工程现场的测试：不在云端跑，不在数据中心跑，而是直接在我们的机器人控制器 H700 上部署 Qwythos-9B-v2，并把它接入 Claude CLI，看看它能不能承担一部分“本地 Claude”的工作。

H700 本地 Agent 架构

Qwythos-9B-v2 是什么？

Qwythos-9B 是 Empero AI 推出的 9B 级推理模型。公开模型信息显示，它基于 Qwen3.5-9B，并使用 Claude Mythos / Claude Fable 轨迹进行后训练，主打长上下文、推理、函数调用和 Agent 场景。

这类模型的价值不在于参数规模特别大，而在于它把“更像 Claude 的解题和工具使用习惯”压缩到一个边缘设备也有机会部署的尺寸上。

我们这次测试的是 GGUF 版本：

这里的重点有三个：

第一，Q6_K。 相比更低比特量化，Q6_K 更偏向质量优先，适合代码、推理、多轮任务这类对稳定性更敏感的场景。

第二，MTP。 MTP 可以理解为模型在生成时先“草拟”多个后续 token，再由主路径校验接受。接受率越高，生成越有机会加速。我们的日志里能看到 draft acceptance，说明 MTP 不是只写在模型名里，而是实际生效了。

第三，多模态。 这次部署同时加载了 mmproj，因此它不只是文本模型，也可以做图片理解测试。

MTP 在运行日志中的实际证据

部署在 H700：不是玩具测试

这次跑测设备就是我们的机器人控制器 H700，硬件配置如下：

最终服务启动后，关键能力如下：

模型：Qwythos-9B-v2-MTP-Q6_K
上下文：256K
MTP：已开启
多模态：已开启
Thinking：已关闭
显存占用：约 13.9GB / 16GB

我们选择关闭 thinking 输出，是因为在 Claude CLI 和工具调用场景里，用户真正关心的是可见答案和任务完成时间。默认 thinking 模式会消耗大量输出 token，有时正文反而被挤掉。关闭后，模型直接输出可用结果，更适合作为本地 Agent 后端。

吞吐量实测：256K 能跑，长上下文也能跑

先看纯文本长上下文测试。H700 上的 Qwythos 在 5K、77K、129K prompt tokens 下都完成了请求。

这个结果很有代表性：

在短上下文里，它可以达到接近实时的响应速度；在 70K 以上长上下文里，prefill 仍然能保持千 token/s 级别；到 129K 级上下文时，decode 会明显下降，但请求仍然可以完整跑完。

对机器人控制器来说，这比“跑一个 4K demo”更有意义。实际工程里，Agent 往往要带上项目文档、设备说明、历史日志、代码片段和工具返回结果，长上下文能力会直接影响可用性。

H700 上的 Qwythos 长上下文吞吐量

MTP 是否真的打开了？

确认MTP启动参数：

--spec-type draft-mtp
--spec-draft-n-max 6

服务日志中也能看到草稿接受率：

draft acceptance = 0.94444
draft acceptance = 0.83333
draft acceptance = 0.63025

这说明 MTP speculative decoding 在运行中确实参与了生成过程。对小模型、本地部署和边缘设备来说，MTP 的价值在于：在尽量不改模型质量的前提下，用“预测 + 验证”的方式减少逐 token 等待。

当然，MTP 不是所有场景都会线性加速。长上下文、复杂推理、低接受率时，收益会下降。但只要接受率稳定，它对交互体验会很有帮助。

多模态测试：可以看图

我们还用一张 MoFang 标识图片做了多模态验证。

多模态实测输入：MoFang 标识图片

thinking off 后，模型直接输出：

图片中的主要文字是“MoFang”，图形是四个小方块，其中两个是深色的，两个是浅蓝色的。

对应性能：

对于 H700 这类机器人控制器，多模态能力的意义不只是“能不能描述图片”，而是未来可以接入现场截图、相机画面、设备 UI、报警截图，让本地 Agent 具备初步视觉理解能力。

这张图由部署在 H700 上、已加载 mmproj 的 Qwythos 服务直接处理；不是网页截图或人工转述。

接入 Claude CLI：把云端入口换成本地模型

更关键的一步，是把 Qwythos 接入 Claude CLI。

我们在 H700 上配置 Claude CLI，将 Anthropic Base URL 指向本地服务：

{
  "model": "qwythos-9b-v2-mtp-q6[1m]",
  "smallFastModel": "qwythos-9b-v2-mtp-q6[1m]",
  "env": {
    "ANTHROPIC_BASE_URL": "http://127.0.0.1:8082"
  }
}

这样 Claude CLI 的交互入口还在，但后端请求走的是 H700 本地 Qwythos。

这件事对工程团队很重要：

使用习惯不变，模型后端可以换成本地。

也就是说，开发者仍然可以用熟悉的 Claude CLI 工作流，而敏感代码、机器人配置、现场日志、设备文档可以尽量留在本地环境里处理。

不只做小题：给 Claude CLI 一个机器人安全排程任务

此前我们用一个依赖排序修复任务验证过本地 Claude CLI：从 1 passed, 3 failed 修复到 4 passed。这证明它能完成边界清晰的小型代码修复，但还不足以说明它在复杂工程任务中的上限。

所以这次我们追加了一个更贴近机器人控制器的任务，并全程录制终端：修复 safety_scheduler.py。它要在不改变公开接口的前提下，同时正确处理动作依赖、资源互斥、重复 ID、未知依赖、环依赖诊断和稳定排程顺序。

H700 Agent 验证任务链路

基线结果是：

这恰好给出更有价值的结论：H700 已经可以稳定承载本地 Claude CLI 的多回合 Agent 推理；Qwythos 对边界清晰的代码修复可用，但面对涉及多种约束、需要持续保持内部数据结构一致性的任务，仍需要更强模型、分步提示词或人工审阅。

录制文件保留了失败基线、Claude CLI 启动、本地服务连续推理以及 15 分钟后的最终结果，方便复核，而不是只展示一次成功输出。

我们怎么看 H700 的定位？

H700 不是单纯拿来“跑分”的机器。它是机器人控制器，所以我们更关心三件事：

第一，本地可用。 模型服务、WebUI、OpenAI API、Anthropic Messages API 都可以在 H700 上提供。

第二，长上下文可用。 单槽 256K 跑通，70K、129K 输入规模都有实测数据。

第三，Agent 工作流可用。 Claude CLI 可以接入，本地 Qwythos 能完成代码修复类任务。

这意味着 H700 不只是控制电机、采集传感器、跑运动控制逻辑，也可以成为现场 AI Agent 的本地推理节点。

在机器人和工业场景里，这个方向很有价值：

• 现场日志分析
• 设备故障问答
• 控制策略脚本辅助修改
• 内网代码助手
• 图像/截图理解
• 长文档本地 RAG 和 Agent 调度

结论

Claude Fable5 这类云端能力很强，但不是每个场景都适合一直依赖云端。

这次我们在 H700 上部署 Qwythos-9B-v2，跑通了：

• Q6_K 高质量量化
• MTP 推理加速
• 多模态图片理解
• 256K 单槽上下文
• OpenAI 兼容接口
• Anthropic Messages 兼容接口
• Claude CLI 本地接入
• 代码修复任务验证

最终我们得到一个更接近工程现场的结论：

H700 已经具备承载本地长上下文、多模态、Agent 推理服务的能力。

如果云端 Claude 适合做“最强大脑”，那么 H700 上的本地 Qwythos，更像是部署在机器人身边的“现场工程师”：成本可控、数据本地、响应稳定，并且可以和现有 Claude CLI 工作流衔接。

关注 芯动力AI，我们会继续分享 H700 在机器人控制、本地大模型、多模态 Agent 和边缘智能部署方面的实测结果。

参考

• Empero AI Qwythos-9B 发布说明：https://empero.org/writing/qwythos-9b-release
• Qwythos-9B-Claude-Mythos-5-1M-GGUF：https://huggingface.co/empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF
• H700 Qwythos 部署与测试记录：REMOTE-192.168.1.37-QWYTHOS-9B-V2-MTP-Q6.md