大模型私有化部署实战指南：从硬件选型到生产运维

在企业内部真正跑通一次大模型私有化部署，你会发现网上那些教程大多数只讲了一半。一半教你如何用开源框架把模型跑起来，另一半——如何让它稳定扛住生产流量、如何做版本迭代、如何监控推理质量——基本靠自己在故障里摸出来。这篇文章把我踩过的坑、验证过的方案、测过的参数全部整理成一条可复用的路径，从硬件评估到推理服务上线，再到后续的监控和模型更新，每一环都有明确的操作步骤和判断依据。

如果你正准备把某个开源大模型部署到内网生产环境，或者已经在部署途中被各种诡异问题卡住，这篇文章应该能帮你少走不少弯路。内容偏工程实践，涉及到的概念我会尽量用通俗方式讲清楚，有基础的可以直接跳到对应章节抄作业。

1. 部署前的需求评估与硬件选型

很多人第一步就搞反了，先买卡再想场景。但实际上硬件选型应该完全由你的业务场景决定，不同场景对硬件的要求差异非常大。

1.1 先想清楚：你的业务到底需要什么

私有化部署大模型，首先要想清楚一个问题：你的业务是偏生成还是偏理解。这决定了模型选型和硬件投入的方向。

拿企业内部最常见的几个场景举例：

• 智能客服助手：需要模型理解用户问题并给出回答，对延迟敏感，并发量中等。
• 文档摘要和情报分析：输入文本长，需要大上下文窗口，对单次推理速度要求不高，但要求输出质量稳定。
• 代码辅助生成：需要模型有较强的代码能力，同时要能配合IDE实时补全，延迟要求高。
• 结构化数据抽取（比如从合同里抽关键字段）：需要模型遵循指令的能力强，输出格式稳定，通常配合JSON模式使用。

还有一个经常被忽略的维度：并发量。我见过不少团队在做技术选型时只盯着单次推理的延迟，完全没算并发，结果上线后一压测就崩。并发量直接决定你需要多少张卡、要不要做多副本、需不需要推理框架的continuous batching能力（后面会细讲）。

1.2 显存计算的实用公式

选定模型后第一步是估算推理所需的显存。这里给一个经过实测校正的经验公式，比官方文档里给的更贴近真实情况：

推理显存 ≈ 模型权重显存 + KV Cache显存 + 推理框架开销

模型权重显存的计算方式是：参数量乘以每个参数的字节数。以7B模型为例，FP16精度下每个参数占2字节，所以权重显存约14GB。70B模型FP16就是约140GB。

实际上现在部署基本都会做量化，常见的组合如下：

KV Cache的显存开销容易被忽略。它的大小由序列长度、层数、注意力头数等共同决定。有个粗略的估算方法：对于7B模型，输入输出各2K tokens的情况下，KV Cache大约占1-2GB；如果开到32K上下文，KV Cache显存可能涨到8-10GB，这时候就必须对显存做精细化规划了。

注意：上面这些数字是静态估算。实际生产环境还涉及推理框架的缓存、多路复用、CUDA context开销，所以建议在估算值基础上额外留出20%-30%的冗余。显存留得太紧，并发一上来就会OOM，这是生产环境最常见的崩溃原因之一。

1.3 单卡、多卡还是多机

选型的时候可以通过一个简单的推理来判断：假设你的业务峰值并发是50路请求，平均每个请求的生成长度为500 tokens，在单张主流加速卡上，7B模型的单请求生成速度大约在每秒60-80 tokens。这意味着单卡理论上能支撑的并发其实有限。

50路并发意味着每秒需要生成约25000-40000 tokens，单卡远远不够。这种量级就需要多卡多副本，用负载均衡分发。如果模型是70B级别，单卡放不下，就需要多卡张量并行（Tensor Parallel），或者直接选量化方案。

多卡部署还要考虑卡间通信带宽。同机多卡用NVLink/NVSwitch，带宽高，张量并行的效率损耗小；跨机多卡走RoCE或InfiniBand网络，通信延迟会显著影响推理速度。能用单机多卡解决的，尽量不要跨机。

另外强烈建议在选型阶段就用压测工具验证，而不是只靠理论估算。真实场景下的并发表现和卡间通信开销，只有实测才作数。

2. 模型选型与量化落地

模型选型直接决定私有化部署的上限。开源模型生态已经非常丰富，从1.5B的轻量模型到上百B的旗舰模型都有对应场景，关键是不要盲目求大。

2.1 模型规模怎么定

模型规模选择的底层逻辑是：模型能力要和任务复杂度匹配。

我自己的实践经验是：

• 1.5B-3B级别的模型，适合意图识别、文本分类、格式化输出这类简单任务，延迟低，硬件成本小。
• 7B-14B级别的模型，适合通用对话、文档摘要、中等复杂度的指令跟随，是目前企业私有化部署的甜点区间。
• 32B-70B级别的模型，适合复杂推理、长文档理解、高质量代码生成，硬件投入大，只有当业务确实需要这个级别能力时才建议上。

选模型时不要只看榜单分数。同一个模型家族的不同尺寸版本，往往在特定能力上表现差异很大。比如有些小模型在数学推理上意外地强，有些大模型在中文理解上反而不如专门优化过的中等规模模型。建议拿自己业务场景的真实数据做评测，而不是用公开benchmark做决定。

2.2 量化方案对比与实践

量化是目前私有化部署绕不开的环节。模型量化本质上是把高精度权重用低精度来表示，用轻微的质量损失换取显存和速度的显著优化。

我实测下来几种主流方案的感受：

GPTQ：以4bit权重为主，部署时仍按FP16计算，支持较好的批处理性能。压缩比高，质量损失在大部分场景可控。缺点是量化时间较长，且对校准数据集有一定要求。

AWQ：激活感知量化，在量化时考虑了激活值的分布，对质量损失的把控比GPTQ更精细一些。在相同比特数下，AWQ的困惑度表现通常优于GPTQ，尤其是极端低比特时优势更明显。

FP8/INT8：损失极小，几乎可以做到无损部署。对于显存不是瓶颈、但希望提升吞吐的场景很合适。缺点是压缩比有限，INT8下7B模型仍需约7GB权重显存。

GGUF/llama.cpp方案：主要面向CPU和混合部署场景，支持在内存和显存之间做分层。如果是纯CPU环境跑中小模型，这个方案值得考虑。但生产环境追求高吞吐时，GPU方案的效率优势还是明显的。

实操层面给几个具体建议：

第一，量化前先校准。无论用GPTQ还是AWQ，校准数据集都要尽量贴近真实业务数据。用一个通用数据集校准的量化模型，在特定领域的表现可能下滑很明显。

第二，量化后必须做质量回归。选一批有标准答案的业务测试题，量化前后各跑一遍，对比输出的准确率和格式合规率。不要只看一两个case就下结论。

第三，小心KV Cache的精度。有些框架默认用FP16的KV Cache，在长上下文场景下显存增长很快。新版框架支持INT8甚至FP8的KV Cache量化，能大幅降低长上下文的显存占用，但有可能影响生成质量，建议实测后决定是否开启。

2.3 微调还是RAG

部署大模型到生产环境时，几乎一定会遇到一个问题：模型不懂你们公司的内部知识。这时候有两个选择：微调（Fine-tuning）和检索增强生成（RAG）。

我的判断标准很简单：知识型问题用RAG，能力型问题用微调。

• 如果需求是让模型知道你们公司的制度规范、产品文档、历史工单，这是知识型问题，用RAG就够了。把文档切块、向量化、存到向量库，推理时先检索再生成。
• 如果需求是让模型学会某种特定的输出格式、某种业务逻辑判断、或者跟特定的工具/API联动，这是能力型问题，微调更合适。

RAG的优势是更新知识不用重新训练模型，改向量库就行。微调的优势是模型本身的行为模式会改变，输出风格和执行逻辑更稳定。

生产级方案往往是两者结合：先微调让模型学会业务场景的对话方式和逻辑规则，再挂上RAG补齐事实性知识。这个组合看起来增加了复杂度，但实际上比单用任何一种都稳。

3. 推理框架选型与部署

推理框架决定了你的模型在硬件上能跑多快、能支撑多大并发、好不好运维。这一步选择的影响会在上线后被持续放大，值得花时间对比。

3.1 主流推理框架横向对比

现阶段私有化部署最常用的几个方案，我一一说下实际感受。

vLLM：目前社区生态最活跃的框架之一，PagedAttention显存管理效率很高，支持continuous batching（连续批处理），吞吐能力出色。兼容OpenAI接口协议，接入业务系统非常方便。生产环境首选，除非你有特殊需求。

TensorRT-LLM：推理性能优化的天花板，延迟和吞吐都比通用框架有优势，但使用门槛高，模型转换和编译过程繁琐，对动态shape的支持不够灵活。适合对性能有极致要求的场景。

SGLang：在复杂推理任务上做了很多优化，RadixAttention在处理多轮对话和共享前缀时效率很高。如果你的业务有大量多轮对话或few-shot场景，值得关注。

llama.cpp：CPU/混合部署方案，部署灵活，但GPU利用率相对较低，吞吐有限。

MindIE：特定硬件生态的推理加速方案，如果使用的是对应硬件环境，可以关注官方的适配版本。

实际项目中选型逻辑通常是：先用vLLM快速跑通业务验证，如果性能不达标再评估是否迁移到TensorRT-LLM。这样迭代效率最高。

3.2 部署架构的关键配置

框架选好之后，部署架构有几个关键配置项直接影响生产表现。

模型并行策略：单卡放得下的模型不需要做模型并行。放不下就按层切分做张量并行，同一张卡上跑多个模型副本做数据并行。70B这样的大模型，一般用张量并行拆到多卡。并行度设置太高会引入通信开销，边际收益递减，这个需要通过压测找最优值。

连续批处理（continuous batching）：这是影响吞吐的核心机制。传统批处理要等一个批次全部生成完才处理下一批，连续批处理则是在每个token生成后动态调度，哪个请求生成了就让它离开，新请求随时补进来。实测下来，连续批处理能把GPU利用率拉高数倍，强烈建议开启。

前缀缓存（Prefix Caching）：如果你的业务场景有大量共享前缀（比如系统提示词固定、多轮对话中历史消息固定），开启前缀缓存能显著减少重复计算。vLLM对这块支持得比较好，实测能降低30%-50%的首字延迟。

部署形态：个人建议用容器化方式部署，镜像管理方便，回滚也容易。如果公司有Kubernetes环境，做成 deployment 加 service 的形式，搭配HPA（水平自动伸缩），可以按负载自动扩缩容。但这要求推理框架本身支持优雅缩容，否则缩容时会掐断正在生成的请求。

3.3 环境配置的坑

部署过程中有一类问题几乎每个团队都会遇到：CUDA和PyTorch版本不匹配。

我的建议是尽量用推理框架官方发布的带CUDA环境的镜像，而不是自己在基础镜像上装。自己组装环境时，常常会遇到cuBLAS版本不对、NCCL找不到、CUDA运行时库冲突这类问题。用官方镜像相当于把这些坑都提前踩掉了。

另外一个容易忽略的是共享内存。容器默认的/dev/shm只有64MB，而大模型推理时张量数据和缓存经常需要GB级别的共享内存，不调大就会莫名其妙地crash。docker启动时加上 --shm-size=10g 或者通过Kubernetes的emptyDir配置，能避免这个坑。

4. 生产级性能优化

模型能跑起来只是第一步，要让它在生产环境稳定扛住流量，还需要做系统性的性能优化。我把线上踩过的坑和优化手段按优先级整理出来。

4.1 吞吐与延迟的平衡

先明确一个概念：吞吐和延迟有时候是矛盾的。吞吐优先意味着让GPU尽可能满负荷运转，单请求延迟可能会变高；延迟优先则反之。生产环境需要根据SLA(服务水平协议)找到平衡点。

一个实用的调参路径：

• 先用框架默认参数跑一轮压测，记录吞吐（tokens/s）和TTFT(首个token生成延迟)、TPOT(每token生成延迟)。
• 如果TTFT偏高，检查是否开启了前缀缓存、请求是否被排到了长队列后面。适当降低最大并发数或增加实例数。
• 如果TPOT偏高，检查KV Cache是否碎片化、是否开启了不影响质量的量化、GPU利用率是否打满。
• 反复调整并发数和batch size参数，找到“延迟达标下的最大吞吐”这个点。

4.2 推理质量与速度的取舍

量化是质量与速度最典型的交换。但在推理框架层面，还有一个容易被忽略的设置是采样参数。

很多团队上线时直接沿用默认的temperature=1.0，top_p=1.0，导致模型输出发散，业务方觉得模型“不稳”。而生产环境大部分任务恰恰需要确定性输出。把temperature调到0.2-0.4之间，输出稳定性会明显改善，某些任务甚至可以设为0。

在追求速度的场景还可以考虑投机采样（Speculative Decoding）：用一个小的草稿模型先生成多个候选token，再用大模型一次验证。这个机制在batch size较小的时候能显著提升速度，但并发较高时收益会下降，需要实际测试决定是否开启。

4.3 长上下文场景的优化

长上下文是当前部署的热点需求，也是性能优化的重灾区。要支撑长上下文，基本绕不开这几个手段：

• KV Cache量化：把KV Cache从FP16降到INT8，显存占用直接减半。代价是极少数case可能出现质量下降，建议在业务场景中实测决定。
• 上下文压缩：多轮对话场景下，历史消息会不断累积。可以用一个轻量模型对历史消息做摘要压缩，只保留关键信息，大幅降低KV Cache压力。
• 滑动窗口注意力：有些框架支持只保留最近N个token的注意力计算，适合只关注局部上下文的场景，但对需要全局依赖的任务不适用。

注意：长上下文的性能衰减问题目前仍然存在。即使模型宣称支持128K上下文，实测下来35K左右准确率就开始明显下降。生产环境不要盲目追求超长上下文，该截断就截断，该压缩就压缩。

5. 模型微调的完整流程

如果RAG解决不了你的问题，需要对模型本身的行为做调整，那就得走微调这条路。这里分享一套经过多次验证的完整流程。

5.1 数据准备与清洗

微调的数据质量直接决定模型表现，这个环节值得投入最多时间。

数据格式：大部分开源模型使用对话格式的指令数据。每条样本包含system、user、assistant三个角色，assistant的回复就是模型要学习的目标。

数据清洗：重点检查三类问题。一是重复样本，特别是相似语义的样本重复过多，会导致模型对这类输入过拟合。二是格式不一致，比如有的回复带了“好的，我来回答”这类前缀，有的不带，模型会学到这种不确定性。三是噪声数据，目标输出本身是错的样本要果断删掉。

数据量：对于7B-14B级别的LoRA微调，5000-20000条高质量样本是一个合理的起步区间。低于这个量，微调效果不明显；高于这个量，需要关注是否引入了噪声。

5.2 LoRA与QLoRA实操

全参数微调在私有化场景下很少用，因为显存和时间成本太高。LoRA（低秩适配）是更现实的选择，只训练一小部分参数，效果在大部分场景已经足够。

LoRA的关键参数：

• rank（秩）：常用8-64。rank越大，模型能学到的模式越复杂，但过拟合风险也越高。7B模型起步用16或32。
• alpha：缩放系数，一般设为rank的2倍。
• target_modules：决定在哪些模块上挂LoRA。默认通常是q_proj和v_proj，如果想更强一些可以加上k_proj、o_proj、gate_proj等。

QLoRA是在LoRA基础上先用4bit量化加载基座模型，让有限显存能跑更大的模型或者更大的batch。代价是训练速度稍慢，稳定性略差。如果显存够用，优先用LoRA，省心。

5.3 微调训练的操作细节

训练环节有几个影响成败的细节：

学习率：LoRA微调的常用范围在1e-4到2e-4之间。过大会导致loss振荡，模型学崩；过小则收敛慢，效果出不来的错觉。

epoch数：LoRA微调通常2-4个epoch就够了。跑太多轮数在指令数据上很容易过拟合，表现为在训练集上效果好，一换到真实业务输入就开始胡言乱语。

上下文长度：根据业务数据长度设置。如果业务都是短对话，设2048就够了，硬撑4096只会增加显存消耗。如果确实有长文档需求，再开长序列训练。

混合精度：bf16是首选，精度损失小，数值稳定性好。如果硬件不支持bf16，用fp16但需要注意loss溢出问题。

5.4 微调后的评估与验收

微调完不等于结束，还要做严格的评估。我的评估方案是三层：

• Loss曲线：训练loss持续下降到收敛，验证loss不反弹，这是基本盘。
• 固定测试集：准备50-100条业务测试题，微调前后分别跑一遍，对比正确率、格式规范率、拒答率。用打分制评估，不要只看主观感受。
• 随机抽查：从测试集外随机抽20-30条，人工评估输出质量。这一步能发现自动化指标发现不了的问题，比如模型学会了“偷懒”用模板回复。

提醒：微调最大的风险是模型能力回退。常见表现是学会了业务场景的格式，但通用能力下降，或者出现重复输出、逻辑混乱。如果在评估中发现这类问题，优先怀疑过拟合或者学习率太大，降低训练强度重新跑。

6. 上线部署与高可用架构

微调完成、推理框架选定之后，才进入真正的生产部署阶段。这一环节解决的是工程化问题：怎么接API、怎么做高可用、怎么扩展。

6.1 API服务搭建

主流推理框架都支持OpenAI兼容的API协议，这意味着你可以用标准的HTTP方式调用，业务系统接入非常方便。

API服务设计上几个要点：

• 超时设置：生成式模型的响应时间波动很大，网关超时时间要设置得比传统接口宽裕很多。建议分阶段超时——连接超时5秒，读取超时根据业务需求设300秒以上，避免大请求被网关截断。
• 流式输出：面向最终用户交互的场景（比如客服对话），一定要用流式输出（stream）。首字延迟可以压到1秒以内，用户体验比等待全部生成完再显示好太多。
• 接口鉴权：即使在内网也不能裸奔。加一层API Key或OAuth认证，防止内部滥用或误调用。

6.2 高可用与容灾方案

生产环境的大模型服务和传统服务最大的不同在于：它是有状态的。一个推理请求包含大量中间状态（KV Cache、采样状态等），不能像普通无状态服务一样随意重启。

高可用方案建议这样设计：

• 多副本部署：部署至少2个推理实例，前端用负载均衡分发。实例故障时，负载均衡器自动把流量切到健康实例。
• 优雅停机：收到停机信号后，先停止接收新请求，等存量请求生成完成再杀掉进程。这需要推理框架支持优雅关闭，配合Kubernetes的preStop钩子实现。
• 模型文件独立存储：模型文件（几个GB到上百GB）不要打进镜像里，单独放在共享存储或对象存储中，启动时挂载。避免每次发布新版本都要重新构建上百GB镜像。
• 热备切换：如果对可用性要求很高，可以部署一主一备两个服务组，主服务故障时自动切换。切换过程会丢掉正在处理的请求，但可以保证服务整体可用。

6.3 版本管理与灰度发布

模型也需要像普通软件一样有严格的发布流程。我见过的最好的实践是：

• 每个模型版本有明确的版本号，对应一组权重文件、配置文件、微调数据的版本记录。
• 新旧版本并存部署。新版本先在一个独立的实例上跑，用真实业务流量观察一段时间，确认无异常后再切流量。
• 发现问题时能快速回滚到上一个版本。回滚动作就是改一下路由配置，不需要重新部署。

模型不像代码那样可以一行行diff，出了问题排查成本很高。灰度发布是现阶段最务实的风险控制手段。

7. 性能压测与调优实战

生产环境部署完成后，最重要的验证环节就是压测。这一节给出一套已经验证过的压测方法和关键指标。

7.1 压测工具选型

大模型压测和传统HTTP压测不一样，不能只用简单的并发工具，因为要模拟真实场景中的输入输出长度分布。

常用的方案有：

• WRK/Locust：传统压测工具，适合验证网关和基础并发能力，但无法模拟生成式模型的真实负载特征。
• 框架自带的Benchmark工具：vLLM等框架提供离线压测脚本，可以设定并发数、请求数、输入输出长度，适合硬件性能摸底。
• 自建压测脚本：用Python脚本，通过API发送真实业务样本，记录每个请求的TTFT、TPOT、总耗时、成功率等指标。这是最贴近生产环境的验证方式。

实际做压测时，建议先用框架自带Benchmark摸清硬件上限，再用自建脚本验证真实业务负载下的表现。

7.2 核心性能指标解读

压测报告里的指标非常多，但真正需要关注的就这么几个：

压测时特别留意一个现象：并发数提高时，TTFT和TPOT会同时恶化。这是因为所有请求在抢同一个GPU资源。这时候要通过Kubernetes的HPA（水平自动伸缩）或限流来控制整体负载，而不是一味堆并发。

7.3 调优路径的实操建议

根据压测结果，调优路径按优先级排序：

• 第一步，调并发参数和max_num_seqs/batch size。这是影响吞吐最直接的因素。
• 第二步，调KV Cache相关配置。显存充足的情况下，扩大KV Cache可以降低缓存淘汰率，提升命中率。
• 第三步，开开启前缀缓存、投机采样等框架级优化。
• 第四步，评估量化方案是否需要调整。比如从INT8换到INT4，牺牲一点质量换吞吐。
• 最后一步，才是考虑换更强的硬件或增加节点。

调优时每次只改一个参数，记录前后指标差异。不要同时改多个参数，否则出了问题根本定位不到是哪个改动导致的。

8. 生产环境的运维与监控

大模型服务上线只是开始，真正的考验是后续的稳定运行。大模型的运维和传统服务有显著区别，关键要抓住推理质量、资源、容量这几个维度。

8.1 核心监控指标

大模型服务的监控指标分三层：

基础设施层：GPU利用率、显存使用率、卡温度、CPU内存。GPU利用率长期跑满且伴随显存打满，说明容量快不够了，需要扩容。

服务层：请求量、TTFT、TPOT、吞吐、错误率、队列等待时间。队列等待时间飙升通常是并发超限的早期信号。

质量层：输出长度分布、拒答率、超时率。这层的指标最容易被忽略，但对业务影响最大。模型权重文件被意外替换、量化参数配错，都会在这里反映出来。

8.2 日志与链路追踪

大模型请求的处理链路比普通接口长得多，一次请求要经过网关、推理框架、可能还有RAG检索。链路追踪是排查问题的必备工具。

建议在关键节点都打上日志：网关记录请求参数和耗时，推理框架记录排队时间、首字时间、生成耗时、token数，RAG模块记录检索命中和耗时。这样出了问题才能快速定位是哪一环。

另外一定要记录模型的版本号和参数配置在日志里。大模型灰度发布时，出了质量事故要能快速判断是哪个版本的模型导致的。

8.3 告警策略

告警规则建议设置五类：

• 错误率超过阈值（比如超过1%持续5分钟）
• TTFT或TPOT超过SLA阈值（说明服务在降级）
• GPU显存使用率超过90%持续10分钟（有OOM风险）
• 队列长度持续超过上限（说明容量不足）
• 模型输出异常（比如输出长度突然为0，或者拒绝回答的比例显著上升）

告警要分级，区分P0（业务中断）、P1（质量下降）、P2（容量预警）。不要让所有问题都打到同一个群里，那样重要告警会被淹没。

9. 常见故障与排查实录

这一节整理了几类我在实际部署中遇到过的典型故障，每条都包含现象、排查路径和解决方案，可以直接作为排查手册参考。

9.1 显存不足与OOM

现象：服务运行一段时间后报CUDA OOM，进程崩溃。

排查路径：

• 先用nvidia-smi确认单卡显存使用情况，看是模型权重占大头，还是KV Cache在持续增长。
• 检查max_num_seqs/最大批量参数，如果开得太大，并发上来后KV Cache瞬间吃满显存。
• 检查是否有请求的输入特别长，生成长度也特别长，导致单个请求的KV Cache撑爆显存。

解决方案：调小最大批量、开启KV Cache量化、设置max_model_len上限、或者干脆扩容。生产环境中最大模型长度一定不要设成模型理论上下文长度的最大值，要结合显存容量留余量。

9.2 生成速度突然变慢

现象：服务刚上线时生成很快，运行一段时间后速度明显下降，TPOT翻倍。

排查路径：

• 先看GPU利用率。如果利用率降下来了，大概率是显存碎片化导致无法启用更大的batch。
• 看输入序列长度分布。如果最近接到的请求输入长度普遍增长，KV Cache压力变大，速度自然会下降。
• 检查是否开了前缀缓存但命中率极低，缓存管理本身消耗了额外开销。

解决方案：定期重启服务清理显存碎片（可以通过Kubernetes的定时任务做）、优化请求长度、检查并调整缓存策略。这类问题在长上下文场景尤其容易出现，需要提前规划。

9.3 量化后输出质量明显下降

现象：量化模型在某些输入上胡言乱语、逻辑混乱，特别是数学推理、代码生成类任务。

排查路径：

• 确认量化校准数据集是否覆盖了业务场景。用CMS（常见公开数据集）校准的模型在特定领域上质量下降是正常现象。
• 对比量化前后的输出，找出质量劣化的具体模式。是全方位的，还是特定类型任务才劣化。
• 如果是特定任务劣化，尝试用业务数据重新校准模型，再量化一遍。

解决方案：换用AWQ重新量化、提高量化精度（从INT4换成INT8）、或者对质量敏感的任务单独部署一个未量化的高精度模型。我倾向于后者，混合部署的成本可控，质量有保证。

9.4 并发上升后批处理失效

现象：并发数提高后，吞吐反而下降，延迟暴涨。

排查路径：

• 检查推理框架的并发调度策略，看batch size是否到了上限。
• 确认负载均衡器是否把请求均匀分发到了多个实例，如果存在热点实例，整体吞吐会被单个实例拖累。
• 检查是否开启了RAG或前置网关带来的额外延迟。

解决方案：增加实例数做水平扩展，同时在前端加限流保护，防止单实例过载。这里需要明确一个观念：推理框架的batch size不是越大越好，超过一定阈值后，KV Cache会挤占计算资源，吞吐反而下降。

9.5 多卡环境的通信瓶颈

现象：多卡张量并行部署后，实际加速比远低于预期，增加卡数延迟没有明显改善。

排查路径：

• 检查卡间通信方式。如果是跨机部署，PCIE网络带宽会成为硬瓶颈。
• 检查是否启用了NVLink/NVSwitch。同机多卡如果只走PCIE，通信效率损失很大。
• 分析模型并行度设置是否合理。有些模型并行度提升的收益会被通信开销抵消。

解决方案：尽量同机多卡部署、确保NVLink启用、或者减少并行度换更多数据并行副本。实测下来，7B模型用TP=2的性能提升显著，TP=4时通信开销就开始吃掉收益了；70B则通常需要TP=4到TP=8。

10. 维护与迭代的长期策略

部署完成并稳定运行只是第一步，后续的维护和迭代才是长期运营的核心。大模型技术迭代速度快，不建立可持续的更新机制，模型会逐渐落后于业务需求。

10.1 定期更新评估机制

大模型不是训练一次就一劳永逸的。建议建立周期性的模型评估机制，做法是：

• 每个月跑一轮固定测试集，对比当前线上版本和最新开源模型的差异。
• 关注业务侧反馈：拒答率、改单率、用户投诉是否在上升。这些指标能间接反映模型能力是否落后于业务需求。
• 新模型候选确定后，走一遍完整的灰度发布流程验证，用真实业务数据说话。

10.2 RAG知识库的维护节奏

如果用了RAG，知识库的更新是常态化工作。要建立知识入库的规范化流程：

• 新文档进来后做格式转换、清洗、切片，然后向量化入库。
• 已失效的文档要及时下线，否则模型会引用过期信息。
• 定期检查检索质量，抽检一批query看召回是否准确。
• 当知识库规模增长到一定量级后，考虑做rerank重排序，提升检索精度。

10.3 成本管理与容量规划

私有化部署大模型的成本大头是硬件，因此容量规划要做在前面。建议按业务增长预期规划未来6-12个月的算力需求，留出扩卡空间。

成本优化的几个方向：

• GPU利用率不达标的场景，考虑混合部署多个模型，复用同一批GPU资源。
• 不同任务按延迟要求拆分服务，用高吞吐模式跑非实时任务，用低延迟模式跑交互任务。
• 硬件残值管理，老旧GPU如果跑不动大模型，可以考虑专门跑小模型或向量检索类任务。

10.4 团队技能建设

大模型私有化部署对团队的要求比传统后端高不少，涉及分布式系统、GPU编程、机器学习工程等多个领域。建议关注这几个方向的技能储备：

• 推理框架的原理和调优（至少团队内有一个人能深入框架源码层面做问题排查）。
• Kubernetes容器编排和GPU调度。
• 数据工程能力，特别是微调数据和RAG知识库的构建能力。
• 模型评估方法论，能设计合理的评测方案判断模型好坏。

写在最后的一些经验

这套部署流程跑下来，我最深的体会是：大模型私有化部署真正难的不是让模型跑起来，而是让它在业务负载下稳定地跑、持续地跑、坏了能快速修复地跑。它比传统后端起服务复杂得多——模型有状态、资源消耗大、故障模式不直观、质量评估有主观性，每一个维度都需要单独建立配套的工程能力。

另一个强烈建议是：任何配置变更都要有版本记录和回滚方案。大模型的配置和代码不一样，改一个参数可能不影响语法，但会让输出质量发生明显漂移。没有版本管理意识，出了事故连改动记录都找不到，排查会异常痛苦。

最后想说的是，别被各种新概念和技术名词劝退。大模型私有化部署的核心问题清单其实很固定：用什么模型、怎么压缩、什么框架跑、怎么调度、怎么监控、怎么迭代。把这六个问题逐个落地，你的生产环境就是可用的、可靠的。剩下的都是锦上添花。