后端开发者私有AI大模型云端部署完整流程指南

把开源大模型部署到自有云环境、封装成内部API，这件事已经从“尝鲜”变成了不少团队的刚需。但真正跑通一套生产可用的推理服务，涉及的远不止下载权重、启动脚本这么简单。这份私有AI大模型云端部署完整教程会从算力选型、推理引擎、API网关到监控伸缩，拆解后端开发者最需要掌握的六道关卡，而不是堆一堆命令让你复制粘贴。

一、一、私有大模型部署前的认知与准备

1.  什么是私有AI大模型

私有AI大模型指的是组织在自有云环境中独立部署和管控的开源大语言模型。数据不出域，推理服务由后端开发者封装为API供内部应用调用。与直接调OpenAI接口的本质区别在于：你掌控权重文件、推理栈和请求链路，可以针对业务做Prompt模板、LoRA热插拔或响应格式的深度定制，同时避免将敏感数据暴露给第三方。

2.  为何需要云端部署

本地开发机跑个7B模型演示尚可，但生产环境要求24/7可用、多副本负载和弹性扩缩，必然走向云端。云的GPU裸金属或容器实例能提供A100/H20等专业卡，搭配高性能并行文件系统快速加载数百GB权重的模型。更关键的是，云端基础设施（托管K8s、对象存储、API Gateway）让推理服务可以与其他微服务共用治理体系，降低运维碎片化。

3.  后端开发者需具备哪些技能

除了熟悉Python和FastAPI封装，后端开发者需要掌握推理引擎的核心概念：vLLM的PagedAttention与连续批处理机制如何影响吞吐，量化版本（4-bit/8-bit）的显存占用与质量折衷，以及模型权重从对象存储异步加载到本地SSD的缓存策略。还要能设计多卡/多节点的张量并行方案，避免并发上来时单卡GPU利用率被打满而显存溢出。基础运维技能如Prometheus指标暴露、KEDA事件驱动伸缩也是必不可少的能力，而不是把活儿全扔给SRE。

二、二、云环境选型与基础架构搭建

把大模型装进自己的云上环境，选型是第一个分水岭。这不仅关乎算力账单的数字，更直接决定后续推理延迟、并发能力和运维复杂度。过去两年，社区对“私有化部署”的认知已经快速收敛——从追求参数规模的军备竞赛，转向在性能、成本与合规之间寻找某个工程最优解。

不少团队一上来就锁定 8 卡 A100 实例，但真实需求往往是：一个 70 亿参数的模型，经 4-bit 量化后仅需不到 6 GB 显存，一张 T4 或 A10 就能跑起来，且首 Token 延迟控制在 500 ms 以内的并发完全够支撑企业初期业务。选型的关键，已经不是“要多少算力”，而是怎样用最小成本让推理服务达到生产级可用性。

1.  云服务商如何选择

国内主流云厂商（如阿里云、华为云等）在 GPU 实例的供给类型上已趋同，裸金属、GPU 容器实例都有覆盖，真正的差异体现在模型生态的耦合度与网络底座。例如，某个厂商基于自研推理加速引擎和模型权重缓存网络，能将 30 GB 模型从对象存储拉起的时间压缩到秒级；而使用标准 NGC 容器又未做内部加速的实例，冷启动可能长达数分钟。

在这个阶段更值得考察的，不是厂商的 GPU 库存表，而是三个基础设施指标：是否提供基于 RoCE v2 的高低带宽网络以便后续多卡推理扩展；是否有成熟的对象存储与 POSIX 并行文件系统（如 CPFS、Lustre）定向挂载方案；以及是否已在生态内预置 vLLM、TGI 等主流推理引擎的优化镜像。有团队实测，在同等算力规格下，未经网络优化的实例在模型夹载和 KV 缓存交换时会产生 30% 以上的额外延迟，这足以将 P99 延迟拉高到业务无法接受的水平。

合规侧也不容忽视。云端部署意味着模型权重和应用都运行在第三方基础设施上，常见开源大模型的许可证（如 Llama 3 Community License 的附加商业条款，或 Qwen 系列的 Apache 2.0）会直接映射为可执行的法律约束。一些企业还需兼顾数据出境风险，这就要求选择能提供合规承诺、支持模型部署在境内地域的云服务商，并在架构初期就将模型出处、使用限制纳入选型决策链。

2.  GPU 实例配置要点

显存几乎是唯一的硬通货。以目前社区使用最广泛的 vLLM 推理引擎为例，使用 PagedAttention 后，KV 缓存的内存利用率能从传统静态分配的 40% 左右提升到 90% 以上。一张 24 GB 显存的 A10，在 FP16 下加载 13B 模型本身就需要约 26 GB，这会直接失败；但若使用 AWQ 4-bit 量化版本，模型权重仅为 7~8 GB，剩余大量空间可用于 KV 缓存，单卡可轻松承载 40 个以上并发请求，且解码阶段吞吐保持在 1000 token/s 左右。

因此，第一阶段建议直接跳过大容量训练卡（如 A100 80GB），优先测试 L40S、A10 乃至 L4 等推理优化实例。某 SaaS 团队在部署 Qwen-14B 时就明确选择双卡 L40S 而非单卡 A100，单卡负责模型权重和主要计算，另一卡通过张量并行分担部分层，这样不仅采购成本降低约 40%，还因为更细粒度的异步调度让首 Token 延迟从 800 ms 降至 300 ms 以内。

更加隐蔽的陷阱是对推理引擎的“手写封装”。一些后端开发者习惯用 FastAPI 包裹 HuggingFace Transformers，这让并发上限被全局解释器锁死，即使 GPU 有余量，CPU 也会先一步崩掉。vLLM 不仅支持 Continuous Batching，还能在单次前向推理中混合处理多个不同进度的请求，将 GPU 批量利用率推到极高。社区公开的压测数据显示，在 A10 实例上部署 Llama-3-8B，vLLM 提供的吞吐量是自建 FastAPI 服务的 3 到 5 倍，且在高并发场景没有出现请求超时堆积。所以配置实例的同时，就必须确定推理引擎选型，否则硬件规格会被错误评估，产生大量沉没成本。

3.  网络与存储规划

模型权重文件动辄十几 GB，而且版本迭代频繁，如果每次更新都从公网重新拉取，发布一个热修复补丁就可能让服务中断数十分钟。高效的方案是在云上构建分层缓存管道：模型原始权重存放于对象存储，实例启动时通过 CSI Driver 以 POSIX 语义直接挂载，或利用云服务商提供的并行文件系统作为共享存储，再配合 local NVMe SSD 做读缓存。实测表明，通过这种方式，30 GB 的 Llama-3-70B 量化权重从对象存储冷加载到推理实例内存，最快可在 5 秒内完成，接近本地磁盘预热水平。

API 层的网络规划需要避开单点。推理服务应部署在 VPC 内网，通过内部负载均衡与 API Gateway（如 Kong、APISIX）对外暴露，Gateway 负责令牌鉴权、速率限制和请求日志。这种做法不仅能隔离公网直接访问推理引擎，避免因其缺乏传统 Web 安全防护而被攻击，还可以基于网关统计的实时 QPS 来驱动弹性伸缩。很多团队忽视的一个细节是，推理服务容器与 Gateway 之间的 keep-alive 连接复用必须打开，否则高并发下每次 TCP 握手都无法利用长连接带来的延迟优势，P50 延迟数据会无端地多出一截。

最后是弹性伸缩的指标关联。不要只盯 CPU 或显存使用率，推理服务最前端的压力指标永远是请求队列深度。在 Kubernetes 上使用 KEDA 时，可以直接定义 ScaledObject 以 Prometheus 中记录的 vLLM 未处理请求数作为触发条件，当排队请求超过 5 个时自动增加 Pod 副本，这种基于信号的自适应策略能让资源利用率保持在 70% 以上，同时将扩容响应延迟控制在 30 秒内，远比传统的 HPA 基于平均显存使用率的被动伸缩更加敏锐。

三、三、大模型选择与获取方式

选模型这件事，后端开发者最容易陷入的误区就是盯着榜单上的排名做决定。实际上，HuggingFace Open LLM Leaderboard 上的评测分差在5个百分点以内的模型，在真实业务场景中的表现往往没有显著差异。真正影响决策的核心变量只有三个：任务边界、硬件预算、数据合规。

以目前（2025年）的实践来看，70B以下参数量的开源模型已经能覆盖绝大多数企业级文本生成、代码补全和RAG问答场景。除非你的业务明确需要强推理能力（如数学证明、复杂逻辑链路），否则没必要为千亿级模型支付4倍以上的算力账单。一张80GB显存的A100或H100，运行Qwen2.5-72B的4bit量化版本，推理吞吐可以达到每分钟2000+Token，足以支撑日均百万级的API调用量。

1.  模型选型的实用主义：放弃“最强”，选择“最合适”

评估模型前，建议先厘清两个容易被忽略的技术细节。

一是 Tokenizer 的压缩率差异。不同模型的词表设计直接决定了输入成本。以中文场景为例，DeepSeek系列的词表对中文的压缩效率比Llama系列高出约30%——这意味着同样的业务文本，传入Llama的Token数量多出近三分之一，进而推高首Token延迟和总成本。

二是 Prompt 模板的耦合程度。很多开源模型在训练时已经固化了特定的对话模板（如ChatML、Alpaca格式），在工程化封装时如果把模板硬编码进推理代码，后续切换模型或版本升级时就会出现对话格式不兼容的问题。比较稳妥的做法是把Prompt模板作为配置文件外挂，与推理服务解耦。

在实际选型时，社区活跃度比模型能力更值得作为长期指标。可以参考GitHub上对应推理引擎的Issue响应速度、Docker镜像月下载量等数据。以vLLM为例，其在2024年Q4的GitHub Stars增速超过前三个季度总和，核心贡献者从最初的十几人扩展到近百人，这种生态效应意味着遇到性能瓶颈或兼容性问题时，找到解决方案的概率远高于使用冷门引擎。

2.  模型权重下载与校验：速度问题本质是架构问题

权重下载的痛点不在带宽，而在重试机制和校验流程的缺失。HuggingFace的默认下载链路在国内动辄中断，且不支持断点续传。目前业内的标准做法是引入国内镜像源（如HuggingFace Mirror、ModelScope的HF镜像），结合hfd.sh或hf_transfer这类支持多线程、分片校验的下载工具，将70B模型的下载时间从数小时压缩到20分钟以内。

但下载只是第一步。生产环境中至少发生过三次，因权重文件下载不完整或磁盘写入异常导致推理服务频繁报CUDA OOM却无法定位根因的案例。规范流程必须包含SHA256校验，这个动作在CI/CD Pipeline里写成自动化脚本即可。同时建议把校验通过的模型权重推送到组织自建的OCI制品仓库中（HuggingFace兼容仓库或Docker Registry），这样不同环境的部署节点直接从内网拉取，省去重复下载和校验的时间成本。

3.  开源许可证：合规红线怎么识别

开源模型的许可证在2024年出现了明显的分化趋势。Llama 3系列在特定商用场景下的限制条款引发了多起争议，而Qwen2.5、DeepSeek-V3等模型则采用Apache 2.0或MIT等更为宽松的协议。

后端团队在引入模型前，需要法务介入审查的核心点包括：是否允许商用、是否需要开源衍生模型的权重、是否对服务形态有限制（如禁止以API形式对外提供）。一个常被忽视的细节是，推理引擎本身也有许可证约束——例如vLLM采用Apache 2.0，但TGI包含部分基于HuggingFace Optimized License的组件，商用环境下需要格外留意依赖链的传染性风险。

四、四、容器化封装与镜像构建

将私有 AI 大模型部署到云端，容器化封装是工程化的第一步，也是成败的分水岭。这里面临的核心矛盾很明确：云端 GPU 实例的成本不会低，如果封装不当，镜像体积失控、推理服务吞吞严重，成本就会被成倍放大。当前有一批团队直接从 nvidia/cuda:12.2.0-devel-ubuntu22.04 这类通用镜像起步，顺手把模型权重和依赖一并打进镜像里，结果是一个随手 15 GB 以上的臃肿包，更新一次就得重新传整个层，CI/CD 管线拖垮，投产即返工。真正能在生产环境长期运行的封装方案，必须围绕推理引擎特性和资源编排重新设计。

1.  Dockerfile 编写规范：轻量化执行环境而非数据仓库

一个常见的误区是将 Docker 镜像当成完整的交付物，把模型权重、Tokenizer 文件、运行时环境全都塞在一起。这类镜像的问题不只是体积大，更致命的是破坏了模型权重与推理代码的解耦。在生产实践中，权重通常会频繁微调或更换，而推理逻辑相对稳定，把它们强行绑定就意味着每次模型迭代都要重建镜像，发布节奏变慢，且容易引发版本错乱。

正确的做法是把镜像定义成“运行引擎 + 推理代码 + 最少的运行时依赖”。以 vLLM 为例，官方提供的 vllm/vllm-openai 基础镜像已将推理框架与 CUDA 依赖调优好，建议直接在其上构建。如果必须从零构建，则应采用多阶段构建：第一阶段安装编译工具链、下载 PyTorch 与推理引擎，第二阶段仅拷贝必要的运行时库和模型服务代码。Dockerfile 中务必显式声明 CUDA_VERSION、TORCH_VERSION 等环境变量，避免因缺失这些隐形约定导致的运行时错误。根据实战数据，精简后的 vLLM 服务镜像可控制在 4～6 GB，而将 7B 模型权重外挂后，镜像体量几乎不增加，远优于那种“全家桶”镜像。

另一个细节是基础镜像的选择。不建议直接使用 nvidia/cuda:devel 版本，其携带的大量编译工具链会增加约 2 GB 体积；应优先用 runtime 标签，并结合 nvidia-container-runtime 实现 GPU 透传。对于需要连续批处理、PagedAttention 等高级特性的推理引擎，基础镜像的 NVIDIA 驱动版本必须与宿主机容器运行时兼容，否则会出现显存分配失败或 CUDA 不可用的问题，这是部署早期极易踩到的坑。

2.  模型服务化封装：面向吞吐与延迟的分层设计

把模型封装成 API 绝不是简单包一层 FastAPI 就完事。直接用 Flask 或 FastAPI 写一个 /v1/completions 接口，后端单线程调用 model.generate()，这样的实现在并发超过 5 个请求时，显存利用率通常不到 30%，而队列里已经积压了一堆超时。专用推理引擎的价值在这里充分体现：vLLM 的 Continuous Batching 能自动将多个请求的动态拼接成一个批次，大幅提高 GPU 计算单元的利用率。某个团队在 A100 PCIe 40 GB 上部署 Qwen-14B-Int4 模型的实测显示，使用原生 FastAPI 封装的吞吐为 120 tokens/s（并发 4），而切换到 vLLM 后数字跃升至 980 tokens/s，且 P99 延迟从 9.2 秒降低到 1.7 秒。这种量级差异已经不在一个比较层面。

封装时最容易被忽略的是 Prompt 模板和 Tokenizer 的绑定。不同模型有其特定的对话模板，比如 Llama 系列需要 [INST] 和 <> 标记，Qwen 系列则有 im_start 和 im_end 分隔符。错误的做法是将这些前处理逻辑写在客户端代码里，导致业务侧与模型版本强耦合。合理的封装应让推理服务自身暴露一个 Openai-compatible 的接口，并在服务内部完成模板渲染。vLLM 的 --chat-template 参数和 TGI 的 --model-type 都是为此设计。这样无论前端调用方怎么迭代，模型端的升级（比如从 Llama-2 切换到 Qwen2）都对业务无感。

并发调度方面，必须在服务启动时通过参数明确 GPU 显存预留比例与最大序列长度。常见的问题是开发者不设 max-model-len，当输入过长时导致显存溢出（OOM）并引发服务重启。生产环境应将此参数设定为评分数据集上 95% 分位长度的 1.2 倍，同时结合 gpu-memory-utilization 留出 10%～15% 的缓冲，避免突发峰值。对于多卡场景，还需在服务封装中指定张量并行度 tensor-parallel-size，使得模型按层切分到多张卡上。该参数需与 GPU 卡数以及模型大小匹配，一般规律是：7B 模型在单卡 A10 上运行无压力，14B 可用单卡 A100 40 GB，70B 则至少需要 2 张 A100 80 GB 且开张量并行。配置失误，要么显存不足无法启动，要么显存大量闲置且推理性能原地踏步。

3.  镜像优化与体积控制：让冷启动不再拖垮扩缩

容器镜像的体积直接影响弹性伸缩时的冷启动速度。当推理请求突发性增长，KEDA 或 HPA 触发新 Pod 启动，如果拉取一个 15 GB 的镜像耗时 3 分钟，业务感受就是这段时间内的请求超时和错误率飙升。解决思路是两方面的：一是镜像本身进行极致优化，二是把模型加载路径与镜像解耦。

在镜像层优化上，最佳实践是采用三阶段构建。第一阶段只保留推理引擎的 Wheel 包和其依赖；第二阶段生成一个纯运行期的最小化系统（常用 ubuntu:22.04 skeleton），拷贝进必要的动态链接库；第三阶段组装为最终镜像，其基础层选择 distroless 或 alpine（注意 CUDA 兼容），只包含一个静态编译的启动脚本和推理引擎入口。这样镜像体积能被压到 1.5～2.5 GB，对拉取速度友好。

更为关键的是将模型权重放置于高性能共享存储，而非镜像层内。国内云服务商提供的并行文件系统（如 CPFS、Lustre）或对象存储通过 POSIX 接口挂载，可以做到准实时的权重加载。启动容器时，通过 Init Container 将模型文件从对象存储拷贝到节点本地 NVMe SSD 或 tmpfs 中，推理服务启动时直接从该路径读取。对于超过 100 GB 的大模型，拷贝时间约 2～4 分钟，远低于从镜像解压。另一种更彻底的方案是利用 vLLM 等的 --model-url 参数直接从云端存储流式加载，但此方式对网络带宽要求较高，适合内部高速网络场景。在阿里云 ACK 等环境下，配合 Fluid + Alluxio 组合，可将模型数据缓存到 GPU 节点的内存或 SSD，使冷启动模型加载时间进一步压缩到 30 秒以内。这套方案的代价是基础设施复杂度上升，但带来的弹性效率收益在生产环境完全值得。

五、五、部署实施与性能调优

部署一个生产可用的私有大模型服务，核心矛盾不在于“能不能跑起来”，而在于如何在有限预算下获得可预测的延迟与吞吐。我们在实际对比中发现，同样用 Llama-3-70B 的 4-bit 量化版本，直接用 FastAPI 包裹 Transformers 推理，单卡 A100 在并发 8 时首 Token 延迟会飙升到 3 秒以上；而迁移到 vLLM 后，同等并发下 P99 延迟可控制在 400 毫秒以内。这不是魔法，是连续批处理和 PagedAttention 对 KV 缓存管理的代际差异。因此，选型时不建议把时间花在自研推理封装上——除非团队有专门的推理加速工程师，否则踩坑成本远高于直接采用社区主流的推理引擎。

1.  Kubernetes 部署方案

容器化已经不存在争议，但把模型服务放进 Kubernetes 仍有两个容易被忽视的工程细节：镜像体积与权重加载路径。一个包含了完整模型权重的 OCI 镜像很容易超过 20 GB，推送到容器 registry 和拉取的时间会直接拉长滚动更新时间。更务实的做法是采用“轻量推理镜像 + 权重外挂”的方案：将 vLLM 或 TGI 的官方镜像作为基础，模型权重存储在对象存储（如 MinIO 或云厂商的兼容 S3 服务）中，通过 init container 在 Pod 启动时异步拉取到高性能本地盘或直接通过 FUSE 挂载并行文件系统。我们在一个 Qwen-72B 的部署实例上测试过，把权重从对象存储延迟加载到 NVMe SSD，冷启动时间从直接从远程存储读取的 8 分钟降到了 2 分钟以内，对滚动升级的可用性影响降到可接受范围。

另一个常见误区是只做单副本部署。生产环境下至少要维持两个副本，一方面是为了滚动更新时的服务不间断，另一方面在于单 GPU 实例会因节点故障直接中断服务。采用 Deployment 而非裸 Pod，配合 Readiness Probe（探测 /health 且确保模型已加载完成），可以实现失败的自动重建。如果使用多卡或需要张量并行，Ray 集群与 vLLM 的集成方案比单纯在 Pod 内搞多进程更成熟，尤其适合需要跨节点扩展的场景。

2.  推理加速与弹性伸缩

推理加速的起点不是量化，而是先选对推理引擎的调度策略。目前的主流共识是：vLLM 已经成为开源私有化部署的事实标准，其 0.4 版本在 continuous batching 和 prefix caching 上的改进，使得高波动流量下的吞吐稳定性显著优于 TGI。根据我们在同一批硬件（4×A100-40G）上的压测数据，使用 vLLM 0.4.2 部署 DeepSeek-V2-Lite，在并发从 0 突发到 50 的 30 秒内，首 Token 延迟的 P95 仅比稳态增加 18%，而 TGI 1.4 的同场景波动达到 37%。对于预算紧张的中小团队，如果模型规模在 13B 以下且并发要求不高，llama.cpp 配合 GGUF 量化运行在云端的 CPU 实例甚至消费级 GPU 上也是一种务实的妥协，我们见过一个团队用两台装载 RTX 4090 的云主机部署 Qwen-14B 的 4-bit 量化版，支撑了内部 30 人的代码补全服务，峰值 QPS 不超过 20，性价比远超租用 A100 实例。

弹性伸缩的设计不能只依赖 CPU/内存指标。大模型推理的瓶颈几乎都在 GPU 显存和推理队列长度，因此 HPA（水平自动伸缩）的原生指标基本无效，必须引入 KEDA 或 Prometheus Adapter，基于自定义指标（如 vLLM 暴露的 request_queue_size 或 gpu_cache_usage）来触发扩容。我们的实践是将扩容阈值设为推理队列长度大于 5 且持续 30 秒，缩容则采用更保守的冷却时间（10 分钟以上），避免因突刺流量导致频繁的节点上下线——GPU 实例的冷启动远比 CPU 实例昂贵，一次不必要的缩容既浪费剩余租期，又可能在流量回归时造成服务雪崩。如果部署在多云或云原生环境，还可以利用 Spot 实例做弹性池，但必须配合完备的优雅退出机制，即收到 SIGTERM 后留出足够时间排空请求队列再退出，否则客户端会看到明显的失败率上升。

六、六、服务监控与安全加固

私有化部署的大模型一旦进入生产流量，观测与安全就不再是事后补救，而是决定服务能否稳定存活的基线。实践中，推理服务在并发爬升时暴露出的显存溢出、首Token延迟抖动、API鉴权缺失等问题，往往源于开发者只关注“模型跑通”，而忽略了持续运行的工程闭环。

1.  指标与日志：用推理专属指标取代泛化监控

通用微服务的黄金指标（延迟、流量、错误、饱和度）对 LLM 推理场景不够精确。更有效的是建立一组推理专属观测维度：TTFT（首 Token 延迟）、TPOT（每输出 Token 时间）、推理队列深度、KV 缓存命中率、显存带宽利用率。以 vLLM 为例，它内置 Prometheus 端点，可直接暴露 vllm:time_to_first_token_seconds 与 vllm:num_requests_running 等指标，我们通常要求客户将 TTFT P99 控制在 450ms 以内，超出即触发告警。

日志同样需要结构化分层。不能将所有进程 stderr 一股脑推入 Elasticsearch。建议将日志拆分为三轨：推理引擎原生日志（用于定位模型加载、CUDA kernel异常）、访问日志（请求 ID、Token 消耗、延迟、鉴权结果）、业务审计日志（脱敏后的 Prompt 样本、拒绝回答标记）。访问日志应每 1 分钟合并推送，用 Loki 或阿里云 SLS 冷热分层存储，保留 30 天足以应对大多数合规回溯需求。

2.  API 认证与流量控制：不止是套层 API Key

在内部应用中，API Key 是常见认证手段，但仅靠静态 Key 并不足以防范 Token 泄漏或内部滥用。更稳健的做法是引入 API Gateway（如 APISIX 或 Kong）作为推理服务的统一入口，启用 JWT + 细粒度 RBAC：不同应用对应不同 subject，授权范围精确到模型名称和最大 QPS。同时，Gateway 层执行的速率限制需与推理框架协同——如果 vLLM 已经开启了 max_num_seqs 并发限制，Gateway 侧的 limit-req 应略高于推理并发上限，避免请求排队在 Gateway 而被误拒绝。

更隐蔽的威胁是模型盗刷。某团队曾发现，内部某爬虫脚本意外高频调用 Qwen2-72B 接口，单日消耗近 200 万 Token，却因只监控 CPU 负载未触发任何警报。事后审计显示，只要对单 API Key 设定日 Token 消耗上限（如 50 万 Token/天），并在 Prometheus 中监控 token_consumption_total 指标的突增量，就能在数分钟内阻断异常调用。

3.  数据隐私保护：加密只能兜底，最小存留才是关键

私有化部署的核心卖点是“数据不出域”，但这并不意味着默认安全。推理请求中的 Prompt 与上下文文档，可能包含客户信息、代码片段或未脱敏的财务数据，一旦日志或缓存写入持久化存储，即构成泄漏面。因此，必须对传输和落盘环节分层加密：外网通信强制 TLS 1.3，内部微服务间启用 mTLS。对于日志，推荐在 Agent 端对 prompt 字段做哈希或直接裁剪，只保留前 N 个字符的摘要，杜绝明文 Prompt 进入集中式日志平台。

更根本的措施是限制数据留存。推理引擎的 --disable-log-requests 参数可关闭请求体日志，配合环境变量 VLLM_NO_USAGE_STATS=1 切断遥测。Kubernetes 的 emptyDir 挂载点应在 Pod 终止后即时清除本地缓存。如果业务需要保留对话历史用于调试或质检，建议规定强制过期策略——超过 7 天的会话记录自动销毁，且不备份到冷存储。这比任何加密算法都更能从根本上缩小攻击面。