先更新一下硬件：内存已经从原来的 48GB 升级到 64GB，当前 Linux 可见约 59 GiB。旧帖的 48GB 是当时的配置，不是这一轮的环境。

这次跑的是什么

用的是 peasantsmith 已发布的 Maya-L 权重，按固定 revision 下载并核对 SHA-256，没有自己重新量化。

当前是双卡自动 layer split、FP16 KV、KV streaming 关闭，使用 GLM 自带的 MTP。只跑文本，没有开 DFlash2、Turbo、近似跳专家或 suffix drafting。

Maya 和这份部署各负责什么

Project Maya 提供推理引擎、打包工具、网页聊天/监控，以及供客户端调用的 API。我这边的 local-llm 只负责本机配方和启动/停止控制，不是另写了一个推理引擎。

GLM 的专家仍从原始 GGUF 读取；旁边的 pack 是索引、tokenizer 和部分 dense 投影等运行资产，不是又复制一遍完整模型。当前请求的专家缓存命中率在日志里显示为 100%，但这不等于所有长度、所有负载都已验证。

双卡合计显存占用目前约 162 GiB。这是运行中的设备占用快照，包含桌面等其他 GPU 分配，不能当成精确的纯模型显存需求。

已经验证到哪一步

• 模型可以加载，API 的 health 和模型列表正常。
• 短算术请求 17 × 19 返回 323。
• 结构化工具调用的返回格式通过一次检查；这不代表已经测完真实编码 Agent 的多轮工具执行。
• 接入 OpenCode 后已完成实际请求；输入包含系统提示和工具定义，不是我手工塞了五万字。

Maya 监控中最近两条已完成的 OpenAI 兼容接口请求如下，按时间先后排列：

第一条没有 prompt 前缀复用，实际处理了约 5.16 万输入 tokens；但模型已经加载，专家缓存也已运行，不等于模型冷启动。

第二条总 prompt 虽然也是约 5.18 万 tokens，但其中 51,615 tokens 已复用，差额只有 181 tokens。因此 2.6 秒是这条复用请求的总耗时，不是从零处理完整 51K 输入再输出 267 tokens 的耗时。

两条记录中的 decode 分别为 136.8 和 127.2 tok/s。输出长度不同，第一条只有 20 tokens；预填充长度和缓存条件也不同，所以这里只作为实际请求记录，不当成重复测量的正式 benchmark，也不拿两条 prefill 数字直接判断谁更快。表格保留监控原始读数，没有把多个阶段的速度混成一个吞吐数字。

重点：配置了 512K 容量，不等于已经实际输入 512K tokens。 目前有五万多 token 的实际请求，但 GLM 这套配置的满长输入、长文质量、并发，以及独立的编码/工具调用质量评测还没有完成。

也不把这里的数字和旧帖 DeepSeek 的 2.7/2.9 bpw 测试直接排高低：模型、量化、RAM 和请求条件都不同，不能据此判断 Maya 比 Strata 快多少，或 GLM 比 DeepSeek 强多少。

接入 OpenCode

本机把 GLM、DeepSeek 和 Qwen 的配方放在同一个仓库里，一次只启动一个模型，共用一个本地 API 端口。OpenCode 里也统一成 local-llm provider，GLM 可选 fast / thinking 两个 variant。

切换客户端模型并不会自动切换服务端模型，还是要先停掉当前配方，再启动另一个。我把 Maya 的下载/删除/切模型管理入口关掉了，避免客户端操作意外触发大模型加载或下载；这是本机部署选择，不是 Maya 没有这些功能。

• Project Maya：https://github.com/mw00/project-maya
• 本机配方和控制脚本：https://github.com/lunarmoon26/local-llm
• Maya-L 权重：https://huggingface.co/peasantsmith/GLM-5.3-Flash-Maya-GGUF

仓库只包含控制脚本、配方和配置模板，不带权重、环境或本机私有配置，也不是新机器上一条命令自动装完的安装包。

先把能复核的配置和边界写清楚。后面如果做正式速度对照，会把输入长度、输出长度、thinking、MTP、缓存条件和计时范围一起列出来。大家有同配置下的 GLM/Maya 使用结果，或者希望优先看的真实任务，也欢迎交流。

补充实验（2026-11-06）：DFlash2 没提速，checkpoint 间隔反而有效

后面又做了两项有控制变量的对照。先说结果：DFlash2 能正常跑，但在我这台机器上 decode 吞吐下降约 42%；最后保留 MTP，只调整会话状态检查点间隔，让全新 51K 请求的总耗时降低约 21%。 两项实验各有自己的对照，不把不同采样、输出长度下的数字直接横比。

1. DFlash2：不是跑不通，而是比 MTP 慢

用的是 Anbeeld 的 DFlash2 Q4_K_M drafter，约 697 MB，按 Maya 固定的 revision 下载并核对大小和 SHA-256。它的许可证是 CC BY-NC-ND 4.0，限非商业使用。DFlash2 替代 MTP 起草，不是两者叠加。

测试保留 524,288 context、FP16 KV、单会话和全部专家计算，没有开 Turbo。采用该版本默认的双卡 DFlash2 策略，提示、temperature=1.0、top_p=0.95、seed 和输出预算一致；每轮预热后测 3,072 个输出 tokens，按 MTP → DFlash2 → MTP 顺序运行，排除只比较一次启动的影响。

MTP 列按前后两轮的总输出 tokens / 总 decode 时间计算，不是简单平均瞬时速度。8K 组没有前缀复用；51K 组测量的后续请求均复用了 49,152 tokens，三轮缓存条件一致。预填充速度基本不变。

八条测量请求的生成文本在三轮里一致，算术、JSON、工具参数检查也通过；问题是速度，不是模型加载或基本功能失败。不过这里只测了这套硬件上的默认策略，没有穷尽 DFlash2 参数，更不能据此断言其他 GPU 组合也没收益。目前 DFlash2 已关闭，继续使用 MTP。

2. 真正保留的改动：周期性 checkpoint 从 16K 拉到 64K

这里的 checkpoint 是会话状态检查点，不是训练权重。改动只是在 serving 配置的 env 中设置 Maya 已有的选项：

"MAYA_GLM_CKPT_EVERY": "65536"

原默认间隔是 16,384 tokens。周期检查点会把长 prompt 的读取切成多段，每段都要填充、排空双卡的 prefill pipeline。间隔拉到 65,536 后，这个约 51K 的输入少了中途切段；系统提示和回合边界的检查点仍保留，不是关掉所有缓存。--prefill 仍是 auto，context 仍是 524,288。

确认测试使用类似 OpenCode 的 长 system prompt + 短 user 问题布局，并非一次真实 OpenCode Agent 任务。输入 51,681 tokens、greedy、thinking 关闭，首次请求输出 64 tokens，前缀复用为 0；模型已加载并预热，不计模型启动时间。按对照 → 优化 → 对照运行：对照共四次，优化两次。

也就是首次长输入请求减少约 8.44 秒，延迟下降 21.4%；不是声称 decode 提高了 21%。表中的两条后续请求各输出 128 tokens、各复用 51,667 tokens，所以也不能把 2.78 秒当作从零读完整 51K 的速度。

算术、JSON、工具参数，以及从长输入前部、中部、后部提取标记的英文/中文检查均通过。正式应用配置后，又测了一条 51,685-token、零复用请求：30.29 秒，prefill 1,737.7 tok/s，检索检查通过。

这次没有改 Project Maya 源码、CUDA kernel、引擎二进制、模型权重或 pack。 推理收益来自 serving 参数；另外修了本地 controller 的端口检查，避免重启时被已关闭连接的 TCP TIME_WAIT 拖住，这项不计入上面的推理计时。

代价也写清楚：周期检查点更稀疏，改写较早的长输入时可能需要重读更多 tokens；prefill 切段改变后，部分 greedy 措辞也会不同，不保证 bit-identical 输出。这些基础检查不等于完整质量评测，实际测到约 51K 也不代表已经完成 512K 满长验证。