AI-Infra 在证券金融行业的建设必要性、技术支撑与典型应用

引言：金融机构需要的不是更多 AI Demo，而是稳定的生产体系

大模型正在进入证券金融行业的投研、投顾、客服、营销、运营、合规和软件研发等环节。越来越多机构已经能够用大模型完成知识问答、研报摘要、材料生成或代码辅助，但从试点走向生产后，问题往往迅速变化：模型从一个增加到多个，算力从少量服务器扩展为异构集群，业务从内部助手延伸到客户服务，风险也从“回答不够准确”升级为数据泄露、内容违规、越权操作和服务中断。

这时，仅有一个模型接口、一个知识库或一套 GPU 集群已经不够。证券金融机构需要建设面向 AI 应用全生命周期的基础设施，即AI-Infra（人工智能基础设施）。

AI-Infra 不只是硬件和算力，也不只是大模型管理平台。完整体系应覆盖算力与应用承载、模型运营、调用治理、数据闭环、安全防护、监控审计和生产运维，使模型真正成为可复用、可控制、可评价、可持续运营的机构级能力。

一、证券金融行业为什么必须建设 AI-Infra

1. AI 应用正在从单点试验转向规模化使用

试点阶段，一个项目组可以直接调用商业模型 API，或在几台服务器上部署开源模型。但当投研、客服、投顾、合规、营销等多个部门同时使用 AI 时，分散建设会带来明显问题：

• 各部门重复采购模型服务和算力；
• 不同应用分别保存模型密钥，权限边界不清；
• 模型版本、Prompt、知识库和评测标准无法统一；
• Token 用量和 GPU 资源消耗难以按部门核算；
• 调用日志散落在各应用中，发生问题后难以追踪；
• 相同安全规则被多次开发，执行口径不一致。

AI-Infra 的首要意义，是将分散的项目能力升级为机构级公共能力，避免每个部门重复建设一套“小平台”。

2. 金融数据不能脱离安全边界自由流动

证券金融业务涉及客户身份、账户信息、持仓数据、交易行为、投研材料、内部制度以及未公开经营信息。不同数据具有不同密级、用途和访问权限，不能因为接入大模型就改变原有安全边界。

机构需要明确：哪些数据可以进入外部模型，哪些数据只能在内网处理；请求和响应是否留存；日志如何脱敏；知识库如何授权；模型是否会调用外部工具；数据保存多长时间；发生风险后如何追溯。

这些问题无法仅靠一段系统提示词解决，需要通过 AI 网关、安全围栏、身份权限、数据分级、审计日志和私有化部署共同落实。

3. 模型具有不确定性，必须建立持续评测机制

传统软件通常按照确定逻辑运行，而大模型的输出受到模型版本、Prompt、上下文、知识库、采样参数和输入方式影响。即使同一个模型，在升级后也可能出现效果变化。

证券金融场景对准确性、时效性和合规性要求较高。投研问答需要区分事实与推断，投顾辅助需要遵守适当性和业务口径，客服不能泄露客户信息，营销内容不能作出不当承诺。因此，模型上线不能只依赖人工体验，而应建立包含正确性、完整性、合规性、幻觉率、时延、吞吐量和稳定性的评测体系。

4. 多模型和异构算力将长期并存

金融机构通常不会只使用一个模型。通用大模型、金融行业模型、Embedding、Rerank、OCR、语音和多模态模型各有所长；部分能力运行在机构本地，部分来自外部模型 API。底层算力也可能同时存在 NVIDIA GPU、国产 GPU/NPU、不同 CPU 架构以及多种推理框架。

如果缺少统一平台，模型切换、资源调度、容量规划和故障转移都要由业务应用自行处理。AI-Infra 通过统一模型目录、部署管理和网关抽象，使业务与具体模型供应商解耦，保留模型选择权。

5. 金融生产系统要求稳定、可审计、可追责

金融机构关注的不只是模型“能不能回答”，还包括服务是否高可用、调用是否授权、费用是否超限、响应是否合规、异常是否告警、问题是否能够复盘。

大模型进入客户服务或业务办理后，风险会进一步从“说错话”升级为“做错事”。当 Agent 能够查询内部系统、调用工具或触发流程时，必须限制其可调用的工具、参数、数据范围和执行权限，并对关键操作保留人工确认环节。

二、证券金融 AI-Infra 的总体技术架构

一套完整的 AI-Infra 可以划分为六个层次。

1. 基础设施与算力层

该层提供 CPU、GPU、NPU、存储、网络、容器和虚拟化资源，是模型训练、推理和 AI 应用运行的物理基础。

关键能力包括：

• 异构算力纳管与资源池化；
• Kubernetes 容器编排与任务调度；
• GPU/NPU 切分、共享和拓扑感知调度；
• 高性能存储、对象存储和模型文件管理；
• 高速网络、负载均衡和多集群管理；
• 资源配额、容量规划、故障隔离与弹性扩缩容；
• 国产 CPU、操作系统、加速卡、数据库和中间件适配。

对于证券机构，基础设施既要支持大模型推理，也要兼顾传统应用、中间件和数据服务，避免形成彼此割裂的资源孤岛。

2. AI-PaaS：统一应用与资源承载层

AI-PaaS 在 Kubernetes、容器、监控和日志等通用技术之上，形成一站式的金融信创私有云和应用运行底座。

它应统一管理集群、应用、镜像、配置、中间件、数据库、算力、日志、告警、审计和应用市场，使 AI 应用能够标准化部署、版本化升级并快速复制到开发、测试、生产和灾备环境。

AI-PaaS 的核心价值不是替代 Kubernetes，而是降低客户将多个开源组件集成为金融生产平台的难度和长期维护成本。

3. LLM-OPS：模型全生命周期运营层

LLM-OPS 负责统一管理第三方 API、本地模型、开源模型和行业模型，覆盖模型接入、训练、微调、部署、评测、版本、监控和数据回流。

关键能力包括：

• 模型目录、版本和元数据管理；
• 训练、微调、量化和推理部署；
• 数据集采样、清洗、标注和质量管理；
• 效果评测与性能压测；
• 模型上线准入、灰度发布和回退；
• 会话追踪、效果反馈和数据回流；
• 模型、应用、算力和业务指标关联分析。

这一层把模型从一次性交付的算法成果，转化为可以持续评价和优化的生产资产。

4. AI-Gateway：模型统一接入与调用控制层

AI-Gateway 位于业务应用与模型服务之间，对上提供统一接口，对下连接本地模型、云厂商模型、行业模型和多模态服务。

关键能力包括：

• 接口协议转换与模型别名；
• 供应商密钥统一托管；
• 面向团队和应用的虚拟 Key；
• 模型访问权限、RPM/TPM 限流和预算额度；
• 多实例负载均衡、健康检查、重试和 Fallback；
• Token、成本、时延、状态码和工具调用统计；
• 调用日志、链路追踪和监管审计。

统一网关可避免业务系统直接绑定某个模型供应商，也为成本治理、故障切换和安全策略提供集中控制点。

5. LLM-WAF：AI 应用安全围栏层

LLM-WAF 对模型输入、输出、上下文和 Agent 工具调用进行检测与控制，用于补齐传统 WAF 和 API 安全产品难以识别的自然语言语义风险。

主要防护对象包括：

• 提示词注入、越狱和角色诱导；
• 敏感信息输入、输出和跨会话泄露；
• 违规、虚假、不当承诺或不符合业务口径的内容；
• 知识库越权访问和跨部门数据混用；
• Agent 工具滥用、参数越权和高风险操作；
• 风险事件记录、规则命中、处置结果和安全态势分析。

需要强调的是，安全围栏不能承诺“绝对安全”。其效果必须通过攻击检出率、误报率、漏报率、处理时延和持续红队测试进行验证，并与人工审核、身份管理、数据防泄漏和传统网络安全体系协同。

6. AI 应用与业务集成层

最上层是投研、投顾、客服、营销、合规、办公和研发等 AI 应用。该层应通过标准 API 或 Agent 协议调用模型能力，而不应自行保存真实供应商密钥或绕过统一安全和审计体系。

对于涉及交易、客户权益、投资建议或敏感数据的高风险场景，应设置规则校验、最小权限、人工复核和操作确认，不能让模型直接代替有责任主体的业务决策。

三、证券金融行业的典型使用场景

1. 智能投研

大模型可辅助检索公告、研报、财报、新闻和会议纪要，完成摘要、对比、事件提取、指标解释和研究线索生成。

AI-Infra 在该场景中的支撑包括：

• 对内部研报和授权数据建立分级知识库；
• 统一接入通用模型、金融模型和搜索能力；
• 记录引用来源，减少无法核验的结论；
• 对模型答案进行事实性、时效性和完整性评测；
• 隔离未公开研究成果和不同团队的数据权限。

模型应定位为研究辅助工具，重要结论仍需分析师核验。

2. 投顾与财富管理辅助

大模型可以辅助客户经理查询产品资料、整理客户需求、生成沟通提纲和解释专业概念。

该场景必须重点控制客户适当性、产品风险揭示、收益承诺和个性化建议边界。LLM-WAF 可检测不当承诺和越界表述，AI-Gateway 负责用户权限与调用审计，LLM-OPS 负责用合规测试集持续评测模型版本。

模型不应绕过持牌人员和既有业务规则，直接作出应由专业人员承担责任的投资决策。

3. 智能客服与坐席辅助

AI 可以承担常见问题解答、业务流程导航、工单分类、会话摘要和坐席话术建议。

AI-Infra 能够统一管理知识库版本、客户数据访问权限、模型并发、敏感信息脱敏和服务降级。当模型置信不足、问题超出范围或涉及投诉与敏感业务时，应及时转人工。

4. 合规审核与风险监测

大模型可辅助检查营销材料、直播文案、客服会话、投顾内容和内部文件，识别疑似违规表述、敏感信息及异常行为。

平台需要保留规则版本、模型版本、命中内容、处理结果和人工复核记录，形成可追溯证据链。AI 的判断可以提高筛查效率，但不能替代最终合规责任和正式审批流程。

5. 金融知识库与内部办公助手

机构可将制度、流程、产品手册、技术文档和会议材料纳入权限化知识库，提供内部问答、文档摘要、材料生成和信息检索。

该场景上线门槛相对较低，但仍需防止跨部门越权、过期制度误用、引用来源缺失和敏感信息外发。知识库权限应继承原始文档权限，而不是所有内容进入模型后默认全员可见。

6. 研发、测试与运维辅助

大模型可以辅助生成代码、解释日志、编写测试用例、查询运维知识和分析故障。

对于源代码、配置、密钥和生产日志，应通过私有化模型、脱敏和权限控制避免泄露。Agent 执行发布、变更或运维命令时，应采用只读优先、最小权限、审批确认和完整审计。

7. 营销与内容生产

大模型可辅助生成市场解读、活动文案、短视频脚本、客户触达内容和多版本素材。

安全围栏应检测夸大宣传、收益暗示、虚假信息和不适当表述；模型生成内容应进入既有审核流程，不能因自动生成而降低发布标准。

8. 数据分析与自然语言取数

通过语义解析和工具调用，业务人员可以用自然语言查询经营、客户和产品数据。

该场景应重点防范模型生成错误查询、越权访问明细数据、扩大查询范围或执行写操作。建议采用语义层、指标口径库、行列权限、查询成本限制和只读数据库账号。

四、AI-Infra 建设的主要技术支撑

1. 云原生与容器技术

Kubernetes、容器运行时、Helm、服务网格和多集群管理构成应用与模型部署基础。技术重点不只是容器化，还包括 GPU/NPU 调度、批任务与在线推理混部、资源隔离、灰度升级和灾备。

2. 模型训练与推理技术

训练侧通常涉及 PyTorch、分布式训练、参数高效微调和数据处理；推理侧涉及 vLLM、TGI、TensorRT-LLM、MindIE 等框架，以及量化、批处理、KV Cache 和推测解码等优化方式。

具体框架应根据模型、芯片、许可证、兼容认证和性能实测选择，不能仅依据厂商宣传。

3. 数据工程与知识增强

RAG 系统需要文档解析、切分、Embedding、向量检索、关键词检索、Rerank、引用和权限过滤。证券金融数据具有时效性和版本性，需要同时管理数据来源、更新时间、授权范围和失效机制。

4. 模型评测与可观测性

效果评测应覆盖准确性、相关性、完整性、忠实度、合规性和业务任务完成率；性能评测应关注成功率、QPS、首 Token 时延、包间时延、端到端时延和资源利用率。

可观测性需要贯通应用、网关、模型服务和算力，能够根据 Trace 定位一次请求在检索、护栏、路由、推理和工具调用中的耗时与异常。

5. 安全、身份和审计技术

AI-Infra 应与机构现有 IAM、单点登录、堡垒机、密钥管理、数据防泄漏、安全运营中心和审计平台集成。核心原则包括身份可验证、权限最小化、密钥不下发、敏感数据可脱敏、关键操作可确认、全链路可追溯。

6. 高可用与容灾技术

模型网关和安全围栏处于关键调用链路，应支持无单点部署、水平扩展、健康检查、熔断、超时、重试、备用模型和限流降级。

对于重要业务，应设计模型不可用、算力不足、知识库异常、外部 API 故障和安全服务超时等场景下的降级策略，而不是默认所有依赖始终可用。

五、典型厂家与产品生态

AI-Infra 涉及多个技术层次，通常不存在一家厂商在所有领域都绝对领先。选型时应根据机构已有基础设施、信创要求、数据边界、模型路线和运维能力进行组合。以下厂家仅作为行业常见类型与代表示例，不构成采购推荐。

1. 算力芯片与服务器

• NVIDIA：GPU、CUDA、通信库及训练推理软件生态成熟；
• 华为昇腾：提供国产 NPU、CANN、MindIE 等软硬件体系；
• 海光、寒武纪、壁仞、沐曦、天数智芯等：提供不同路线的国产 CPU 或 AI 加速产品；
• 浪潮信息、新华三、联想、华为等：提供 AI 服务器、集群和相关基础设施方案。

选型不能只比较芯片峰值算力，还要验证目标模型的精度、吞吐、时延、显存利用、分布式效率、框架兼容性和运维工具成熟度。

2. 云平台与云原生基础设施

• 阿里云、华为云、腾讯云、百度智能云、火山引擎：提供云计算、容器、AI 算力和大模型平台能力；
• Red Hat OpenShift、Rancher、VMware Tanzu：属于常见企业级 Kubernetes 与云原生平台方案；
• Kubernetes、Helm、Prometheus、Grafana、OpenTelemetry：构成常见开源云原生与可观测技术栈。

公有云适合快速开通与弹性使用，企业级平台适合标准化治理，纯开源方案灵活但要求客户具备较强集成和维护能力。

3. 大模型与模型开发平台

• 阿里云百炼、百度智能云千帆、火山方舟、腾讯云大模型平台、华为云盘古相关平台：提供云上模型服务、开发、评测和应用构建能力；
• DeepSeek、通义千问、智谱、百川、月之暗面等：提供不同形态的大模型或 API 服务；
• MLflow、Kubeflow、Dify、FastGPT、Langfuse 等开源项目：分别覆盖实验管理、机器学习流水线、应用编排、知识库或可观测等能力；
• 同花顺等金融科技厂商：更强调金融业务系统集成、私有化、信创环境适配和行业运营闭环。

不同产品定位差异很大，不宜把应用编排平台、模型运营平台和云上 MaaS 简单放在同一维度比较。

4. AI 网关

• Higress、Kong、Apache APISIX、Envoy AI Gateway 等：提供 API 网关或 AI 网关相关开源能力；
• 主流云厂商 API 网关和大模型网关服务：适合云内统一接入和治理；
• 同花顺 AI-Gateway 等行业方案：强调虚拟 Key、模型权限、Token 成本、路由容灾、金融审计和私有化交付。

开源网关具有开放和扩展优势，行业产品的价值应通过开箱可用的治理模型、审计字段、运营报表和交付服务体现，而不能简单宣称开源网关“只能转发”。

5. 大模型安全

• NVIDIA NeMo Guardrails、Guardrails AI、Llama Guard 等：提供对话规则、输入输出约束或安全分类能力；
• 云厂商内容安全服务：提供在线内容检测和审核能力；
• 奇安信、深信服、绿盟科技、安恒信息等安全厂商：正在不同程度布局大模型安全、数据安全和安全运营方案；
• 同花顺 LLM-WAF 等金融行业方案：强调金融业务规则、模型调用链路、Agent 行为约束、私有化和审计证据链。

安全产品选型应通过真实业务数据和对抗测试验证，重点比较检出率、误报率、漏报率、时延、规则运营和私有化能力。

6. 金融科技和行业解决方案厂商

证券机构已有核心业务、行情、交易、投顾、客服和合规系统往往来自不同金融科技厂商。AI-Infra 建设不能脱离这些系统单独进行。

行业方案商的优势通常在于业务理解、存量系统接口、交付经验和合规口径；云与基础设施厂商的优势在于算力、平台规模和通用技术；开源生态的优势在于开放性和创新速度。比较合理的建设方式，是明确主平台和责任边界，在统一架构下组合各类能力。

六、建设路径建议

第一阶段：统一底座与治理入口

优先盘点现有 GPU/NPU、模型、知识库、应用和外部 API，建立统一资源目录、模型目录和 AI-Gateway。选择内部知识问答、研发助手等相对低风险场景验证身份、权限、日志、成本和基本安全机制。

第二阶段：建立模型运营与评测体系

建设标准数据集、效果评测、性能压测、模型上线准入、灰度发布和数据回流流程。逐步把分散模型服务纳入 LLM-OPS，并与 AI-PaaS 的算力和监控打通。

第三阶段：进入客户服务和关键业务

在客服、投顾辅助、营销、合规等场景上线前，完善 LLM-WAF、业务规则、人机协同、应急降级和审计证据链。高风险动作必须保留人工确认和明确责任主体。

第四阶段：持续运营和成本优化

围绕应用上线周期、模型效果、调用成本、算力利用率、风险事件和用户反馈建立运营指标，根据实际数据优化模型路由、资源配置、评测集和安全策略。

七、AI-Infra 建设应重点衡量的指标

这些指标应在 POC 阶段形成基线，并在生产运行中持续观测。只有能够被量化和复盘的优势，才能转化为可信的建设价值。

结语

证券金融行业建设 AI-Infra，本质上不是采购更多服务器或再建一个模型平台，而是建立一套管理 AI 生产要素的制度与技术体系。

AI-PaaS 负责统一承载，LLM-OPS 负责模型生命周期，AI-Gateway 负责每一次调用，LLM-WAF 负责内容与行为安全。四者与数据、身份、审计和业务系统结合后，才能让模型在金融机构中既发挥效率价值，又处于可控边界内。

短期看，分散调用模型和拼装开源工具可能更快；长期看，随着应用和模型规模扩大，统一 AI-Infra 是降低重复建设、控制数据风险、保留技术选择权并推动 AI 从试点走向规模化生产的必要基础。

说明：文中厂家与产品仅为行业生态示例，不构成采购建议。厂商能力会随产品版本、授权模式和部署形态变化，正式选型应以官方资料、兼容认证、现场 POC、性能测试和安全评估结果为准。