抄作业翻车三次：4080S 32G 上 NInfer 跑 Qwen3.8-27B，双路 256K 全部跑通，崩卡根因定位到 CUDA Graph × 批量投机
-
-
-
这份定位很扎实，尤其崩3的对照（关 MTP 存活 / 只关 CUDA Graph 存活 / 单路带 Graph 也稳）把「Graph × batch≥2 投机」这个组合条件锁死了，比只报「并发崩」有用得多。几点可复现/可迁移的补充：
-
崩1的根因是「按 128 SM 写死的 resident CTA 预算 + 未按 split 区分 CTA/SM」，换 SM 数（80 的 4080S、92 的 4090D）就会在临界 chunk 翻车，1664/1665 的边界很干净。建议把 resident_ctas 改成 min(schedule_ctas, occupancy_per_sm × sm_count) 反哺 fork 作者；在那之前用 --prefill-chunk ≤1024 是对的。
-
崩3 建议再拆一刀：固定 batch=2，但让批里始终只有 1 个请求在跑（另一路只挂空），看是否仍崩。若仍崩 = 图重放本身有问题；若不崩 = 一个 capture 里塞了多请求的 KV 偏移。这能决定修法是「每 batch-size 各捕获」还是「投机 head 关 capture」。
-
速度 −11.5% 别急着归引擎：你自己也列了量化方案、投机机制、上下文三个变量都不同。要下结论至少把 SGLang 那条压到 262K、并把「内嵌头 vs 独立草稿」对齐到同一侧。AGIEval 分歧 32/34 完全对称、CEval/CMMLU 在 ±4pp 内，质量打平的结论站得住。
-
262K 双路只余 4.2GB 偏紧，建议做一次 needle-in-haystack（关键信息埋 200K+ 位置）确认是「跑通且召回不丢」，而不是 KV 换页。--no-cuda-graph 掉 2.6% 换稳定，这个 trade 很划算。
-
-
，
T terry 固定了此主题
-
-
-
-
-
，系统 取消固定了此主题
-
同卡用户（4080S 32G / 80 SM）。这篇帖子把我们直接引到了源码里那个出问题的数字上。先说结论：第一个崩溃已经在源码里修好了，修复代码也提交给原作者了（他还没合并）。 另外有三块我们自己踩出来的东西可以补充。
一、崩溃 1：已从源码层面修好（修复已提交原仓库）
4 楼 Xiaote 的建议
min(schedule_ctas, occupancy_per_sm × sm_count)方向是对的。我们做成了更彻底的形式：问题的实质是这样的。 显卡里有若干个运算单元（叫 SM，4080S 有 80 个）。有些计算任务必须"一次性同时占满所有运算单元"才能启动，所以程序在启动前要先算一下：按我们这次的规模，能不能放得下？ 这个"一个运算单元能同时放几个任务块"的数字，原本在两个不同的文件里各写了一份，而两份对不上——内核代码那份写乐观了（写成 2，实际只能放 1）。于是程序算出来"放得下"，一启动就被显卡拒绝，整个服务进程直接崩掉。
我们的修法：把这个数字抽到一个公共文件里作为唯一依据，让两处代码都读它；并且加了 8 条"编译期断言"——意思是，如果将来谁改了这个数字却忘了同步另一处，代码根本编译不过，而不是等到线上崩了才发现。这样就不需要靠人去记住"两个地方要一起改"。（这几档具体的设备级上限数字是 256/128/256/512/384。）
实测（27B 模型，sm_89）：
--prefill-chunk 2048加一个 26,298 token 的长提示词，不再崩溃，1,360 tok/s，服务存活；--prefill-chunk 1024是 1,348 tok/s（改之前 1,347，等于没有变化）。修复已提交给原作者（尚未合并），标题是
fix(gdn-gating-proj): correct per-SM residency constants for cooperative launch，
目标是sergiuszm/ninfer-4090的rtx4090-port分支。
️ 顺带提醒一句，免得有人白折腾：这个修复只是让大的 --prefill-chunk变得"不会崩"，并不会让它"更快"。 同一张卡的预填充速度实测：一次处理多少 token（chunk） 256 512 1024 2048 预填充速度 1,262 1,319 1,348 1,360 tok/s 过了 1024 基本就不涨了。所以即使打了补丁，chunk 设 1024 仍然是最优的——这个修复的作用是把"崩溃"变成"不崩但也没更快"。
二、两条和版本有关的观察
2.1 新版模型文件（19.03 GiB，附带了 DFlash2 草稿权重）在 sm_89 上并不是不能用
你说必须用旧的 commit，因为新版在文件里标注了
cuda_architecture: sm_120a和minimum_revision: 385b30ce。但同一种规格的模型文件，在我们这边跑得好好的——我们正在生产上跑的就是 19.03 GiB、同样附带了 DFlash2 草稿权重的版本。翻源码可以确认：sm_89 这条移植线上，引擎加载模型文件时检查的东西只有这几项——
"artifact magic is not NInfer v2" // 文件头标识 NINFER\0\002 "identity" 必须含 model_id, weights_id "objects" 必须是非空数组cuda_architecture和minimum_revision这两个字段，加载器根本不读、也不检查。 在这条线上它们只是写在文件里的标注，不影响能不能加载，所以不可能是"加载失败"的直接原因。但请把话说全，别被我们误导：我们的模型文件是用 sm_89 的工具链自己转换出来的（底模是
ukisai/Swift-Qwen3.8-27b，加上z-lab/Qwen3.8-27B-DFlash2 @ 50307d4c的草稿权重），不是直接下载 HF 上那份文件。我们只证明了「19.03 GiB + 带 DFlash2 草稿权重这种规格在 sm_89 上能跑」，没有测过那份原文件本身。而且minimum_revision这类字段存在，通常意味着权重数据的排列方式变过——引擎忽略它，不等于结果就是对的；"能加载"不等于"安全"。想直接下那个文件的人，请自己验一遍输出质量。2.2 崩溃 3（CUDA Graph × 多路投机解码）我们没能复现，有一个可能被忽略的变量
我们的配置同样是 CUDA Graph 开着、MTP 投机解码 3 个草稿 token、
--max-concurrency 4（比你的 2 还高），累计 24 小时以上混合并发连续压测（其中包含一次 10 分钟 / 1,397 个请求 / 4 路并发的压力测试），没有出现过任何cudaErrorLaunchFailure、没有任何 Xid 报错、没有出现整卡复位。唯一明显不同的变量：驱动版本。你是 595.84，我们是 595.91.07。
所以想请有条件的人验一刀：先在 595.84 上复现一次、抓下系统内核日志（dmesg），再升到 595.91.07 跑同样的 40 分钟基线。 如果升级后就不崩了，那这就不是"必须关掉 CUDA Graph"的引擎缺陷，而是特定驱动版本才会触发的组合问题——那 2.6% 的性能代价就能省掉。
保留意见：我们的模型文件是自己转的、引擎也是自己编的、不是社区预编译镜像，所以变量不止驱动一个。请当线索，别当结论。
顺带回应 4 楼 Xiaote 提的那个拆解实验（固定 2 路并发、但只让其中一路真的在跑）：我们没做——因为在我们这套参数下压根没复现出崩溃 3。真要分辨是"CUDA Graph 重放本身有问题"还是"一次图捕获里塞进了多个请求的 KV 位置"，那个实验应该在做会崩的配置上做才有意义。另外他提的 needle-in-haystack（在 20 万 token 的长文里埋一个关键信息、看模型还能不能回忆出来）我们也没做——我们只验了"不崩"，没验"记忆不丢"。这点他说得对，是我们的缺口。
三、底模换成 Swift-Qwen3.8-27b，而且引擎和模型都自己编
底模。 你们跑的是 HF 上
neroued/Qwen3.8-27B-NInfer的官方模型文件。我们换成了ukisai/Swift-Qwen3.8-27b——它是官方Qwen/Qwen3.8-27B的微调版，官方页面上的标签就写着efficient-thinking（高效思考）和token-efficient（省 token）。厂商自己页面上的原话是：using 58.3% fewer thinking tokens while maintaining near-identical performance
(<1% loss) and as a result getting a x1.95 speed-up on several tasks.意思是：思考用的 token 少了 58.3%，而质量几乎不掉（低于 1%），所以在若干任务上快了 1.95 倍。做法是找出"会引发过度思考的那类词"，在微调时惩罚它们，于是推理过程更短、想太多的错误也更少。在 Agent 场景下这点很关键：思考 token 直接等于你要等的墙钟时间，而且会挤占上下文。
我们的实测：26 小时生产流量、2,787 个开了思考的请求
引擎会给每个请求记一行日志，其中有两个字段：
model_thinking_tokens（这次实际思考了多少 token）和thinking_budget（这次允许它思考多少）。于是可以算出 "思考被上限截断"的比例：允许思考的上限 请求数 思考被截断的比例 2048 120 17.5% 4096 2,562 0.8% 8192 37 40.5% 16384 25 64.0% 上限设 4096 时，2,562 个请求里只有 0.8% 被截断——这用真实生产流量独立证实了你「budget ≥4000 是死参数」的结论（你那是 20 题探针，我们这是 2,562 个真实请求）。另外，没被截断的那些请求里，思考长度中位数只有十几到几十个 token——绝大多数请求想得很少，只有少数会想很久。确实"思考小"。
️ 但反过来，别把上限降太狠。 上限设 2048 时，17.5% 的请求会被截断。你说的「2000 省 10% 且不掉分」，在我们这边的流量上意味着大约每六个请求就有一个的思考被硬生生截断：简单题省 10% 是真的，但题一难就撞天花板。而 8192 / 16384 两档的截断率反而更高（40% / 64%）——可能是给多少预算它就思考多少，也可能只是这些请求本来就难（这两档样本只有几十个，我们分不清）。诚实说明：我们没有和官方底模做过同题对比，所以无法独立证实 58.3% 这个数字，只能报告我们自己流量的形态。想换 Swift 的人，请自己做一次对照。
自己编的方法
- 引擎：从
sergiuszm/ninfer-4090的源码自己编译成可运行的程序包（基础镜像是 CUDA 13.1.2 devel，一次编译约 13 分钟），编译流程里带自动化测试。这也正是我们能打上"崩溃 1 修复"和"请求进场改造"的前提——社区预编译好的程序包没法打补丁。 - 模型：用仓库自带的 Python 转换工具。它会读取模型里
generation_config.json这个文件的内容特征，自动判断来源（是官方版还是 Swift 微调版），并把 DFlash2 草稿权重一起打包进同一个模型文件：
python3 tools/convert/qwen3_8_27b/convert.py \ --model /path/to/Swift-Qwen3.8-27B-BF16 \ --dflash2-model /path/to/Qwen3.8-27B-DFlash2 \ --out swift_qwen38_27b.ninfer \ --device cpu它还会顺带产出一份记录来源的转换报告（用的是哪套转换配方、来源仓库和版本号、每个文件的内容指纹）。我们给转换工具加了一个提交，让它接受 Swift 这个来源——否则它的特征值不在工具认识的清单里，加载前的检查会直接拒绝。
"自己编"的真正收益：不是图省事，而是能修。崩溃 1 和请求进场这两个问题，等作者发新版不知要等多久；自己编是 13 分钟一次。
四、我们这边的几条调优差异
1）媒体缓冲那条，建议修正一下说法。 你写「裁剪 + 并发数改成 2 → 显存 −2.46 GB」，踩坑表里写「开视觉吃 3GB → 用 media 256/512 解决」。我们单独测过这项：只把 media 参数从默认改成 512/256，显存完全没有变化（30,880 对 30,882 MiB，KV 池大小也不变）。因为
media cache/live capacity这两个参数是 "需要时才分配"的上限，不是提前占用的内存。所以你看到的 −2.46 GB 应该来自裁剪 + 并发数改成 2，不是 media 参数本身的功劳。
但 media 参数仍然值得设，只是理由不同：它把开视觉功能时最坏情况会占用的显存，从 2048 MiB 压到 512 MiB。你当时只剩 4.2 GB 余量，而默认上限是 2048 MiB——那是个可能把显存撑爆的口子。别指望它省日常显存，指望它在关键时刻保命。
2）KV 池不是"并发数 × 单路上下文"。 你的并发数设 2，拿到 524,288，正好等于 2 × 262,144，所以看起来像是"引擎按并发数 × 单路上下文精确配池"。但我们同一张卡、同样用
--kv-capacity auto、并发数设 4，拿到的是 648,576——只有 4 × 262,144 的 62%。看起来
auto的规则是min(并发数 × 单路上下文, 显存装得下的量)。它的含义是：把并发数调大，每个请求能用的上下文长度会被悄悄摊薄。并发数 2 时你能给两路各 262K；设成 4 就给不了。所以在 32G 卡上，并发数 ≤ 2 是"每一路都能跑满 256K"的干净配置，你这个选择我认为是对的。3）思考预算：你把 budget ≥4000 判定为死参数（模型自然思考约 800 token），我们这边也把进程级默认钉在 4096，观测一致。
4）温度：我们把进程级默认设成 0.6（
--temperature参数，只影响那些没在请求里显式指定温度的直连客户端；走代理时每个请求都会带上自己的温度，会覆盖它）。多个客户端共用一个实例时，在服务端设一个默认值比让每个客户端自己带更可控。五、大杀器：把"大预填充把交互请求堵在门外"从 17 秒打到 0.3 秒
你第六节写
queue 5m35.8s、另一条被压到 3.3~3.7 t/s——这个现象我们也撞上了，而且追到了请求进场那一步。根因不是显卡怎么调度，而是调度器里有两条隐含的规矩：同一时刻只允许一个请求"占住"预填充，而且必须等正在跑的那个预填充彻底结束，新请求才能进场。后果就是：一个只需要 466 token 预填充的交互请求，必须等 92,700 token 的大预填充从头跑到尾才能被放进场——实测排队 16.4–17.0 秒、首字延迟 17.2 秒。这不是"慢"，是根本就进不来。
改法：允许多个请求同时排队等预填充，然后每轮挑一个来推进。挑的规则是 "谁剩余工作量小谁先做"，再加一条保险——被连续跳过 8 轮的，下一轮强制让它做。这条保险是关键：否则短请求源源不断到来时，长预填充会被无限期往后拖。我们还写了一个不依赖显卡的测试来验证这条保险确实有效（实测 100 个短请求连续到达时，长预填充被跳过的最大间隔正好是 8 轮，也就是上限）。
实测（4080S）：
修复前 修复后 60 token 探针请求的排队时间 16.4 – 17.0 秒 0.127 秒 探针请求的首字延迟 17.2 秒 0.279 秒 大预填充自己的速度 1.37k tok/s 1.37k tok/s（没有变慢） 
代价在 0~8% 之间，取决于小请求插了多少；只有单个请求时不付代价。另外做了 10 分钟 / 4 路并发 / 1,397 个请求的混合连续压测：0 失败、0 引擎报错、显存没有增长，其中 911 次采样出现过两到三份预填充同时在排队。
️ 这条必须把边界说清楚，否则容易被理解成吹牛：它只修好了 "还没进场的请求"。你描述的 "一条已经在解码、另一条在预填充，解码被压到 3.3~3.7 t/s"，是显卡一轮只能算一个任务单元的固有结果，这个改动并没有改善它。所以双路场景下"一边跑长预填充、一边还要低延迟"，仍然得靠别的办法（比如把长短请求分到不同实例上）。顺带一个副产品：我们把自己 agent 后端送进引擎的最长提示词，从 92,700 token 压到了约 9,800（改的是它自己的会话归档阈值，不是引擎参数）。这件事和引擎无关，但如果你那边也有"固定几个后端在猛灌超长提示词"的情况，先把喂进去的量降下来，往往比调引擎更立竿见影。
我们的配置供对照，差异处已标注（这些是引擎启动参数，括号里是含义）：
底模：ukisai/Swift-Qwen3.8-27b（官方 Qwen3.8-27B 的微调版）+ z-lab/Qwen3.8-27B-DFlash2 草稿权重打进同一个模型文件；模型自转（见第三节），引擎自编译 --max-context 262144 单路上下文上限 --kv-capacity auto 自动决定 KV 缓存池大小 --max-concurrency 4 最大并发数（我们设 4 → KV 池 648,576） --prefill-chunk 1024 一次预填充处理多少 token --kv-dtype rk4v4-e8 KV 缓存量化格式 --spec mtp --draft-tokens 3 --lm-head-draft 投机解码设置 --vision --vision-max-tokens 10240 开视觉（你设 8192） --media-cache-mib 256 --media-live-mib 512 图片缓冲上限 --max-pending-requests 16 --pending-timeout-ms 600000 排队上限与超时 --default-max-tokens 32768 --default-thinking-budget 4096 温度 0.6（服务端默认值） CUDA Graph：开启（我们没关，也没复现崩溃 3） 驱动 595.91.07感谢这份帖子，崩溃 1 的源码分析直接省了我们重新定位的时间。
说明：文中数据都来自我们自己机器上的实测日志，引擎每个请求的日志字段、提交记录、源码位置均可复核。本文由我提要点、AI 协助撰写整理。
- 引擎：从
-
-
