@catazshadow 纯显存推理情况下，27b 比 flash next 慢一半的样子

8745hs 办公机+edge ，卡顿不跟手。

跌了一半了，现在已经心静如水了

@jinsongzhaocn 不知道你是哪里看到的没超过 27B ，astra 调研的结果是 Flash Next 编程略优、Agent 大幅领先、速度翻倍：
以下分数按 **27B ／ Flash-Next** 排列：
- **智力**：AA 指数 34 ／ 40 ； Flash-Next 整体更强，普通推理、数学差距较小。
- **编程**：SWE-bench Pro 为 61.7 ／ 62.5 。
- **Agent**：Toolathlon 工具调用 67.1 ／ 73.5 。
- **长文**：AA-LCR 为 82%／ 80%，不足以证明普遍优势。
- **速度**：同硬件纯显存推理（ RTX Pro 6000 96G ），Flash-Next NVFP4 预填充和解码速度较 27B NVFP4 快约一倍。
- **资源**：27B 内存需求明显更低。

@jackOff 应该是不如的但是差距不大，完全可用的水平，并且快。我是萌新。

AI 让无用但有趣的想法得以实现，让菜鸟也能享受创造的乐趣，真是最好的年代。

我最大的需求是：能不能把 ins 从我的键盘上扣掉！！！经常影响我按 del 和 backspace

给你自己的建议：我 27 的时候也觉得自己老了笨了，过了 30 岁又自信起来了，老登雄起，人生就是这样，接受自己，努力生活。

省流：楼主 27 岁，父母 63 岁（身份证写大 3 岁）在姐姐姐夫的食品血汗工厂干活：一周七天无休、两人月薪 3000 、爸爸还被拉去深夜送货到拼多多仓库，受姐夫（家暴、看监控盯梢、群里骂人抓典型）的气。爸爸查出主动脉硬化+膝关节退化，姐姐是厂里顶梁柱还会修机器但不敢离婚（两个孩子）。父母"闲不住要找活干"，当地很多活卡年龄，楼主不知道怎么办。
建议：多挣点钱，每月给爸妈发两三千块钱，别和姐夫打交道。

@klc 有些任务会用到，比如长文本的推理，论文检查一类的，256K 上下文会不太够用，1M 确实有点丢三落四，四五百 K 左右还是可用的

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 至少需要两张(好像也很紧张，四张比较稳)