大模型私有化部署这件事我从去年下半年开始密集接触前后经手过三个不同规模的落地场景一个十几人的算法团队做内部知识问答一个中型制造企业做设备日志的异常归因还有一个是对数据出域极其敏感的研发部门做代码辅助。这三个场景的共同点是——数据不能出门模型必须跑在自己的机房里。但它们的硬件预算、并发量级、运维人力又完全不同所以最终落地的方案差异非常大。这篇文章我打算把这一路踩过的坑、做过的取舍、以及那些文档里不会写的细节完整地摊开讲一遍。如果你正在评估要不要把大模型搬进自己的生产环境或者已经立项但卡在选型、显存估算、推理框架这些环节那这篇内容应该能帮你省下不少试错成本。我会从整体架构思路讲起再到具体的显存计算、量化选型、推理引擎对比、并发压测、监控告警最后落到几个真实踩过的坑。全程不堆砌名词尽量用我实际操作的视角来说。1. 私有化部署的整体架构与选型思路1.1 先想清楚私有化到底私在哪一层很多人一上来就问用什么显卡能跑这其实是把问题想窄了。私有化部署的核心诉求通常有三个层次你得先明确自己卡在哪一层。第一层是数据不出域。这是最刚性的需求常见于金融、医疗、制造、政企类场景。用户的提问、上传的文档、模型生成的回答全程不能经过任何外部接口。这一层决定了你必须自建推理服务不能调用任何云端API。第二层是模型权重可控。有些团队不仅要求数据不出门还要求模型本身是自己能拿到权重、能微调、能替换的。这就排除了那些只提供API的闭源服务必须选择权重开放的基础模型。第三层是成本与自主性。当调用量上来之后按token计费的云端方案会变得很贵而且高峰期可能被限流。自建虽然前期投入大但边际成本低且不受外部服务稳定性影响。我经手的那三个场景第一个和第三个卡在第一层和第二层第二个场景其实三层都沾。明确层次之后后面的硬件和框架选型才有依据。如果你只是想让数据不出门但模型可以用开源的那选择面很宽如果连权重都要自己掌控并微调那就要考虑微调成本和推理框架的兼容性。1.2 硬件选型的核心是显存而不是算力这是我最想强调的一点。大模型推理阶段瓶颈几乎永远在显存而不是GPU的浮点算力。训练阶段算力吃紧但推理阶段尤其是自回归生成每一步只算一个token算力利用率其实不高真正卡脖子的是能不能把模型权重和KV Cache塞进显存。显存占用大致可以拆成三块模型权重、KV Cache、以及框架本身的运行时开销。模型权重这块一个粗略的估算公式是显存占用GB≈ 参数量B× 每参数字节数FP16精度下每参数2字节INT8是1字节INT4是0.5字节。所以一个70B的模型FP16需要约140GBINT8约70GBINT4约35GB。注意这只是权重还没算KV Cache。KV Cache的估算稍微复杂一点公式大致是KV Cache字节≈ 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批大小 × 每元素字节数以常见的70B模型为例层数80、注意力头数64、头维度128序列长度4096批大小1FP16精度算下来单条请求的KV Cache大约是2×80×64×128×4096×2 ≈ 10.7GB。这个数字很吓人所以长上下文场景下KV Cache往往是压垮显存的最后一根稻草。我实际选型时的经验是先按权重占满显存的60%来预留剩下40%给KV Cache和运行时。如果并发要求高还要进一步压缩权重精度。下面这张表是我整理的不同规模模型的显存需求速查供你快速估算模型规模FP16权重INT8权重INT4权重建议最低显存含KV Cache余量7B14GB7GB3.5GB24GB13B26GB13GB6.5GB40GB34B68GB34GB17GB80GB70B140GB70GB35GB160GB这张表是单卡或单机多卡的粗略参考实际还要看你的序列长度和并发数。我见过有人拿一张24GB的卡硬跑13B的FP16结果一上并发就OOM就是因为没给KV Cache留够空间。1.3 推理框架的选型逻辑推理框架这块主流的选择有几个方向我按自己的使用体验来说。vLLM是我目前最推荐的通用选择。它的PagedAttention机制把KV Cache按页管理显存利用率比朴素实现高很多吞吐量提升明显。它对主流开源模型的支持也最全社区活跃遇到问题基本能搜到答案。缺点是首次加载模型比较慢且对某些自定义模型结构的支持需要改代码。TGIText Generation Inference是另一个成熟选择部署体验很顺滑自带Docker镜像监控指标也齐全。它的连续批处理做得不错但在极端高并发下的显存管理不如vLLM激进。llama.cpp适合CPU或低显存场景量化支持非常丰富从Q2到Q8都有。如果你的场景是单用户、低并发、或者只有CPU服务器它是很好的选择。但它的吞吐量在高并发下明显不如GPU方案。TensorRT-LLM性能最强但编译流程复杂对模型结构有要求调试成本高。我一般只在性能压到极限、且团队有专门推理优化人力时才考虑。选型的核心判断依据是你的并发量级和延迟要求。如果只是内部几十个人用vLLM或TGI足够了如果要支撑上百并发且延迟敏感才需要往TensorRT-LLM方向走。2. 模型量化与显存优化的实操细节2.1 量化不是越低越好要看任务类型量化是私有化部署里绕不开的一环但很多人有个误区觉得INT4一定比INT8好因为省显存。实际上量化会带来精度损失而不同任务对精度损失的敏感度完全不同。我做过一组对比测试用同一个13B模型分别在FP16、INT8、INT4下跑三类任务通用问答、代码生成、数学推理。结果很明显任务类型FP16INT8INT4通用问答基准几乎无损轻微下降代码生成基准轻微下降明显下降数学推理基准可感知下降严重下降通用问答对量化最宽容INT4基本能用代码生成对精度敏感INT4下会出现语法错误和逻辑断裂数学推理最敏感INT4下错误率飙升。所以我的建议是如果你的场景是知识问答类INT4可以大胆用如果涉及代码或推理至少上INT8条件允许就FP16。2.2 GPTQ、AWQ、GGUF三种量化格式怎么选这三种是目前最主流的量化格式各有适用场景。GPTQ是较早的方案基于逐层量化兼容性好几乎所有推理框架都支持。它的INT4效果在通用任务上不错但量化过程需要校准数据集校准集选得不好会影响效果。AWQ是后起之秀它观察到模型权重中有一小部分重要通道对精度影响很大于是对这些通道做保护其余部分才量化。实测下来AWQ在INT4下的精度普遍优于GPTQ尤其是代码和推理任务。我现在默认优先选AWQ。GGUF是llama.cpp生态的格式最大优势是支持CPU推理和混合推理部分层放GPU、部分放CPU。如果你的硬件是CPU为主或者显存不够需要offloadGGUF是唯一选择。选型建议很直接GPU推理优先AWQ兼容性优先GPTQCPU或混合推理用GGUF。2.3 量化实操中的几个坑第一个坑是校准数据集的选择。GPTQ量化需要一批校准数据来估计权重分布如果你用通用语料校准但实际任务是垂直领域量化后的效果可能比预期差很多。我的做法是校准集里混入至少30%的目标领域文本。比如做医疗问答校准集里就要有医疗问答对。第二个坑是量化后的模型加载配置。AWQ模型加载时需要指定量化配置如果配置写错模型会以错误的方式反量化输出乱码。我踩过一次排查了半天才发现是quantization参数没对上。第三个坑是量化模型的微调兼容性。如果你打算先量化再微调或者先微调再量化要注意顺序。一般建议先微调再量化因为量化后的模型微调会引入额外误差。而且不是所有微调框架都支持量化模型训练QLoRA是专门为此设计的方案。提示量化前一定要在验证集上跑一遍基线量化后再跑一遍对比指标下降幅度。如果下降超过可接受范围就退回更高精度。3. 推理服务的部署与并发压测3.1 从单机单卡到多机多卡的部署路径部署路径要跟你的规模匹配不要一上来就搞分布式那是给自己找麻烦。单机单卡是最简单的起点。一张卡装一个模型实例用vLLM起一个OpenAI兼容的API服务前面挂个Nginx做转发。这个方案能撑住几十个并发适合内部小团队。单机多卡有两种模式张量并行TP和流水线并行PP。TP是把单层拆到多卡通信频繁但延迟低PP是把不同层放不同卡通信少但有流水线气泡。推理场景我一般用TP因为延迟更可控。vLLM启动时加--tensor-parallel-size 4就能开4卡TP。多机多卡就要引入更复杂的调度了。常见做法是用Ray做集群管理vLLM支持Ray后端。但这个方案的运维复杂度陡增网络带宽成为关键瓶颈。我建议除非单机实在装不下否则不要轻易上多机。3.2 并发压测的正确姿势压测是部署后必须做的一步但很多人压测方法不对得出的结论没有参考价值。首先压测指标要看四个吞吐量tokens/s、首token延迟TTFT、单token延迟TPOT、并发数。只看吞吐量是不够的因为吞吐量可以通过增大批大小来提升但延迟会恶化。你要找到的是满足延迟要求前提下的最大吞吐。其次压测工具要选对。我常用的是locust配合自定义的请求脚本或者直接用vLLM自带的benchmark脚本。关键是请求要模拟真实分布——输入长度有长有短输出长度也不固定不能全用固定长度压。第三压测要分阶段。从并发1开始逐步加到并发8、16、32、64每个阶段跑够时间记录四个指标的变化曲线。你会看到某个并发点之后TTFT开始陡增那就是系统的拐点。我实测过一个13B AWQ模型在单张A100 80G上的表现大致是这样的并发数吞吐量(tokens/s)TTFT(ms)TPOT(ms)1451202282801802816420350453251090088645402200160可以看到并发32之后TTFT从350ms跳到900ms延迟恶化明显。所以这个配置下并发16到24是比较舒服的区间。这个拐点位置跟模型大小、量化精度、序列长度都有关必须自己压出来。3.3 批处理策略的取舍连续批处理continuous batching是现代推理框架的标配它允许新请求在旧请求还没生成完时就插入批次大幅提升吞吐。但它也有代价批内请求的延迟会互相影响长请求会拖慢短请求。vLLM默认开启连续批处理你可以通过--max-num-seqs控制单批最大请求数。这个值设大了吞吐高但延迟抖动大设小了延迟稳但吞吐低。我的经验是延迟敏感场景设16到32吞吐优先场景设64到128。还有一个细节是抢占策略。当显存不够时vLLM会抢占正在运行的请求把它们的KV Cache换出到CPU内存。这个机制能防止OOM但换入换出有开销。如果发现抢占频繁说明显存确实不够了该考虑加卡或降精度。4. 生产环境的监控、告警与运维4.1 必须监控的核心指标模型跑起来只是开始生产环境要能看见它的状态。我一般会监控这几类指标资源类GPU利用率、GPU显存占用、GPU温度、CPU利用率、内存占用、磁盘IO。这些用nvidia-smi配合Prometheus的node exporter和dcgm exporter就能采集。服务类QPS、请求延迟分布P50/P95/P99、错误率、超时率。这些从推理框架的metrics接口拿vLLM和TGI都暴露了Prometheus格式的指标。模型类首token延迟、单token延迟、批大小分布、KV Cache使用率、抢占次数。这几个是判断模型服务健康度的关键尤其是KV Cache使用率和抢占次数能提前预警显存瓶颈。业务类这个因场景而异。问答场景可以监控回答长度分布、拒答率代码场景可以监控生成代码的编译通过率。业务指标能反映模型效果是否漂移。4.2 告警阈值的设定经验告警阈值不能拍脑袋定要基于压测数据来。我的一般做法是GPU显存占用超过85%持续5分钟告警。这说明KV Cache快满了可能要触发抢占。P99延迟超过压测拐点延迟的1.5倍告警。说明系统已经在过载边缘。错误率超过1%告警。这个不用解释。抢占次数在10分钟内超过10次告警。说明显存严重不足。阈值设定后要定期回顾因为业务量在变模型也可能更新。我见过有人设了阈值就不管了结果业务翻了三倍告警天天响最后大家都不看了真出事的时候反而没人注意。4.3 模型更新的灰度策略模型不是部署一次就完事后续会有微调版本、量化版本、甚至换基座模型。更新时不能直接替换要做灰度。我的做法是新模型先起一个独立实例把1%的流量切过去观察一周。对比新旧模型在业务指标上的差异同时看资源占用和延迟有没有异常。没问题再逐步放大到10%、50%、100%。整个过程用Nginx或网关的权重配置来控制随时可以回滚。这里有个细节新旧模型的tokenizer可能不同如果直接混用会导致输出异常。灰度期间要确保请求路由到对应模型时用的是匹配的tokenizer。这个坑我踩过排查了很久才发现是tokenizer版本不一致。5. 常见问题排查与避坑实录5.1 启动就OOM的排查顺序模型加载就OOM是最常见的问题排查按这个顺序来第一确认权重文件的实际大小。有时候下载的模型是FP16的但你以为是INT4的加载时按FP16算显存自然不够。用du -sh看文件大小除以参数量反推精度。第二检查是否有其他进程占用显存。nvidia-smi看一眼如果有残留进程kill掉再试。第三降低max-model-len。vLLM默认会按模型最大上下文预分配KV Cache如果模型支持32K上下文但你的实际请求只有4K那预分配就浪费了。把--max-model-len设成实际需要的长度能省不少显存。第四开启CPU offload。vLLM支持--cpu-offload-gb参数把部分权重放CPU内存。但这会拖慢推理速度是最后的退路。5.2 输出乱码或重复的几种原因模型输出乱码、重复、或者答非所问通常有这几个原因量化配置错误。前面提过AWQ模型加载时量化配置没对上会输出乱码。检查启动参数里的quantization字段。tokenizer不匹配。用了错误的tokenizer或者tokenizer版本和模型不配套会导致输出异常。确认tokenizer是从模型仓库一起下载的。采样参数问题。temperature设得太高会胡言乱语设得太低会重复。一般问答场景temperature设0.1到0.3创意场景设0.7到0.9。repetition_penalty设1.1左右能缓解重复。上下文超长。请求超过了模型的最大上下文框架可能截断或报错。要在网关层做长度校验超长的请求提前拒绝或分段。5.3 并发上不去的原因分析压测时并发上不去吞吐量卡在某个值常见原因有批大小受限。检查--max-num-seqs是不是设得太小或者显存不够导致批大小上不去。CPU瓶颈。tokenize和detokenize是CPU操作高并发下CPU可能成为瓶颈。看CPU利用率如果打满了考虑多进程或换更快的tokenizer。网络瓶颈。多机部署时卡间通信走网络带宽不够会拖慢。检查网络利用率和延迟。调度开销。请求量太大时调度器本身的开销不可忽略。这种情况要考虑加实例做负载均衡而不是单实例硬扛。5.4 一份速查表现象可能原因排查动作启动OOM精度误判/显存被占/预分配过大查文件大小/查进程/降max-model-len输出乱码量化配置错/tokenizer不匹配查quantization参数/查tokenizer来源输出重复temperature过低/repetition_penalty未设调采样参数并发上不去批大小受限/CPU瓶颈/网络瓶颈查max-num-seqs/查CPU/查网络延迟抖动大连续批处理批太大/抢占频繁降max-num-seqs/加显存灰度后效果差tokenizer不一致/流量分配错核对tokenizer/查路由配置6. 几个我实际踩过的坑和对应心得6.1 别忽视磁盘IO模型加载慢很多时候不是GPU的问题是磁盘IO的问题。一个70B的模型权重文件上百GB如果放在机械盘上加载要十几分钟。换成NVMe SSD后加载时间降到一两分钟。这个投入很值因为每次重启服务都要等运维体验差很多。6.2 显存碎片化比想象中严重长时间运行后显存会出现碎片化明明总空闲显存够但就是分配不出连续的大块。vLLM的PagedAttention缓解了这个问题但没完全解决。我的做法是定期重启服务比如每天凌晨低峰期重启一次。听起来很土但确实有效。6.3 日志要分级且可检索生产环境的日志量很大如果不分级排查问题时会被淹没。我的做法是ERROR级别单独输出到文件并告警WARN级别按天轮转INFO级别只保留最近三天。同时所有日志带上请求ID方便串联一次请求的完整链路。6.4 备份和回滚要提前演练模型文件、配置文件、启动脚本都要有版本管理。我见过有人直接在生产环境改配置改错了没法回滚只能重装。我的做法是所有配置进Git模型文件用对象存储做版本启动脚本带版本号。回滚时切换版本号即可一分钟内完成。6.5 别低估运维人力私有化部署不是部署完就没事了日常要有人盯着监控、处理告警、更新模型、扩容缩容。如果团队没有专职运维建议至少指定一个人兼职负责并且把常见问题的处理流程写成文档。我见过太多项目部署时轰轰烈烈上线后没人管最后模型服务挂了三天才被发现。7. 关于成本与规模的一点个人判断私有化部署到底划不划算这个问题没有标准答案但可以算一笔账。假设你调用云端API按每百万token几块钱到几十块钱不等如果月调用量在千万token级别月成本可能几千到几万。自建的话一张A100的卡按月租或折旧算加上电费、运维人力月成本也在这个量级。所以调用量不大的时候自建并不省钱自建的价值主要在数据安全和自主可控。但如果调用量上到亿级token自建的边际成本优势就出来了。因为自建的成本主要是固定成本调用量越大单位成本越低。这也是为什么大厂都在自建推理集群。我的建议是先明确你的核心诉求是安全还是成本。如果是安全那没得选必须自建成本是次要考虑如果是成本那要算清楚调用量低于某个阈值就用云端高于阈值再考虑自建。这个阈值因模型大小和硬件价格而异需要具体测算。另外规模上去之后可以考虑混合方案敏感数据走自建非敏感数据走云端。这样既保证了安全又控制了成本。这个方案在实操中需要做数据分级和路由复杂度不低但确实是个务实的折中。最后分享一个我最近在用的技巧部署新模型前先用小规模流量做A/B测试对比新旧模型在真实业务数据上的表现。不要只看公开榜单的分数那些分数和你的实际场景可能差很远。我见过一个模型在榜单上排名很高但在我们的垂直场景里表现还不如一个小模型。真实数据才是唯一的裁判。