zzutmebwd

glm 5.3 flash 叫 ox 的时候也飞快，现在慢的一批...模型的速度厂商随意调控的。。。

hhh 看到最后一句果然是这样 其实本地模型就是够用够快，追求绝对智力直接换 opus api

@coefu 我认为至少需要一张 4090 48G 或者 dgx spark 128G 才能收获一个可用的速度(prefill ＞ 1000 decode ＞ 40) ，再低就没意义了，长程 agent 任务的单流输入输出量巨大，任务总时长会拉长到不可用的程度。我认为在智力达到一定程度后，速度更为重要。昨天一个论文审计任务的会话数据供您参考：

会话编号：20260903_204118_09742f

统计时间：2026 年 9 月 3 日 20 时 41 分 21 秒至 21 时 10 分 05 秒，总持续时间 28 分 44 秒。

该会话共完成 94 次模型调用，全部与 SGLang 请求日志成功匹配。累计处理输入 5,755,742 tokens ，其中缓存命中 5,359,296 tokens ，实际新增预填充 396,446 tokens ，缓存命中率 93.11%。

净新增上下文的加权预填充速度为 11,357.44 tok/s 。单请求预填充速度中位数为 7,560.8 tok/s ，P10 至 P90 范围为 2,335.6 至 12,391.9 tok/s 。短增量请求受固定调度开销影响，因此单请求中位数低于按新增 token 加权后的总体速度。

Hermes 记录的总生成量为 156,358 tokens ，SGLang 记录为 156,487 tokens ，两者差异来自结束符等特殊 token 。加权单请求解码速度为 159.21 tok/s ，单请求解码速度中位数为 162.0 tok/s ，P10 至 P90 范围为 141.8 至 218.3 tok/s 。

SGLang 调度批次的单流解码速度中位数为 153.3 tok/s 。期间只有 3 个双并发批次，双并发聚合解码中位数为 248.1 tok/s ，不适合作为该会话的主要性能口径。

MTP 投机解码的接受长度中位数为 2.5 ，P10 至 P90 范围为 2.0 至 3.2 ，非结构性代码任务 MTP 命中率明显偏低。请求排队时间中位数为 2.09 毫秒，P90 为 3.82 毫秒，最大 15.03 毫秒，未出现明显排队拥塞。

@c0xt30a 当前 long 模式（ systemd 默认跑的 serve-flash-next.sh ）是这样设置的：

通过 SGLang 的 `--json-model-override-args` 覆盖到 `text_config.rope_parameters`：

```json
{"text_config":{"rope_parameters":{
"mrope_interleaved":true,
"mrope_section":[11,11,10],
"rope_type":"yarn",
"rope_theta":10000000,
"partial_rotary_factor":0.25,
"factor":2.0,
"original_max_position_embeddings":262144
}}}
```

配合命令行 `--context-length 524288`。

要点拆解：
- `partial_rotary_factor=0.25` 是模型原生值（只有 25% 的 head dim 带 RoPE ，这个不是为扩长改的，只是随 override 一起显式声明，防止 SGLang 读不到 config 里的 rope 字段）
- `factor=2.0` 是扩长手段：原生 `original_max_position_embeddings=262144`（ 256K ），YaRN ×2 → 524288 （ 512K ）
- `rope_theta=1e7`、`mrope_interleaved` + `mrope_section [11,11,10]` 保持不变，与原生配置一致
- 权重文件本身 config.json 里 rope 字段是空的（ NVFP4 转换版没带），所以才需要 json-model-override-args 注入，两套脚本（ serve-flash-next.sh / serve-flash-next-test.sh ）里这段 override 相同
- fast 模式则不带这组 override ，直接用原生 256K

注意 factor 不是自己拍脑袋设的缩放率——262144×2.0=524288 ，与 `--context-length` 严格对应；两者不一致时 SGLang 会在 rope 外推区间外产生质量断崖。

@coefu 那就慢的多了...纯显存+fp4 是最快的。n-gram 已经卸载了 nvfp4 完整权重 130G

@SiWXie 至少需要两张(好像也很紧张，四张比较稳)

@kekxv 通用模型执行 pdf 转 xls 一类的任务不如 mineru 的。

@prosgtsr 果粉是这样的 精神胜利法

具体不评价，提两个建议：1.除 Git 做版本控制外，同时使用 synology drive 等带版本管理系统的同步软件同步项目，32 个版本，只要修改就同步，成本很低，效果很好； 2.写入项目规则，要求 agent 将所有删除命令改为剪切到备份文件夹 ../bak ，剪切时要在 bak 内构建相同的路径便于寻找，如有重复文件名的补按删除时间做后缀。