
从技术评估到供应商谈判,从组织推动到落地管理,记录一个传统企业 信息化负责人引入魔芋企业AI网关(MAI Gateway)的完整决策过程。
魔芋AI大模型网关I https://www.moyu.info/register?aff=qBX9
背景
我在一家企业做信息化负责人(CIO),集团下属 12 家子公司,员工 8000 多人。主营业务是能源和基础设施建设,属于传统行业。
去年年底,集团领导在年度工作会上明确提到了要探索大模型在企业中的应用。
任务落到我头上:调研大模型平台,AI网关平台,出方案,报预算,推进落地。
这篇文章是我从调研到上线的完整决策记录。因为涉及特有的决策流程和合规要求,跟互联网公司的选型思路有很大不同,所以单独写一篇。
一、为什么不能直接用 SaaS
在调研之前,我先梳理了我们企业的约束条件。
1.1 数据安全要求
我们有严格的数据安全管理规定:
企业内部数据(文件、邮件、业务数据)原则上不得出企业内网
涉及工作秘密的信息,严禁通过互联网传输
关键信息基础设施运营者需要满足等级保护要求
直接结论:不能把内部数据发给公有云大模型 API。
1.2 采购流程
企业的 IT 采购需要走招标或比选流程,不能直接采购 SaaS 服务。需要有正式的采购文件、技术规格书、评标标准。供应商需要具备相应的资质(ISO 认证、等保测评等)。
1.3 组织复杂性
集团 12 家子公司,每家的 IT 水平参差不齐。有的子公司有自己的 IT 团队,有的只有一两个兼职管理员。平台需要支持分级管理——集团层面统一管理,子公司层面有各自的管理权限。
1.4 运维能力
集团 IT 部门 15 人,要维护 30 多个业务系统。没有精力去维护复杂的技术栈。平台需要尽可能"省心"——最好部署简单、运维自动化、出问题有人支持。
二、选型过程
2.1 候选方案
调研了四类方案:
方案类型 |
代表 |
优点 |
缺点 |
公有云大模型平台 |
阿里云百炼、百度千帆 |
功能全面,接入简单 |
数据出内网,不符合安全要求 |
开源自建 |
LangChain + Ollama |
免费,可控 |
运维复杂,没有企业级管理功能 |
开源聚合网关 |
NewAPI、OneAPI |
免费,接入快 |
缺乏组织架构、安全审计能力 |
企业级私有化部署 |
MAI Gateway 等 |
私有化部署,功能完整 |
有采购成本 |
2.2 评估维度
我制定了一个评估矩阵,从技术、安全、管理、成本四个维度打分:
评估维度 |
权重 |
公有云平台 |
开源自建 |
开源网关 |
MAI Gateway |
数据安全 |
25% |
2分 |
5分 |
3分 |
5分 |
功能完整性 |
20% |
5分 |
2分 |
3分 |
4分 |
组织架构适配 |
15% |
2分 |
1分 |
1分 |
5分 |
运维简易性 |
15% |
5分 |
1分 |
2分 |
4分 |
合规资质 |
15% |
3分 |
1分 |
1分 |
4分 |
总体成本 |
10% |
3分 |
5分 |
5分 |
3分 |
加权总分 |
3.15 |
2.40 |
2.35 |
4.30 |
MAI Gateway 得分最高,主要赢在数据安全、组织架构适配和合规资质三个维度——这三个恰好是我们最看重的。
2.3 关键决策点
为什么选私有化部署?
最直接的原因是数据安全。企业的内部文件、工程数据、人事信息,不能发到外部服务器。私有化部署意味着所有数据在企业内网流转,不经过公网。
为什么不用开源自建?
开源自建最大的优势是免费,最大的劣势是"什么都要自己做"。我们没有 ML 工程师,没有人力去维护模型推理服务、写管理后台、做组织架构集成。开源自建省的是软件钱,花的是人力钱,而且做出来的东西未必比商业产品好。
为什么不用开源聚合网关?
看了 NewAPI 和 OneAPI,功能上确实能接入多个模型,做基本的转发。但有几个硬伤:
不支持组织架构同步(我们需要跟集团 AD 域对接)
没有分级管理(集团-子公司两级权限)
安全能力薄弱(没有 PII 脱敏、内容过滤)
没有等保相关资质(国企采购需要)
三、部署方案
3.1 架构设计
最终方案采用"1 + N"架构:集团总部部署主网关和本地 GPU 等服务,各子公司通过内网接入集团网关。统一认证、统一权限、统一审计。
3.2 组织同步
MAI Gateway 支持与 AD 域对接。我们的组织架构已经在 AD 里维护好了——集团 → 子公司 → 部门 → 人员。对接后,组织架构自动同步到网关,不需要手动建组织。
角色和权限分配:
角色体系:
集团超级管理员(IT部门负责人)
├── 集团运维管理员(IT部门运维组)
├── 集团安全管理员(IT部门安全组)
├── 子公司管理员(各子公司IT负责人)
│ └── 子公司普通用户
└── 集团普通用户
集团层面可以查看所有子公司的使用情况和费用,子公司层面只能看自己的数据。权限边界清晰。
3.3 模型接入
模型 |
部署方式 |
用途 |
DeepSeek-V3 |
本地 GPU(集团机房) |
内部知识问答、文档分析 |
Qwen-7B |
本地 GPU |
公文写作辅助 |
通义千问-Qwen-Max |
外部 API |
通用问答(仅限非敏感内容) |
GPT-4o-mini |
外部 API |
创意类文案(仅限非敏感内容) |
路由原则:涉及内部文件、工程数据、人事信息的请求,一律走本地模型。通用知识问答、创意文案等非敏感场景,可以走外部 API。
3.4 硬件配置
集团机房部署了两台 GPU 服务器:
GPU 服务器 × 2:
GPU:4 × A100 80GB(每台2卡)
CPU:2 × Intel Xeon Gold 6348
内存:512GB DDR4
存储:4TB NVMe SSD
网络:万兆内网
用途:运行 DeepSeek-V3 和 Qwen-7B 模型推理
网关服务器单独部署(双机热备),与 GPU 服务器分离。
四、实施过程
4.1 时间线
第1-2周:需求调研 + 方案设计
第3-4周:采购流程(比选 + 评标 + 合同签订)
第5-6周:硬件到货 + 机房准备
第7周:网关部署 + 模型部署
第8周:AD 域对接 + 组织同步 + 权限配置
第9周:模型接入 + 路由配置 + 安全策略
第10周:试点上线(集团总部 + 2家子公司)
第11-12周:全集团推广
总共 12 周,比预期多了 2 周(采购流程比计划慢)。
4.2 试点先行
没有一开始就在全集团推广。先选了集团总部和 2 家 IT 能力较强的子公司做试点,运行一个月,收集反馈,调整策略后再全量推广。
试点期间发现的问题:
子公司网络延迟:有一家子公司的内网带宽较窄,调用集团网关的延迟偏高。解决方案是在该子公司部署了一个网关代理节点,缓存常用模型响应。
用户习惯:很多员工不习惯用 AI 工具,需要培训。我们做了 3 场内部培训,编写了操作手册。
权限过紧:一开始给普通用户的权限设得太紧(只能用一个模型),用户反馈不方便。调整后放宽了模型范围,但通过配额控制使用量。
4.3 预算与成本
一次性投入:
GPU 服务器 × 2:约 ¥120万
网关服务器 × 2:约 ¥15万
网关软件授权:约 ¥30万/年
网络改造:约 ¥10万
合计:约 ¥175万(一次性)+ ¥30万/年(软件)
持续成本(年度):
软件授权:¥30万
外部API费用:约 ¥8万/年
电费和机房运维:约 ¥15万/年
合计:约 ¥53万/年
对比方案——如果全集团用公有云大模型 SaaS,按人均 ¥100/月计算,8000 人年费用约 ¥960 万。私有化方案三年总成本约 ¥175 + 53×3 = ¥334 万,不到公有云方案的 1/3。
当然这个对比不完全公平——私有化方案用的是开源模型(DeepSeek),效果跟顶级公共模型有差距。但对于我们的场景(知识问答、公文辅助、文档分析),DeepSeek 的效果已经够用。
五、管理与运营
5.1 日常运营体系
平台上线后,建立了日常运营机制:
角色 |
职责 |
频率 |
集团超级管理员 |
全局策略、权限管理、预算审批 |
按需 |
集团运维管理员 |
链路监控、告警处理、容量规划 |
每日 |
集团安全管理员 |
安全审计、日志检查、策略更新 |
每周 |
子公司管理员 |
本子公司用户管理、使用统计 |
每周 |
5.2 关键运营指标
通过网关的报表功能,每周生成运营报告:
周度运营报告(示例):
总调用量:28,500 次
活跃用户:1,230 人(占全集团 15.4%)
模型分布:DeepSeek 72% / Qwen-Max 18% / 其他 10%
场景分布:知识问答 45% / 公文辅助 25% / 文档分析 20% / 其他 10%
平均响应时间:1.2s(本地模型)/ 2.8s(外部API)
本周安全事件:PII 脱敏触发 156 次,注入拦截 3 次
本周费用:¥1,850
5.3 安全管理
安全策略是国企场景的重中之重:
安全配置:
PII 脱敏:全场景开启(检测到身份证号/手机号自动脱敏)
内容过滤:开启(敏感词库 + 自定义规则)
令牌管理:个人令牌30天过期,系统令牌90天强制轮换
IP 白名单:仅允许企业内网 IP 访问
日志审计:全量日志保留 180 天
外部 API:仅限白名单模型,禁止未经审批的模型
每月做一次安全审计,检查是否有异常调用、越权访问、数据泄露风险。
六、遇到的挑战
6.1 组织推动比技术难
技术部署花了 3 周,组织推动花了 9 周。12 家子公司,每家的态度不一样——有的积极配合,有的敷衍了事,有的直接说"我们不需要"。
最终的解决方案是:不强制,用数据说话。每月发使用报告给集团领导和各子公司负责人,展示各子公司的 AI 使用率。使用率低的子公司负责人自然会有压力。
6.2 模型效果的期望管理
有些员工用了 ChatGPT 后,对我们内部的 DeepSeek 模型不满意:"为什么没有 ChatGPT 聪明?"
这个需要管理期望。我们通过培训告诉大家:内部模型处理的是内部数据,数据不出内网是底线。在效果和安全之间,我们优先保安全。同时,对于确实需要高端模型的场景(如重要报告撰写),我们保留外部 API 通道,但需要走审批流程。
七、效果与反思
7.1 半年后的数据
上线半年后:
全集团 AI 使用率:28%(目标 30%,基本达成)
月调用量:约 12 万次
月 AI 相关费用:约 ¥7,800(外部 API 费用 + 电费分摊)
员工满意度:3.8/5(内部调研)
领导满意度:认可"数据不出内网"的安全策略
7.2 最大的收获
不是省了多少 API 费用(私有化方案主要成本在硬件),而是建立了一个企业级的大模型基础设施。以前各子公司自己买 AI 工具,现在统一走集团平台,管理规范了,数据安全了,成本也可控了。
7.3 如果重来一次
有几个决策我会做调整:
GPU 算力可以多配一些。目前 2 台 GPU 服务器在高峰期(上午 9-11 点)比较紧张,如果预算允许,建议配 3 台。
试点时间可以缩短。我们试点了一个月,其实两周就够了。国企的效率本来就不高,能快则快。
培训要更早开始。员工培训不应该在上线后才开始,应该在部署阶段就同步推进,上线后马上就能用起来。
八、给同行 CIO 的建议
如果你也是传统行业的信息化负责人,正在考虑引入大模型平台,几点建议:
1. 安全合规是选型的第一优先级
不要被"效果最好"、"价格最低"带偏。对于国企来说,"数据不出内网"是底线,在这个底线之上再谈效果和成本。
2. 私有化部署的长期 ROI 更好
虽然一次性投入高,但 3 年总成本通常远低于公有云 SaaS。而且私有化部署的可控性、安全性、定制能力都更强。
3. 组织架构同步是刚需
不要低估组织架构管理的工作量。8000 人的集团,手动建组织、分配权限几乎不可能。选择一个能跟 AD/LDAP/钉钉/企微对接的平台,能省很多事。
4. 试点先行,不要一上来全量推广
先选 1-2 个部门或子公司试点,验证效果、收集反馈、调整策略,再全面推广。企业的容错空间小,一次失败的推广可能让整个项目被否定。
5. 运营比部署更重要
平台上线只是开始。后续的运营(用户培训、使用推广、效果评估、持续优化)才是决定项目成败的关键。建议安排专人负责 AI 平台的运营,而不是让运维"兼着管"。
本文为个人选型实践分享,具体方案需根据企业实际情况调整。涉及国企采购,请遵循相关法律法规和内部流程。
(免责声明:此文内容为本网站刊发或转载企业宣传资讯,仅代表作者个人观点,与本网无关。仅供读者参考,并请自行核实相关内容。)