最近半年，被问得最多的问题已经从“要不要做私有化部署”变成了“到底选哪个模型、买多大机器”。尤其几个开源系列把门槛拉下来之后，很多团队都打算自己搭一套，但真正动手才发现，模型选型、资源规划、量化精度、推理引擎这些事，每一步都藏着坑。上周还有位朋友拿着两张消费级显卡来找我，说要跑一个70B级模型做知识库问答，我一听就知道，这又是没算清楚显存账，也没搞清楚“跑起来”和“跑得好”完全是两码事。
这篇文章就把我做私有化部署踩过的坑、总结出来的方法一次性讲清楚。核心解决三件事：第一，不同业务场景到底该选什么规模的模型；第二，显存、内存、硬盘、并发这些资源到底怎么算，才能不浪费、不爆掉；第三，部署完之后怎么调优、怎么排查问题。内容会尽量给到可复用的计算公式和配置参考，适合正在做技术选型的架构师、运维同学，也适合想自己搭一套私有模型的中高级开发者。
1. 私有化部署为什么突然成了“必修课”
与其跟风上私有化，不如先搞清楚它到底解决了什么问题。我见过不少团队，业务量不算大，API调用也够用，结果买了几台昂贵机器回来，模型没多少人用，资源闲置一大半。所以第一步不是选模型，而是判断“你真的需要私有化吗”。
1.1 什么场景真正需要私有化部署
私有化部署的核心动力，通常是这三类：数据合规、系统集成、长期成本。数据合规不用多说，金融、医疗、政务类业务，数据不能出内网，这个几乎没得选。系统集成也很常见，比如要把模型接进内部的工单系统、审批流、私有知识库，API方式在权限控制、网络策略上会有很多别扭的地方。长期成本则是个容易被误判的点——初期看API便宜，但调用量上来之后，按token计费比自建贵得多，而且模型版本迭代时，API服务的兼容性不可控。
我自己的经验是，如果业务有下面几个特征，私有化基本是必然选择：
- 输入数据包含客户信息、合同内容、源代码等敏感数据，且不允许出域。
- 需要把模型输出与内部系统深度耦合，对时延、可用性有SLA要求。
- 推理量长期稳定且巨大，每月的token消耗折算下来已经可以覆盖一台卡的折旧。
- 需要离线可用，断网环境或内网隔离环境下也要提供服务。
如果一条都不占，建议老老实实用API，把运维成本省下来做业务。
1.2 明确需求边界，才能选对模型
需求边界这件事，我在项目里一般会通过三个问题来收口。
第一个问题是并发量级。是内部几十个人偶尔用，还是面向全网用户的在线服务？并发直接决定了需要几张卡，也决定了你能不能用消费级显卡顶一阵。第二个问题是时延要求。内部辅助工具3到5秒出结果可以接受，但面向客户的会话式产品，首字延迟超过1秒就会有人投诉。第三个问题是数据规模与任务复杂度。只是做抽取、分类、标题生成这类简单任务，7B级别完全足够；要处理长文档、复杂推理、代码生成，就得往32B以上看。
把这三个问题想清楚，再去看模型参数量、上下文长度、量化方案。否则很容易出现“买回来发现推理速度跟不上”或者“模型太大根本装不进显存”的情况。我常跟人讲，私有化部署的选型不是比谁模型大，而是比谁的资源利用率高，能把一个7B模型用透，比硬上一个跑不动的70B有价值得多。
2. 开源模型选型：不同规模、不同定位
现在开源模型家族非常多，同一个参数量级别可以列出好几个候选。选型时会让人眼花缭乱，但只要按参数量分档，思路就清晰很多。我习惯把当前的主流选择分成四档：7B~9B、14B、32B、70B及以上，外加专门的多模态、嵌入模型。
2.1 7B~9B级：性价比最高的通用起点
7B~9B这一档是目前最成熟、部署成本最低、社区生态最完善的区间。代表模型包括Qwen系列、Llama 3.1 8B、InternLM系列、GLM系列等。这个级别的模型在文本分类、信息抽取、摘要生成、关键词提取、简单问答、意图识别这些任务上，表现已经不差，而且BF16精度下权重只有14GB左右，一张24GB显卡就能带起来，还能留出不少KV Cache空间给并发。
我个人的建议是，如果这是团队第一次做私有化部署，不要犹豫，直接从7B~9B级别的模型开始。先跑通一套完整流程，包括数据预处理、模型加载、接口封装、监控告警，然后再评估是否需要往更大参数升级。这样做的好处是踩坑成本低，而且能建立起一套稳定的评测基线，后面换模型才有对比数据。
这一档里，还要特别关注模型的中文能力和指令遵循能力。有些海外模型的英文很强，但中文能力会略弱一些。落地前建议准备一份覆盖自己业务场景的中文测试集，至少二三十个问题，手动打分对比后再确定。
2.2 14B和32B级：质量与成本平衡的“主力区间”
当7B模型在业务评测集上明显表现出逻辑混乱、指令理解不到位、幻觉严重时，可以考虑升级到14B或32B。14B模型（如Qwen2.5-14B）在多轮对话、代码解释、中等难度数学推理上已经比7B强不少，BF16重量约28GB，在单张48GB卡或者两张24GB卡上能比较舒服地跑，INT8量化后单张24GB也能勉强带起来。
32B级别则是目前“质量”和“成本”的最佳平衡点。以Qwen2.5-32B为例，BF16权重约64GB，INT8量化后约33GB，INT4量化后约18GB。也就是说，一张80GB的卡可以BF16跑，一张48GB的卡可以INT8跑，高端些的24GB卡也能INT4跑。这个跨度非常实用，意味着团队可以根据手里的硬件灵活选择精度档位，而不需要为了某个量化格式单独买卡。
如果业务涉及代码解释、报表分析、复杂查询改写这类需要一定推理能力的任务，32B基本是性价比最优解。它的能力比7B高出一大截，但资源消耗又没有到80B那种必须上多卡集群的程度。
2.3 70B及以上：复杂任务的“重型武器”
70B~72B级别的模型（如Llama 3.3 70B、Qwen2.5-72B等）适合复杂推理、长文档理解、高准确率要求的知识库问答，以及推理质量直接决定业务口碑的场景。这个档位的模型BF16权重约140GB，单卡肯定放不下，通常需要两张80GB卡做张量并行，或者4张48GB卡配合INT8量化，再或者用FP8精度在H系列卡上跑。
我在这里要提醒一句：不是所有团队都适合上70B。首先是硬件成本，一台双卡大显存服务器的成本绝对不是小数目；其次是推理延迟，同样的并发下，70B的吞吐比32B差一大截。如果业务评测显示32B已经能覆盖90%以上的情况，那就没必要为了最后那5%的质量提升多花好几倍的资源。更合理的做法是“小模型兜底、大模型兜质量”，高频简单请求走32B，低频复杂请求切到70B。
关于多模态模型和嵌入模型，这里顺带说一句。如果业务需要读图、截图解析、扫描件转文字，选Qwen2-VL或InternVL系列；如果做RAG，建议单独部署一个嵌入模型，用BGE系列这类专用向量模型，而不要用一个通用对话模型扛所有事。专用模型在检索效果上和通用模型拉开差距的。
3. 资源规划：显存、内存、硬盘、网络到底怎么算
资源规划是私有化部署里最容易出差错的一环。很多人的印象是“显存够放模型权重就行”，但实际一上线就OOM，就是因为没算清楚KV Cache和推理引擎的开销。这一节我会把计算公式完整列出来，大家可以直接套用。
3.1 模型权重显存估算
模型权重需要的显存，本质上就是“参数量 × 每个参数占用的字节数”。不同精度下每个参数的字节数如下：
- FP32：4字节
- BF16/FP16：2字节
- INT8：1字节
- INT4：约0.5字节
所以一个7B模型，BF16下权重约14GB，INT8下约7GB，INT4下约3.5GB。一个70B模型，BF16下约140GB，INT8下约70GB，INT4下约35GB。实际部署时，因为推理引擎还需要额外的显存来放激活值、KV Cache、以及CUDA上下文，通常建议在理论值基础上额外预留10%到20%的空间。比如7B的INT4权重只有3.5GB，但实际单卡跑起来，显存占用会在8GB到12GB之间，这也不算异常。
这里给一个快速计算表供参考：
| 模型规模 | BF16权重 | INT8权重 | 量化后总显存参考 | 建议最低硬件 |
|---|---|---|---|---|
| 7B~9B | 14GB~18GB | 7GB~9GB | 16GB~24GB | 24GB单卡 |
| 14B | 28GB | 14GB | 32GB~48GB | 48GB单卡或24GB双卡 |
| 32B | 64GB | 32GB | 48GB~80GB | 80GB单卡或48GB双卡 |
| 70B~72B | 140GB | 70GB | 96GB~160GB | 80GB双卡或48GB四卡 |
3.2 KV Cache与并发容量计算
很多人低估了KV Cache的显存消耗。简单说，每次对话过程中，计算出来的Key和Value矩阵会暂存在显存里，用来加速后续token的生成。序列越长、并发越多、模型层数越多，KV Cache占用越大。
KV Cache的估算公式可以写成：
KV Cache显存 ≈ 2 × 层数 × KV头数 × 头维度 × 每值字节数 × 总token数
其中总token数 = 序列长度 × 并发请求数。举个例子，一个7B模型，24层，用了GQA后KV头数是8，头维度128，以BF16计算每值2字节。如果平均输出长度是2048 token，同时处理8个请求，KV Cache占用大约是：
2 × 24 × 8 × 128 × 2 × 2048 × 8 = 约6.4GB
也就是说，光KV Cache就需要6.4GB显存。如果把模型权重的INT4版本约4GB算进去，再加上推理引擎本身的开销，一张16GB卡跑这个并发其实已经很紧张。这也是为什么很多人“模型放进去了，一压测就OOM”的原因——问题不在模型本身，而在KV Cache。
实际规划并发时，建议这么算：
- 先确定总显存，减去模型权重显存，再减去2GB~4GB的引擎开销，剩余视为KV Cache可用显存。
- 估算单请求KV Cache消耗，用上面的公式除以单路并发，得出单路KV内存。
- 用KV可用显存除以单路KV内存，得到理论并发上限。
- 再做一次算力上限估算，用整卡的输出吞吐除以单路平均输出码率，取两者较小值。
以我实际部署的经验，7B INT4模型在单张24GB卡上，理论并发可以做得很高，但输出速度会先到瓶颈。反过来，70B INT8模型在多卡环境里，显存往往先到瓶颈。两种瓶颈都要提前算清楚。
3.3 CPU、内存、硬盘与网络的配套估算
纯GPU部署经常忽视CPU和内存。模型加载时需要把权重从硬盘读入内存再拷贝到显存，所以内存至少要是模型权重的1.5到2倍。比如70B模型BF16权重140GB，服务器内存建议256GB起步，否则加载过程会非常慢，甚至因为内存不足加载失败。
CPU核数方面，7B级模型部署，16核基本够用；32B以上建议24核以上。CPU主要用于数据预处理、编解码、Python运行时、以及KV管理的辅助计算。如果是llama.cpp这类走CPU推理的方案，那CPU核心数和内存带宽就直接决定速度，这个另说。
硬盘建议用NVMe SSD。一个70B模型的量化文件可能有40GB到70GB，加载时如果走机械硬盘，IO会卡很久。同时还要预留日志、评测数据集、多版本模型的存储空间。我的经验是，硬盘容量至少是模型文件大小的3倍，这样既放得下当前版本，也放得下后续升级的候选模型。
网络方面，单机部署走千兆内网就够用了。但如果用多卡做张量并行，卡间通信就是决定性能的关键。NVLink带宽远高于PCIe，能用NVLink就不要用纯PCIe互联。跨机部署时，至少万兆网，否则多机并行反而比单机慢。
4. 不同场景下的推荐配置清单
模型选型和资源规划其实是一体的，场景不同，最优配置完全不同。我按常见的四类场景，整理了一份可以直接借鉴的初始配置，方便大家对照自己的情况做微调。
| 场景 | 推荐模型规模 | 量化精度 | 显卡建议 | 内存/CPU建议 | 风险提示 |
|---|---|---|---|---|---|
| 个人学习、原型验证 | 7B~9B | INT4/GGUF | 单张24GB | 内存32GB/8核 | 别追求并发，能跑通即可 |
| 内部知识库QA、办公助手 | 14B~32B | INT8/AWQ | 1~2张24GB | 内存64GB/16核 | 注意RAG检索质量比模型大小更关键 |
| 高并发生产服务 | 32B~70B | INT4~INT8 | 2~4张48GB/80GB | 内存256GB/32核 | 显存和网络带宽都可能成瓶颈 |
| 数学/代码/长文档专项 | 70B级 | BF16/FP8 | 2张80GB或4张48GB | 内存256GB以上 | 建议先跑评测集验证真实增益 |
举一个真实案例。某团队要做一个面向全员的私有知识库问答，预估并发20路，平均输出长度800 token，用的是32B模型的INT8量化。按之前的公式算，单路KV Cache大约0.8GB，20路就是16GB，而32B INT8权重约33GB。两张24GB卡合计48GB显存，减去权重后剩下约15GB，再减引擎开销，KV可用大概11GB，其实勉强只能跑13路左右。后来我把方案改成一张48GB的卡，weights 33GB + KV 16GB正好能放下，压力测试也稳定通过。如果当初按“权重能放下就行”的思路直接上两张24GB，上线当天可能就要出事故。
所以配置完成后，不要急着采买，先写一个基于上面公式的估算表，把所有假设列出来，比如最大序列长度、并发、输出token量。这些假设里任何一项变动，显存占用都会显著变化。
5. 推理框架与量化方案选型
模型选好，显卡预算排好，下一个问题就是用什么推理引擎、量化到什么程度。这两件事直接决定“同样的模型跑出来的速度差多少”以及“输出质量掉多少点”。
5.1 常用推理引擎对比
目前主流的开源推理框架有vLLM、SGLang、Ollama、llama.cpp、TensorRT-LLM等。我自己的分工是这样：vLLM用于生产，SGLang用于多轮会话或共享前缀明显的场景，Ollama用于本地快速验证，llama.cpp用于CPU或低资源环境，TensorRT-LLM则是在确定只用NVIDIA卡、且愿意投入转换时间时使用。
vLLM的PagedAttention和连续批处理机制，在并发吞吐上优势非常明显。同样的7B模型，同一张卡，vLLM的吞吐通常比朴素的HuggingFace pipeline高好几倍。SGLang的RadixAttention对多轮对话很友好，如果业务是聊天机器人或会话说，可以多测测它。
Ollama适合“我想5分钟跑起来看看效果”的需求，它把模型管理和启动封装得很好，但真到了高并发、精细控制显存、定制API返回格式的时候，Ollama就不够灵活了。llama.cpp则强在GGUF格式，特别适合CPU和GPU混合场景。
TensorRT-LLM的延迟优化很猛，但要把模型从PyTorch格式转换到TensorRT引擎，中间坑非常多。我的建议是，先不要上来就上TensorRT-LLM，用vLLM做基线，如果并发压测不达标，再考虑深度优化。
5.2 量化方案选择：AWQ、GPTQ、GGUF与FP8
量化是私有化部署里性价比最高的一环，但有收益就有风险。常见的量化路线是GPTQ、AWQ、GGUF，以及新卡支持的FP8。
AWQ目前我使用最多。它做的是激活感知量化，也就是说它不是单纯按权重分布找量化参数，而是按激活值的敏感度来保护重要的权重通道。在知识库问答、文本生成这类任务里，AWQ 4bit相对BF16的掉点往往很小，显存却能砍掉近四分之三。GPTQ则是一个经典的训练后量化方法，生态很成熟，但同等位数下我主观感受比AWQ略容易被异常值影响。GGUF主要用于llama.cpp和Ollama，量化档位细腻（如Q4_K_M、Q5_K_S），对资源限制很大的场景非常友好。
如果你的显卡是H100、MI300这类支持FP8的卡，70B以上模型优先考虑FP8。FP8很多场景下与BF16质量基本持平，但显存几乎减半，部署体验比INT4还顺。
这里要特别强调一个点：量化是“用质量换显存”。团队在决定量化位数前，一定要先建立评测集。把业务里最典型的30到50个用例跑一遍，对比BF16和INT4的输出差异。如果发现幻觉变多、格式乱掉、指令跟随变差，说明任务对量化太敏感，优先用AWQ或降一档量化位数，而不是直接上INT4。
5.3 部署后的基础调优
模型部署起来只是开始，调优才决定体验。几个最重要的参数如下。
max_model_len是很多人第一个踩的坑。上下文窗口设置得越大，KV Cache预留就越大。如果业务根本用不到32K上下文，就别把max_model_len调到32K，否则可用并发直接掉一大截。先用2048或4096起步，压测不够再往上加。
gpu_memory_utilization控制显存占用比例，我一般设置在0.85到0.95之间。设得太低浪费显存，设得太高容易触发OOM。这个值需要压测时观察显存曲线，找到那个“刚好压线但不爆”的点。
max_num_seqs控制显存中同时处理的序列数，设得过高会导致显存爆炸，设得过低则压不出吞吐。这个参数和KV Cache预算强相关，建议根据第3节的计算结果动态调整。
还有两个容易被忽略的调优点：enable_chunked_prefill——把长输入的预填充阶段切块，能避免一个长请求卡住整个批处理；以及停止符和repetition_penalty——很多私有化模型默认参数下输出会带大量重复词或多余的“思考过程”，需要按业务微调。
6. 从踩坑到稳定：常见问题与排查实操
这一节是我个人觉得整篇最有价值的部分。无论模型选得多好，资源算得多准，上线后大概率还是会遇到下面这些奇奇怪怪的问题。我把最常见的问题和排查思路整理成了一份速查表。
| 症状 | 常见原因 | 排查方法 |
|---|---|---|
| CUDA OOM | KV Cache预留不足、max_num_seqs过大 | 调低gpu_memory_utilization或max_num_seqs |
| 模型加载特别慢 | 硬盘IO慢、CPU内存不足 | 换NVMe、增加内存、检查换页 |
| 首token延迟高 | 长输入的prefill阶段过大 | 开enable_chunked_prefill |
| 生成速度越来越慢 | max_model_len被撑大、KV碎片化 | 重启服务、限制max_model_len |
| 输出重复严重 | 采样参数没调好 | 调repetition_penalty、增加top_p |
| 量化后质量下降 | 量化方案不适合当前任务 | 改AWQ、降量化位数、细测评测集 |
| API时通时断 | 并发超过算力瓶颈 | 做AB压测，加限流或扩卡 |
| 显卡利用率低 | 数据加载和GPU计算未重叠 | 检查数据流、批处理大小 |
6.1 显存OOM与加载失败
OOM是所有私有化部署里最常见的。排查看三处：一是max_num_seqs和max_model_len，看KV Cache预算；二是gpu_memory_utilization是否设置过小；三是多卡环境里是否出现了显存不均衡，也就是张量并行的分配逻辑问题。
如果没有改任何参数还是OOM，我教你一个笨办法：把并发降到1，max_model_len降到最短，然后再逐步加回。这样能快速定位是“模型本身放不下”还是“KV Cache超预算”。
6.2 首token延迟高、吞吐上不去
首token延迟高，大多是prefill阶段太长。当一个请求带着几千token进来时，模型要对全部token做一次前向计算，这本身就耗时几十到几百毫秒不等。如果多个长请求同时打进来，GPU会被一次prefill占满，后续请求全部排队，表现得就像“卡死”。
解决办法是在vLLM或SGLang里开启chunked prefill，把prefill和decode混在一起调度，让短请求能插队生成，而不是被长请求堵死。另一个手段是限制单请求最大输入长度，超出部分做截断或者切片处理。
6.3 量化后效果异常与幻觉增多
量化不是无损操作。如果发现量化后模型在特定任务上变笨了，我的建议是按照这个优先级尝试：先用BF16跑出来作为基准线，然后试FP8或AWQ INT8，基本能保住90%以上的质量。实在要上INT4，优先AWQ，并且专门评测与业务强相关的字段，比如JSON输出格式、代码是否有语法错误、摘要是否跑题。
如果业务输出涉及严谨结构，比如合同条款、诊断建议，建议保持INT8或以上精度。大模型幻觉本身就难防，量化会放大这个风险，不值得为了省一半显存去赌输出质量。稳健的方案是把量化版本和原始版本同时部署，做一个灰度路由，先让量化版本处理低风险请求。
6.4 日常监控与维护清单
推荐配置起来之后，维护比部署更磨人。我自己的运维清单大概是这几条：GPU显存使用率、温度、功耗通过nvidia-smi或Prometheus收集，每5秒一个采样点；接口延迟分位数，包括P50、P95、P99，P99是体验上限；每日token消耗和平均并发，用来预测什么时候要加资源；模型输出日志至少要保留30天，方便事后追问题。
还有一个建议：把模型版本和配置文件纳入版本管理，不要直接在生产服务器上改参数。每次改动只改一个变量，记录前后压测数据。这是我从一次事故里学到的教训——当时某团队同时调了量化位数和并发限制，结果出了性能问题，根本分不清是谁导致的。
最后分享一个我个人的习惯：不要追求把显存用满。每张卡留出10%左右的余量，用来应对突发的长请求和临时的高并发。这个余量不是浪费，是给稳定性买的保险。我也倾向于从7B模型先起步，把整套链路跑通，建立评测集，再逐步升级到14B、32B。这个路径见效快、容错高，也不至于一开始就陷入多卡分布式部署的巨大调试成本里。私有化部署本质上是一个工程问题，模型只是其中的一环，数据、评测、监控、升级路径，每一项都值得认真规划。
