私有化部署与合规交付

• 纯软件包、一体机、混合云三种形态的部署方式与适用场景
• 三者在成本、性能、运维、灵活性上的取舍
• 按客户规模与需求选择形态的方法

三种形态各有取舍。纯软件包（Ollama/vLLM/llama.cpp）：在客户已有 GPU 服务器上部署开源推理框架，成本低、灵活，但需要客户自备硬件、依赖客户运维能力，适合已有 GPU 且技术能力强的客户，也适合快速适配多芯片。一体机（DGX/HGX）：预置硬件+软件+推理服务的整机交付，开箱即用、性能稳定、运维简单，适合对性能与稳定性要求高、不愿自建的环境，但成本高、扩展不灵活。混合云：公有云+私有化结合，核心数据/敏感部分留私有，弹性部分走云端（或公有云 GPU 与本地混合），兼顾数据不出域与弹性算力，适合数据合规要求高又有弹性需求的场景。取舍的关键维度：预算、已有硬件、算力需求、运维能力、合规要求。一般原则：有硬件者选软件包，追求稳定开箱选一体机，既要合规又要弹性选混合云。

部署形态的选择本质是"成本、性能、运维、合规"的权衡。纯软件包最灵活但责任在客户，一体机最省心但贵，混合云兼顾合规与弹性但架构复杂。选型要结合客户实际情况，避免"一刀切"。性能上 vLLM 吞吐高、llama.cpp 面向边缘/CPU、Ollama 易用，按场景选推理框架。

• 各模型在通用能力、推理、代码、多模态上的差异
• 中文能力与领域适配（中文理解、生成质量）
• 工具链（推理框架、微调、量化、生态）与合规（许可证、商用）支持

国产开源模型选型需从四维评估。能力：Qwen（通义千问）系列尺寸全、通用与多模态强，DeepSeek 推理与代码能力突出（尤其是 DeepSeek-R1 系列）、开源权重友好，GLM（智谱）中文与工具调用均衡，Baichuan、Hunyuan（腾讯混元）各有侧重，需按任务（通用/推理/代码/多模态）选。中文：国产模型中文理解普遍优于国外开源模型，细粒度中文（古文、方言、专有领域）需评测，Qwen、GLM 中文表现稳。工具链：看推理框架兼容（vLLM、SGLang、TensorRT-LLM）、微调支持（LoRA/全参）、量化（AWQ/GPTQ）、部署生态与国产芯片适配（昇腾/寒武纪）。合规生态：许可证（是否允许商用、衍生品义务）、数据合规、生态成熟度（社区、文档、示例）。选型方法是按实际评测集打分，而非只看 benchmark。

国产模型选型的核心是"按场景评测 + 生态可用性"。单纯性能对标不够，要结合私有化部署的推理框架兼容、国产芯片适配、许可证商用条款。中文场景国产模型通常占优，推理/代码场景 DeepSeek 突出。选型要建立自己的评测集，验证能力、稳定性、部署成本。

• 各模型开源许可证类型（Apache 2.0、MIT、自定义）与商用条款
• 衍生作品（微调、蒸馏）的义务与再分发限制
• 私有化交付中的许可证合规要点

模型许可证合规决定了"能否商用、能否改、能否再分发给客户"。Qwen 系列采用 Apache 2.0 许可证（大部分版本），允许商用、修改、再分发，衍生作品需保留许可证声明；DeepSeek 采用 MIT 许可证（大部分模型），宽松、允许商用与再分发，但需注意部分版本（如 DeepSeek-R1 蒸馏版）可能有附加条款；GLM（智谱）不同版本许可证不同，早期 GLM-130B 有自定义条款，ChatGLM 系列商用与再分发需核对具体版本的 License 条款，部分版本要求遵循其附加限制。关键合规点：核对每个模型的具体版本许可证（不能只看系列名）；理解衍生作品义务——微调/蒸馏出的模型是否需开源、是否保留原许可证声明；再分发限制——把模型打包进私有化交付再分发给客户时，是否允许、是否需附带原文与条款。商用前需法务确认，遵循"许可证版本化、逐版本核对"原则。

许可证合规是私有化交付的"法律红线"，不同版本的许可证条款可能不同。Qwen(Apache 2.0)、DeepSeek(MIT) 相对宽松，GLM 等需逐版本核对。衍生作品（微调/蒸馏）与再分发（交付客户）是最高风险点，需明确义务并保留合规记录。商用前必须走法务/合规确认。

• 交付物组成：模型权重、推理服务、数据、配置、运维脚本
• 交付物如何打包、版本化与安装
• 升级与回滚的打包策略

私有化交付清单把"能跑起来的完整系统"打包，包含五类：模型——模型权重（含量化版）、模型配置与许可证文件；推理服务——推理框架（vLLM/Ollama/Triton）及其镜像/二进制、服务配置、启动脚本；数据——初始化数据、向量库索引、示例配置、种子知识库；运维——部署脚本、监控告警配置、健康检查、日志与升级/回滚脚本、运维手册；升级——版本化升级包、数据库迁移脚本、兼容性说明。清单要版本化（一个版本号对应一套可复现组合），安装可用 Docker/K8s 镜像或离线安装包一键化，交付手册说明环境依赖（GPU 型号、驱动、CUDA）。升级要打包"增量升级包"与"回滚包"，保证升级可回退。每个交付物需有哈希校验与签名，确保完整性。

交付清单的核心是"可复现、可安装、可运维、可升级"。把模型、服务、数据、配置、脚本打包成版本化制品，保证客户环境一键部署且与测试环境一致。升级回滚是私有化交付的生命线，必须打包完整。哈希/签名防篡改，离线交付保证安全。

• air-gapped 环境下的介质传递（U盘/光盘/专线）与流转
• 模型权重、依赖镜像、升级包的打包与校验
• 哈希与数字签名校验流程，防篡改与防伪造

air-gapped 环境与外部网络隔离，交付物只能通过受控介质（加密 U 盘、光盘、专线拷贝）传递。设计要点：给出交付物清单（模型权重、依赖镜像、升级包、配置），每个文件计算 SHA-256 哈希并签发数字签名（用公司私钥对哈希签名），提前把公钥与校验工具传给客户。客户侧导入流程：核对清单 → 校验每个文件哈希 → 用公钥验签确认来源可信 → 导入镜像与模型 → 启动前校验运行时完整性。签名用非对称加密（私钥签名、公钥验签），防止介质被篡改（哈希不一致）或伪造来源（签名不合法）。升级包同样走哈希+签名校验，且升级前校验当前版本与升级包兼容性。整个流程记录审计，保证"谁、何时、导入什么、校验结果"可追溯。

air-gapped 交付的核心是"在无网络下保证完整与可信"。哈希校验保证"没被改"，数字签名保证"来源可信"，二者结合防篡改防伪造。介质传递要受控、加密，传递过程留痕。校验在导入前强制进行，避免木马或损坏文件进入生产环境。这是安全合规的关键环节。

• 在客户真实数据上构建评测集（而非演示集）
• 建立基线（baseline）与验收标准，避免过拟合
• 验收争议的防范（评测口径透明、样本抽样、人工复核）

客户侧验收评测要避免"演示集过拟合"（在自造/演示数据上表现好但真实数据不行）。方法：用客户真实数据构建评测集，覆盖真实业务场景、边界与长尾，样本由客户参与确认，保证代表性；建立基线——先定义"什么算通过"的量化标准（如 Faithfulness、答案准确率、命中率阈值），并可与客户既有流程/人工结果做对比基线，避免主观争议。为避免过拟合，评测集要分"训练/验证/测试"思维，系统在测试集上验收，且测试集不在调参过程中泄露。验收争议防范：评测口径透明公开（指标定义、样本、评分标准事先书面化），用抽样+人工复核（专家抽评与自动指标结合），争议样本由双方共同裁定，并保留评测记录（样本、结果、版本）可追溯可复现。

验收评测的本质是"用客户真实数据、透明的标准、可复现的方法"衡量系统价值。演示集过拟合是常见陷阱，必须用真实数据+分集验证。争议防范靠"事先约定口径、抽样人工复核、记录可追溯"。建立基线让验收从"感觉好不好"变成"是否达标"。

• air-gapped 部署的网络隔离与数据流转
• 离线模型更新的介质与校验挑战
• 向量库迁移（数据、索引、版本）的工程难点

私有化网络隔离的三大挑战：air-gapped 部署——环境与外网隔离，所有依赖（模型、镜像、依赖包）需提前打包走受控介质传递，且内部无外网拉取，需自建内网镜像源，部署要在隔离环境内完成，无法在线调试；离线模型更新——新模型权重无法在线下载，需通过介质传递，更新时要校验哈希/签名、评估新旧模型兼容性（输出格式、参数），并支持灰度与回滚，更新的安全与合规要求高；向量库迁移——私有化交付时需把向量数据（索引、文档、元数据）从开发环境迁移到客户环境，向量库版本差异可能造成索引不兼容，需重新建索引或版本对齐，迁移要保证数据完整性（哈希校验、断点续传）与一致性（迁移后检索结果与源一致）。这些挑战的共同点是"隔离环境下的完整性与一致性"。

网络隔离的难点在于"无网络依赖下的可运维性"。air-gapped 需自包含交付与内网镜像源；离线更新需校验、兼容与回滚；向量库迁移需版本对齐与数据校验。工程上要提前规划"离线制品库"与"迁移/校验工具"，把隔离环境的一次性交付做成可重复的流程。

• 模型与国产/信创 GPU 的兼容性验证（算子、框架、精度）
• 性能压测的指标（吞吐、延迟、并发、显存）与方法
• 兼容与压测的自动化与报告

私有化/信创环境（昇腾、寒武纪、海光、天数等）的模型兼容与压测需专门设计。兼容性验证：确认模型算子与推理框架（vLLM、MindIE、Triton）在目标 GPU 上的支持，验证 FP16/INT8/INT4 量化是否可用、精度是否有损（与 x86 参考对比输出差异），处理算子缺失/降级问题；用代表性 prompt 集做正确性回归。性能压测：用压测工具（如 vLLM benchmark、自研脚本）模拟并发请求，测 TTFT（首 token 延迟）、吞吐（tokens/sec）、端到端延迟、并发上限、显存占用，找出瓶颈（是算力、显存、还是带宽/框架开销），并压测到资源饱和看稳定性。压测要覆盖真实负载模型（请求长度、并发分布），并形成报告（指标、环境、结论、优化建议）。压测还要在客户目标硬件上做，而非只在开发机。

信创硬件兼容的难点是"算子/框架支持不齐、精度差异"，需逐模型验证并做精度回归。性能压测要贴近真实负载、测透资源边界、定位瓶颈。兼容与压测都要在客户目标硬件上做，避免"开发环境跑得动、客户环境跑不动"。报告要量化、可复现。

• License（授权）与订阅的机制（按节点/按用量/按期限）
• 授权校验与防滥用（离线授权、机器指纹）
• 安全审计：日志保护与模型文件保护（防泄露）

私有化交付的 License 与订阅设计：授权模式可按节点数、期限、或按用量（QPS/token）计费，离线授权用"机器指纹+签名"绑定到客户硬件，防止跨机复制；订阅含版本更新与技术支持，到期后降级或停服。授权校验需防绕过：授权文件带签名、绑定硬件指纹、加密存储，启动时校验，校验失败降级或拒绝。安全审计：日志保护——访问日志、操作日志加密存储、防篡改（审计日志哈希链），日志脱敏避免泄露敏感信息，日志分权限访问；模型文件保护——模型权重是核心资产，需加密存储、防止被拷贝，运行时解密，可加指纹/水印，限制文件权限与访问，防止模型文件被窃取导出。审计要覆盖"谁、何时、做了什么、授权是否合法、模型是否被访问"。

License 与审计是私有化交付的"商业与安全闭环"。License 保证商业化回报（防滥用），审计保证可追溯与合规（防泄露）。核心是"离线授权防复制 + 日志模型防泄露"。模型文件保护要防导出，授权要防绕过，审计要不可篡改。三者都以"加密+签名+权限"为技术底座。

• 安装部署验收项（环境、服务、依赖）
• 数据初始化验收项（数据导入、索引、一致性）
• 性能压测与安全基线的验收项

私有化交付验收清单需覆盖四类。安装部署：环境依赖（GPU 驱动、CUDA、OS、网络）就绪、推理服务与网关/应用服务启动正常、健康检查通过、依赖组件（向量库、消息队列）可用、集群与高可用配置生效。数据初始化：数据导入完整（数量与源一致）、向量索引构建完成、检索结果与预期一致、元数据与权限正确、初始化脚本可复现。性能压测：在目标硬件上跑基准，TTFT、吞吐、并发、P95 延迟达到约定 SLA、长时间稳定性（无内存泄漏/崩溃）、资源（显存/CPU）占用合理。安全基线：数据加密（静态/传输）、登录认证与权限、网络隔离、审计日志开启、漏洞扫描通过、模型文件保护好。验收清单要逐项可勾选、有证据（报告/日志/截图），双方签字确认。

验收清单是"把交付承诺变成可验证的检查项"。重点是"可验证、有证据、双方确认"。安装与数据保证"能跑起来"，性能保证"达标"，安全保证"合规"。清单要具体（有阈值、有命令/报告），避免模糊表述导致验收争议。逐项留痕供后续审计。

• 性能基准（TTFT、吞吐、并发）的 SLA 定义与测量
• 稳定性压测（长时间、高并发、故障恢复）的验收
• 安全基线写入验收流程的方式

把性能/稳定性/安全写入交付清单与验收流程，本质是把 SLA 量化成"可测、可验收"的条款。性能基准：定义 TTFT（首 token 延迟）、吞吐（tokens/sec）、并发能力、P95 延迟的具体目标值，明确测试环境（硬件、模型、负载模型）与测量方法，验收时在客户硬件上复测并与 SLA 对比。稳定性压测：定义长时间运行（如 7×24）、高并发、故障注入（断网、kill 进程、重启）的测试场景，验证恢复能力与无崩溃，SLA 里写"可用性 ≥ X%、故障恢复时间 ≤ Y"。安全基线：把数据加密、认证授权、审计、漏洞扫描等安全项写成验收门槛，不达标则不通过。验收流程把这些做成"检查项+证据+阈值"，双方按流程逐项确认，SLA 违约有明确判定与责任。

验收与 SLA 的关键是"把模糊承诺变成可测量的阈值"。性能基准要定义环境与方法，否则争议；稳定性要加故障场景，验证真可用；安全要设门槛。所有条款写入交付文档，验收按流程执行并留证据，SLA 违约有判定标准。这样避免"验收靠感觉"。

• 内网部署下远程诊断的通道（VPN/SSH/代理）与安全
• 日志回传的设计（脱敏、加密、按需）
• 远程与现场支持的分工与流程

内网部署的远程运维通道设计要兼顾"可运维"与"安全"。远程诊断：通过客户授权的 VPN/专线、跳板机（bastion）或反向代理建立受控通道，运维人员经多因素认证+审计登录诊断，权限最小化（只读诊断优先），操作留痕。日志回传：日志经脱敏（去 PII/敏感）后加密回传，按需、按范围回传（不全量），可自建内网日志中心+定时导出，或经批准的通道推送到云端分析，回传链路加密、可审计。远程与现场分工：常规监控、告警处理、配置调整、远程诊断由远程支持完成；硬件故障、网络物理隔离、断电、需要现场操作的安全类操作由现场工程师处理；远程先诊断定位，需要物理操作时派现场。流程上明确"远程能做什么、什么必须现场"的边界，所有远程操作有审批与审计。

远程运维的难点是"既要能远程修，又不能因远程造成安全风险"。受控通道+最小权限+审计保证安全，脱敏加密回传保证合规，明确分工保证效率。关键是"边界清晰"：远程处理软件问题，现场处理物理问题，安全敏感操作走审批。全程审计是可追溯的保障。

• 各国产芯片（昇腾、海光、寒武纪、天数）的生态与支持现状
• 推理框架与国产芯片的适配（算子库、Triton、MindIE）
• 全栈信创（OS、数据库、中间件）下的集成适配

信创全栈下 LLM 推理适配的现状是"生态逐步成熟但仍需专门适配"。昇腾（华为）：通过 CANN 算子库与 MindIE 框架适配主流模型（Qwen、DeepSeek、GLM），生态较完善，支持 vLLM 的昇腾后端；海光（DCU）：基于 ROCm 兼容，通过补齐算子适配 vLLM/DeepSeek 等，生态在完善；寒武纪（MLU）：通过 Cambricon 算子库与专用推理框架适配，支持常用模型；天数智芯（Iluvatar）：通过自研算子库适配，生态相对早期。共性：国产芯片的算子库覆盖度、精度（FP16/BF16/INT8）、性能与 N 卡有差距，需针对模型做算子补齐与精度回归。全栈信创还涉及国产 OS（麒麟/UOS）、国产数据库（PolarDB/达梦等）与中间件，需验证推理服务、网关、向量库在国产 OS 上的兼容与性能。适配要"逐模型、逐算子验证 + 性能压测 + 精度回归"。

信创适配的现状是"能跑但需逐项适配"。关键在算子库覆盖度、精度一致性、性能与框架兼容。不同芯片生态成熟度不同，昇腾相对完善，其他需更多适配。全栈信创不只是 GPU，还包括 OS/数据库，需全链路验证。适配成本高，需按客户信创要求评估投入。

• 许可证（商用、再分发）对私有化的影响
• 数据合规（数据不出域、训练数据、隐私）
• 定制能力（微调、领域适配、工具链）的评估

私有化模型选择需从三方面评估。许可证：模型是否允许商用、微调、再分发给客户（私有化交付常涉及再分发），许可证条款是否满足交付场景，避免法律风险。数据合规：模型训练数据是否含敏感/版权问题、部署后数据是否满足"数据不出域"、数据的处理与留存是否符合客户合规要求（GDPR/等保/行业监管），模型本身是否涉及数据驻留约束。定制能力：模型能否微调（LoRA/全参）、领域适配能力（专有术语、行业知识）、工具链（train/推理/量化）是否成熟、是否支持国产化部署（芯片/OS），以及定制的成本与效果。评估方法：按许可证逐条核对、做合规审查、用行业数据评测定制能力，综合打分选出"合规+可定制+可部署"的模型。

私有化模型选择的本质是"合规可行 + 能力匹配 + 可定制可部署"。许可证决定能否商用再分发，数据合规决定能否过审，定制能力决定能否贴合业务。三者缺一不可，且都要落到实际评测与法务确认，而非只看 benchmark。多因素综合才能避免交付后踩坑。

• 模型版本管理（版本、灰度、兼容性）
• 监控告警（GPU、服务、延迟、错误）
• 升级回滚（灰度、回滚预案、一致性）

私有化交付的运维管理围绕"版本、监控、升级"三块。模型版本：每个模型版本有记录（权重、配置、评测结果、兼容性），支持多版本并存与灰度切换，版本间兼容性（输出格式、tokenizer）需评估，避免切换后行为突变。监控告警：监控 GPU（利用率、显存、温度）、推理服务（延迟、吞吐、错误率）、网关（QPS、限流）、数据组件（向量库、队列），设置阈值告警，异常能定位到服务与模型。升级回滚：升级走灰度（先小流量/小节点），验证后全量；升级保留回滚预案与旧版本快照，失败可一键回滚；升级涉及模型、服务、数据多组件时，保证一致性（同版本号），避免"模型升级了但索引没更新"。运维要有手册、告警响应 SLA 与定期演练。

私有化运维的核心是"版本可控、状态可见、升级可回退"。多版本+灰度降低切换风险，监控告警保证可观测，回滚预案保证可恢复。难点是"模型/服务/数据多组件的一致性"——升级要联动，回滚要整体回退。运维是私有化交付的长期价值，需规范化。

• 显存规模估算（模型权重、KV cache、激活、batching）
• 单机/多机吞吐的估算与扩展（tensor/pipeline 并行）
• 性能瓶颈定位（算力、显存、带宽、框架）

私有化性能估算需覆盖显存与吞吐。显存估算：模型权重显存（参数量 × 每参数字节，如 70B FP16 ≈ 140GB）+ KV cache（随并发与生成长度增长）+ 激活/中间显存 + 框架开销，多并发时 KV cache 是主要增量，需按"并发数×平均生成长度×每 token KV 大小"估算。吞吐估算：单机受算力（FLOPS）与显存带宽限制，实际吞吐用"总 token 数/时间"衡量，受 batch size、生成长度、模型大小影响；多机用张量并行（单模型分拆多卡）或流水线并行（分层）扩展，吞吐随卡数增长但受通信/负载不均限制，不是线性。瓶颈定位：先看是否显存不足（OOM/低 batch），再看是否算力饱和（GPU 利用率高但吞吐低→算力是瓶颈）、带宽瓶颈（显存带宽高时读权重慢）、通信瓶颈（多卡时互联带宽）、框架开销（prefill/decode 分离、量化）。用 profiling 工具（如 nsight、vLLM 统计）定位。

性能估算的关键是"算清显存与吞吐的构成"。显存主要看权重+KV cache（随并发），吞吐看算力与带宽，多机扩展看通信开销。瓶颈定位要区分"算力、显存、带宽、通信、框架"五类，用探测工具实测。估算要结合真实负载（并发、生成长度），避免拍脑袋。

• 私有化与 SaaS 的本质区别（数据与算力部署位置）
• "数据不出域"的界定（数据、日志、模型、密钥）
• 满足数据不出域的实施层面（部署、加密、传输、审计）

私有化与 SaaS 的边界核心是"数据与算力在哪里"。SaaS 由厂商统一部署在云端，客户数据进入厂商云，合规性靠厂商承诺；私有化把系统部署在客户环境（内网/VPC），数据、模型、推理、日志都在客户域内，满足"数据不出域"。数据不出域的界定：不仅指业务数据，还包括日志、trace、模型输入输出、密钥、配置，都不能出客户域；向量库、缓存、监控数据也须在域内。满足的实施层面：系统（推理、网关、向量库、应用）全部部署在客户域内；存储与传输加密；日志/监控本地化，不外传（或经脱敏审批后回传）；密钥本地管理；模型文件部署在客户环境；出口通道（如远程运维）受控、脱敏、审计。边界上要明确"什么数据绝对不出域、什么可经批准出域"，写入合同与合规条款。

私有化与 SaaS 的边界本质是"数据驻留与算力归属"。私有化是为了满足"数据不出域"的强合规要求。关键是"不出域"要覆盖全链路（数据、日志、模型、密钥、监控），且实施上要真正做到（部署、加密、本地化、受控出口）。边界要书面化，避免"以为不出域实际泄露"。

• GPU 监控（利用率、显存、温度、功耗）与告警
• 模型更新的流程（灰度、兼容性、验证）
• 模型回滚的预案与一致性

私有化运维的 GPU 监控：监控 GPU 利用率、显存占用、温度、功耗、显存带宽、错误（如 ECC 错误），设置告警阈值（显存接近上限、温度过高、利用率异常），关联到服务指标（延迟升高是否因 GPU 饱和），异常能定位是哪张卡/哪个服务。模型更新流程：先评估模型兼容性（输入输出格式、tokenizer、量化），在灰度节点/小流量上发布新模型，用评测集验证质量与性能，达标后全量；更新记录版本。模型回滚预案：保留旧模型快照与配置，更新失败或质量下降时一键回滚到旧版本；回滚要保证一致性（模型、服务配置、相关索引/缓存一起回退），避免"模型回滚了但其他组件还是新版"。整个更新与回滚有审计与演练。

私有化运维的 GPU 监控保证"看得见状态"，模型更新走灰度验证与回滚预案，保证多组件一致。

• 模型版本升级的灰度（小流量、小节点、验证）
• 升级失败的回滚预案
• 升级伴随的数据迁移（向量库/缓存重建或兼容）

私有化模型更新的核心是"灰度、回滚、数据迁移"三件事。灰度：先在一个小节点/小流量上发新模型，用评测集与监控验证质量、延迟、错误率，达标后再逐步放量到全量，避免大爆炸式升级。回滚：保留旧模型快照与配置，一旦发现质量下降或异常，一键回滚到旧版本；回滚要整体一致（服务配置、参数一起恢复）。数据迁移：升级模型若涉及 embedding 模型或 tokenizer 变化，向量库索引可能不兼容——需重建索引（用新 embedding 重算）或迁移向量库数据，同时缓存（语义缓存、问答缓存）需失效或重建，避免旧 embedding 的向量与新模型不匹配。迁移要校验数据完整性（哈希、数量、检索结果），并支持回滚时恢复旧索引。灰度/回滚/迁移用版本化流程驱动，保证一致性。

模型升级不只是换权重，还牵动 embedding、向量库、缓存等数据层。升级要"灰度控制风险、回滚保底、数据迁移保一致"。难点在"模型升级与数据索引的联动"——embedding 变了要重建索引，缓存要失效。三者都要版本化、可回退，避免升级后检索错乱。

• 显存/算力隔离（多实例、GPU 分区、共享调度）
• 队列隔离（独立队列、优先级、公平）
• 数据隔离与配额管理（按部门限额、超限控制）

多部门共用私有化集群需做资源隔离与配额管理。显存/算力隔离：为每个部门部署独立模型实例（多实例部署，隔离显存与故障域），或用 GPU 分区/共享调度（如 MIG、K8s 资源配额）按部门分配 GPU 份额，防止一个部门占满显存拖垮其他部门；也可用推理框架的并发/速率限制按部门限流。队列隔离：为每个部门配置独立队列或按权重/优先级调度，保证高优先级部门不被排队挤占，低优先级部门不饿死高优先级；公平调度（权重、轮询）平衡多部门。数据隔离：按部门隔离向量库 namespace、数据目录、密钥与权限，防止跨部门检索与访问。配额管理：按部门设置显存、并发、QPS、token 预算等配额，超限时降级/拒绝/告警，配额可配置、可审计。目标是"隔离透明、公平分配、配额可控、数据隔离"。

多租户资源隔离是"资源隔离 + 数据隔离 + 配额管理"三合一。显存隔离防资源抢占，队列隔离保公平调度，数据隔离防越权，配额管理控总量。难点是"共享与隔离的平衡"——既要提高集群利用率（共享），又要保证隔离（不互相影响）。用实例隔离+调度配额+数据 namespace 组合实现。