私有化AI部署：内网、GPU、权限、日志、备份和合规检查
摘要
私有化 AI 部署的目标不是把模型搬进内网后宣布安全，而是把数据、算力、权限、日志、备份和合规证据放进同一套可运维边界。本文把内网入口收口、GPU 资源规划、模型网关、RAG 权限、日志审计、备份恢复和合规检查作为一个整体讨论，强调“部署位置”不能替代“治理能力”。私有化只改变信任边界和运行约束，不能自动解决越权检索、提示注入、工具滥用、审计缺失和恢复不可用等问题。
关键词
私有化 AI；内网部署；GPU 规划；模型网关；权限控制；日志审计；备份恢复；合规证据
研究问题与方法
本文的研究问题是：企业把 AI 能力放入内网后，哪些风险下降了，哪些风险只是换了表现形式。方法上采用资产边界分析，把模型权重、业务数据、向量索引、日志、密钥、工具权限和备份介质都视为需要保护的资产，再用恢复演练和权限链路检查验证部署方案是否可用。
图中的网关不是为公网供应商准备的可选层，而是内网部署中连接权限、算力和审计的控制面。若 GPU 推理池直接面对多个业务系统，模型能力会被分散使用，费用、权限和安全事件都难以归因。私有化方案的取舍可以用下面的表来判断。
| 取舍对象 | 低治理部署的表面收益 | 生产部署必须补上的证据 |
|---|---|---|
| 单机模型服务 | 启动快，团队容易演示 | 调用日志、模型版本、权限来源、容量上限 |
| 全量内网知识库 | 检索简单，命中看似充分 | 文档 ACL、片段版本、撤权后索引失效 |
| 手工备份 | 初期成本低 | 恢复时间、恢复点、演练记录、备份权限 |
私有化 AI 部署不是把一个开源模型放到一台服务器上，再给它套一个聊天页面。真正进入生产环境后，问题很快会从“模型能不能回答”变成“哪些人能访问、哪些数据能进入、GPU 怎么分配、日志怎么留、故障怎么恢复、合规怎么证明”。如果这些问题没有提前设计，模型越聪明，系统越容易变成不可控的黑箱。
这篇文章面向正在学习和落地私有化 AI 的工程实践者。这里说的私有化，不只包括完全离线的本地部署，也包括企业内网部署、专有云部署、混合云部署和受控模型网关。它们的共同点是：企业希望对数据、权限、运行环境、审计证据和成本有更强控制，而不是把所有业务请求直接发给外部 SaaS。
截至 2026-05-22，私有化 AI 的工具链已经比两年前成熟很多。vLLM、Text Generation Inference、llama.cpp、KServe、NVIDIA GPU Operator、Kubernetes、OpenTelemetry、Loki、restic 等项目把推理服务、GPU 管理、观测、备份和恢复拆成了可组合的工程模块。成熟不等于简单。越多组件可选，越需要一套清晰的部署方法。
引言：先明确私有化部署到底保护什么
私有化部署的第一层目标是数据边界。企业内部文档、客户资料、合同、日志、代码、工单、邮件、会议纪要、财务数据和生产指标，不一定都允许离开内网。把模型放到内网，可以减少数据外传路径，也能让检索、解析、缓存和中间产物都留在受控环境里。
第二层目标是权限边界。很多 AI 系统不是简单问答，而是会调用知识库、数据库、代码仓库、工单系统、审批系统和办公工具。模型如果能看到太多工具，或者工具返回太多字段，就可能越过用户本来没有的权限。私有化部署必须把“用户能做什么”和“模型能代用户做什么”绑定起来，不能只靠提示词约束。
第三层目标是运行边界。GPU、模型权重、容器镜像、向量库、对象存储、推理缓存、队列任务和日志系统都需要被管理。业务高峰时，GPU 显存可能比 CPU 更先成为瓶颈；知识库重建时，后台任务可能拖慢在线问答；日志无限增长时，磁盘会先把数据库压垮。私有化部署不是拥有机器，而是拥有运行纪律。
第四层目标是证据边界。一个合规可解释的 AI 系统，需要证明它在正确时间由正确用户发起，访问了哪些数据，调用了哪个模型版本，使用了哪些工具，输出了什么结果，是否被人工确认，是否发生外部副作用。没有这些证据，出问题时无法复盘，也无法向安全、法务、客户或监管说明。
因此，私有化部署的核心不是“本地模型优先”，而是“控制面优先”。模型只是数据面的一部分。真正决定系统是否可用的是身份、授权、网络、推理服务、任务状态、日志、备份和合规检查。
一张最小私有化 AI 架构图
一个生产级私有化 AI 系统可以先拆成九个区域：入口层、身份层、应用层、模型网关、推理层、知识层、任务层、观测层和恢复层。每个区域都可以从简单形态开始，但角色不能缺失。
入口层负责内网域名、HTTPS、反向代理、访问来源限制和基础限流。身份层负责用户登录、组织、角色、服务账号和会话。应用层负责业务页面、API、任务创建、权限判断和最终结果展示。模型网关负责统一模型调用、路由、限额、密钥隔离和模型日志。推理层负责 vLLM、TGI、llama.cpp 或其他模型服务。知识层负责原始文件、对象存储、解析文本、向量索引和引用关系。任务层负责异步解析、批量 embedding、重试和人工确认。观测层负责日志、指标、链路追踪、告警和质量反馈。恢复层负责数据库备份、文件备份、模型权重备份、配置备份和恢复演练。
如果团队规模小，可以用一台机器和 Docker Compose 承载这些角色；如果团队已经有 Kubernetes，可以把推理服务、应用服务、队列、数据库客户端和观测组件放进集群；如果要求更强隔离，可以把 GPU 推理、数据存储和业务应用分在不同网络区域。重要的不是一开始就很大，而是每条边界明确。
最小请求路径可以这样理解：用户从内网页面发起任务，应用层先做身份和业务权限检查，然后模型网关根据任务类型选择模型；如果需要知识库，检索服务只返回该用户有权读取的片段；模型生成答案或工具调用建议后，应用层执行确定性校验；高风险动作进入人工确认；最终结果、引用、模型版本、工具结果和用户确认都写入审计日志。
这条路径有一个关键原则：模型不直接拥有系统权限。模型可以提出“需要查询合同编号 A 的付款条款”，但真正查询要由应用层或工具服务执行授权检查。模型可以生成“建议发送邮件”，但真正发送前要展示收件人、主题、正文、附件和依据。模型可以总结日志，但不能直接读取所有日志。私有化 AI 的安全性来自系统边界，不来自模型自觉。
内网架构：先收口入口，再分区访问
内网部署最常见的错误，是把“只在内网开放”当成安全设计。内网不是天然安全区。办公网、测试网、生产网、运维网、GPU 服务器、数据库网络和文件存储网络的风险不同，访问者也不同。一个用户能打开聊天页面，不代表他应该能访问向量库管理端、对象存储控制台或推理服务原始端口。
入口层应该统一收口。对最终用户，只暴露产品页面和必要 API；对内部管理者，暴露管理后台，但要走更高权限认证；对服务之间的调用，使用内部服务名、私有地址或集群网络。数据库、向量库、对象存储、Prometheus、Loki、模型推理端口和 Kubernetes API 不应该直接面向普通办公网。
在 Kubernetes 中，网络策略是内网分区的重要工具。NetworkPolicy 用应用视角描述 Pod 之间允许的通信，但前提是集群使用支持 NetworkPolicy 的网络插件。实践中可以把命名空间按职责分开：ai-app 放应用服务，ai-inference 放推理服务，ai-data 放知识和对象存储客户端，ai-observability 放观测组件。默认拒绝跨命名空间流量，再逐条开放必要路径。
如果还没有 Kubernetes，Docker Compose 也可以建立基本网络边界。把前端代理放在可访问网络，把数据库、向量库、对象存储和推理服务放在内部网络，只让应用后端访问它们。Compose 不能替代完整的集群策略，但对早期内网系统来说，比所有容器都绑定到宿主机端口可靠得多。
内网还要考虑出网控制。很多模型部署会拉取 Hugging Face 权重、容器镜像、Python 包、系统包和模型许可证页面。生产环境不应依赖临时外网。应当准备镜像仓库、模型权重仓库、离线依赖包、许可证记录和校验哈希。完全离线环境还要提前确认驱动、CUDA、容器运行时、Python wheel、模型 tokenizer、量化文件和安全扫描工具都能从内部源获取。
对混合云部署，最重要的是定义“哪些数据可以出网”。一种常见架构是：敏感文档解析、检索、权限和日志留在内网；低敏摘要或通用任务可以走外部强模型；外部模型只接收脱敏片段、任务指令和必要上下文；输出回到内网后再做审计和展示。混合云不是把私有化做一半，而是把数据分级和模型分工做清楚。
GPU 规划：显存、吞吐和隔离比卡数更重要
私有化 AI 采购 GPU 时，很多团队先问“几张卡够不够”。更好的问题是：要跑哪些模型、最大上下文多长、峰值并发多少、是否流式输出、是否需要多模型常驻、能接受多少排队时间、是否有批处理任务、是否要给不同团队隔离资源。GPU 不只是算力，显存才是大模型推理的硬边界。
模型权重会占显存，KV cache 也会占显存。长上下文、多并发和流式对话都会增加 KV cache 压力。一个模型能在单卡上加载，不代表它能在同一张卡上服务多个长文档请求。上线前必须用真实上下文长度和真实并发做容量测试，而不是只看模型卡片里的参数量。
vLLM 适合高吞吐推理服务。它提供 OpenAI 兼容的 HTTP 服务，并支持 Chat Completions、Responses、Embeddings、转写、翻译、rerank 等多类接口。对应用层来说，OpenAI 兼容接口能降低适配成本；对推理层来说，必须理解每个模型的 chat template、采样默认值、并行工具调用能力和上下文限制。vLLM 文档也提醒，模型仓库中的 generation_config.json 可能改变默认采样参数，生产部署应明确自己的默认值。
Text Generation Inference 也是常见选择。TGI 面向开源 LLM 服务化，支持连续批处理、流式输出、张量并行、量化、Prometheus 指标和 OpenTelemetry 追踪，并提供 OpenAI 兼容的 Messages API。它适合团队希望用 Hugging Face 生态服务开源模型，又需要生产推理能力的场景。
llama.cpp 和 llama-cpp-python 更适合轻量、本地、边缘和成本敏感场景。llama-cpp-python 提供 OpenAI 兼容 Web Server，可以加载 GGUF 模型，也支持多模型配置和 API key。它不一定适合大规模高并发，但很适合办公室服务器、开发内网、边缘节点、低敏任务和离线验证。很多企业会同时保留 vLLM/TGI 的 GPU 服务和 llama.cpp 的轻量服务，用不同模型承担不同任务。
在 Kubernetes 中管理 GPU，NVIDIA GPU Operator 可以自动化部署驱动、容器运行时、device plugin、GPU Feature Discovery、DCGM 监控等组件，减少手工配置差异。对拥有多台 GPU 机器的团队来说，Operator 的价值在于把 GPU 节点变成可调度资源，而不是每台机器靠人工维护。
如果使用支持 MIG 的 NVIDIA GPU，可以把一张物理 GPU 切成多个隔离实例，用于小模型、多租户或测试任务。MIG 不是万能切片：不同模型对显存、计算和带宽的需求不同，切片后也会限制单个任务能使用的资源。适合切片的场景是“多个稳定小负载共存”；不适合切片的场景是“大模型需要整卡或多卡通信”。生产规划要根据真实模型选择 MIG、时间切片、整卡独占或多卡张量并行。
GPU 还需要运维规则。推理服务要有并发上限、请求队列、超时、最大输入长度、最大输出长度和后台任务窗口。批量 embedding、知识库重建、长文档总结和评测任务不应与在线问答无限竞争同一张卡。高峰时可以降级到小模型、排队执行或切换外部 API；但这些策略必须由网关和任务系统控制，不应让用户请求直接把 GPU 打满。
模型网关：把模型能力变成受控服务
私有化部署里，模型网关是 AI 控制面的中心。它不只是转发请求，还负责模型目录、路由策略、密钥隔离、预算、限流、审计、降级和灰度。没有网关时，每个应用都会直接调用推理服务或外部供应商，最后密钥散落、日志分散、模型替换困难、成本无法归因。
模型目录要记录每个模型的用途、能力、上下文、部署位置、许可证、数据等级、成本估算和风险等级。比如本地 Llama 或 Mistral open-weight 模型适合内网问答、文档摘要和可控 RAG；强推理外部模型适合复杂规划和代码任务；小模型适合分类、改写和路由；嵌入模型适合检索；视觉模型适合图片、截图和表格理解。没有模型目录，路由会变成“谁最近效果好就用谁”。
路由策略要面向任务，而不是面向模型名。用户问一句普通 FAQ，不需要动用最贵模型；合同审查、代码修复、复杂计算和多工具任务需要更强模型；含敏感字段的请求应该进入本地模型或脱敏流程；低风险批处理可以走低成本模型；高风险输出要进入人工确认。模型网关应根据任务类型、数据等级、用户额度和服务健康度选择模型。
网关还要保存最少但足够的调用记录：请求 ID、用户或服务账号、业务任务 ID、模型名、模型版本、输入长度、输出长度、耗时、状态、错误类型、工具调用摘要、引用来源和成本估算。敏感原文不一定要完整落日志，但摘要和哈希要能支持复盘。对合规系统来说，“不知道这次调用用了哪个模型”是不可接受的。
降级策略应提前设计。模型不可用时，不同任务有不同处理方式：简单分类可换小模型，知识库问答可提示稍后重试，合同审查不能悄悄换成低能力模型，代码修改不能在没有测试的情况下自动提交。降级不是越自动越好，而是要符合业务风险。
权限设计：用户权限、工具权限和数据权限要合一
AI 系统的权限比普通后台复杂，因为模型在用户和工具之间做推理。用户本来只能看自己的客户，模型如果通过工具拿到了全量客户列表，就等于绕过了业务系统。模型本来只应该生成草稿，如果工具允许直接发送邮件，就可能造成真实外部影响。权限设计必须覆盖用户、工具、数据和动作。
第一层是用户身份。所有入口请求都要绑定真实用户、组织、角色和会话。内部服务调用要使用服务账号，不要共享管理员密钥。审计记录中要能区分“用户主动发起”“后台任务发起”“系统定时任务发起”和“管理员代操作”。
第二层是业务授权。知识库、文件、客户、项目、代码仓库、工单和审批记录都要按业务权限过滤。RAG 检索不是先全库召回再让模型判断是否可见，而是在检索前或检索时就加权限条件。向量库的 payload、数据库的过滤字段、对象存储的元数据和应用层授权要保持一致。
第三层是工具权限。工具应按风险分级：只读查询、草稿生成、内部写入、外部发送、删除、付款、权限变更、命令执行。模型默认只能使用低风险工具，高风险工具必须通过业务规则和人工确认。工具参数要尽量最小，不要把内部 API 的所有字段暴露给模型。工具返回也要最小化，不要为了方便把整张表、完整用户资料或密钥配置返回给模型。
第四层是运行时授权。一次工具调用必须带上用户上下文、任务上下文和权限范围。工具服务不能相信模型传来的“用户有权限”，而要自己验证。比如查询合同工具收到合同 ID 后，应根据用户身份检查合同所属部门、项目角色和文档状态；发送邮件工具收到正文后，应检查收件人域名、附件权限、审批状态和发送额度。
在 Kubernetes 层面，RBAC 用于限制集群资源访问。Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 可以把权限限定到命名空间或集群范围。默认不要给应用服务账号 cluster-admin，也不要让业务 Pod 能读取所有 Secrets。Kubernetes 文档明确说明，edit 权限可能允许访问 Secrets 并以命名空间内任意 ServiceAccount 运行 Pod，因此生产环境要谨慎分配。
Pod Security Admission 可以在命名空间级别执行 Pod 安全标准，常见模式包括 privileged、baseline 和 restricted。AI 推理服务有时需要 GPU、共享内存和特殊设备，但这不意味着所有 Pod 都应该获得特权。应把基础设施组件、推理组件和普通应用组件放在不同命名空间，为每类工作负载设置不同安全级别。
Secrets 管理也不能粗放。模型 API key、数据库密码、对象存储密钥、JWT 密钥、备份仓库密码、许可证 token 都属于敏感数据。Kubernetes Secret 可以承载敏感配置，但仍要配合加密静态存储、最小 RBAC、密钥轮换和审计。不要把密钥写进镜像、前端代码、日志或文章示例。
日志和观测：要能解释一次回答从哪里来
私有化 AI 的日志不是为了保存聊天记录，而是为了解释系统行为。一次用户问题可能经过身份认证、权限过滤、文档检索、模型调用、工具调用、人工确认和结果写入。任何一步出错，用户看到的都可能只是“回答不准确”或“任务失败”。没有观测数据，团队只能猜。
日志可以分成五类。访问日志记录谁在什么时间访问了哪个入口。任务日志记录任务状态、步骤、重试和人工确认。模型日志记录模型名、版本、token、耗时、错误和路由。工具日志记录工具名、参数摘要、权限结果、外部系统返回和副作用证据。质量日志记录用户采纳、人工修改、引用错误、拒答原因和评测结果。
不要把所有原文直接写入日志。合同、客户资料、代码、身份证件、财务记录和医疗信息都可能出现在提示词里。更稳的做法是保存结构化摘要、数据对象 ID、片段哈希、引用位置、权限范围和必要的脱敏内容。需要完整留存的场景，应有明确的数据保留周期、加密存储和访问审批。
OpenTelemetry 的价值在于把 traces、metrics 和 logs 统一到一套可观测模型中。对 AI 系统来说，trace 可以串起一次请求经过的组件，metrics 可以看成功率、延迟、GPU 利用率、队列长度和 token 消耗，logs 可以解释具体错误。OpenTelemetry 本身不是存储后端，而是生成、收集和导出遥测数据的框架。
Loki 适合做日志聚合，强调按标签索引元数据而不是全文重索引。AI 系统可以用标签表达服务名、环境、任务类型、模型、用户组、请求 ID 和错误类型。标签不要无限膨胀，用户 ID、文档 ID 这类高基数字段要谨慎使用，否则日志系统会先被自己的索引拖垮。
指标体系要覆盖基础设施和 AI 质量。基础指标包括 CPU、内存、磁盘、网络、GPU 显存、GPU 利用率、容器重启、请求耗时和错误率。AI 指标包括每个模型的调用量、token、费用估算、超时率、拒答率、工具调用失败率、引用命中率、人工修改率和用户满意度。只监控服务在线，不足以判断 AI 产品是否健康。
告警要按影响分级。磁盘快满、数据库不可用、模型网关错误率升高、GPU 显存长期不足、队列积压、备份失败、异常调用量激增和高风险工具连续失败，都应该有告警。提示词效果变差、某知识库引用错误增多、某模型成本异常，也应该进入质量看板。AI 运维不是只看机器，而是看结果。
备份：恢复路径比备份命令更重要
私有化部署最怕“以为有备份”。真正的备份对象至少包括数据库、对象存储、向量索引、模型权重、配置、密钥、镜像版本、提示词版本、评测集和运行手册。只备数据库不备文件，知识库无法恢复；只备文件不备元数据，权限和引用丢失；只备向量不备原文，无法校验来源；只备配置不备密钥，服务起不来。
数据库通常保存用户、组织、权限、任务、提示词版本、模型目录、工具调用、审计记录和业务配置，应有定期逻辑备份或物理备份。对象存储保存原始文件、图片、导出报告、中间产物和证据附件，应做增量备份。向量库如果可由原文重建，也仍要备份索引元数据和构建版本；如果重建成本很高，就要备份快照。
restic 这类工具适合文件级加密增量备份，并支持恢复指定快照。它的价值不在命令漂亮，而在能把本地文件、对象存储导出、配置目录和证据附件纳入统一备份策略。备份仓库应放在不同磁盘、不同机器或可信云存储中。把备份放在同一块系统盘上，只能应对误删，不能应对硬盘损坏。
备份策略要包含保留周期。比如每日备份保留 14 天，每周备份保留 8 周，每月备份保留 12 个月。AI 系统常见数据错误不是当天就发现：一次错误脚本可能把知识库权限写坏，一次模型批处理可能覆盖人工修订，一次错误索引可能影响几周。只保留最近一次备份无法应对逻辑错误。
恢复演练必须按用户路径验证。一次合格演练不是“备份命令成功”，而是在临时环境恢复数据库、文件、索引和配置，启动应用，登录测试账号，打开历史文档，执行一次检索，调用一次模型，生成一份带引用的结果，并确认审计日志能看到完整路径。恢复时间也要记录，因为它决定业务能承受多长中断。
模型权重也要备份。开源模型可能来自 Hugging Face、Meta、Mistral 或内部训练仓库，下载链接、许可证、tokenizer、量化文件和校验哈希都要保存。很多团队恢复时才发现模型仓库权限变了、旧版本找不到、tokenizer 不匹配、量化文件缺失，导致服务无法复现。私有化部署不能依赖“到时候再下载”。
密钥恢复要单独设计。数据库主密码、对象存储 root key、模型供应商 key、备份仓库密码、Kubernetes kubeconfig、证书私钥和加密盐都不能只存在某个人电脑。可以使用企业密码管理器、KMS、硬件密钥或加密密钥文件。关键是明确谁能访问、如何轮换、如何吊销、如何在灾难恢复时取得。
合规检查：从制度语言落到工程证据
合规不是最后写一份说明，而是部署设计的一部分。NIST AI RMF 把 AI 风险管理组织为 Govern、Map、Measure、Manage 等功能，这对私有化 AI 很有启发：先建立治理责任，再识别场景和风险，再度量风险和效果，最后管理和持续改进。工程上要把这些抽象要求翻译成可检查证据。
数据合规首先看数据来源。知识库文档是否有合法来源，是否允许用于 AI 处理，是否包含个人信息，是否有保留期限，是否能按用户权限过滤，是否支持删除和重建索引。很多 RAG 系统只关心“能不能搜到”，却忘了“是否有权搜到”。私有化部署要把数据目录、权限目录和索引目录对齐。
模型合规要看许可证和用途。不同开源模型的许可证、可商用范围、再分发条件、可接受使用政策不同。企业不能只看“开源”两个字。模型目录应记录模型来源、版本、许可证、下载时间、权重哈希、适用场景、禁止场景和安全评估结果。外部 API 模型也要记录数据处理条款、区域、保留政策和供应商风险。
权限合规要看最小权限和职责分离。普通用户不能通过 AI 看到未授权文件，应用服务账号不能拥有集群管理员权限，模型服务不能读取业务数据库，观测平台不能暴露敏感原文，备份管理员不能随意恢复到生产覆盖当前数据。每类权限都要能用配置和审计记录证明。
日志合规要看留存和访问。审计日志应该不可随意修改，关键操作要有时间、用户、对象、动作和结果。日志中如果包含个人信息或商业秘密，就要有脱敏、加密和访问审批。留存时间不应无限，也不应短到无法追溯。不同日志类型可以有不同保留周期。
安全合规要看供应链。容器镜像、系统包、Python 依赖、模型文件、前端依赖和基础镜像都可能引入漏洞。离线环境也要有内部镜像源和扫描流程。模型文件本身也要校验哈希，避免下载错误版本或被替换。部署清单里应记录镜像 tag、digest、模型 hash 和配置版本。
质量合规要看评测。AI 系统不能只靠上线前主观试用。应该准备代表性问题集、拒答样本、越权样本、长文档样本、工具调用样本和失败样本。每次换模型、改提示词、重建索引、升级推理引擎，都跑回归评测。合规不仅关心安全，也关心系统是否稳定履行承诺。
实操路径：从单机闭环到集群治理
第一阶段是单机闭环。适合团队验证真实业务场景。可以用 Docker Compose 组织应用、数据库、向量库、对象存储、模型网关、轻量推理服务和观测组件。目标不是支撑所有部门，而是让一个场景完整跑通：用户登录、上传文档、解析、检索、调用模型、生成答案、显示引用、记录日志、备份恢复。
这个阶段最容易偷懒的是权限和备份。很多人觉得试点阶段不用做复杂权限，但试点数据往往就是真实业务数据。至少要做用户身份、文档归属、知识库可见范围、管理员操作审计和每日备份。否则试点成功后，技术债会直接进入生产。
第二阶段是内网服务化。把模型网关、推理服务、知识库、对象存储和后台任务拆成清晰服务。应用不再直接调用模型容器，而是通过网关；知识库不再只是一堆文件，而是有文档表、片段表、索引版本和权限字段；任务不再同步阻塞用户请求，而是进入队列。这个阶段要建立模型目录、工具目录、日志字段规范和恢复演练。
第三阶段是 Kubernetes 化。不是所有团队都必须上 Kubernetes，但多 GPU、多服务、多团队、多环境时，Kubernetes 的调度、命名空间、RBAC、NetworkPolicy、Pod Security 和 Operator 生态会很有价值。NVIDIA GPU Operator 可以统一 GPU 组件，KServe 可以用 CRD 管理模型服务，vLLM/TGI 可以作为推理后端，OpenTelemetry 可以统一采集。
第四阶段是平台治理。多个业务团队同时接入后，要做租户隔离、预算管理、模型路由、工具审批、提示词版本、评测集、质量看板和审计报表。此时模型网关和任务系统会成为 AI 平台核心。平台治理不是做一个大而全的页面，而是让每个模型、工具、知识库和业务应用都有清楚责任边界。
典型案例：私有合同助手如何部署
假设一家企业要做内网合同助手，目标是让业务人员上传供应商合同，系统自动识别付款条款、数据处理条款、违约责任和审批风险，并给出引用依据。这个场景看起来像文档问答，实际涉及权限、合规、日志、备份和人工确认。
入口层只允许企业账号访问，合同按部门、项目和角色授权。上传后，文件进入对象存储，数据库记录文件 ID、上传人、部门、密级、版本和保留期限。解析服务提取正文、页码和表格，并把片段写入知识库。向量索引的每个片段都带合同 ID、部门、项目、密级和版本，检索时按用户权限过滤。
模型层可以使用本地开源模型完成条款初筛，用强推理模型完成复杂风险解释。模型网关记录每次调用的模型、版本、token、耗时和任务 ID。高风险建议必须附上合同页码、原文片段和制度依据。模型不能直接修改合同状态，只能生成审查草稿。法务确认后，系统才把结果写入正式审查记录。
工具层提供只读查询制度、查询历史模板、生成修订建议和创建审查草稿等工具。发送外部邮件、变更合同状态、关闭审查任务都需要人工确认。工具服务每次都按用户上下文检查权限，不能相信模型声称的权限。
观测层记录上传、解析、检索、模型调用、工具调用、人工确认和最终报告生成。日志不保存完整合同正文，但保存片段哈希、页码、引用 ID 和结果摘要。备份覆盖数据库、对象文件、向量索引快照、提示词版本和模型目录。恢复演练必须能打开历史合同，重新检索并生成带引用报告。
这个案例说明，私有化合同助手的重点不只是模型是否懂法律语言，而是系统能否保证用户只看有权合同，风险点有来源，正式结论有人确认，过程可复盘，数据可恢复。
常见误区
第一个误区是把开源模型等同于私有化。开源模型可以本地运行，但如果文件上传到外部解析服务、embedding 走外部 API、日志进了第三方平台，系统仍然不是完整私有化。私有化要看全链路，不只看生成模型。
第二个误区是把内网等同于安全。内网里也有越权访问、弱密码、共享账号、测试数据泄漏、未授权端口和日志暴露。真正的安全来自身份、授权、网络分区、最小权限、审计和恢复能力。
第三个误区是只看 GPU 利用率。GPU 利用率高不一定代表服务健康，可能是队列堆积、长上下文过多或批处理抢资源。还要看首 token 延迟、输出 token 速度、超时率、显存占用、失败率和用户等待时间。
第四个误区是把日志当聊天记录。合规需要的是可解释证据，不是无限保存用户原文。日志设计要兼顾复盘和隐私，保存必要结构化信息，控制敏感内容留存。
第五个误区是没有恢复演练。很多系统平时看起来稳定，真正迁移或故障时才发现备份缺少模型权重、密钥、对象文件或索引版本。没有演练的备份不能算完成。
第六个误区是让模型直接执行高风险动作。提示词不能替代权限系统。退款、删除、发邮件、改权限、执行命令、提交审批等动作必须有确定性校验和必要人工确认。
上线前检查清单
- 数据边界：明确哪些数据可进入模型，哪些必须脱敏，哪些不能离开内网。
- 网络边界：只暴露用户入口和管理入口，数据库、向量库、对象存储、推理端口不直接开放。
- 模型目录：记录模型来源、版本、许可证、用途、上下文、部署位置和风险等级。
- GPU 容量：用真实上下文、真实并发和真实输出长度测试显存、吞吐和延迟。
- 权限过滤：知识库检索、工具调用和文件访问都按用户权限过滤。
- 工具分级：只读、草稿、内部写入、外部副作用、高风险动作分级管理。
- 日志审计：记录请求 ID、用户、任务、模型、工具、引用、确认和结果摘要。
- 敏感日志：避免明文保存合同、客户资料、密钥、身份证件和完整代码。
- 备份范围：数据库、对象文件、向量索引、模型权重、配置、密钥和评测集都在备份内。
- 恢复演练：定期在临时环境恢复，并按用户路径验证 AI 功能可用。
- 合规证据：能证明数据来源、用户授权、模型许可证、日志留存和质量评测。
- 变更流程：升级模型、改提示词、重建索引、换推理引擎前跑回归评测。
变更、演练和日常运营
私有化 AI 系统一旦上线，最容易出问题的不是第一天，而是后续变化。模型权重会升级，推理引擎会升级，CUDA 和驱动会升级，知识库会重建，提示词会调整，权限规则会变化，业务工具会新增字段。任何一个变化都可能影响答案质量、延迟、成本或安全边界。生产级部署必须把变更当成正常工作流，而不是临时操作。
模型变更要有灰度。不要把新模型直接替换旧模型。更稳的做法是先在评测集上跑离线对比，再让少量内部用户试用，再按任务类型逐步切换。评测要覆盖普通问答、长文档、越权样本、拒答样本、工具调用、格式输出和高风险建议。只看平均分不够，还要看失败样本是否可接受。一个模型在通用问题上更强，不代表它在企业制度问答里更可靠。
推理引擎变更也要谨慎。vLLM、TGI、llama.cpp、CUDA、NCCL、驱动和容器镜像升级后，吞吐、显存、首 token 延迟、采样行为和 chat template 都可能变化。升级前要记录当前基线：同一批提示词的输出、耗时、显存占用和失败率。升级后用同样样本复测。若输出风格、工具调用格式或拒答边界明显变化，要先调整提示词和后处理，再进入生产。
知识库变更要能追溯。新增文档、删除文档、重建索引、调整分块、替换 embedding 模型、修改重排规则，都会改变 RAG 结果。每个知识库应有版本号，文档、片段、向量、权限和引用都能对应到同一个版本。用户看到答案时，系统应知道它引用的是哪份文档、哪个版本、哪一页或哪一段。否则用户追问“这个依据还有效吗”，系统无法回答。
权限变更要比功能变更更严格。增加一个工具、扩大一个服务账号权限、开放一个命名空间访问、允许模型读取一类新数据，都应该经过审查。审查内容包括：谁能触发、能读哪些字段、能写哪些对象、失败会怎样、日志是否记录、是否需要人工确认、是否有回滚方式。很多 AI 安全事故不是模型突然失控，而是某个工具权限给得太大。
日常运营要有固定节奏。每天看服务健康、模型错误率、队列积压、GPU 显存、磁盘、备份结果和异常调用。每周抽样检查答案质量、引用准确性、人工修改和高风险任务。每月做恢复演练和权限复核。每次重大变更后做回归评测。运营不是额外负担，而是让系统持续可用的成本。
还要准备事故分级。模型网关不可用、GPU 节点故障、数据库异常、对象存储不可访问、知识库权限错误、日志写入失败、备份失败、外部模型额度耗尽，都应该有处理顺序。低风险任务可以暂停，高风险任务应停止自动执行，用户入口要给出清楚状态，管理员要知道先恢复哪条链路。事故期间不要临时放宽权限或绕过审计，否则恢复了服务，却留下更大的安全问题。
日常巡检还要关注用户侧信号。用户频繁重试、不断改写同一个问题、复制答案后又大量人工修改、在某类文档上集中给差评，往往比机器指标更早暴露质量问题。私有化 AI 不应只由运维团队看机器，也要让产品、业务和安全人员看到可读的质量摘要：哪些知识库最常出错，哪些工具最常失败，哪些模型成本异常，哪些场景需要补人工流程和业务培训。
生产级私有化 AI 的成熟标志，是团队不害怕变化。因为每次变化都有评测、灰度、日志、回滚和恢复路径。模型可以升级，硬件可以扩容，知识库可以重建，工具可以增加，但系统责任边界始终清楚。
结语
私有化 AI 部署的难点不是把模型跑起来，而是把模型放进一个可控、可审计、可恢复、可持续演进的系统。内网解决数据路径，GPU 解决推理能力，权限解决谁能做什么，日志解决如何解释，备份解决如何回来，合规检查解决如何证明。少任何一环，系统都只能算实验环境。
真正稳的路线是从一个真实业务闭环开始，把数据、权限、模型、工具、日志和恢复做完整，再逐步扩大场景和规模。这样建设出来的私有化 AI，不只是“在本地回答问题”，而是企业内部可以长期使用的智能基础设施。
参考资料
- Kubernetes RBAC 官方文档：https://kubernetes.io/docs/reference/access-authn-authz/rbac/
- Kubernetes NetworkPolicy 官方文档：https://kubernetes.io/docs/concepts/services-networking/network-policies/
- Kubernetes Pod Security Admission 官方文档：https://kubernetes.io/docs/concepts/security/pod-security-admission/
- NVIDIA GPU Operator 官方文档：https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/
- NVIDIA Multi-Instance GPU User Guide：https://docs.nvidia.com/datacenter/tesla/pdf/MIG_User_Guide.pdf
- vLLM OpenAI-Compatible Server 文档：https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html
- vLLM Online Serving 文档：https://docs.vllm.ai/en/latest/serving/online_serving/
- KServe LLMInferenceService 文档：https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview
- KServe Envoy AI Gateway 集成文档：https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-envoy-ai-gateway
- Hugging Face Text Generation Inference 文档：https://huggingface.co/docs/text-generation-inference/main/en/index
- llama-cpp-python OpenAI Compatible Server 文档：https://llama-cpp-python.readthedocs.io/en/latest/server/
- OpenTelemetry 官方介绍：https://opentelemetry.io/docs/what-is-opentelemetry/
- Grafana Loki 官方文档：https://grafana.com/docs/loki/latest/
- restic 恢复文档：https://restic.readthedocs.io/en/v0.17.2/050_restore.html
- NIST AI Risk Management Framework 1.0：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf