最近半年被问得最多的问题已经从“要不要做私有化部署”变成了“到底选哪个模型、买多大机器”。尤其几个开源系列把门槛拉下来之后很多团队都打算自己搭一套但真正动手才发现模型选型、资源规划、量化精度、推理引擎这些事每一步都藏着坑。上周还有位朋友拿着两张消费级显卡来找我说要跑一个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权重约64GBINT8量化后约33GBINT4量化后约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 模型权重显存估算模型权重需要的显存本质上就是“参数量 × 每个参数占用的字节数”。不同精度下每个参数的字节数如下FP324字节BF16/FP162字节INT81字节INT4约0.5字节所以一个7B模型BF16下权重约14GBINT8下约7GBINT4下约3.5GB。一个70B模型BF16下约140GBINT8下约70GBINT4下约35GB。实际部署时因为推理引擎还需要额外的显存来放激活值、KV Cache、以及CUDA上下文通常建议在理论值基础上额外预留10%到20%的空间。比如7B的INT4权重只有3.5GB但实际单卡跑起来显存占用会在8GB到12GB之间这也不算异常。这里给一个快速计算表供参考模型规模BF16权重INT8权重量化后总显存参考建议最低硬件7B~9B14GB~18GB7GB~9GB16GB~24GB24GB单卡14B28GB14GB32GB~48GB48GB单卡或24GB双卡32B64GB32GB48GB~80GB80GB单卡或48GB双卡70B~72B140GB70GB96GB~160GB80GB双卡或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~9BINT4/GGUF单张24GB内存32GB/8核别追求并发能跑通即可内部知识库QA、办公助手14B~32BINT8/AWQ1~2张24GB内存64GB/16核注意RAG检索质量比模型大小更关键高并发生产服务32B~70BINT4~INT82~4张48GB/80GB内存256GB/32核显存和网络带宽都可能成瓶颈数学/代码/长文档专项70B级BF16/FP82张80GB或4张48GB内存256GB以上建议先跑评测集验证真实增益举一个真实案例。某团队要做一个面向全员的私有知识库问答预估并发20路平均输出长度800 token用的是32B模型的INT8量化。按之前的公式算单路KV Cache大约0.8GB20路就是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 OOMKV 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我教你一个笨办法把并发降到1max_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、P99P99是体验上限每日token消耗和平均并发用来预测什么时候要加资源模型输出日志至少要保留30天方便事后追问题。还有一个建议把模型版本和配置文件纳入版本管理不要直接在生产服务器上改参数。每次改动只改一个变量记录前后压测数据。这是我从一次事故里学到的教训——当时某团队同时调了量化位数和并发限制结果出了性能问题根本分不清是谁导致的。最后分享一个我个人的习惯不要追求把显存用满。每张卡留出10%左右的余量用来应对突发的长请求和临时的高并发。这个余量不是浪费是给稳定性买的保险。我也倾向于从7B模型先起步把整套链路跑通建立评测集再逐步升级到14B、32B。这个路径见效快、容错高也不至于一开始就陷入多卡分布式部署的巨大调试成本里。私有化部署本质上是一个工程问题模型只是其中的一环数据、评测、监控、升级路径每一项都值得认真规划。