文章目录1. 估完显存之后还缺一步2. 先说结论3. 三个旋钮各自改什么3.1 量化3.2 上下文长度3.3 batch / 并发4. 推荐联调流程4.1 写下硬约束4.2 用扫描脚本缩小候选4.3 只拿少数候选上机压测4.4 固化默认值另留压力档5. 失败时的优先调整项6. 扫描结果的读法6.1 有多组 OK6.2 只有更短上下文才 OK6.3 全部 OOM_RISK7. 检查清单8. 常见误区8.1 以“打满显存”为优化目标8.2 先加 batch再发现上下文不够8.3 量化一降再降却不动过长默认上下文8.4 只在短 prompt 下测通就定默认值8.5 把扫描脚本结果当成实测9. 术语速查10. 小结11. 相关阅读摘要上一篇讲了如何从模型卡粗算显存。真正部署时问题往往变成同一张卡上上下文开多大、batch 开几路、量化选哪档才能既不浪费显存又不在长输入时频繁失败。本文给出三个旋钮各自影响什么、推荐联调顺序、失败时先动哪一项以及可运行的组合扫描脚本。适合已经能加载模型、准备把默认配置定下来的人。纸面扫描只作候选筛选最终以目标推理框架的峰值显存与失败率为准。承接前文本地部署大模型从模型卡估算本地显存大模型里的 MoE本地部署大模型前要不要加显卡建议继续用~/vram-lab或新建联调目录mkdir-p~/vram-tune/{notes,scripts,logs,configs}cd~/vram-tune# 本文sweep_vram_knobs.py / estimate_vram.py / probe_runtime_mem.sh文件作用scripts/sweep_vram_knobs.py扫描量化 × 上下文 × batch 组合scripts/estimate_vram.py单点粗算承接上一篇scripts/probe_runtime_mem.sh压测时采样显存峰值notes/tune_checklist.md联调与固化默认值清单configs/defaults.env最终默认上下文 / batch / 量化1. 估完显存之后还缺一步粗算回答的是这个模型在某组假设下“大概放不放得下”。联调回答的是另一件事业务上下文要开到多少才够用还剩多少显存可以换成并发batch为了腾出空间量化还能再重一档吗默认配置在长输入、多会话下会不会隔三差五失败很多人卡在两个极端极端表现过于保守4K 上下文 batch1显卡长期半空过于激进宣传上限上下文 多会话平时能跑一忙就 OOM图1. 量化压权重上下文和 batch 主要推 KV三者要一起调。2. 先说结论目标更合理的调法先保证业务可用先定业务所需上下文不先追模型宣传上限权重已经贴顶先加重量化或换更小模型再谈加长上下文权重还有空、对话偏短可逐步提高上下文再考虑 batch1要吞吐 / 多会话在上下文够用的前提下加 batch并重测峰值追求“打满显存”不建议更稳的是留 15%30% 余量后压测再压成四条先定业务上下文再选量化最后用剩余显存换 batch。一加载就失败多半是权重问题跑一会儿或长输入才失败多半是 KV / batch。纸面扫描负责缩小候选上机压测负责定默认值。稳定优先于打满打满后的第一次失败成本通常高于空一点显存。图2. 定上下文 → 选量化 → 加 batch → 压测留余量。3. 三个旋钮各自改什么3.1 量化主要改变权重体积和一定的质量风险。方向常见效果FP16 → Q8 / Q5 / Q4权重显存下降质量与兼容性要验收已经 Q4 仍放不下再降可能得不偿失优先换更小激活规模模型量化几乎不解决“开了 32K 上下文才爆”的问题那种情况要动上下文或 batch。3.2 上下文长度主要改变 KV 缓存近似随序列长度增长。方向常见效果2K → 8K → 32KKV 明显上涨长文档/长对话更稳开到宣传最大值纸面能写业务未必需要显存却先被吃光业务若只需 6K8K 有效上下文就按业务值定默认把 32K/128K 留给专项压力测试。3.3 batch / 并发主要用更多 KV 和临时缓冲换吞吐。方向常见效果batch1 → 2/4吞吐上升峰值显存上升多会话共用一卡等价于变相提高并发失败模式类似 batch 过大单用户助手常先 batch1 定稳服务端再按 QPS 目标加并发。图3. 过低浪费硬件过高换来偶发失败中间留余量更稳。4. 推荐联调流程4.1 写下硬约束在动旋钮前先写死三行GPU 可用显存预算____ GiB不要按标称值 100% 算 业务默认上下文____ tokens 最低可接受质量____例如固定验收题集通过预算建议先扣掉系统、桌面、其他常驻进程再留框架余量。4.2 用扫描脚本缩小候选scripts/sweep_vram_knobs.py会在量化 × 上下文 × batch 网格上做纸面粗算标出OK/TIGHT/OOM_RISK。示例一张大约 12GiB 可用预算的卡7B 稠密模型python3 scripts/sweep_vram_knobs.py\--total-b7\--gpu-gib12\--quantsq4,q5,q8\--contexts2048,4096,8192,16384,32768\--batches1,2,4\--margin0.25\--target-util0.85\--csvlogs/sweep_7b_12g.csv解读best在预算内、利用率不超过target-util时更偏向“够用且不太浪费”的组合OK纸面上看可进入实测名单TIGHT可能能跑但余量薄长输入风险高OOM_RISK先别拿去当默认值需要 JSONpython3 scripts/sweep_vram_knobs.py\--total-b7--gpu-gib12--json|teelogs/sweep_7b_12g.jsonMoE 同样先填总参激活参用于理解速度不默认拿来把权重显存估得很乐观。相关说明见上一篇与 大模型里的 MoE。4.3 只拿少数候选上机压测从扫描结果里挑 23 组不要把整个网格都实测一遍。对每一组记录记录项示例quant / context / batchq4 / 8192 / 1峰值显存9.6 GiB短输入延迟可接受 / 不可接受长输入接近默认上下文通过 / OOM / 明显变慢质量抽检通过 / 不通过采样可用上一篇的probe_runtime_mem.shchmodx scripts/probe_runtime_mem.sh# 终端 A按候选配置启动服务并跑固定长提示# 终端 B./probe_runtime_mem.sh304.4 固化默认值另留压力档通过压测后写入configs/defaults.envMODEL_QUANTq4CTX_DEFAULT8192BATCH_DEFAULT1CTX_STRESS32768BATCH_STRESS2日常服务只用*_DEFAULT压力档只在发版前或排障时开。图4. 加载即失败优先动量化/模型长输入失败优先动上下文/batch。5. 失败时的优先调整项现象优先动作次选动作模型还没开始对话就 OOM更重量化或更小模型确认是否重复加载了第二个模型短对话正常粘贴长文档后失败降低默认上下文降低 batch / 限制单请求长度单用户正常三人同时用就失败限流或降 batch略降上下文给并发留 KV显存还空但速度不够提高 batch 或换引擎/量化策略检查是否 CPU 卸载过多量化后答非所问增多回退到更轻量化换同尺寸更高质量量化档而不是盲目加上下文一条实用规则权重贴顶→ 动量化 / 模型规格KV 贴顶→ 动上下文 / batch两者都紧→ 先保业务上下文再砍并发最后才考虑再重量化6. 扫描结果的读法假设gpu-gib12target-util0.85扫描后常见三种读法6.1 有多组 OK优先选满足业务上下文质量可接受的最稳向量化再考虑 batch1 是否真有吞吐收益不要只因为util最高就选中最高利用率往往最脆。6.2 只有更短上下文才 OK说明这张卡在该模型上撑不住目标上下文。选项是接受更短默认上下文长文档改分段更重量化并做质量回归换更小模型或加卡6.3 全部 OOM_RISK先回到单点粗算确认总参、量化、预算是否填错若无误则当前卡不适合该模型的目标配置不要靠“再减一点余量”硬上。图5. 扫描出候选压测定峰値再写入默认配置。7. 检查清单保存为notes/tune_checklist.md# 上下文 / batch / 量化联调清单 ## 约束 - [ ] GPU 可用预算GiB已写下 - [ ] 业务默认上下文已写下 - [ ] 质量验收题集已准备 ## 纸面扫描 - [ ] 跑通 sweep_vram_knobs.py - [ ] 选出 23 组 OK/TIGHT 候选 - [ ] MoE 未误把激活参当成权重上限 ## 压测 - [ ] 每组都测短输入与近上限长输入 - [ ] 记录峰值显存与失败次数 - [ ] 多会话场景单独测过如需要 ## 固化 - [ ] defaults.env 已写入 - [ ] 压力档与默认档分开 - [ ] 发版说明里写清默认上下文与并发8. 常见误区8.1 以“打满显存”为优化目标打满后下一次稍长的输入就可能失败。稳定服务更需要余量。8.2 先加 batch再发现上下文不够顺序反了。上下文是产品能力batch 是吞吐手段。8.3 量化一降再降却不动过长默认上下文质量已经被压坏显存却仍被超大 KV 吃掉。8.4 只在短 prompt 下测通就定默认值默认值要用接近上限的长输入验收。8.5 把扫描脚本结果当成实测脚本继承上一篇的规划公式负责排序候选不负责替框架签名。9. 术语速查术语本文用法上下文 / context单次可保留的输入历史长度上限batch同时处理的序列数或并发度量化降低权重精度以减小常驻体积利用率规划占用 / GPU 可用预算TIGHT纸面能放下但余量偏薄的组合默认档 / 压力档日常配置与极限测试配置分开OOM显存不足导致分配失败10. 小结大模型本地部署时联调上下文、batch和量化核心是按顺序做取舍先定业务上下文再选能通过质量验收的量化用剩余显存决定 batch纸面扫描缩候选压测定默认值并留余量显存估清楚之后真正让服务稳下来的是把这三个旋钮写成可重复的默认配置而不是每次凭手感拧。11. 相关阅读本地部署大模型从模型卡估算本地显存大模型里的 MoE本地部署大模型的详细考虑含脚本/代码本地部署大模型前要不要加显卡本地大模型跑通了为什么还是不好用本地部署大模型显卡/Orin如果后面继续写相关主题可以再展开本地推理服务里如何给单请求做上下文限流与排队避免一个长文档拖垮整张卡相关链接NVIDIA nvidia-smiHugging Face Model Cards如果这篇对你有所帮助欢迎点赞、收藏也欢迎关注后续更新。 大模型本地部署，联调上下文、batch和量化
文章目录1. 估完显存之后还缺一步2. 先说结论3. 三个旋钮各自改什么3.1 量化3.2 上下文长度3.3 batch / 并发4. 推荐联调流程4.1 写下硬约束4.2 用扫描脚本缩小候选4.3 只拿少数候选上机压测4.4 固化默认值另留压力档5. 失败时的优先调整项6. 扫描结果的读法6.1 有多组 OK6.2 只有更短上下文才 OK6.3 全部 OOM_RISK7. 检查清单8. 常见误区8.1 以“打满显存”为优化目标8.2 先加 batch再发现上下文不够8.3 量化一降再降却不动过长默认上下文8.4 只在短 prompt 下测通就定默认值8.5 把扫描脚本结果当成实测9. 术语速查10. 小结11. 相关阅读摘要上一篇讲了如何从模型卡粗算显存。真正部署时问题往往变成同一张卡上上下文开多大、batch 开几路、量化选哪档才能既不浪费显存又不在长输入时频繁失败。本文给出三个旋钮各自影响什么、推荐联调顺序、失败时先动哪一项以及可运行的组合扫描脚本。适合已经能加载模型、准备把默认配置定下来的人。纸面扫描只作候选筛选最终以目标推理框架的峰值显存与失败率为准。承接前文本地部署大模型从模型卡估算本地显存大模型里的 MoE本地部署大模型前要不要加显卡建议继续用~/vram-lab或新建联调目录mkdir-p~/vram-tune/{notes,scripts,logs,configs}cd~/vram-tune# 本文sweep_vram_knobs.py / estimate_vram.py / probe_runtime_mem.sh文件作用scripts/sweep_vram_knobs.py扫描量化 × 上下文 × batch 组合scripts/estimate_vram.py单点粗算承接上一篇scripts/probe_runtime_mem.sh压测时采样显存峰值notes/tune_checklist.md联调与固化默认值清单configs/defaults.env最终默认上下文 / batch / 量化1. 估完显存之后还缺一步粗算回答的是这个模型在某组假设下“大概放不放得下”。联调回答的是另一件事业务上下文要开到多少才够用还剩多少显存可以换成并发batch为了腾出空间量化还能再重一档吗默认配置在长输入、多会话下会不会隔三差五失败很多人卡在两个极端极端表现过于保守4K 上下文 batch1显卡长期半空过于激进宣传上限上下文 多会话平时能跑一忙就 OOM图1. 量化压权重上下文和 batch 主要推 KV三者要一起调。2. 先说结论目标更合理的调法先保证业务可用先定业务所需上下文不先追模型宣传上限权重已经贴顶先加重量化或换更小模型再谈加长上下文权重还有空、对话偏短可逐步提高上下文再考虑 batch1要吞吐 / 多会话在上下文够用的前提下加 batch并重测峰值追求“打满显存”不建议更稳的是留 15%30% 余量后压测再压成四条先定业务上下文再选量化最后用剩余显存换 batch。一加载就失败多半是权重问题跑一会儿或长输入才失败多半是 KV / batch。纸面扫描负责缩小候选上机压测负责定默认值。稳定优先于打满打满后的第一次失败成本通常高于空一点显存。图2. 定上下文 → 选量化 → 加 batch → 压测留余量。3. 三个旋钮各自改什么3.1 量化主要改变权重体积和一定的质量风险。方向常见效果FP16 → Q8 / Q5 / Q4权重显存下降质量与兼容性要验收已经 Q4 仍放不下再降可能得不偿失优先换更小激活规模模型量化几乎不解决“开了 32K 上下文才爆”的问题那种情况要动上下文或 batch。3.2 上下文长度主要改变 KV 缓存近似随序列长度增长。方向常见效果2K → 8K → 32KKV 明显上涨长文档/长对话更稳开到宣传最大值纸面能写业务未必需要显存却先被吃光业务若只需 6K8K 有效上下文就按业务值定默认把 32K/128K 留给专项压力测试。3.3 batch / 并发主要用更多 KV 和临时缓冲换吞吐。方向常见效果batch1 → 2/4吞吐上升峰值显存上升多会话共用一卡等价于变相提高并发失败模式类似 batch 过大单用户助手常先 batch1 定稳服务端再按 QPS 目标加并发。图3. 过低浪费硬件过高换来偶发失败中间留余量更稳。4. 推荐联调流程4.1 写下硬约束在动旋钮前先写死三行GPU 可用显存预算____ GiB不要按标称值 100% 算 业务默认上下文____ tokens 最低可接受质量____例如固定验收题集通过预算建议先扣掉系统、桌面、其他常驻进程再留框架余量。4.2 用扫描脚本缩小候选scripts/sweep_vram_knobs.py会在量化 × 上下文 × batch 网格上做纸面粗算标出OK/TIGHT/OOM_RISK。示例一张大约 12GiB 可用预算的卡7B 稠密模型python3 scripts/sweep_vram_knobs.py\--total-b7\--gpu-gib12\--quantsq4,q5,q8\--contexts2048,4096,8192,16384,32768\--batches1,2,4\--margin0.25\--target-util0.85\--csvlogs/sweep_7b_12g.csv解读best在预算内、利用率不超过target-util时更偏向“够用且不太浪费”的组合OK纸面上看可进入实测名单TIGHT可能能跑但余量薄长输入风险高OOM_RISK先别拿去当默认值需要 JSONpython3 scripts/sweep_vram_knobs.py\--total-b7--gpu-gib12--json|teelogs/sweep_7b_12g.jsonMoE 同样先填总参激活参用于理解速度不默认拿来把权重显存估得很乐观。相关说明见上一篇与 大模型里的 MoE。4.3 只拿少数候选上机压测从扫描结果里挑 23 组不要把整个网格都实测一遍。对每一组记录记录项示例quant / context / batchq4 / 8192 / 1峰值显存9.6 GiB短输入延迟可接受 / 不可接受长输入接近默认上下文通过 / OOM / 明显变慢质量抽检通过 / 不通过采样可用上一篇的probe_runtime_mem.shchmodx scripts/probe_runtime_mem.sh# 终端 A按候选配置启动服务并跑固定长提示# 终端 B./probe_runtime_mem.sh304.4 固化默认值另留压力档通过压测后写入configs/defaults.envMODEL_QUANTq4CTX_DEFAULT8192BATCH_DEFAULT1CTX_STRESS32768BATCH_STRESS2日常服务只用*_DEFAULT压力档只在发版前或排障时开。图4. 加载即失败优先动量化/模型长输入失败优先动上下文/batch。5. 失败时的优先调整项现象优先动作次选动作模型还没开始对话就 OOM更重量化或更小模型确认是否重复加载了第二个模型短对话正常粘贴长文档后失败降低默认上下文降低 batch / 限制单请求长度单用户正常三人同时用就失败限流或降 batch略降上下文给并发留 KV显存还空但速度不够提高 batch 或换引擎/量化策略检查是否 CPU 卸载过多量化后答非所问增多回退到更轻量化换同尺寸更高质量量化档而不是盲目加上下文一条实用规则权重贴顶→ 动量化 / 模型规格KV 贴顶→ 动上下文 / batch两者都紧→ 先保业务上下文再砍并发最后才考虑再重量化6. 扫描结果的读法假设gpu-gib12target-util0.85扫描后常见三种读法6.1 有多组 OK优先选满足业务上下文质量可接受的最稳向量化再考虑 batch1 是否真有吞吐收益不要只因为util最高就选中最高利用率往往最脆。6.2 只有更短上下文才 OK说明这张卡在该模型上撑不住目标上下文。选项是接受更短默认上下文长文档改分段更重量化并做质量回归换更小模型或加卡6.3 全部 OOM_RISK先回到单点粗算确认总参、量化、预算是否填错若无误则当前卡不适合该模型的目标配置不要靠“再减一点余量”硬上。图5. 扫描出候选压测定峰値再写入默认配置。7. 检查清单保存为notes/tune_checklist.md# 上下文 / batch / 量化联调清单 ## 约束 - [ ] GPU 可用预算GiB已写下 - [ ] 业务默认上下文已写下 - [ ] 质量验收题集已准备 ## 纸面扫描 - [ ] 跑通 sweep_vram_knobs.py - [ ] 选出 23 组 OK/TIGHT 候选 - [ ] MoE 未误把激活参当成权重上限 ## 压测 - [ ] 每组都测短输入与近上限长输入 - [ ] 记录峰值显存与失败次数 - [ ] 多会话场景单独测过如需要 ## 固化 - [ ] defaults.env 已写入 - [ ] 压力档与默认档分开 - [ ] 发版说明里写清默认上下文与并发8. 常见误区8.1 以“打满显存”为优化目标打满后下一次稍长的输入就可能失败。稳定服务更需要余量。8.2 先加 batch再发现上下文不够顺序反了。上下文是产品能力batch 是吞吐手段。8.3 量化一降再降却不动过长默认上下文质量已经被压坏显存却仍被超大 KV 吃掉。8.4 只在短 prompt 下测通就定默认值默认值要用接近上限的长输入验收。8.5 把扫描脚本结果当成实测脚本继承上一篇的规划公式负责排序候选不负责替框架签名。9. 术语速查术语本文用法上下文 / context单次可保留的输入历史长度上限batch同时处理的序列数或并发度量化降低权重精度以减小常驻体积利用率规划占用 / GPU 可用预算TIGHT纸面能放下但余量偏薄的组合默认档 / 压力档日常配置与极限测试配置分开OOM显存不足导致分配失败10. 小结大模型本地部署时联调上下文、batch和量化核心是按顺序做取舍先定业务上下文再选能通过质量验收的量化用剩余显存决定 batch纸面扫描缩候选压测定默认值并留余量显存估清楚之后真正让服务稳下来的是把这三个旋钮写成可重复的默认配置而不是每次凭手感拧。11. 相关阅读本地部署大模型从模型卡估算本地显存大模型里的 MoE本地部署大模型的详细考虑含脚本/代码本地部署大模型前要不要加显卡本地大模型跑通了为什么还是不好用本地部署大模型显卡/Orin如果后面继续写相关主题可以再展开本地推理服务里如何给单请求做上下文限流与排队避免一个长文档拖垮整张卡相关链接NVIDIA nvidia-smiHugging Face Model Cards如果这篇对你有所帮助欢迎点赞、收藏也欢迎关注后续更新。