最近两周我把大部分精力都砸在了一个预览版推理模型的本地部署上——就是标题里说的 Step 5 Preview。第一次拉起服务的过程可以用惨烈来形容模型权重刚加载到 78%终端直接甩出一行CUDA out of memory显存 OOM 报错干脆利落连个商量的余地都没有。我先后换了三种量化方案、两套推理框架、四次调整上下文长度才让它在一张 24G 显存的消费级卡上稳稳跑起来并且留出了足够的余量给并发请求。这个过程中踩的坑比我在任何一份官方文档里看到的都多。这篇内容想解决的就是一个非常具体的问题当你想在自己的一台机器上跑一个参数量不算小的预览版模型显存 OOM 反复出现时到底该从哪几个维度去拆解原因以及在预算极其有限的前提下一人公司该怎么做出性价比最高的选型。它不是一个装完就能用的教程而是一份从报错现象倒推根因、再倒推硬件与参数配置的完整思路。适合三类人看手上有单卡或双卡工作站、想省钱自建的独立开发者正在评估租算力还是买卡的小团队负责人以及那些模型能加载进去、但一跑长文本就崩的技术同学。哪怕你只有 8G 或者 12G 的显存文中的估算方法和降级路径同样适用——只是你要接受的性能妥协更多一些。1. 先把账算清楚一人公司为什么要碰本地部署在讨论显存之前得先说清楚动机。如果只是想试试模型效果调用云端接口的成本几乎可以忽略一分钟就能跑通。真正让人愿意折腾本地部署的是另外几件事数据不出机器、调用量大了之后的边际成本、以及对推理过程的完全掌控权。对一人公司来说这三点的权重和大型团队完全不同——你没有专门的运维没有采购流程也没有可以分摊的闲置算力每一分钱和每一个小时都要算得很清楚。1.1 本地部署对一人公司的真实价值我自己的业务场景是批量处理文档和做内部知识检索。这类任务的特点是请求量大、单次上下文长、对延迟不敏感但对单位成本极其敏感。按云端接口的计费方式一天几千次调用下来费用很快就会超过一张消费级显卡的价格。再加上文档里可能包含客户资料走外部接口需要额外做脱敏这部分人力成本其实更贵。所以本地部署对我不是技术洁癖而是一道很直白的算术题一次性投入硬件换来一个固定的、可预测的边际成本曲线。但这里有个容易被忽略的前提本地部署的成本不只是硬件还包括你的时间。一人公司最贵的资源就是注意力。如果为了省几百块的算力费你要花两周去调优一套不稳定的推理环境那这笔账是亏的。所以我在选型时给自己定了一条硬规则任何方案如果调试时间超过两个工作日还不能稳定跑起来就放弃换更保守的路线。这条规则后来帮我砍掉了好几个看起来很美好、实际上坑很深的方案。1.2 OOM 报错背后其实是三类完全不同的问题新手最容易犯的错误是把所有out of memory当成同一个问题。实际上它至少分为三类处置手段截然不同。第一类是权重装不下也就是模型本身的参数在目标精度下超过了显存容量这种情况无论你怎么调参数都没用只能降精度或者换卡。第二类是权重装得下但运行时爆掉通常发生在处理长文本或者并发请求的时候元凶是 KV Cache 的膨胀。第三类是碎片化和框架预留导致的假性不足明明理论上够用实际就是分配不出来。我最初遇到的就是第二类和第三类混合的情况。日志显示加载阶段已经过了模型也返回了一次正常的回答但当我喂进去一份两万字的文档时进程直接被杀。那段时间我一直以为是显存不够大差点就去下单更大显存的卡后来用监控工具逐秒打印显存占用才发现静态占用只有 60% 左右剩下 40% 全被一个我没预料到的缓冲区吃掉了。这个发现直接省下了一笔不小的开支。1.3 这篇文章的组织逻辑接下来的内容按照先归因、再估算、后选型、最后落地的顺序展开。第二章拆解显存到底被谁吃掉了把每一块占用都量化出来第三章给出一套可以在纸上算完的估算公式让你在下载模型之前就知道能不能跑第四章讲低成本的选型组合包括量化等级、推理框架和硬件路线第五章是完整的实操配置和压榨显存的顺序第六章是问题速查表和我踩过的具体坑。这套顺序很重要。我见过太多人上来就问用什么参数能跑然后在论坛里复制粘贴一堆互相冲突的启动命令。先搞清楚原理后面的参数选择就是自然推导出来的结果而不是碰运气。2. OOM 根因拆解显存到底被谁吃掉了要把显存这个黑盒打开最有效的办法是把它拆成几块相对独立的账单。我习惯分成五块模型权重、KV Cache、激活值与临时缓冲区、框架自身的运行时开销、以及显存碎片。这五块的特性完全不同——前两块是大头但可控中间一块随输入波动后两块是纯粹的损耗却经常是压垮骆驼的最后一根稻草。2.1 模型权重的显存账单模型权重是最大的一块也是最容易估算的。基本公式是参数量 × 每个参数的字节数。半精度FP16 或 BF16下每个参数占 2 字节8 位量化占 1 字节4 位量化理论上占 0.5 字节。一个 30B 参数的模型半精度需要大约 60GB8 位需要 30GB4 位需要 15GB。这就是为什么一张 24G 的卡跑 30B 模型半精度想都别想4 位量化才是唯一现实的路径。但实际占用总比理论值高一些原因是并不是所有层都会被量化。嵌入层、输出层、归一化层通常保持较高精度否则会明显影响效果。这部分参数占比不高但在 4 位量化的情况下会显得突出。我的经验是4 位量化后的实际权重占用大约比理论值高出 8% 到 15%。也就是说 30B 模型 4 位量化不要按 15GB 算按 17GB 算更保险。这个余量看起来不多但在 24G 卡上它可能就是你能否开启长上下文的关键。还有一点常被忽略加载过程中的峰值显存。不少框架会先把权重加载到内存再逐层搬到显存这个过程中显存里可能同时存在半精度副本和量化副本。如果你直接从半精度模型加载并在线量化峰值可能接近半精度的占用。规避办法是先离线量化好存盘再直接加载量化后的权重这样加载期的峰值就压下来了。我第一次 OOM 就发生在加载阶段正是这个原因。2.2 KV Cache 才是真正的隐形大户如果说权重是明面上的开销KV Cache 就是那个你永远算不准的变量。它的作用是缓存注意力计算中的键和值避免每生成一个新 token 都重新计算历史。公式大致是2 × 层数 × KV 头数 × 头维度 × 序列长度 × 批大小 × 每元素字节数。注意这里的 KV 头数可能远小于注意力头数因为现在普遍采用分组查询注意力多个查询头共享一组 KV 头这让缓存规模降低了好几倍。代入具体数字感受一下。一个 80 层、8 个 KV 头、头维度 128 的模型在 FP16 下每个 token 每层的 KV Cache 是 2 × 8 × 128 × 2 4096 字节也就是 4KB。80 层加起来是每 token 320KB。看着不多但上下文开到 32768 的时候单个请求就是 10GB。如果再叠加 4 路并发40GB 直接蒸发。我当时就是把上下文设成了模型支持的最大值然后并发设为 4相当于在权重之外又预约了四十多 G 的空间不爆才怪。这就解释了一个常见现象模型能跑短对话一喂长文档就崩。很多人误以为是模型能力问题其实是 KV Cache 撑爆了。处置手段有三个方向缩短上下文、减少并发、降低 KV Cache 的精度。第三个方向收益最直接——把 KV Cache 从 FP16 降到 8 位甚至 4 位显存直接减半或减到四分之一而质量损失在多数任务上几乎感知不到。我在文档处理场景下把 KV Cache 降到 8 位主观评测几乎没有差异显存却省下来一半。2.3 预览版模型特有的两个坑标题里之所以强调预览版是因为这类模型有一些额外的麻烦。第一个坑是默认配置不留余地。预览版的发布往往优先考虑效果展示默认上下文长度、默认批处理大小都设得比较激进直接跑就是给显存上满负载。你必须手动把默认值往下调而不是指望它自己适配你的卡。第二个坑是算子与硬件适配的不确定性。预览版可能用了一些比较新的注意力实现或者位置编码方案这些算子在特定硬件上可能没有办法走最优路径于是框架退回到一个更耗显存的通用实现。这种情况最气人——同样是这个模型别人跑得好好的你这里就是多吃两个 G。排查方法是看加载日志里有没有回退提示如果有试着换框架版本或者关掉某些优化开关。我在一次升级后就遇到过这个问题回退到上一个稳定版本立刻恢复正常。2.4 碎片化与框架预留最容易被忽略的 10%最后这块最没有存在感。推理框架通常会预分配一块显存池预分配的比例可以配置CUDA 的显存分配器在反复申请释放之后会产生碎片某些框架还会为了加速预留额外的 workspace。这些加起来通常会吃掉总显存的 10% 到 15%。所以那条显存够用的判断线绝对不能按理论值算。我的经验法则是理论占用不要超过总显存的 80%剩下 20% 留给上述所有损耗和突发波动。24G 的卡按 19G 可用来规划16G 的卡按 12.8G 规划。如果你发现按 80% 算下来装不下那就老老实实降级别赌。我见过太多人算到 95% 然后反复重启浪费时间不说还对硬件不友好。占用类型典型占比是否随输入变化主要压缩手段模型权重50%-70%否降低量化位宽、裁剪层数KV Cache15%-30%是随上下文和并发线性增长降 KV 精度、限上下文、限并发激活与缓冲区5%-10%是随批大小变化减小批大小、缩短输入框架运行时5%-8%否调整预分配比例、换框架显存碎片3%-8%是随运行时长累积定期重启、固定分配策略3. 参数算例把能不能跑变成一张纸上的算术题我特别推荐在下载模型之前先做一遍纸上计算。这个过程只需要五分钟却能避免下载几十 G 文件、装一遍环境、最后发现跑不起来的巨大浪费。下面给出我自己在用的估算流程以及两个真实用过的算例。3.1 权重显存的快速估算公式先用最粗的公式卡一道线权重占用 ≈ 参数量(B) × 每参数字节数 × 1.1那个 1.1 是未量化层和加载冗余的修正系数。4 位量化时每参数字节取 0.58 位取 1半精度取 2。比如 30B 模型 4 位量化30 × 0.5 × 1.1 16.5GB。这个数字已经超过了 16G 卡的 80% 安全线12.8G所以 16G 卡跑 30B 的 4 位量化理论上有戏实际上很难稳。而 24G 卡的 80% 是 19.2G16.5G 还在范围内剩下的 2.7G 就是留给 KV Cache 和缓冲的全部空间——这意味着你能开的上下文非常有限。3.2 一个完整的算例24G 卡跑 30B 模型假设我们有30B 参数、80 层、8 个 KV 头、头维度 128、4 位量化权重。目标场景是文档问答单次输入约 8000 token并发 2。第一步算权重16.5GB。第二步算 KV Cache每 token 320KBFP168000 token 单请求是 2.56GB并发 2 就是 5.12GB。第三步加缓冲按 1.5GB 估。合计 16.5 5.12 1.5 23.1GB。这个数字对比 24G 的物理显存看起来只差 0.9G实际上已经越过了安全线随时可能崩。于是我开始做减法按收益从高到低排序把 KV Cache 降到 8 位5.12GB 变成 2.56GB把量化权重里的部分层用更激进的量化权重压到 15.5GB缓冲压缩到 1GB。新的合计是 15.5 2.56 1 19.06GB正好卡在 19.2GB 的安全线以内。实测下来确实稳住了连续跑了两天没有出现 OOM。3.3 另一个算例16G 卡的上限在哪同样的方法算 16G 卡。安全线 12.8GB。如果跑 13B 参数模型、4 位量化权重约 7.15GB剩下 5.65GB 给 KV Cache 和缓冲。按每 token 320KB 算层数和头数会更小实际约 200KB8000 token 单请求是 1.6GB并发 2 是 3.2GB加 1GB 缓冲总共 11.35GB。有戏而且还有一点余量可以把上下文拉到 12000 左右。这个对比很说明问题16G 卡不是不能玩而是模型规模的天花板大概在 13B 到 14B 之间再往上就得靠 CPU 卸载而 CPU 卸载带来的延迟增加对交互式场景几乎是不可接受的。所以如果你的目标是 30B 级别的模型24G 是一个更现实的起点16G 只能算入门。这也是我在选型建议里最想说的一句话先定模型规模再定卡别反过来。显存容量安全可用80%4位量化可跑模型规模典型上下文与并发12GB9.6GB7B-8B8k 上下文并发 216GB12.8GB13B-14B8k-12k 上下文并发 224GB19.2GB27B-30B8k 上下文并发 2-348GB38.4GB60B-70B16k 上下文并发 2-44. 低成本选型量化、框架、硬件三者的平衡算清楚账之后选型就变成了一个约束优化问题在给定预算下找到量化等级、推理框架和硬件方案的最优组合。一人公司的特殊之处在于这三个维度里最贵的其实不是硬件而是试错时间。所以我的选型原则是优先选生态成熟、文档齐全、社区问题多的路线宁可牺牲一点理论性能。4.1 量化等级怎么选4 位是甜点但不是唯一答案量化等级的取舍本质是显存、速度和质量的三角权衡。我在同一个模型上做过一组对比用的是文档问答和摘要两类任务主观评测加客观指标混合打分。量化方案权重显存30B相对速度质量主观评分适用场景半精度约 60GB1.0x100单卡放不下需要多卡8 位约 30GB0.85x98显存充裕追求稳定质量4 位分组量化约 16.5GB0.9x-1.1x92-95单卡主力方案4 位激进分组约 15GB1.1x-1.3x85-90显存极度紧张可接受质量下降3 位及以下约 12GB1.2x70-80不建议用于生产有个反直觉的现象值得说4 位量化有时候比半精度还快。原因是权重变小之后从显存读取数据的时间大幅减少而解码阶段的瓶颈往往就在显存带宽上。只要反量化算子的开销不至于拖后腿整体就是净收益。我在实际测试中4 位分组的生成速度比半精度快了约 10%这对一人公司来说是个相当划算的意外收获。至于分组大小怎么选经验值是 64 或 128。分组越小精度越高但开销越大分组越大越省显存但质量下降明显。我用 128 分组跑下来感觉良好切换到 64 分组质量有小幅提升速度慢了大概 5%。这个取舍取决于你的任务对细节的敏感程度——摘要任务差别不大但需要精确引用原文的任务我建议用 64。注意如果你直接把半精度模型在线量化为 4 位加载期的峰值显存会接近半精度水平很可能在加载阶段就 OOM。务必先用工具离线量化并存盘再加载量化后的权重文件。4.2 推理框架选型吞吐、易用、显存占用的取舍框架这块我试过四个方向感受差异非常大。为了避嫌这里用特征描述代替具体名称。第一种是高吞吐批处理型框架核心优势是 PagedAttention 一类的显存分页技术能把 KV Cache 切分成固定大小的块统一调度碎片率极低并发能力强。代价是部署相对复杂对模型格式有要求且需要额外的服务化配置。如果你的场景是多用户并发或者批量离线推理这是首选。我在文档批处理任务上用它吞吐比单请求模式高出好几倍。第二种是轻量本地加载型框架主打一个开箱即用量化格式丰富CPU 和 GPU 混合推理支持得非常好。它的显存开销最低适合显存紧张的场景但并发能力弱基本是单请求串行。个人调试和小规模自用这个最省心。第三种是训练推理一体型框架生态最全几乎所有新模型第一时间就能跑各种量化方案齐全调试工具链完善。缺点是默认配置比较贪预分配显存比例高需要手动调参数才能压榨出余量。第四种是通用后端运行时跨硬件兼容性好但推理性能通常不是最优显存管理也比较粗糙。我只在硬件比较特殊、前三者都不支持的情况下才考虑它。框架类型显存效率并发能力部署复杂度一人公司推荐度高吞吐批处理型高强中高有并发需求时首选轻量本地加载型最高弱低调试与自用首选训练推理一体型中中中新模型尝鲜首选通用后端运行时中低中中特殊硬件兜底4.3 硬件路线买卡、租卡还是混合这是一人公司最纠结的地方。按我自己的账三条路各有明确的适用边界。自有单卡的优势是边际成本趋近于零随时可用不用排队数据完全可控。缺点是前置投入不小而且显卡会折旧、会过时。我的判断标准是如果你的日均推理时长稳定超过四小时并且会持续半年以上自有卡的经济性就明显占优。反之偶尔跑跑买卡就是浪费。按量租用的优势是零前置成本显存规格可以按需选择大显存卡也能短时用上。缺点是长期成本高、有网络传输开销、数据要出本地。它特别适合模型选型的探索期——你需要在不同规模上试跑这时候租几小时比买一张卡划算太多。我最初评估模型规模的时候就是租的两天时间试了三种规格成本远低于买错一张卡。混合路线是我现在采用的方案一张 24G 卡做日常主力遇到需要更大显存的任务临时租用。这样既保证了日常的即时可用性又避免了为峰值需求买单。对于一人公司来说我认为这是性价比最高的一种结构。4.4 CPU 卸载能救急但别当常规方案显存实在不够的时候把部分层放到内存里跑也就是 CPU 卸载是唯一的选择。这个技术的原理是把模型按层切分一部分层的计算在显卡上完成一部分在处理器上完成中间通过总线传输数据。问题是这个传输带宽远低于显存带宽所以速度下降是断崖式的。我实测下来卸载 20% 的层生成速度大概掉到原来的三分之一卸载 40%掉到十分之一以下。这个速度对批处理任务也许还能忍对交互场景基本不可用。所以我的建议很明确CPU 卸载只作为跑通验证的临时手段不作为生产方案。用它来确认模型效果、验证业务逻辑没问题然后老老实实升级硬件或者换更小的模型。我见过有人靠卸载硬撑着跑线上服务用户体验一言难尽。5. 实操从 OOM 到稳定跑起来的完整路径这一章是我自己最终落地的方案包含环境配置、启动参数和压榨显存的顺序。硬件前提是一张 24G 消费级显卡系统是常规的 Linux 发行版模型就是标题里那个预览版参数量在 30B 级别。5.1 环境与依赖的最小集合环境这块最容易出问题的是版本冲突。我的做法是严格隔离每个模型一个独立环境绝不共用。基础依赖锁定到具体版本号不用最新的用社区验证过最多的那个版本组合。# 创建独立环境避免版本污染 python -m venv step5_env source step5_env/bin/activate # 锁定基础版本不要盲目升到最新 pip install --upgrade pip24.0 pip install torch2.3.1 --index-url 内部镜像地址 pip install transformers4.42.3 accelerate0.31.0 pip install bitsandbytes0.43.1 # 4位量化核心依赖 pip install sentencepiece protobuf装完之后先跑一个最小验证确认推理框架能识别到显卡、显存容量读取正确、量化算子能正常初始化。这一步千万别跳过我吃过亏——有一次量化库版本和框架不匹配表面装成功了一加载模型就报一个和显存毫无关系的错排查了大半天。import torch print(设备:, torch.cuda.get_device_name(0)) print(总显存: %.1f GB % (torch.cuda.get_device_properties(0).total_memory / 1024**3)) print(可用显存: %.1f GB % (torch.cuda.mem_get_info()[0] / 1024**3)) # 简单验证量化算子是否可用 import bitsandbytes as bnb print(量化库版本:, bnb.__version__)5.2 一套可直接抄的启动配置下面这套配置是我反复调出来的能在 24G 卡上稳定跑 8k 上下文、并发 2。关键参数我都加了注释说明为什么这么设。from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig import torch quant_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, # nf4 在正态分布权重上表现最好 bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue, # 二次量化再省约 0.4 bit/参数 ) model AutoModelForCausalLM.from_pretrained( 本地模型目录, quantization_configquant_config, device_mapauto, max_memory{0: 19GiB, cpu: 48GiB}, # 关键给显存留出安全余量 attn_implementationflash_attention_2, # 显著降低激活值占用 trust_remote_codeTrue, ) tokenizer AutoTokenizer.from_pretrained(本地模型目录)几个参数值得展开说。max_memory设成 19GiB 而不是 24GiB是为了强制框架把超出的部分放到内存而不是硬塞进显存直到崩溃。attn_implementation选带优化的注意力实现对长上下文的激活值占用影响很大实测能省 1-2GB。bnb_4bit_use_double_quant这个开关很划算多花一点点解量化时间再省下接近 1GB 权重显存。如果你的框架支持 KV Cache 精度配置再加一行把它降到 8 位。这一步在我这里是收益最高的单项优化5GB 直接砍到 2.5GB# 服务化启动时通过参数控制 KV Cache 精度与显存分配比例 启动命令 --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 2 \ --swap-space 8gpu-memory-utilization 0.85这个值我试了 0.8 到 0.95 之间0.85 是稳定性和吞吐的最佳平衡点。高于 0.9 之后长时间运行容易出现突然的 OOM低于 0.8 又浪费显存上下文开不长。max-num-seqs控制并发这是最容易忽略却影响最大的参数我这里设成 2意味着 KV Cache 最多占两份而不是模型默认的 256 份。5.3 压榨显存的顺序按收益排序当显存不够时很多人是随手改一个参数试试效率极低。我总结了一个按收益排序的调整顺序从上往下做通常做到第二三步就够用了。第一步降低并发数。收益最大、代价最小只影响吞吐不影响质量。把并发从 4 降到 2KV Cache 直接减半。第二步降低 KV Cache 精度。从 FP16 到 FP8再省一半质量几乎无损。这一步做完通常已经能省下 60% 以上的 KV 开销。第三步缩短最大上下文长度。从模型支持的最大值降到实际需要的值。如果你的文档平均只有 5000 字就没必要开 32k。这一步需要你对自己业务有清晰认识。第四步启用量化的二次压缩。权重的二次量化省的不多但白给的。第五步换框架。框架之间的显存效率差异可以达到 20%如果前面几步都做完了还差一点换一个显存管理更精细的框架往往能解决问题。第六步CPU 卸载。最后手段只用于验证。提示不要同时改多个参数。每次只改一项观察显存和速度变化记录在案。我有一张表专门记录每次调整前后的显存峰值、首 token 延迟和生成速度这张表比任何调优指南都有用因为它是针对你这台机器的。5.4 运行期监控与压测配置好之后一定要做压测不能凭跑了一次没崩就上线。我的压测方法是构造一批包含最长预期输入的样本连续跑 200 次同时每 500 毫秒采样一次显存占用记录峰值。重点是观察显存占用是否随时间单调上升——如果是说明有泄漏或者缓存没有释放。import torch, time, threading peak 0 stop False def monitor(): global peak while not stop: used torch.cuda.memory_allocated() / 1024**3 peak max(peak, used) time.sleep(0.5) t threading.Thread(targetmonitor) t.start() # ... 执行压测请求 ... stop True t.join() print(显存峰值: %.2f GB % peak)我这个场景压测下来显存峰值稳定在 20.3GB 左右持续时间两小时没有出现单调上升说明没有明显泄漏。这个数字比我估算的 19.06GB 高了一些差额主要来自框架的 workspace 和碎片这也是为什么我坚持留 20% 余量。6. 常见问题与排查实录下面这些是我在实际部署中真实遇到的问题按出现频率排序。每一条都写清楚症状、根因和处置方便你遇到时直接对照。6.1 症状与处置速查表症状最可能的原因处置方法加载到 70%-80% 时 OOM在线量化导致峰值过高先离线量化存盘再加载量化权重短对话正常长文档崩溃KV Cache 膨胀超出预留降 KV 精度、限上下文、减并发首次请求正常第二次崩溃缓存未释放或预分配不足调低显存利用率上限检查缓存配置报错与显存无关但加载失败依赖版本不匹配按验证过的版本组合重装显存理论够用但分配失败碎片化严重重启进程设置固定分配策略运行几小时后变慢显存碎片累积定期重启或启用分页式缓存管理速度远低于预期算子回退到通用实现查看日志中的回退提示换框架版本6.2 几个印象深刻的坑第一个坑是版本锁定不彻底。我一开始只锁定了主框架版本没锁定量化库结果某次自动升级之后量化算子在特定硬件上悄悄换了实现显存占用多了两个 G直接导致服务不稳定。后来我把整个依赖树导出冻结所有版本写死问题再没出现。这个教训很值一人公司没有测试团队环境稳定性只能靠你自己用锁文件守住。第二个坑是默认值陷阱。预览版模型的配置文件里默认上下文长度设得非常大默认并发也是夸张的数值。这些默认值在发布方的大机器上没问题在你的单卡上就是灾难。我现在的习惯是拿到任何一个新模型先打开配置文件把所有和显存相关的默认值逐个改成自己估算出的安全值然后再启动。第三个坑是用内存指标判断显存问题。系统级内存监控看到的数字和推理框架内部的实际占用经常对不上因为框架有自己的分配池。判断显存问题一定要用框架自带的统计接口或者显卡厂商提供的工具看真实占用。我曾经因为看了错误指标误判成权重太大白折腾了两天降精度。第四个坑是忽略散热与功耗墙。长时间满载运行显卡频率会下降某些情况下框架检测到资源紧张会调整策略表现就是跑着跑着变慢甚至报错。这类问题最隐蔽日志里什么都看不出来。加个风扇、把机箱风道理顺或者调低功耗上限往往能解决。6.3 给一人公司的几条实战建议如果非要总结几条我真心觉得有用的经验大概是这样先租后买。模型选型的探索期一定用租的把模型规模、量化方案、框架组合都试明白了再决定买什么卡。这个顺序反过来大概率会买错。显存宁可留多不留少。20% 的安全余量不是浪费是稳定性的保险。省下来的那点显存换来的可能是半夜被报警叫醒。记录每一次调整。调优是个黑盒过程不记录就等于每次从零开始。我那张记录表救过我很多次尤其是在换机器、换版本的时候。接受性能妥协。一人公司不可能在每一项指标上都做到最优。我在这个项目上的取舍是接受比半精度慢 10% 的量化方案接受只有 2 的并发接受 8k 的上下文上限换来的是稳定运行和一个可控的成本结构。这个取舍我到现在都觉得是对的。真要说还有什么想补充的就是这个领域变化太快了。半年前需要折腾一整天的配置现在的框架可能一条命令就搞定了反过来新模型又会带来新的显存难题。我自己的做法是把这套估算—选型—压榨—监控的方法论固化下来具体参数随时改方法不变。这样每次新模型出来我大概半小时就能判断出这张卡能不能跑、要付出什么代价。这套判断力比任何一个具体的配置参数都更值钱。