企业官网建设流程全解析

最近两周我把大部分精力都砸在了一个预览版推理模型的本地部署上——就是标题里说的 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 参数的模型，半精度需要大约 60GB，8 位需要 30GB，4 位需要 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% 然后反复重启，浪费时间不说，还对硬件不友好。

3. 参数算例：把"能不能跑"变成一张纸上的算术题

我特别推荐在下载模型之前先做一遍纸上计算。这个过程只需要五分钟，却能避免下载几十 G 文件、装一遍环境、最后发现跑不起来的巨大浪费。下面给出我自己在用的估算流程，以及两个真实用过的算例。

3.1 权重显存的快速估算公式

先用最粗的公式卡一道线：

权重占用 ≈ 参数量(B) × 每参数字节数 × 1.1

那个 1.1 是未量化层和加载冗余的修正系数。4 位量化时每参数字节取 0.5，8 位取 1，半精度取 2。比如 30B 模型 4 位量化：30 × 0.5 × 1.1 = 16.5GB。这个数字已经超过了 16G 卡的 80% 安全线（12.8G），所以 16G 卡跑 30B 的 4 位量化，理论上有戏，实际上很难稳。而 24G 卡的 80% 是 19.2G，16.5G 还在范围内，剩下的 2.7G 就是留给 KV Cache 和缓冲的全部空间——这意味着你能开的上下文非常有限。

3.2 一个完整的算例：24G 卡跑 30B 模型

假设我们有：30B 参数、80 层、8 个 KV 头、头维度 128、4 位量化权重。目标场景是文档问答，单次输入约 8000 token，并发 2。

第一步算权重：16.5GB。第二步算 KV Cache：每 token 320KB（FP16），8000 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 算（层数和头数会更小，实际约 200KB），8000 token 单请求是 1.6GB，并发 2 是 3.2GB，加 1GB 缓冲，总共 11.35GB。有戏，而且还有一点余量可以把上下文拉到 12000 左右。

这个对比很说明问题：16G 卡不是不能玩，而是模型规模的天花板大概在 13B 到 14B 之间，再往上就得靠 CPU 卸载，而 CPU 卸载带来的延迟增加，对交互式场景几乎是不可接受的。所以如果你的目标是 30B 级别的模型，24G 是一个更现实的起点，16G 只能算入门。这也是我在选型建议里最想说的一句话：先定模型规模，再定卡，别反过来。

4. 低成本选型：量化、框架、硬件三者的平衡

算清楚账之后，选型就变成了一个约束优化问题：在给定预算下，找到量化等级、推理框架和硬件方案的最优组合。一人公司的特殊之处在于，这三个维度里最贵的其实不是硬件，而是试错时间。所以我的选型原则是优先选生态成熟、文档齐全、社区问题多的路线，宁可牺牲一点理论性能。

4.1 量化等级怎么选：4 位是甜点，但不是唯一答案

量化等级的取舍，本质是显存、速度和质量的三角权衡。我在同一个模型上做过一组对比，用的是文档问答和摘要两类任务，主观评测加客观指标混合打分。

有个反直觉的现象值得说：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 pip==24.0 pip install torch==2.3.1 --index-url <内部镜像地址> pip install transformers==4.42.3 accelerate==0.31.0 pip install bitsandbytes==0.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_4bit=True, bnb_4bit_quant_type="nf4", # nf4 在正态分布权重上表现最好 bnb_4bit_compute_dtype=torch.bfloat16, bnb_4bit_use_double_quant=True, # 二次量化，再省约 0.4 bit/参数 ) model = AutoModelForCausalLM.from_pretrained( "本地模型目录", quantization_config=quant_config, device_map="auto", max_memory={0: "19GiB", "cpu": "48GiB"}, # 关键：给显存留出安全余量 attn_implementation="flash_attention_2", # 显著降低激活值占用 trust_remote_code=True, ) 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 8

gpu-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 降到 2，KV 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(target=monitor) t.start() # ... 执行压测请求 ... stop = True t.join() print("显存峰值: %.2f GB" % peak)

我这个场景压测下来，显存峰值稳定在 20.3GB 左右，持续时间两小时没有出现单调上升，说明没有明显泄漏。这个数字比我估算的 19.06GB 高了一些，差额主要来自框架的 workspace 和碎片，这也是为什么我坚持留 20% 余量。

6. 常见问题与排查实录

下面这些是我在实际部署中真实遇到的问题，按出现频率排序。每一条都写清楚症状、根因和处置，方便你遇到时直接对照。

6.1 症状与处置速查表

6.2 几个印象深刻的坑

第一个坑是版本锁定不彻底。我一开始只锁定了主框架版本，没锁定量化库，结果某次自动升级之后，量化算子在特定硬件上悄悄换了实现，显存占用多了两个 G，直接导致服务不稳定。后来我把整个依赖树导出冻结，所有版本写死，问题再没出现。这个教训很值：一人公司没有测试团队，环境稳定性只能靠你自己用锁文件守住。

第二个坑是默认值陷阱。预览版模型的配置文件里，默认上下文长度设得非常大，默认并发也是夸张的数值。这些默认值在发布方的大机器上没问题，在你的单卡上就是灾难。我现在的习惯是：拿到任何一个新模型，先打开配置文件，把所有和显存相关的默认值逐个改成自己估算出的安全值，然后再启动。

第三个坑是用内存指标判断显存问题。系统级内存监控看到的数字和推理框架内部的实际占用经常对不上，因为框架有自己的分配池。判断显存问题一定要用框架自带的统计接口或者显卡厂商提供的工具，看真实占用。我曾经因为看了错误指标，误判成权重太大，白折腾了两天降精度。

第四个坑是忽略散热与功耗墙。长时间满载运行，显卡频率会下降，某些情况下框架检测到资源紧张会调整策略，表现就是跑着跑着变慢甚至报错。这类问题最隐蔽，日志里什么都看不出来。加个风扇、把机箱风道理顺，或者调低功耗上限，往往能解决。

6.3 给一人公司的几条实战建议

如果非要总结几条我真心觉得有用的经验，大概是这样：

先租后买。模型选型的探索期一定用租的，把模型规模、量化方案、框架组合都试明白了，再决定买什么卡。这个顺序反过来，大概率会买错。

显存宁可留多不留少。20% 的安全余量不是浪费，是稳定性的保险。省下来的那点显存，换来的可能是半夜被报警叫醒。

记录每一次调整。调优是个黑盒过程，不记录就等于每次从零开始。我那张记录表救过我很多次，尤其是在换机器、换版本的时候。

接受性能妥协。一人公司不可能在每一项指标上都做到最优。我在这个项目上的取舍是：接受比半精度慢 10% 的量化方案，接受只有 2 的并发，接受 8k 的上下文上限，换来的是稳定运行和一个可控的成本结构。这个取舍我到现在都觉得是对的。

真要说还有什么想补充的，就是这个领域变化太快了。半年前需要折腾一整天的配置，现在的框架可能一条命令就搞定了；反过来，新模型又会带来新的显存难题。我自己的做法是把这套"估算—选型—压榨—监控"的方法论固化下来，具体参数随时改，方法不变。这样每次新模型出来，我大概半小时就能判断出这张卡能不能跑、要付出什么代价。这套判断力，比任何一个具体的配置参数都更值钱。