zzutmebwd

zzutmebwd

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