zzutmebwd

zzutmebwd

V2EX member #62082, joined on 2014-05-07 10:29:14 +08:00
Today's activity rank 6908
Per zzutmebwd's settings, the topics list is only visible after you sign in
Deals info, including closed deals, is not hidden
zzutmebwd's recent replies
9h 36m ago
Replied to a topic by hihihihihi 程序员 吐槽一下现在的键盘设计....
我最大的需求是:能不能把 ins 从我的键盘上扣掉!!!经常影响我按 del 和 backspace
1 day ago
Replied to a topic by HetFrame 生活 父母六十了,找不到活干怎么办
给你自己的建议:我 27 的时候也觉得自己老了笨了,过了 30 岁又自信起来了,老登雄起,人生就是这样,接受自己,努力生活。
1 day ago
Replied to a topic by HetFrame 生活 父母六十了,找不到活干怎么办
省流:楼主 27 岁,父母 63 岁(身份证写大 3 岁)在姐姐姐夫的食品血汗工厂干活:一周七天无休、两人月薪 3000 、爸爸还被拉去深夜送货到拼多多仓库,受姐夫(家暴、看监控盯梢、群里骂人抓典型)的气。爸爸查出主动脉硬化+膝关节退化,姐姐是厂里顶梁柱还会修机器但不敢离婚(两个孩子)。父母"闲不住要找活干",当地很多活卡年龄,楼主不知道怎么办。
建议:多挣点钱,每月给爸妈发两三千块钱,别和姐夫打交道。
1 day ago
Replied to a topic by zzutmebwd Local LLM pro6000 部署 Qwen 3.8 flash next nvfp4
@klc 有些任务会用到,比如长文本的推理,论文检查一类的,256K 上下文会不太够用,1M 确实有点丢三落四,四五百 K 左右还是可用的
glm 5.3 flash 叫 ox 的时候也飞快,现在慢的一批...模型的速度厂商随意调控的。。。
5 days ago
Replied to a topic by ldm0 Local LLM 2 台 DGX Spark 上运行的本地 LLM 横向对比
hhh 看到最后一句果然是这样 其实本地模型就是够用够快,追求绝对智力直接换 opus api
5 days ago
Replied to a topic by zzutmebwd Local LLM pro6000 部署 Qwen 3.8 flash next nvfp4
@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 毫秒,未出现明显排队拥塞。
5 days ago
Replied to a topic by zzutmebwd Local LLM pro6000 部署 Qwen 3.8 flash next nvfp4
@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 外推区间外产生质量断崖。
5 days ago
Replied to a topic by zzutmebwd Local LLM pro6000 部署 Qwen 3.8 flash next nvfp4
@coefu 那就慢的多了...纯显存+fp4 是最快的。n-gram 已经卸载了 nvfp4 完整权重 130G
5 days ago
Replied to a topic by zzutmebwd Local LLM pro6000 部署 Qwen 3.8 flash next nvfp4
@SiWXie 至少需要两张(好像也很紧张,四张比较稳)
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   3137 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 565ea56a · 19ms · UTC 12:48 · PVG 20:48 · LAX 05:48 · JFK 08:48
♥ Do have faith in what you're doing.