1. 大模型私有化部署到底在解决什么问题第一次被问到“大模型怎么私有化部署到生产环境”的时候我脑子里冒出来的不是技术方案而是一个很现实的场景某公司的算法团队花了两个月微调出来一个行业模型Demo 演示效果很好老板拍板要上线结果 IT 部门一句“数据不能出内网”就把整个计划卡住了。这不是个例我接触过的团队里十个有八个最终都要走私有化这条路区别只是早晚。私有化部署这件事说白了就是把原本跑在云端 API 后面的大模型搬到你自己能控制的机器上。这个“自己的机器”可能是公司机房里的几台 GPU 服务器也可能是私有云里划出来的一块资源池。它要解决的问题很具体数据不出域、响应延迟可控、成本可预测、模型可定制。这四个需求里只要有一个是硬性的私有化就从“可选”变成了“必选”。但这里有个认知误区需要先打破。很多人以为私有化部署就是“把模型下载下来跑起来”实际上从拿到模型权重到真正扛住生产流量中间隔着一整套工程体系。我见过太多团队卡在“单机能跑”和“生产可用”之间的鸿沟里跑了三个月还在调并发。所以这篇文章不打算讲怎么下载模型、怎么装环境这种基础操作那些内容网上太多了。我想聊的是从零到一搭建一套能上生产的私有化推理服务需要做哪些关键决策踩过哪些坑以及怎么用最少的资源把事办成。这篇文章适合三类人看一是正在评估私有化方案的技术负责人你需要知道这件事的真实成本和风险在哪二是要动手实施的工程师你需要一套可复现的落地路径三是刚接触这个领域的学习者你需要建立对生产级部署的完整认知而不是停留在跑通 Demo 的层面。我会尽量把每个决策背后的“为什么”讲清楚因为生产环境和实验环境最大的区别就是实验环境里错了重来就行生产环境里每一个选择都有代价。2. 部署前的核心决策选型比动手更重要2.1 模型选型不是越大越好而是越合适越好私有化部署第一个要做的决策就是选哪个模型。这里最常见的错误是“参数越大越好”觉得 70B 一定比 13B 强闭源的一定比开源的好。实际做下来你会发现模型选型要同时考虑四个维度任务效果、显存占用、推理速度、许可协议。先说显存占用这个硬约束。一个粗略的估算公式是FP16 精度下模型权重占用的显存约等于参数量乘以 2 字节。也就是说 7B 模型光权重就要 14GB 左右13B 要 26GB70B 要 140GB。这还没算 KV Cache 和中间激活值。KV Cache 的大小跟并发数和上下文长度直接相关公式是 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 并发数 × 精度字节数。以 13B 模型、4K 上下文、并发 8 为例KV Cache 大概要吃掉 6 到 8GB。所以一张 24GB 的卡跑 13B 模型实际能支撑的并发很有限。这就引出一个关键决策是选大模型配少量并发还是选小模型配高并发。我的经验是如果你的场景是内部工具类应用并发不高但对效果要求高可以上大模型如果是面向全公司的服务并发是硬指标那 7B 到 13B 的模型配合好的提示词工程往往比 70B 模型卡成幻灯片要实用得多。许可协议这一块容易被忽略。不同开源模型的商用许可差异很大有的完全放开有的有月活限制有的禁止特定用途。上线前一定要让法务过一遍别等产品做完了才发现不能用。2.2 硬件选型算清楚这笔账再掏钱硬件选型是私有化部署里最烧钱也最容易踩坑的环节。我先给一个结论不要一上来就买顶配卡先租后买、先小后大是更稳妥的路径。推理场景和训练场景对硬件的要求完全不同。训练看重算力和显存带宽推理更看重显存容量和性价比。一张高端训练卡的价格可能是推理卡的三四倍但推理性能提升未必有那么大。对于大多数私有化推理场景消费级旗舰卡或者上一代的专业卡往往性价比更高。具体怎么算这笔账我拿一个真实场景举例。假设你要部署一个 13B 模型目标是支撑 50 个并发用户平均响应时间要求在 3 秒以内。按照前面的估算单张 24GB 卡跑 13B 模型FP16 精度下大概能支撑 4 到 8 个并发。要支撑 50 个并发理论上需要 7 到 12 张卡。但如果你用 INT8 量化显存占用减半并发能力翻倍可能 4 到 6 张卡就够了。如果再配合连续批处理技术实际吞吐还能再提升。这里的关键是量化 批处理 合理的并发控制能让同样的硬件多扛好几倍的流量。所以硬件采购前一定要先做压力测试用真实流量模型跑一遍别拍脑袋决定买几张卡。还有一个容易被忽略的点是网络和存储。模型加载的时候要从存储读取几十 GB 的权重文件如果存储带宽不够启动一次要等十几分钟。生产环境建议用 NVMe SSD 做本地缓存模型文件放共享存储第一次加载后缓存到本地。2.3 推理框架选型别重复造轮子推理框架的选择直接决定了你的开发效率和运行性能。目前主流的方案可以分成三类通用推理框架、大模型专用推理引擎、自研方案。通用推理框架比如 ONNX Runtime、TorchServe优点是生态成熟、文档齐全缺点是对大模型的支持不够极致显存优化和批处理调度做得比较粗糙。大模型专用推理引擎比如 vLLM、TGI、TensorRT-LLM优点是针对 Transformer 架构做了大量优化吞吐量能比通用框架高好几倍缺点是学习曲线陡、配置复杂、对模型格式有要求。自研方案一般不建议除非你有非常特殊的定制需求否则投入产出比很低。我的建议是如果团队没有历史包袱直接上 vLLM 或 TGI。这两个框架我都用过vLLM 的 PagedAttention 对显存碎片管理做得很好高并发下优势明显TGI 的部署体验更顺滑跟 HuggingFace 生态结合紧密。TensorRT-LLM 性能最强但需要把模型转成 TensorRT 引擎转换过程比较折腾适合对延迟极度敏感的场景。选框架的时候还要考虑一个因素你的模型是不是标准 Transformer 架构。如果是 MoE 架构或者有特殊注意力机制很多优化框架的支持会打折扣这时候可能得回退到通用方案。3. 生产环境部署的核心环节拆解3.1 环境隔离与依赖管理生产环境部署的第一条铁律是环境隔离。我见过太多因为依赖冲突导致线上服务挂掉的案例。最稳妥的做法是用容器化部署每个服务跑在独立的容器里依赖版本全部锁定。具体操作上我习惯用 Docker 加 Conda 的组合。基础镜像选官方的 CUDA 镜像然后在里面建 Conda 环境装 Python 依赖。Dockerfile 里要显式指定所有包的版本号不能用 latest。CUDA 版本、驱动版本、PyTorch 版本、推理框架版本这四个的兼容性要提前确认好版本对不上会出现各种奇怪的报错。这里有个实操细节CUDA 驱动是装在宿主机上的容器里装的是 CUDA Toolkit。宿主机的驱动版本决定了容器里能用的 CUDA Toolkit 上限。比如宿主机驱动支持 CUDA 12.2那容器里最多用 12.2 的 Toolkit装 12.4 会报错。这个对应关系在官方文档里有表格部署前一定要查。还有一个坑是共享内存。Docker 默认的共享内存只有 64MB跑大模型推理的时候数据加载会用到共享内存不够的话会报错。启动容器时要加--shm-size8g或者更大。这个参数不加服务跑着跑着就崩而且报错信息很不直观排查起来很费时间。3.2 模型加载与显存优化模型加载看起来简单实际上有很多讲究。首先是加载方式常见的有全量加载、分片加载、懒加载。全量加载是把整个模型一次性读进显存启动慢但运行稳定分片加载是把模型切分到多张卡上适合单卡放不下的情况懒加载是按需加载启动快但首次推理延迟高。生产环境一般用全量加载配合模型预热。显存优化是重头戏。除了前面提到的量化还有几个关键技术。第一个是 PagedAttention把 KV Cache 分成固定大小的块来管理避免显存碎片vLLM 就是靠这个把吞吐量做上去的。第二个是连续批处理把不同请求的推理过程动态合并GPU 利用率能从 30% 提到 70% 以上。第三个是投机采样用一个小模型预测多个 token大模型并行验证能在不损失效果的前提下提速两到三倍。量化方案的选择也有讲究。INT8 量化对效果影响很小基本可以无脑上INT4 量化效果损失明显一些但在很多场景下仍然可接受。量化方式分训练后量化和量化感知训练前者简单但效果损失大后者复杂但效果好。生产环境如果对效果要求高建议用 GPTQ 或 AWQ 这类训练后量化方法它们在 4bit 下能保持不错的效果。我实测下来一个 13B 模型用 AWQ 4bit 量化后显存占用从 26GB 降到 8GB 左右单卡就能跑推理速度还提升了 30% 到 50%。效果方面在通用问答任务上几乎感觉不到差异在专业领域任务上会有轻微下降但通过提示词工程可以弥补大部分。3.3 服务接口与并发处理生产环境的服务接口设计要考虑三件事协议兼容、流式输出、并发控制。协议兼容方面现在业界基本都向 OpenAI 的接口格式看齐。你的推理服务最好也提供兼容 OpenAI 格式的接口这样上层应用切换成本最低。vLLM 和 TGI 都内置了 OpenAI 兼容的 API 服务直接开箱即用。流式输出是大模型应用的标配。用户等 10 秒看到完整回答和每秒看到几个字往外蹦体验差距巨大。流式输出用 Server-Sent Events 或者 WebSocket 实现推理框架一般都有支持。这里要注意的是流式输出下的超时设置和错误处理跟非流式不一样客户端断开连接后服务端要及时释放资源否则会积累大量僵尸请求。并发控制是最容易出问题的地方。大模型推理是计算密集型任务并发数超过硬件承载能力后不是变慢而是直接雪崩。所以必须在服务层做限流和排队。我的做法是在推理服务前面加一层网关网关负责鉴权、限流、请求排队推理服务只负责计算。限流阈值根据压测结果设定一般留 20% 的余量。批处理策略也需要调优。批处理大小不是越大越好太大反而会增加单次推理延迟。要根据显存容量和延迟要求找平衡点。一般来说批处理大小在 8 到 32 之间比较常见具体值要通过压测确定。3.4 监控告警与日志体系生产环境没有监控就是裸奔。大模型服务的监控指标比普通服务要多除了常规的 CPU、内存、网络还要重点监控 GPU 利用率、显存占用、推理延迟、吞吐量、队列长度。GPU 监控用 DCGM 或者 nvidia-smi 定期采集重点看显存有没有泄漏、利用率是不是长期偏低。推理延迟要分位数统计P50、P95、P99 都要看平均值会掩盖长尾问题。队列长度是预警指标队列开始积压说明容量不够了要提前扩容。日志体系要记录每个请求的输入输出、耗时、token 数、使用的模型版本。这些数据既是排查问题的依据也是后续优化的基础。但要注意日志脱敏用户输入里可能包含敏感信息落盘前要过滤。告警规则设置有讲究。显存占用超过 90% 要告警但不要设成 95%因为从 90% 到 OOM 可能只有几秒钟。推理延迟 P99 超过阈值要告警但阈值要根据业务容忍度来定不能拍脑袋。告警要分级P0 打电话P1 发消息P2 记工单别什么都往群里发否则很快就没人看了。4. 实操全流程从裸机到生产服务4.1 基础环境搭建假设我们有一台装了 4 张 24GB 显卡的服务器目标是部署一个 13B 模型支撑 50 并发。下面是完整的操作流程。第一步是装驱动和 CUDA。驱动版本选 535 以上CUDA 选 12.1 或 12.2。装完之后用nvidia-smi确认四张卡都能识别显存正常。这一步如果出问题大概率是驱动和内核版本不匹配需要重装驱动或者升级内核。第二步是装 Docker 和 NVIDIA Container Toolkit。装完之后跑一个测试容器验证 GPU 透传是否正常docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能正常输出显卡信息就说明环境没问题。第三步是准备模型文件。从模型仓库下载权重放到本地 NVMe 盘上。下载完要校验文件完整性MD5 或 SHA256 对一遍避免下载中断导致文件损坏。模型文件目录结构要保持原样配置文件、权重文件、tokenizer 文件都不能少。4.2 推理服务部署我们用 vLLM 来部署因为它对多卡推理和连续批处理支持得比较好。先拉官方镜像docker pull vllm/vllm-openai:latest然后启动容器。关键参数包括模型路径、张量并行度、显存利用率、最大模型长度、服务端口docker run --rm --gpus all \ --shm-size16g \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/your-model \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --served-model-name your-model这里解释几个关键参数。tensor-parallel-size设为 4表示用 4 张卡做张量并行适合单卡放不下的模型。gpu-memory-utilization设为 0.9表示用 90% 的显存留 10% 给系统和其他进程设太高容易 OOM。max-model-len是最大上下文长度设得越大 KV Cache 占用越多要根据实际需求设不要盲目设大。启动后看日志确认模型加载成功、服务监听正常。然后用 curl 测试一下curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: your-model, prompt: 你好, max_tokens: 100 }能正常返回结果就说明服务跑起来了。4.3 性能压测与参数调优服务跑起来只是第一步能不能扛住生产流量要压测了才知道。压测工具我用 locust 或者 wrk模拟真实请求分布。压测指标重点看三个吞吐量每秒处理请求数、延迟P50/P95/P99、错误率。压测的时候要逐步加压从 10 并发开始每轮加 10观察指标变化。当延迟开始非线性上升、错误率抬头的时候就是当前配置的容量上限。然后调整参数再压找到最优配置。可调的关键参数有几个。max-num-seqs控制最大批处理大小调大能提升吞吐但增加延迟。max-num-batched-tokens控制单批最大 token 数影响显存占用。swap-space控制 CPU 交换空间显存不够时会把部分 KV Cache 换到内存但会拖慢速度。这些参数没有万能值要根据硬件和业务需求反复调。我实测下来4 张 24GB 卡跑 13B 模型AWQ 4bit 量化max-num-seqs设 16max-model-len设 4096能稳定支撑 40 到 50 并发P95 延迟在 2 秒左右。这个配置对大多数内部应用够用了。4.4 网关与负载均衡配置推理服务前面要加一层网关负责鉴权、限流、负载均衡。网关可以用 Nginx、Kong 或者自己写。如果只有一个推理实例Nginx 做反向代理就够了如果有多个实例需要配置负载均衡策略。负载均衡策略对大模型服务很关键。默认的轮询策略会导致请求分配不均因为不同请求的推理时间差异很大。更好的策略是最少连接数或者基于队列长度的加权。Nginx 的least_conn策略比round_robin效果好很多。限流配置要跟推理服务的容量匹配。假设压测出来单实例能扛 50 并发网关的限流阈值就设 45留点余量。超过阈值的请求返回 429让客户端重试而不是让请求堆积把服务压垮。网关还要处理超时。大模型推理时间比普通 API 长超时时间要设够一般 60 秒起步。但也不能无限长否则客户端断开后服务端还在算浪费资源。流式请求的超时要单独配置因为流式连接持续时间更长。5. 常见问题与排查技巧实录5.1 显存相关问题排查显存问题是大模型部署中最常见的故障类型表现五花八门排查思路也不一样。问题一启动就 OOM。模型加载阶段显存不够通常是模型太大或者gpu-memory-utilization设太高。解决方法是降低显存利用率、用量化模型、或者增加张量并行度。如果模型本身超过单卡显存必须用张量并行。问题二跑一段时间后 OOM。这是显存泄漏的典型表现。原因可能是 KV Cache 没释放、请求异常导致资源没回收、或者批处理队列积压。排查方法是监控显存占用曲线看是不是持续上升。如果是检查推理框架版本有没有已知的泄漏 bug或者限制最大并发数。问题三显存碎片化。表现为显存总量够但分配失败。vLLM 的 PagedAttention 就是解决这个问题的如果用的是其他框架可以尝试重启服务定期清理碎片。注意显存监控要区分“已分配”和“已预留”。nvidia-smi 显示的是预留显存PyTorch 的memory_allocated显示的是实际使用。排查问题时两个都要看预留高但实际使用低说明有碎片。5.2 性能不达预期排查性能问题比显存问题更难排查因为影响因素多需要逐层排除。第一层硬件层。确认 GPU 是不是满血运行有没有降频。用nvidia-smi -q -d PERFORMANCE看时钟频率和降频原因。常见降频原因是温度过高或者功耗墙机房散热不好很容易触发。第二层框架层。确认批处理有没有生效。看日志里的 batch size如果一直是 1说明连续批处理没工作。可能是请求间隔太长或者配置参数不对。调小max-num-seqs的等待时间让请求更容易凑成一批。第三层模型层。确认量化有没有生效。加载模型时看日志确认用的是量化版本。如果加载的是 FP16 版本显存占用和推理速度都会差很多。第四层应用层。确认请求处理逻辑有没有瓶颈。比如 tokenizer 是不是在 CPU 上跑、有没有不必要的后处理、日志写入是不是同步的。这些环节看起来不起眼但在高并发下会成为瓶颈。5.3 服务稳定性问题排查稳定性问题往往在压力大的时候才暴露平时测试很难发现。服务突然无响应。可能是死锁或者线程池耗尽。检查推理框架的线程配置确认请求队列有没有上限。如果队列无上限请求堆积会耗尽内存。响应时间忽高忽低。可能是批处理大小波动导致的。请求少的时候批处理小延迟低请求多的时候批处理大延迟高。这是正常现象但如果波动太大说明批处理策略需要调优。服务定期重启。可能是内存泄漏或者健康检查配置不当。检查容器的内存限制和健康检查间隔如果健康检查太频繁可能误杀正常服务。5.4 常见问题速查表问题现象可能原因排查方法解决方案启动 OOM模型太大或显存利用率过高看加载日志量化模型或增加并行度运行中 OOM显存泄漏或并发过高监控显存曲线限制并发或升级框架推理速度慢批处理未生效或量化未启用看 batch size 和模型精度调优批处理参数或换量化模型延迟波动大批处理大小不稳定统计延迟分布调整批处理策略服务无响应队列积压或死锁看队列长度和线程状态加限流或重启服务GPU 利用率低请求间隔长或 CPU 瓶颈看 GPU 和 CPU 利用率优化请求调度或 CPU 逻辑6. 成本控制与弹性伸缩的实战经验6.1 私有化部署的真实成本构成很多人算私有化部署的成本只算硬件采购费这是不完整的。真实成本包括四块硬件采购或租赁、机房电费和散热、运维人力、以及机会成本。硬件这块一台 4 卡服务器采购价大概在十几到几十万不等取决于卡的类型。如果走租赁按月付费前期投入小但长期成本高。我的建议是如果项目确定性高、使用周期超过一年采购更划算如果还在探索阶段先租用云上的 GPU 实例验证。电费和散热容易被低估。4 张高端卡满载功耗在 2000W 以上加上服务器其他部件整机功耗 3000W 左右。一天 24 小时跑下来 72 度电按工业电价算一天几十块一年下来也是笔不小的开支。散热方面机房空调要能压住这些热量否则 GPU 降频性能打折。运维人力是最容易被忽略的成本。私有化部署不是一锤子买卖需要持续运维监控、告警、升级、扩容、故障处理。如果没有专职人员这些工作会分散开发团队的精力。所以评估成本的时候要把运维人力折算进去。6.2 弹性伸缩策略生产环境的流量不是恒定的白天高晚上低工作日高周末低。如果按峰值配置硬件低谷期资源浪费严重。弹性伸缩是控制成本的关键。私有化环境的弹性伸缩比云上复杂因为硬件是固定的。但可以通过几种方式实现“软弹性”。第一种是模型分级高峰期用大模型低谷期切到小模型显存占用和算力需求都降下来。第二种是动态批处理根据队列长度自动调整批处理大小流量小的时候降低批处理提升响应速度流量大的时候增大批处理提升吞吐。第三种是多模型共享 GPU把多个小模型部署在同一组卡上按需调度。如果预算允许混合部署是更好的方案核心业务用私有化保证数据安全峰值溢出流量走云端 API。这样既满足了合规要求又避免了为峰值流量过度投资。当然这要求业务能接受部分数据出域需要根据实际情况权衡。6.3 资源利用率的持续优化部署上线不是终点持续优化才能把成本压下来。我习惯定期做资源利用率复盘看几个关键指标GPU 平均利用率、显存平均占用、请求排队率、缓存命中率。GPU 利用率长期低于 30% 说明资源浪费可以考虑合并服务或者降配。显存占用长期低于 50% 说明可以跑更大的模型或者更高的并发。请求排队率高说明容量不足需要扩容或者优化。缓存命中率低说明提示词缓存没做好很多重复请求可以复用结果。优化是个持续过程每次模型升级、流量变化、业务调整都是优化机会。我一般每个月做一次全面复盘每季度做一次容量规划确保资源跟业务匹配。7. 安全合规与数据隔离的落地细节7.1 数据不出域的完整链路设计私有化部署的核心价值就是数据不出域但要真正做到这一点需要在链路上每个环节都做控制。模型推理环节输入数据从应用传到推理服务走的是内网不经过公网。推理服务本身不记录原始输入只记录脱敏后的统计信息。输出结果返回应用同样走内网。整个链路要确保没有任何环节把数据发到外部。模型更新环节容易被忽略。如果模型是从外部下载的下载过程可能泄露信息。建议用内网的模型仓库模型文件先同步到内网再分发。更新过程要有审计日志记录谁在什么时候更新了什么模型。日志和监控数据也要注意。日志里可能包含用户输入落盘前要脱敏。监控数据上报如果走外部服务要确保只上报指标不含内容。这些细节看起来琐碎但合规检查的时候都是重点。7.2 多租户隔离方案如果私有化服务要给多个部门或团队用多租户隔离是必须的。隔离级别从低到高有三种逻辑隔离、资源隔离、物理隔离。逻辑隔离是共用推理服务通过 API Key 区分租户在应用层做权限控制。优点是资源利用率高缺点是隔离性差一个租户的异常请求可能影响其他租户。资源隔离是每个租户分配独立的推理实例或者独立的 GPU互不影响。优点是隔离性好缺点是资源利用率低每个租户都要预留资源。物理隔离是每个租户用独立的服务器隔离性最好但成本最高。一般只有对安全要求极高的场景才用。大多数场景下资源隔离是平衡点。可以用容器做资源隔离每个租户一个容器限制 GPU 和显存使用。Kubernetes 配合 GPU Operator 能实现这种隔离但配置比较复杂需要专门的运维能力。7.3 审计与合规检查要点上线前要做一次完整的合规检查重点看几个方面。数据流向要画清楚从用户输入到模型输出每个环节数据存在哪、怎么传输、谁有权访问都要有文档。访问控制要验证不同角色的权限是不是符合最小权限原则有没有越权访问的可能。日志审计要完整关键操作有没有记录日志能不能防篡改。应急响应要有预案出现数据泄露或者服务异常时怎么处理谁负责多久响应。这些工作看起来是“非技术”的但往往是决定项目能不能上线的关键。我见过技术方案很漂亮但合规没过关导致项目搁置的案例所以建议在技术方案设计阶段就把合规要求考虑进去别等做完了再补。8. 从单机到集群的扩展路径8.1 什么情况下需要上集群单机部署能满足需求的时候不要上集群。集群带来的复杂度是指数级上升的运维成本、故障排查难度、一致性问题的处理都是单机没有的。我一般建议单机 GPU 利用率持续超过 70%、或者单机容量无法满足延迟要求、或者需要高可用保障的时候才考虑上集群。上集群的第一个决策是选什么编排系统。Kubernetes 是事实标准生态成熟但对 GPU 的支持需要额外组件。如果团队已经有 K8s 运维能力直接上 K8s 最省事。如果没有可以考虑更轻量的方案比如 Docker Swarm 或者直接用推理框架自带的多机部署能力。8.2 多机推理的通信优化多机推理的性能瓶颈往往在通信上。张量并行需要频繁同步梯度对网络带宽和延迟要求很高。如果机器之间是普通以太网通信开销会吃掉大部分性能提升。所以多机推理建议用高速互联比如 InfiniBand 或者高速以太网。通信优化还有几个技巧。一是减少同步频率用流水线并行替代部分张量并行。二是用通信压缩把 FP16 的梯度压缩成 INT8 再传输。三是重叠计算和通信让通信在计算的同时进行。这些优化需要框架支持vLLM 和 TensorRT-LLM 都有相关配置。8.3 高可用与故障转移生产环境要考虑单点故障。推理服务的高可用方案有几种主备模式、多活模式、以及基于队列的异步模式。主备模式是一个实例跑另一个待命主挂了备顶上。优点是简单缺点是资源浪费。多活模式是多个实例同时跑负载均衡分发请求挂一个不影响整体。优点是资源利用率高缺点是需要处理会话一致性问题。异步模式是请求先进队列多个 worker 消费worker 挂了请求重新入队。优点是容错性好缺点是不适合实时性要求高的场景。故障转移的关键是健康检查要准。检查太松故障实例还在接流量检查太紧正常实例被误杀。我一般用多层检查进程存活、端口可访问、推理接口能返回正确结果三层都过才算健康。9. 我踩过的坑和给你的建议9.1 那些文档里不会写的坑第一个坑是模型加载时间。文档里不会告诉你一个 70B 模型从磁盘加载到显存要十几分钟。如果服务重启这段时间服务是不可用的。解决方案是模型预热加滚动更新新实例加载好了再切流量老实例再下线。第二个坑是 tokenizer 的性能。tokenizer 默认在 CPU 上跑高并发下会成为瓶颈。解决方案是用快速 tokenizer或者把 tokenizer 也放到 GPU 上。这个优化能提升 10% 到 20% 的吞吐。第三个坑是流式输出的连接管理。流式连接持续时间长如果客户端异常断开服务端不一定能及时感知导致资源泄漏。解决方案是加心跳检测客户端定期发心跳服务端超时没收到就主动断开。第四个坑是模型版本管理。生产环境可能同时跑多个版本的模型做 A/B 测试或者灰度发布。如果没有版本管理机制很容易搞混。解决方案是每个模型版本打标签请求里带版本号服务端按版本路由。9.2 给不同阶段团队的建议如果你是刚开始探索私有化部署我的建议是先跑通最小闭环一张卡、一个小模型、一个简单接口。别一上来就搞集群、搞高可用那些是后面的事。先验证技术可行性再考虑生产化。如果你已经在做生产部署建议把监控和压测做扎实。生产环境和实验环境最大的区别就是流量不可控没有监控就是盲人摸象没有压测就不知道容量边界。如果你在考虑扩容或者上集群建议先做成本收益分析。扩容能带来多少性能提升成本增加多少有没有更便宜的优化方案。很多时候优化现有配置比盲目扩容更有效。9.3 后续可以深入的方向私有化部署做完之后有几个方向可以继续深入。一是模型压缩除了量化还有剪枝、蒸馏能把模型做得更小更快。二是推理加速除了框架优化还有算子融合、内核定制能进一步压榨硬件性能。三是多模态支持现在很多场景需要模型同时处理文本、图像、音频多模态推理的工程挑战更大。四是边缘部署把模型部署到边缘设备上对模型大小和功耗有更严格的限制。这些方向每一个都够写一篇长文后面有机会再展开聊。私有化部署这件事技术方案只是一部分更多是工程实践和权衡取舍。希望这篇内容能帮你少走点弯路把模型顺顺利利搬到生产环境里。