中天推理集群报告

每一轮部署、修复、验收和性能测试的结论与证据。每份报告都带逐项输入 / 输出样例和复现命令。

共 5 份报告 · 本站 1 份 · 更新于 2026-10-18

当前状态每个模型最近一次报告的结论

GLM-5.3

验收全绿
PD 8P+6D · 14 台 8×RTX 6000D · 前缀缓存 + MTP
官方 34 项34/34
单流每 token10.9 ms
128 会话输出3,125 tok/s
1M 冷启动190 s

DeepSeek-V4.1-Flash

验收通过
团队报告(10-16)
官方 34 项34/34
1M 冷启动152 / 233 s

qwen3.8-flash-next

1M 超时待定
团队报告(10-16)
官方 34 项34/34
1M 冷启动811–825 s

glm-5.3-flash

正式上线
团队报告

从这里开始按问题找到报告里对应的那一节(以最新报告为例)

现在能不能用?

看每份报告开头的“结论”和“验收”表:✅ 是逐项通过,❌ 会写明原因和处理。

有多快?

“单流速度”看一个请求单独跑的首字和每 token 时间;“并发曲线”看 1→128 个会话时的总吞吐和延迟。

怎么调用、并发开多大?

“运行建议”写了推荐的并发区间、关闭思考的写法、冷长 prompt 多时怎么调布局。

请求和返回长什么样?

每个用例都能下载 .txt:上半是原始请求 JSON,下半是完整返回(流式就是完整事件流)。

怎么复现?

“复现”给出原样命令;生成报告的脚本和本轮 spec 都在 zhongtian-ops。

下一步做什么?

“下一阶段优化方向”按预期收益排序,标明依据和状态。

全部报告按日期倒序;虚线标签是团队在 reports.aitist.ai 上的报告

2026-10-18

GLM-5.3 PD 部署:验收全绿与性能报告

验收性能修复GLM-5.3

8P+6D 上线后的完整验收(官方 34/34、团队 features / agent、长上下文三档、18 项统一测试),单流和 1→128 会话速度,为 agent 多轮做的取舍,以及下一阶段优化方向。

官方 34 项 26 → 34单流 ≈92 tok/s128 会话 3,125 tok/s后续轮次首字 1.8 s
2026-10-16

DeepSeek-V4.1-Flash 与 qwen3.8-flash-next 正式验收

验收DeepSeek-V4.1-Flash · qwen3.8-flash-next团队报告 · 外部

两个模型按同一套标准验收:官方 34 项都是 34/34,团队脚本通过;qwen 1M 冷启动 811–825 秒超过 600 秒门槛。

2026-10-16

GLM-5.3 修复:断线、关闭思考、协议缺口、长上下文

修复GLM-5.3团队报告 · 外部

PD 切换前的修复轮,官方 34 项从 20/34 提升到 34/34。

2026-10-14

glm-5.3-flash 团队验收脚本结果

验收glm-5.3-flash团队报告 · 外部

团队 validate_features / validate_agent 两个脚本的录制结果与证据包。

日期见报告

glm-5.3-flash 修复与正式验收

验收glm-5.3-flash团队报告 · 外部

glm-5.3-flash 的修复与正式上线验收。

没有匹配的报告。

名词与口径

PD / 8P+6D
prefill 和 decode 分开部署;8 台做 prefill(处理输入),6 台做 decode(生成输出)
首字(TTFT)
从发出请求到收到第一个输出 token 的时间
每 token(ITL)
相邻两个输出 token 之间的时间;倒数约等于单流速度
后续轮次
agent 多轮对话里第 2 轮及以后的请求,前缀命中缓存,只算新增部分
cached_tokens=0
冷请求必须完全不命中缓存,否则测的不是冷启动;所有压测都带唯一前缀并检查这一条
直连入口
验收和压测直接打我们自己的入口,不经过外部网关,结果只反映集群本身
p50 / p90 / p99
一半 / 90% / 99% 的请求不超过这个值