一、项目背景

某政务单位希望在内网环境部署一套大模型能力，用于面向工作人员的政策问答与制度检索。这个项目从第一天起就不是"能不能跑起来"的问题，而是"能不能合规地跑起来"。硬性约束有两条：一是数据绝对不出域，推理与语料必须全部落在政务内网，任何模型权重、知识文档、对话日志都不能触达公网；二是必须满足等保合规要求，覆盖身份鉴别、访问控制、安全审计、数据完整性与保密性。我们采用的新普 AI 私有化部署底座，交付形态正是面向这类内网与信创场景设计的，但这只是起点，真正的工程量在后面的适配与隔离。

政务客户和一般企业客户的差别在于：他们不能接受"先上线再看合规报告"，而是合规前置、验收驱动。这意味着底座的每一个组件——从推理引擎到向量库到网关——都要能说清数据落在哪、谁能访问、访问留痕了吗。我们在立项会上就和客户的安全合规团队对齐了等保条款，把每条要求映射到一个技术控制点，避免后期返工补洞。

二、落地场景

落地形态是私有云集群部署，整体不连公网。底座跑在政务专有云上，模型服务化层用 vLLM 做推理，向量库层承载内部制度文档的切片向量，RAG 层把"政策问答"做成"检索内部文档后作答"的可溯源链路。场景上有多个业务部门共用同一套底座：法规处、办公室、信息中心各有自己的知识库与问答空间，但彼此语料不能串。AI 网关在接入层做统一鉴权与租户识别，底座在数据存储层做物理或逻辑隔离，上层应用只看到自己那一份数据。

除问答外，该单位还把底座用于内部制度检索辅助与文档摘要，输入端同样是受控内网终端。所有流量不出专有云边界，模型权重与知识库均在本集群内完成加载与更新，外部只通过离线介质做合规的版本交付，从物理上杜绝了数据外泄路径。

三、关键技术挑战与解决思路

信创环境适配是第一道坎。客户要求国产 CPU（ARM 架构一类）、国产 GPU 加速卡与国产操作系统，而 vLLM 等推理框架对通用加速生态依赖较深。我们的策略是先做最小可用验证：挑一台信创节点，用兼容层跑通单模型推理，确认算子覆盖与精度达标后再谈规模。监控用 Prometheus 加 Grafana 补齐算力侧可观测，避免"黑盒跑推理"。

# 信创验证节点（示意）
node:
  arch: aarch64            # 国产 CPU
  os: 国产OS               # 国产操作系统
  accelerator: 国产GPU
inference:
  engine: vllm
  backend: 兼容层          # 适配国产加速栈
  tensor_parallel: 2
  max_num_seqs: 64         # 连续批处理上限
monitor:
  - prometheus
  - grafana

验证阶段我们建立了一张算子覆盖矩阵，逐条记录算子是否原生支持、是否需要兼容实现、精度误差区间，只有矩阵全绿才进入扩容，这也是后面能一次性通过审计的基础。

案例片段（已脱敏）：某政务单位信创环境首轮验证覆盖约 12 个核心算子，其中 2 个算子需走兼容实现，精度差异控制在千分之一内，验证周期约 9 个工作日。

多租户数据隔离是合规核心。我们在 AI 网关层按部门划分租户并完成身份与配额隔离，在底座数据层用向量库的 namespace 或 collection 做语料强隔离：每个部门对应独立 collection，跨 collection 检索在路由层就被拒绝。下面是我们采用的 pgvector 划分配置示意：

# 向量库多租户隔离（pgvector 示意）
tenants:
  - dept: 法规处
    collection: vec_fagui
    schema: "embedding vector(1024), doc_id uuid, dept_id text"
    policy: "ROW LEVEL SECURITY ON dept_id = current_tenant()"
  - dept: 办公室
    collection: vec_office
    schema: "embedding vector(1024), doc_id uuid, dept_id text"
    policy: "ROW LEVEL SECURITY ON dept_id = current_tenant()"
routing:
  deny_cross_collection: true   # 网关拒绝跨租户检索

这里的关键是"两层隔离都要硬"：网关层做租户身份与路由隔离，底座层用行级安全策略兜底，即便有人绕开网关直连数据库，也看不到别人的语料，故障域按部门天然切分。

审计与可观测必须满足等保。所有推理调用经网关统一计量与留痕，调用方、模型、token、耗时、返回摘要全部入审计库；知识库检索命中哪些文档也一并记录，保证"答有所据、查有所踪"。Grafana 看板覆盖吞吐、延迟、GPU 利用率与异常率，安全事件可回溯。我们还把审计日志做了防篡改哈希链，确保合规检查时可证实未被事后改写。

案例片段（已脱敏）：某政务单位上线后，合规审计一次性通过；审计周期内共沉淀调用留痕约 38 万条，未出现跨租户访问告警，隔离故障域数按部门切分为 3 个互不影响的命名空间。

四、效果数据

上述为脱敏示意值，用以呈现量级与趋势，不作为审计结论。实际验收中，等保测评机构对该底座的网络边界、访问控制与审计三项均给出符合项。

五、可复用经验总结

隔离要在网关做租户、在底座做数据，两层都要硬，不能只靠应用自觉。网关解决"你是谁、能访问哪个空间"，底座解决"数据物理或逻辑上不串"，两者叠加才是政务级合规的底线。另一条铁律是先信创验证再放量：不要在没跑通最小可用之前就铺开集群，否则兼容问题会被规模放大成事故。最后，政务项目的可审计性不是附加项，而是入场券——把计量、留痕、可观测在设计阶段就接进去，比上线后补日志省力得多。这套"网关租户隔离 + 底座数据隔离 + 先验证后放量"的方法，已在新普底座的其他内网项目里复用。