双2080Ti跑Strata + Qwen 3.8 Flash Next IQ3S优化经验 和 奇葩配置7950X + 双2080Ti实测数据鉴赏
-
1. 先交代机器配置:九九成稀罕物
我的上一篇帖子写了 X99 + 双 V100 的机器,那台机器已经成为我现阶段的重活主力。这篇我想写一下在有双V100机器之前,我的Strata入门机。机器配置如下:
· CPU:AMD Ryzen 7950X 16C 32T AVX-512
· 内存:海盗船DDR5 5600 C40 32G x 2
· 主板:华硕 Proart B650
· 显卡:一块公版2080TI 再加 一块矿卡涡轮2080TI,有NVLink,都是11G显存的
· · 这块板 U 双卡只给 x8+x8,监控里 prefill 期间 PCIe 长时间拉满,确认形成瓶颈了。
· 硬盘(安装ubuntu server和strata的):三星 980 PRO 2TB
· 电源:海韵 850W
· 系统:Win11 + Ubuntu Server Minimal 26.04 双系统
组合在论坛里应该不好找。不过这机器是22年底配的,当时还在上学来着。当时就没想到今天这机器会拿来跑像qwen 3.8 flash next这么大的模型,而且当时主要需求也和AI关系不大。结果阴差阳错地给现在的我留下了入门真正有生产力的本地AI的机会。
这篇文章主要是想分享一下我这边双2080Ti跑Strata和Qwen 3.8 Flash Next IQ3S的优化经验,顺便给大家图一乐,毕竟我这奇葩配置可能不是很常见吧。这台模型档位也不同:IQ3_S(46.8G 权重,比上一篇的 UD-Q4_K_XL 轻一大截),256K 上下文。两篇的数字互不可比,本帖也不和上一篇比大小。
图1:机器照片

2. 性能终档:先把"怎么测"说清楚
2.1 校验流程
本篇所有套件数字都按这个流程跑:
- 冷引擎:跑前重启服务,清掉跨对话缓存;
- 唯一负载:跑分窗口里这台机器只有套件本身(这台跑Strata的话目前是我的备用机,所以窗口好找);
- 完整身份校验:不跳模型哈希,全部权重文件的 SHA-256 写进档案;
- n=3 取中位数,档案目录独立留底,负结果档不删。
软件版本:Terminal 0.2.7 / 引擎 0.1.52(cuda13)/ 驱动 595.91.07。
2.2 短上下文档(conforming 终档
conf-nov1,冷引擎实测)指标(n=3 中位) 短题 4K 16K prompt 读速(tok/s) 34.5(协议也发布了,但短题小分母无意义,正文不聊它) 519.0 982.5 decode(tok/s) 85.5 73.2 73.5 TTFT 首 token 2.25s 7.91s 16.70s 正确性 12/12 在同一档里。一个诚实声明先说在前面:decode 数值天然随题目内容与草稿头接受率起伏(这台 conforming 档实测分布带 73~90,短题 max 90.3),所以本篇所有开关 A/B 都是同轮同批对照、只认成对数字——单看某一次 73 还是 87 没有意义,§3.1 的 69.3→87.6 是同轮 A/B。
图2a:strata benchconforming 终端报告页(含 12/12 与模型哈希行)。

2.3 长上下文档(标题里的 256K,真测到 216K)
语料是自家真实长文重排拼的(每次不同洗牌顺序 + 尾部 unique 编号,保证前缀全新、是真冷读),token 数全部取引擎 usage 回报,不是字符换算;测量脚本兼容思考流的
reasoning_content字段(上一篇交代过的坑,这次直接绕开):实测 prompt_tokens 冷读 TTFT 冷读 prefill tok/s* 深度 decode(tok/s) 同会话第二请求 TTFT 58.7K 45.4s 1293 79.4 0.6s 139.4K 98.5s 1415 77.0 0.9s 215.7K 150.8s 1430 67.6 0.1s (*由 usage 实测数相除,下同。冷读原始 usage JSON 一条:
"prompt_tokens": 58763, "completion_tokens": 162, "prompt_tokens_details": {"cached_tokens": 0}——cached_tokens: 0就是"真冷读"三个字的铁证。(这条与表里 58.7K 那次是同语料不同尾部编号的两次独立冷读,所以 token 数差 32,两条都留在档案里。)引擎计数对账:三档复用共reused_tokens 413779。)2.4 正确性
每个调优档位都是 12/12 sanity(指令遵循/检索/工具调用各 4 题)过了才敢上。三开关采纳前后、长档复测之后,累计多轮复跑零失败。速度收益如果拿正确性抵账,宁可不要。
PS:
- 数字有整有零:全是实测中位数,不凑整。
- 上一篇说过"跑分前重启清缓存",这篇照做了,一次过。上篇的教训救下篇的档,这就是留档案的好处。
2.5 这台画像的天花板:prefill 就是吃满 PCIe 3.0 x8 的活
读速数字先交代理由,这台的天花板不在卡上,在带宽上:
硬件事实两层。第一层:20 系卡是 PCIe 3.0 设备——平台是 4.0 的也没用,卡的代际封顶,这是买卡那天定死的;第二层:这块板双卡只给 x8+x8。两层交集 = 每卡一根原始 7.88GB/s 的速率(lspci 链路状态实测
Speed 8GT/s, Width x8 (downgraded),两卡逐字一致——下面会看到它被顶到线速是什么样子)。为什么分层 MoE 的 prefill 最吃带宽:专家池住内存,prefill 阶段每层每批 token 点到的专家都要现从内存搬进显存——这是全流程搬运量最大的阶段。
"拉满"不是定性说法,是采出来的数。
nvidia-smi dmon -s put每秒采 PCIe 吞吐和板卡功率,配一条 139,395 token 的真冷读(唯一前缀,usage 现场回着cached_tokens:0):卡 rx 峰值(显卡收端=专家搬入向) 持续段(≥85%峰值均值) 持续时长 窗口内功率 均值/功限 GPU0 7.46 GB/s 6.86 GB/s 71 秒 150W / 200W GPU1 7.90 GB/s 6.85 GB/s 84 秒 172W / 220W 7.90 GB/s 这一刀正尖尖顶在 3.0 x8 的原始带宽(7.88GB/s)上——带宽本身就是天花板;持续段 6.85 GB/s ≈ 原始带宽的 87%,是协议开销后的稳定顶法。同一窗口两卡功率均值 150/172W,离 200/220W 的功限还差着一截(瞬时峰值样本短暂越过功限属正常抖动,功限按均值起作用)。算力有富余、带宽顶线速——两个读数并排就是铁证。dmon 原始 196 行、链路 LnkSta(
Speed 8GT/s, Width x8 (downgraded)两卡逐字一致)、功限配对行,全在数据包,不信可以自己对账。具体详细测试数据:

# PCIe 3.0 x8 prefill 吃满实测(2026-11-01 20:56 北京时间,aiserver1,机器重开机后首采) ## 测试方法 - 请求:`~/lp/lp_128k.txt`(家目录下)语料前加唯一 nonce(保证全量前缀未缓存),max_tokens=1、temperature=0,非流式。 - 采样:`nvidia-smi dmon -s put -d 1`(每秒,rxpci/txpci 列 = GPU 侧 PCIe 收/发 MB/s,pwr = 板卡功率 W),与请求并行,请求结束后停止。 - 引擎:Terminal 0.2.7 / 控制包 0.1.53 / engine 0.1.52 cuda13;驱动 595.91.07。 ## 请求原始行(证明真冷读) ELAPSED 98.5 usage {"prompt_tokens": 139395, "completion_tokens": 1, "total_tokens": 139396, "prompt_tokens_details": {"cached_tokens": 0}} ## 链路状态原始行(两卡一致) LnkSta: Speed 8GT/s, Width x8 (downgraded) LnkSta: Speed 8GT/s, Width x8 (downgraded) ## 功限配对原始行(nvidia-smi --query-gpu=index,power.limit,power.draw) 0, 200.00 W, 21.74 W 1, 220.00 W, 32.35 W ## 统计(由原始 dmon 日志程序化重算,rxpci 按 MB/s→GB/s ÷1000) GPU0 rx非零样本74 峰7.46GB/s 峰值85%以上均值6.86GB/s(持续71秒) 全程均值6.65GB/s | pwr 均150W 峰226W(功限200W) GPU1 rx非零样本84 峰7.90GB/s 峰值85%以上均值6.85GB/s(持续84秒) 全程均值6.85GB/s | pwr 均172W 峰250W(功限220W) - PCIe 3.0 x8 原始带宽 = 8GT/s × 8车道 × 128b/130b编码 ≈ 7.88 GB/s。 - GPU1 rx 峰值 7.90GB/s ≈ 线速;持续段 6.85-6.86GB/s ≈ 原始带宽的 87%(协议开销后的稳定顶法)。 - 同窗口功率均值 150/172W,均低于各自功限 200/220W(瞬时峰值样本短暂超限属功率均值的正常抖动,功限按均值起作用)。 - 结论口径:prefill 期间 PCIe 管子拉满、功限吃不满 = 带宽受限的直接画像(本次为精确数值版,替代此前"网页监控画像"的定性表述)。 ## dmon 原始日志全文(196 行) # gpu pwr gtemp mtemp sm mem enc dec jpg ofa rxpci txpci # Idx W C C % % % % % % MB/s MB/s 0 21 34 - 0 2 0 0 0 0 0 0 1 31 30 - 0 0 0 0 0 0 0 0 0 21 34 - 0 2 0 0 0 0 14 2 1 31 30 - 0 0 0 0 0 0 0 0 0 50 35 - 2 3 0 0 0 0 3038 3 1 73 31 - 0 0 0 0 0 0 0 0 0 187 39 - 85 21 0 0 0 0 6846 783 1 70 32 - 0 1 0 0 0 0 0 0 0 123 41 - 100 26 0 0 0 0 6860 797 1 70 32 - 0 0 0 0 0 0 0 0 0 179 40 - 100 25 0 0 0 0 6841 782 1 70 32 - 0 0 0 0 0 0 0 0 0 167 40 - 100 24 0 0 0 0 7458 797 1 127 35 - 71 15 0 0 0 0 6852 783 0 180 42 - 100 26 0 0 0 0 6835 783 1 196 37 - 100 23 0 0 0 0 6831 781 0 175 41 - 100 27 0 0 0 0 6836 789 1 192 37 - 100 23 0 0 0 0 6836 794 0 106 40 - 100 24 0 0 0 0 6831 781 1 186 37 - 100 22 0 0 0 0 6847 784 0 167 42 - 42 10 0 0 0 0 6845 783 1 181 37 - 100 20 0 0 0 0 6822 793 0 128 41 - 100 26 0 0 0 0 6846 797 1 195 38 - 100 23 0 0 0 0 6844 782 0 94 41 - 100 24 0 0 0 0 0 0 1 125 39 - 100 24 0 0 0 0 6849 783 0 171 43 - 39 9 0 0 0 0 6843 787 1 138 39 - 100 22 0 0 0 0 6841 786 0 200 43 - 100 27 0 0 0 0 6849 784 1 188 39 - 100 23 0 0 0 0 6837 794 0 172 44 - 100 28 0 0 0 0 6851 796 1 194 39 - 100 25 0 0 0 0 6841 783 0 81 41 - 100 25 0 0 0 0 0 0 1 127 41 - 100 22 0 0 0 0 6837 784 0 136 43 - 36 7 0 0 0 0 6847 784 1 126 41 - 98 20 0 0 0 0 6845 783 0 186 44 - 100 28 0 0 0 0 6852 786 1 160 41 - 100 23 0 0 0 0 6831 794 0 183 44 - 100 28 0 0 0 0 6834 789 1 160 41 - 100 24 0 0 0 0 6827 795 0 160 43 - 100 26 0 0 0 0 6842 783 1 176 41 - 100 22 0 0 0 0 6863 785 0 190 45 - 38 8 0 0 0 0 6835 782 1 213 42 - 100 22 0 0 0 0 6836 782 # gpu pwr gtemp mtemp sm mem enc dec jpg ofa rxpci txpci # Idx W C C % % % % % % MB/s MB/s 0 182 44 - 100 29 0 0 0 0 6847 782 1 194 42 - 100 23 0 0 0 0 6836 782 0 156 44 - 100 27 0 0 0 0 0 3089 1 198 42 - 100 24 0 0 0 0 6827 782 0 168 44 - 39 7 0 0 0 0 6833 784 1 199 43 - 100 23 0 0 0 0 6837 783 0 187 45 - 100 29 0 0 0 0 6852 784 1 198 43 - 100 24 0 0 0 0 6854 782 0 152 45 - 100 30 0 0 0 0 6840 785 1 196 43 - 100 24 0 0 0 0 6844 782 0 82 43 - 100 26 0 0 0 0 0 0 1 191 43 - 100 23 0 0 0 0 6839 784 0 168 46 - 36 6 0 0 0 0 6851 784 1 190 44 - 98 22 0 0 0 0 6842 784 0 185 45 - 100 30 0 0 0 0 7130 798 1 231 44 - 100 24 0 0 0 0 6837 787 0 189 46 - 100 30 0 0 0 0 6840 782 1 204 44 - 100 24 0 0 0 0 6835 781 0 161 45 - 100 26 0 0 0 0 6843 782 1 181 44 - 100 24 0 0 0 0 6839 782 0 158 46 - 39 8 0 0 0 0 6848 783 1 171 46 - 100 21 0 0 0 0 6841 783 0 224 47 - 100 30 0 0 0 0 6846 783 1 128 46 - 100 25 0 0 0 0 6839 782 0 201 46 - 100 26 0 0 0 0 0 996 1 201 45 - 100 24 0 0 0 0 6844 795 0 203 46 - 39 8 0 0 0 0 6832 782 1 201 46 - 100 24 0 0 0 0 6834 783 0 127 47 - 100 29 0 0 0 0 6830 784 1 211 46 - 100 25 0 0 0 0 6836 782 0 181 47 - 100 30 0 0 0 0 6846 783 1 207 46 - 100 25 0 0 0 0 6831 782 0 84 45 - 100 27 0 0 0 0 0 0 1 174 46 - 100 25 0 0 0 0 6853 784 0 164 48 - 36 9 0 0 0 0 6854 784 1 180 46 - 98 21 0 0 0 0 6839 782 0 152 48 - 100 29 0 0 0 0 6844 784 1 238 47 - 100 25 0 0 0 0 6847 783 0 170 48 - 100 30 0 0 0 0 6854 783 1 204 47 - 100 25 0 0 0 0 6841 782 0 85 47 - 100 28 0 0 0 0 6849 784 1 187 47 - 100 25 0 0 0 0 6851 783 0 194 48 - 100 29 0 0 0 0 6852 784 1 148 49 - 100 23 0 0 0 0 6850 784 # gpu pwr gtemp mtemp sm mem enc dec jpg ofa rxpci txpci # Idx W C C % % % % % % MB/s MB/s 0 209 48 - 100 30 0 0 0 0 6851 784 1 137 49 - 100 25 0 0 0 0 6844 783 0 210 48 - 100 29 0 0 0 0 0 1196 1 192 48 - 100 24 0 0 0 0 6853 781 0 212 48 - 40 10 0 0 0 0 6847 784 1 200 48 - 100 23 0 0 0 0 6846 785 0 157 48 - 100 28 0 0 0 0 6846 785 1 210 48 - 100 26 0 0 0 0 6846 782 0 193 48 - 100 31 0 0 0 0 6880 783 1 198 48 - 100 24 0 0 0 0 6845 783 0 86 47 - 100 29 0 0 0 0 0 0 1 144 48 - 100 26 0 0 0 0 6837 784 0 160 50 - 36 10 0 0 0 0 6884 783 1 140 49 - 98 22 0 0 0 0 6836 782 0 152 49 - 100 27 0 0 0 0 6844 783 1 250 49 - 100 26 0 0 0 0 6846 783 0 146 50 - 100 30 0 0 0 0 6848 783 1 129 49 - 100 25 0 0 0 0 6845 783 0 120 49 - 100 30 0 0 0 0 6850 783 1 127 49 - 100 26 0 0 0 0 6876 783 0 216 50 - 100 27 0 0 0 0 6856 786 1 212 50 - 100 22 0 0 0 0 6849 784 0 183 50 - 100 30 0 0 0 0 6847 784 1 192 50 - 100 27 0 0 0 0 6849 783 0 226 50 - 100 30 0 0 0 0 1815 7162 1 187 50 - 100 26 0 0 0 0 6809 798 0 189 50 - 39 12 0 0 0 0 6846 783 1 183 50 - 100 22 0 0 0 0 6846 784 0 190 50 - 100 26 0 0 0 0 6847 784 1 140 51 - 100 27 0 0 0 0 6845 783 0 189 50 - 100 32 0 0 0 0 6851 784 1 199 51 - 100 27 0 0 0 0 6846 783 0 86 49 - 100 29 0 0 0 0 0 0 1 214 50 - 100 27 0 0 0 0 6852 782 0 132 50 - 37 11 0 0 0 0 6858 797 1 198 50 - 98 22 0 0 0 0 6839 781 0 184 51 - 100 27 0 0 0 0 6845 782 1 194 51 - 100 26 0 0 0 0 6845 783 0 185 51 - 100 32 0 0 0 0 6845 783 1 138 52 - 100 26 0 0 0 0 6840 782 0 86 51 - 39 11 0 0 0 0 6865 784 1 127 52 - 100 27 0 0 0 0 6847 783 0 126 51 - 99 27 0 0 0 0 6856 789 1 212 51 - 100 23 0 0 0 0 6838 784 # gpu pwr gtemp mtemp sm mem enc dec jpg ofa rxpci txpci # Idx W C C % % % % % % MB/s MB/s 0 210 51 - 100 32 0 0 0 0 6905 797 1 169 51 - 100 26 0 0 0 0 6829 791 0 156 51 - 100 30 0 0 0 0 6853 1106 1 198 51 - 100 27 0 0 0 0 6854 783 0 180 51 - 42 11 0 0 0 0 6847 783 1 217 52 - 100 24 0 0 0 0 6838 785 0 144 52 - 98 27 0 0 0 0 6839 782 1 170 53 - 100 26 0 0 0 0 6835 782 0 134 51 - 100 32 0 0 0 0 6848 783 1 192 53 - 100 27 0 0 0 0 6837 783 0 85 50 - 100 30 0 0 0 0 0 0 1 200 52 - 100 27 0 0 0 0 6840 782 0 189 51 - 42 12 0 0 0 0 6827 782 1 194 52 - 98 24 0 0 0 0 6838 782 0 175 51 - 93 26 0 0 0 0 6847 796 1 211 54 - 100 25 0 0 0 0 6832 783 0 189 52 - 100 31 0 0 0 0 6838 785 1 199 53 - 100 28 0 0 0 0 6840 784 0 85 50 - 48 14 0 0 0 0 0 619 1 165 53 - 100 26 0 0 0 0 6854 784 0 124 53 - 89 24 0 0 0 0 6859 785 1 130 53 - 100 25 0 0 0 0 6837 783 0 204 52 - 100 32 0 0 0 0 6852 787 1 170 53 - 100 29 0 0 0 0 6842 783 0 142 53 - 100 30 0 0 0 0 6854 785 1 242 54 - 100 25 0 0 0 0 6836 783 0 150 52 - 53 15 0 0 0 0 6851 785 1 188 53 - 100 25 0 0 0 0 6835 796 0 175 52 - 85 24 0 0 0 0 6853 783 1 199 53 - 100 25 0 0 0 0 6848 783 0 114 52 - 100 32 0 0 0 0 6846 785 1 209 54 - 100 28 0 0 0 0 6846 784 0 85 51 - 100 30 0 0 0 0 0 0 1 139 53 - 100 25 0 0 0 0 6842 795 0 211 53 - 56 16 0 0 0 0 6848 783 1 240 53 - 98 26 0 0 0 0 6844 782 0 214 53 - 78 18 0 0 0 0 6847 783 1 211 53 - 100 24 0 0 0 0 7901 784 0 206 54 - 100 23 0 0 0 0 6837 782 1 220 54 - 100 28 0 0 0 0 6868 782 0 87 51 - 60 13 0 0 0 0 0 0 1 208 54 - 100 25 0 0 0 0 6849 783 0 85 51 - 0 0 0 0 0 0 0 0 1 126 53 - 100 27 0 0 0 0 6836 781 # gpu pwr gtemp mtemp sm mem enc dec jpg ofa rxpci txpci # Idx W C C % % % % % % MB/s MB/s 0 57 49 - 0 0 0 0 0 0 0 0 1 190 54 - 100 22 0 0 0 0 6835 791 0 57 49 - 0 0 0 0 0 0 0 0 1 131 54 - 100 19 0 0 0 0 6842 782 0 57 49 - 0 0 0 0 0 0 6842 781 1 106 53 - 97 19 0 0 0 0 0 562 0 85 50 - 56 1 0 0 0 0 0 0 1 106 52 - 59 2 0 0 0 0 0 0 0 85 50 - 3 1 0 0 0 0 0 0 1 106 52 - 0 0 0 0 0 0 0 0所以 §2.2/§2.3 那些读速是"被带宽钉住的天花板",不是 GPU 的极限。如果 PCIe 通道有余量(同一张 Gen3 卡插 x16,通道直接翻倍到 15.75GB/s),prefill 还应该再往上走一截——能到多少这台测不了(双卡与单条 x16 在本板互斥),我不给倍数承诺,但方向是确定的:瓶颈在带宽不在卡芯。
这笔账顺手解开帖里另外两个疙瘩:为什么 §4 里计算类开关在 16K 口径测出来是零——带宽拉满时,计算再快也只是在带宽口排队,长题靠批量摊薄把每 token 的占管降下来,收益才透得出来;为什么 decode 却能 +26%——decode 每 token 只搬点亮路由的少数专家、99% 命中根本不太占带宽,它的天花板在计算路径上,开关自然够得着。
3. 优化参数全放送:每一条讲原理、给实测、标坑
先立总纲:这台机器优化前后面貌完全不同,但收益全部来自配置,一分钱硬件没加。sm_75 在 Strata 生态里属于"文档没专门写过"的架构,所以每个开关都必须自己 A/B——下面每条都有档案编号可查。
3.1 Turing 三开关(本帖最值钱的一条):decode +18~26%
Turing 没有原生的 BF16/TF32 张量核路径。官方为 Turing 页写了两个 opt-in 开关,还特意注明"这是既有代码路径,不是新写的 kernel";第三个
SM75_PERF的 kernel 来自 issue #3282 的实测(官方回复说考虑设为 sm_75 默认)。三个我都自己 A/B 过:开关 干什么(机理上能解释:) 我的实测 STRATA_BF16_TC=1prefill 的 BF16 投影操作数转 FP16 走 FP16 张量核(FP32 累加) 长题读 +7~19%(与下条叠加后的组合收益,单开关归因见档案臂) STRATA_SELECT_SIMT=1注意力块打分器(QSA)从 warp 通路换成分块 tiled FP32 通路(官方口径) 我这台 decode 大头增益(B 臂 +12~13%);官方 Quadro 数据里它是 prompt 项 +6%——decode 归因是本平台实测 STRATA_SM75_PERF=1为 sm_75 启用专用 kernel(机主提供,未成默认) decode 再 +12~13%(叠加在上两条之上);同机主的贪心重跑对照显示开关开/关生成文本集合与频次一致 叠加后:decode 4k 69.3→87.6(+26%)、16k 67.3→79.7(+18%)、80K 长题 +7.6%、171K 长题 +19.0%(standard-v1 与长题探针,同机同轮三臂对照,档案
sm75ab2-*)。注意每行"我的实测"是组合叠加中的归因,不是可加和的单开关数字。护栏也立着:官方文档对 BF16_TC 的提醒是"舍入次序变了,9 对配对请求里有 3 条回答变了"——这类开关本来就是拿舍入换速度。万一写作/工具调用里出现 JSON/数字类输出异常,撤
SM75_PERF这一条重启,一分钟回退——采纳当晚四轮 12/12 加后续复测都干净,但护栏留着不丢人。3.2 显式层切 + trim:专家槽的隐藏机关
--trim-stage-weights让每张卡只加载自己负责层的密集阶段权重,腾出的显存全换成专家缓存槽。机理简单,坑在一个"显式"上:- 层切设
auto时,引擎自己穷举出的摆放不算显式,trim 被静默忽略——不报错、不告警(引擎日志口径:两卡合计 4087 槽=CUDA0 2109+CUDA1 1978); - 顶层
layer_split=24(显式数字)后 trim 解锁:合计 5088 槽(3103+1985)——正好多出约一千个。重装第一晚开机对账时我发现槽数比预期少了约一千,顺藤摸瓜才抓到这个静默失效; - 顺手也试过
26:合计 5047 槽(2980+2067)、16K 读速与 24 持平——切点不是越大越好,24 是实测甜点。
3.3 显存安全余量:留着余量,读速反而全场最快
默认配置装载完 CUDA0 只剩 552 / CUDA1 只剩 430MiB(引擎自己打出 LOW 警告),第一个真实请求一开工就把红线告警 #2065 撞出来了——原话:"when the card is this full the driver can page GPU memory to system RAM, decode falls to a few tok/s",请求开始低余量告警连打好几行(free 474/454/444/440/420MiB,两卡混合)。余量梯度(11G 卡上的本机 A/B,每档独立 bench 档案):
档位 initial/later(MiB) 专家槽(两卡合计=CUDA0+CUDA1) 16K 读(tok/s) 装载后 free(CUDA0/CUDA1) 告警 默认 5088 964.9 552/430 请求期触发 #2065(告警行 474/454/444/440/420) 1100/1184 4634(2885+1749) 899.5 — 零 900/1184 4743(2994+1749) 902.9(-6.4% vs 964.9) — 零 900/900(终态) 4881(2994+1887) 972.5-973.3(全场最快) 752/630 零(连 215.7K 长档探针期间也零) "省显存"抠到骨头是给读速和 decode 交税的,留足余量几乎免费甚至倒赚;later 预留单独拔高是最亏的一档(900/1184 两头不讨好,-6.4%);余量数值是随配置变的常数,不是通用真理——上一篇那台 16G 卡的预留数照搬过来就是 1184 档的下场,正确姿势是读引擎开机警告点名的数、自己跑梯度,换机器必重测。并且留足显存余量以后显卡的功耗也降下来了一些,这对能效和散热都是有正面积极作用的。
3.4 跨对话缓存:7G 预算的小水杯也能解大渴
--conversation-cache-mib 7168 --conversation-cache-slots 16 --conversation-cache-min-tokens 2048 --conversation-cache-min-free-mib 2048:上一篇 128G 内存那台给 36G 预算,这台 64G 只给得起 7G,机制一样、账法不同——实测快照 ~671MB/2.07 万 token,park 250ms / restore 83.6ms,2 万 token 级会话约容纳 10 个;五会话停放后第二轮请求从 22s 冷读降到 7.1s。小预算的用法是让它只当"最近十来个会话"的速记本,evictions 渐进增长就随它,突增再动。3.5 其余在役参数一览
参数 一句话 --pipeline-windows 2文档写明 CUDA 上不默认开,必须手加(上一篇同款白捡项) --kv int8+--max-context 262144256K 上下文的容量前提 --spec 4 --spec-min-p 0.5+--mtpMTP 投机解码;实测草稿头工作正常(真请求 drafts accepted 137/264) STRATA_PF_FUSED/STRATA_SPLIT_MTP_BATCH/STRATA_STAGE_TRIM沿用上一代配置的无损项,换代后逐项复测过留下 ROUTE_PRIOR(0.1.52 新默认,≤13G 显存卡默认开) 手贱关掉试过:decode -15%。新默认背后都是消融,动它之前先当它是故意的 透明大页 这台引擎原生全量吃到(实测 AnonHugePages≈ 46.8G,正好等于专家池大小),上一篇那台 X99 要手动ARENA_THP=1——同一个优化在不同机器上的"存在形式"可能完全不同,验生效别看参数看日志3.6 一个在目前软件环境下没什么卵用的配置:NVLink
这卡当年最响的卖点 NVLink,桥我插着(
nvidia-smi nvlink -s实测每卡两条 25.8GB/s 链路是活的)——但在 Strata 的层切架构里卡间交接走 pinned 内存通路,NVLink 全程没戏份(文档口径如此,欢迎打脸)。买卡别为它加钱。4. 判决故事:三个开关从"白天否决"到"当晚平反"
这台机器最好看的一场戏,是我的配置连续两次错、第三次才对的全过程——比任何参数都值得抄。
白天:三开关首轮 A/B。
SM75_PERF在 sanity 的 JSON 转换题(I2)上两连败;速度上 16K 读 951/945(基线)对 956/956(该臂),decode 在噪声带。证据在手,当场否决,开关踢出配置。晚上越想越不对,做了三件事:
- 换长度刻度复测。做了长题探针(80K/171K,unique 前缀防缓存、
max_tokens=1、usage.prompt_tokens当分母)——+7% / +19% 出来了。原来短题区(≤21K)这台机器的瓶颈在 PCIe x8 专家换入带宽,计算加速在短题里空转:16K 是把长题真收益测成零的错误仪器。同一开关 16K +0.7%、171K +19%,从此我看任何 prefill 类开关先问"这个长度瓶颈在带宽还是在算力"。 - 查那道 sanity 题的底细。IQ 量化 + temp0 下,JSON/数字类题常存在两个得分几乎相等的候选 token,任何 kernel 舍入路径差异都能翻转它——公开机主帖(#3056)实测过开关全关时它同样抖。这叫"近平局题族"。
- 同开关复跑 sanity ×3:12/12、12/12、12/12 零失败。白天那两次,是题目自己本来就抖,不是 kernel 的锅。当晚恢复开关,终态就是 §2/§3.1 那些数字。
由此立下的判决纪律:sanity 单题失败 → 先查题型是否近平局族 → 再查该题开关全关时的历史失败记录 → 最后才怀疑 kernel。 顺序反了就是冤枉好开关。
外部基准也独立复现过"长度决定测得出测不出":#3282 里一位单卡 2080Ti 机主报同一开关在 16K 口径只有 +5~6%,在他 50K~150K 的真实负载带冷读 +32%(150K 冷读从约 226s 降到约 172s),decode 持平——和本文"16K +0 档、171K +19%"的形状完全一致。对数字之前先对长度刻度,别拿自己 16K 的读数怼别人 150K 的读数。
5. "外部作业抄不动"合集:同型号显卡 ≠ 同平台
这批全是社区真实数据 vs 我这台 2080Ti 的实测。都是 2080Ti,都抄不动,为什么每一条都查得明明白白:
外部结论(都是真实机主数据) 我的实测 为什么抄不动 EXP_MODE=8对 mode4 decode +2.7~8.5%(#2197 多位机主实测,楼里更高口径到 +12~16%)零收益(四臂对照全打平,偏差≤0.5%,sanity 四臂 12/12) 他们的红利是相对 mode 4 测的;咱引擎现行默认早已离开 mode 4(#2197 楼内自己给出 mode 8 对 mode 0 只 +~1.6%),对着现行默认复测,增量落进噪声带 "位等价开关组"(#3161,共五项)decode 均值 +5.6% 查无此账(我装的是其中四项,第五项与层切不兼容弃用) 一查验证机是双魔改 3080(sm_86)——其中一个开关在 Ampere 上本来就默认开,他的 +5.6% 是替新架构补默认,Turing 没有这笔账 上一篇那台的后期余量 1184(照搬成 900/1184 试) 16K 读 -6.4%(两头不讨好的最亏档) 见 §3.3,数值随配置变,跨机必重测 "文档会配合层切自动 trim" auto层切下 trim 静默失效,槽少 1000见 §3.2,必须显式数字切点 判决通用心法就一句:同型号显卡 ≠ 同平台——基线默认值、量化档、布局模式、CPU 平台,任何一个不同,别人的实测到你这就只是假设。包括我这篇的。
6. 终态配置放送(现役原样,已去 key;照抄前先读 §3.3 和 §5)
{ "args": [ "--pack", "~/.../packs/iq3_s", "--native", "~/.../IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf", "--ple-gguf", "~/.../IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf", "--expert-cache", "auto", "--prefill", "auto", "--spec", "4", "--spec-min-p", "0.5", "--mtp", "~/.../mtp/rt", "--max-context", "262144", "--kv", "int8", "--conversation-cache-mib", "7168", "--conversation-cache-slots", "16", "--conversation-cache-min-tokens", "2048", "--conversation-cache-min-free-mib", "2048", "--pipeline-windows", "2" ], "user_args": [ "--trim-stage-weights", "--vram-reserve-mib", "900", "--vram-reserve-later-mib", "900" ], "port": 8080, "host": "127.0.0.1", "gpu": [0, 1], "layer_split": 24, "env": { "STRATA_BF16_TC": "1", "STRATA_SELECT_SIMT": "1", "STRATA_SM75_PERF": "1", "STRATA_PF_FUSED": "1", "STRATA_SPLIT_MTP_BATCH": "1", "STRATA_STAGE_TRIM": "1" } }(
args里内部组件路径省略为~/...;另有沿用的速度投影控制向量一组(--control-vector-scaled/--cvec-*/--pcie-frac/--adapt-*)与--expert-profile未展开贴出——它们是上一代沿来的沿用项、本篇不聊;layer_split=24必须显式数字,理由 §3.2。)配套三句话:服务生命周期归 systemd(
Restart=on-failure,开机自启,重启就绪约 30 秒——NVMe 的机器加载真不慢;引擎只听127.0.0.1:8080+ API key,对外由同机 Caddy 反代加 HTTPS,裸 8080 不进局域网;功限/风扇是我自己反复实测的甜点(200/220W + 风扇 75/60),每台机器该有自己的数,不适合直接抄。但可以参考的是,我的公版卡是300A核心,涡轮卡是300,并且公版卡显存体质也好,整卡200W TDP上限和那张涡轮卡220W最后能分给核心的TDP差不多,最后实测他们跑LLM基本性能一致。散热这方面公版卡就是差一点,要多拉高一点风扇转速,不过好在公版卡哪怕拉到75%声音也比涡轮卡60%小,但涡轮卡热量直接往机箱外面排确实散热更容易处理。
7. 未完事项(立字据)与结语
- 带模型哈希的 conforming 终档:已交(§2.1 流程)
- 192K 级长上下文真测:已交
- prefill 拉满带宽的精确采样值:已采(2026-11-01 重开机窗口,
dmon -s put配 139,395 token 唯一冷读,数字已进 §2.5 表格,原始 196 行在数据包 05 文件) - 观察名单三个小开关(
IO_PREFETCH/DISJOINT_ADAPT/PA_V2T):机理上都是噪声带预期,随下次引擎升级一起回归,不单开实验轮 - 引擎版本更新后重跑本篇全部判决(尤其三开关——社区在推 Turing kernel 默认化,哪天它们变成免费午餐,本篇 §3.1 就该退休了)
结语:这台机器上发生的最重要的事不是"加了三个开关快了 26%",而是仪器错了两次才发现真收益、题目自己抖差点冤枉了 kernel、照搬自己的旧参数也要翻车。所有档案、长档语料脚本、被我自己判死的负结果都留着,要复现或对线的话,楼里说一声。
PS:
- 升级换代可以不重复下载(但我先交了 11.4G 学费):先把结论说死——安装程序不会自己找文件,光移动文件也没用。它只认
~/.config/strata/settings.json里data_dir这一个指针,而升级之后这个文件还是旧安装留下的,指针仍指旧目录。正确三步: -
- ① 首启前把 data_dir 改指新数据目录(或安装时传
--data-dir);
- ① 首启前把 data_dir 改指新数据目录(或安装时传
-
- ② 把模型分片/MTP/packs(连
.done完成标记)整个mv进那个目录;
- ② 把模型分片/MTP/packs(连
-
- ③ 再启动下载,它会按清单核对、直接"认领"现有文件,权重和草稿层零下载(引擎本体是版本组件,几百 MB 必须重下)。
- 我第一次跳过了①让它自己跑,它就在旧目录原地静默重下 83.6G,跑到 11.4G 我才从速度不对劲察觉并掐停(半成品
.part当场删掉,没污染正式文件)。改指后重跑,权重果然一个字节没再下——全程唯一实际下载 ≈ 646MB 引擎包。教训:升级前先cat一遍 settings.json,看清 data_dir 指的哪,别信"它会自动认"; - 双启时钟地狱:Windows 把北京时间数值写进 RTC、Linux 当 UTC 读,开机差 8 小时还伪装成"NTP 正常"。根治两件套
timedatectl set-local-rtc 1+set-timezone Asia/Shanghai——只改 local-rtc 不改时区等于没改; - 给分层机制"帮倒忙"的故事(mlock 钉死动态分层)上一篇讲过了,这台照方抓药没再踩。
-
-
-
版主审定:本帖设为优秀,作者 +3 积分奖励,继续加油!