一、项目背景

去年我们接了一个典型的金融内网场景：某股份制银行希望在完全离线、数据不落公网的环境下，搭建一套大模型私有化底座，主要服务两类内部业务——一是面向行内员工的知识问答（制度、流程、产品口径的快速检索与解释），二是研报摘要与风控材料的自动提炼。

硬约束非常明确，也几乎是所有持牌金融机构上大模型的共性红线：第一，数据不出域，训练语料、检索知识、推理输入输出全程留在内网，不能有任何外发通道；第二，等保合规，平台要满足行内安全基线，包括访问审计、权限最小化、传输加密；第三，多业务域共享算力但数据隔离，零售、对公、风控、合规等不同条线要共用一套 GPU 底座以摊薄成本，但彼此的私有语料、索引、调用链路必须严格互不越界。

银行原有技术栈以 X86 私有云为主，但信创改造目标已经写入年度规划。所以我们从第一天起就把底座设计为"一体机可交付、私有云可扩展、信创可适配"的三种形态并存，避免后期推倒重来。

二、落地场景

这个项目里，底座以三层形态落地：

1. 推理一体机做快速验证：先交付两台推理一体机，内置我们采用的推理框架栈（vLLM 类推理引擎 + 向量数据库 + RAG 流水线），在隔离网段内跑通知识问答最小闭环，约三周完成首版可用。
2. 私有云集群做规模化：验证通过后，把同一套底座镜像化部署到行内私有云 Kubernetes 集群，横向扩展到多张 GPU 卡，支撑全行多部门并发。
3. RAG 接内部研报与制度文档：底座的 RAG 知识库层对接行内文档中台，把研报、信贷政策、内控手册做解析切片与向量化，对外提供检索增强问答。

最关键的诉求是多部门共用一套底座但语料互不越界。比如零售条线的产品话术库、对公条线的授信模板、合规条线的监管文件，都属于不同"租户"，在底层就做了逻辑隔离，任何一个租户的检索结果和推理上下文，都不能跨域泄漏。

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

① 数据不出域的部署形态

我们把所有模型权重、embedding 模型、知识库全部打包进内网镜像仓库，交付过程是"离线介质 + 内网镜像同步"，整个推理链路没有任何出网调用。针对信创适配，我们用了国产 CPU/OS 组合做了兼容性验证，重点解决推理框架在国产 GPU 上的算子支持度、算子精度回退、以及驱动版本锁定的问题——先在一台信创节点上跑通单卡推理，再逐步放大。

② 多租户在底座层的隔离

我们的隔离原则是"在网关做租户、在底座做数据"。网关层按部门/应用号识别租户身份并完成鉴权与配额；底座层则把数据隔离做实：向量库按租户划分独立的 namespace（或 collection），每个 namespace 配置独立的访问凭证和行级路由；推理实例按业务域分组，不同租户默认路由到不同推理实例池，避免上下文串扰；再叠加 Kubernetes NetworkPolicy，把数据库、推理服务、网关之间的东西向流量按命名空间做白名单管控。这样即使某个租户实例被攻破，也拿不到其他租户的数据平面。

③ 算力调度与配额

金融场景的 GPU 是宝贵资源，我们做了 GPU 池化：多个推理实例以 MIG/时间片方式共享同一张卡，同时保留关键业务独占卡的能力。任务层面引入排队与优先级队列，闲时把低优先级批处理（如研报摘要批量任务）填进去，忙时优先保障在线问答。弹性扩缩则根据网关的限流信号反向驱动——当某租户 QPS 抬升，底座按预设阈值扩容推理副本。

④ 审计与可观测

等保要求的"谁、在什么时间、调了什么模型、喂了什么数据"必须可回溯。我们在网关层落全量调用留痕（脱敏后的用户标识、租户、模型、耗时、token），底座层用 Prometheus + Grafana 采集吞吐量、首 token 延迟、GPU 利用率、队列深度，并通过告警规则联动扩容。所有日志不落公网，统一归集到行内日志平台。

案例片段（已脱敏）：多租户向量库 namespace 划分与资源配额配置（节选）。yaml tenants:  - id: retail      # 零售条线    milvus_namespace: ns_retail    cred: "***"      # 独立访问凭证    inference_pool: pool-retail    quota:      gpu_mig_slice: 1      max_qps: 20      daily_tokens: 2000000  - id: corp        # 对公条线    milvus_namespace: ns_corp    cred: "***"    inference_pool: pool-corp    quota:      gpu_mig_slice: 1      max_qps: 15      daily_tokens: 1500000 networkPolicy:  denyEastWestByDefault: true  allow:    - from: [gateway-ns]      to: [ns_retail, ns_corp]

四、效果数据

数据是脱敏示意值，但结构和量级真实：

• 从一体机到私有云全量上线，部署周期约 6 周（含信创单卡验证 1 周、私有云扩容 2 周）。
• 在线问答峰值 吞吐量约 80 QPS，P95 首 token 延迟控制在 1.2 秒以内。
• 通过 namespace + 推理实例分组 + 网络策略，划分出 4 个独立故障域/数据域，任一租户异常不影响其他条线。
• 等保合规审计 一次性通过，调用留痕完整度 100%，无外发流量记录。
• GPU 利用率从独占模式下的平均 35% 提升到池化后的 约 68%，批量摘要任务闲时填充使闲置算力下降明显。

五、可复用经验总结

这个项目沉淀下来几条，对其他金融机构私有化底座基本通用：

• "隔离在网关做租户、在底座做数据"：网关只管身份和配额，真正的数据边界要在向量库 namespace、推理实例池、网络策略三层同时做实，单层隔离都不够。
• "先信创验证再放量"：不要一上来就全量上信创集群。先用单卡跑通推理兼容性，确认算子精度和驱动稳定，再横向扩张，能省掉大量返工。
• "算力—流量联动闭环"：让网关的限流/排队信号反向驱动底座扩缩容，比单纯按 CPU/GPU 指标扩缩更贴近业务真实负载。
• "审计是设计出来的，不是补出来的"：调用留痕、权限最小化、日志归集，从第一天就要进架构，等保审计前再补几乎一定返工。

结语：金融私有化底座的核心矛盾，从来不是"模型够不够强"，而是"强模型能不能安全、合规、可控地待在域内"。把隔离、调度、审计当一等公民设计，落地就顺了。