张颖月从去年开始，我陆续帮几家企业搭过内部的大模型平台。这件事看起来门槛不高，因为现在API调用已经足够简单，三行代码就能让大模型开口说话，可一旦到了企业内部，情况就完全变了：数据要过安全审查、模型输出要能追责、接口要能扛住业务流量、功能要跟现有系统做联动，更别提权限隔离、审计日志、成本统计这些东西。如果一开始就想清楚要做“企业AI全栈平台”，而不是临时拼一个demo应付汇报，确实是有章法可循的。
这篇文章我把最近一年多的落地经验整理成一份可以照着抄的指南，覆盖架构分层、模型选型、本地部署工具、RAG知识库、Agent能力接入、统一网关、安全治理和成本控制，最后附上我实际踩过的坑和推荐的落地节奏。不管是技术负责人、架构师，还是准备转型做AI应用的产品经理，应该都能从这里找到自己关心的那部分。
1. 企业AI全栈平台：先理解它到底在解决什么问题
1.1 “全栈”不是技术名词的堆叠，而是四层架构的咬合
很多老板看完ChatGPT的演示，第一反应是“我们也做一个”。但企业内部的大模型应用，跟网页上聊天完全是两码事。想要让大模型真正干活，技术底座至少要分成四层：
- 模型层：负责“理解和生成”，包括模型选型、推理部署、微调、量化等。
- 数据层：负责“喂给模型的知识”，包括文档清洗、知识库切割、向量化、检索。
- 能力层：负责“让模型动手操作”，包括工具调用、工作流编排、各业务系统的API接入。
- 应用层：负责“给用户交付”，包括统一入口、权限管控、对话记录审计、效果评测。
搭建全栈平台，本质上就是把这四层打通，每一层都做适度抽象，让上层业务不必关心底层跑的是开源模型还是商业API。前期宁可多花点时间梳理清楚，也不要等项目上线以后发现所有AI功能都写在同一个文件里，改一个模型要全局返工。
1.2 平台建设前，先回答三个问题
动手之前，先回答下面三个问题，它们决定了你的技术选型方向：
第一，数据能不能出域？如果要求所有数据必须留在企业内部，那大概率要私有化部署开源模型，整个选型思路围绕GPU资源和推理框架展开。如果数据合规上允许使用商用API，那落地速度会快很多，但仍然要加一层网关做审计，不能把业务密钥直接散落到各项目里。
第二，场景是“知识问答”还是“业务流程自动化”？前者重点是RAG（检索增强生成），要把搜索质量和问答质量做扎实；后者重点是Function Calling和Agent，模型要能主动决定调用哪个工具、拼接什么参数。这俩的技术重心差异很大，混在一起设计容易两头都不讨好。
第三，谁会调用平台能力？如果主要给内部业务系统调用，那必须提供一套规范的API网关；如果主要给业务人员直接对话使用，那还要做一个前端应用以及一套完整的权限体系。
1.3 一套可以复用的最小技术栈参考
以我目前实践下来比较顺手的组合为例，初次搭建全栈平台时可以照猫画虎：
- 模型层：商业API保留主备，同时在GPU服务器上用vLLM部署一个开源模型做补充。
- 推理与接入：本地用Ollama做开发调试，生产统一走OpenAI兼容协议接入网关。
- 知识库：向量数据库选pgvector或Milvus，Embedding模型选用中文场景表现较好的开源模型。
- 应用开发框架：后端推荐Python FastAPI或Spring AI，前端按团队习惯选型。
- 网关：用LiteLLM或one-api做统一入口，集中处理多模型路由、限流与计量。
这套组合每一环都有替代方案，关键在于它们之间通过标准接口衔接，任何一层都能独立替换。这也是我想强调的第一个经验：全栈平台的命门不是某一层的技术选型有多炫，而是层与层之间的接口是否足够干净。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模型选型与部署：决定整个平台地基的关键决策
2.1 开源模型与商业API怎么取舍
模型选型是平台上线的第一个十字路口。我的建议是：先别急着站队，把场景需求拆成“数据边界、效果要求、并发规模、成本预算”四个维度再决策。
- 数据边界严格、需要私有化部署，那就选开源模型。目前Qwen、DeepSeek、GLM这几个系列的中文能力都比较成熟，且都有从0.5B到上百B的完整尺寸谱系。
- 场景开放、对效果上限敏感、业务量波动大，商用API会更合适。GPT、Claude这类模型在复杂推理上的表现通常更稳定，且省去了GPU运维负担。
- 最稳的方案其实是一起用：敏感数据走本地模型，开放场景走商业API，网关统一路由，按业务场景自动分流。
我见过不少团队为了“模型自主可控”直接上私有化，忽略了GPU运维成本和模型更新滞后的问题；也见过因为贪图API方便，把客户核心数据直接送出去的。这种本可以避免的麻烦，根源就是没在开头把数据边界想清楚。
2.2 本地模型部署：开发用Ollama，生产用vLLM
本地模型部署现在最常用的推理工具是Ollama和vLLM，它们各有明确的使用场景。
Ollama适合开发调试和知识验证。一条命令就能启动Qwen、Llama等模型，还自带OpenAI兼容接口，对前端联调非常友好。我搭环境时基本都用它做冒烟测试，确认模型效果没问题再切到生产链路。
vLLM则适合生产环境高并发推理。它实现了PagedAttention等优化手段，推理吞吐量远超原生transformers实现，还支持动态批处理，能把GPU利用率拉高不少。企业在生产环境跑私有化模型的标配就是vLLM加多张GPU，部署后用OpenAI兼容协议提供给上层应用。
如果是在低配设备或边缘场景部署，也可以考虑llama.cpp配合GGUF量化格式。它在CPU和Mac设备上跑起来很顺，但单机并发吞吐有限，不适合做高并发服务。
2.3 GPU显存估算：先算清楚再买卡
很多项目到了部署阶段才发现显卡不够用，问题通常出在只算了模型权重，没算KV Cache和推理开销。以一个7B参数的BF16模型为例，权重就要占14GB显存，量化到INT8大约7GB，INT4大约4GB，同时还要给KV Cache预留至少2到4GB，实际部署需要的显存往往是模型权重的1.5倍左右。
70B模型就更明显了：BF16权重140GB，单张80GB的卡放不下，要么用两张80G或四张48G的卡做张量并行，要么用AWQ或GPTQ量化后压到单卡可承载的范围。我建议按“模型权重×1.5=最低显存”这条公式做初算，再参照实际场景做压力测试。
这里顺便提醒一句：GPU采购周期通常不短，如果方案还未确定，可以先租云GPU做验证，别一上来就买机器。很多企业的硬件最后吃灰，主要就是因为前期的显存规划做错了。
2.4 量化微调要不要做
关于微调，我的建议是克制。企业场景里80%的需求靠RAG就能解决，真正需要微调的场景只有两类：一类是模型输出格式严格受限，比如必须输出固定JSON结构；另一类是特定领域术语密集，比如医疗、法律等专业词频很高的情况。
如果确实要微调，早期用LoRA这类参数高效微调方法就好。一张24GB显存的消费级GPU就能微调7B模型，不需要整卡微调。同时训练数据和评估集至少要分开，否则模型效果在评测集上的表现会虚高。
3. RAG知识库：让大模型真正懂企业的私有数据
3.1 为什么企业第一站通常是RAG
企业部署大模型，最常见需求是“让AI能回答基于公司知识的问题”。这里我不建议直接微调模型硬记知识，因为业务资料更新频繁，每次微调都要重训，成本高且周期长。
RAG的思路是“先检索后生成”：用户提问后，从知识库中检索相关片段，把这些上下文拼进Prompt，再让模型回答。这相当于给模型开卷考试，既能保证答案有据可循，又便于知识更新——替换文档就行。从落地效果看，RAG在企业场景里远比“背书的模型”靠谱。
3.2 文档解析、分块与向量化
RAG想做好，最关键的不是模型而是链路。完整链路是：文档解析→清洗→分块→向量化→存入向量库→查询时召回→重排→交给模型生成。
文档解析是最容易被低估的环节。PDF里的表格、扫描件、复杂排版都很容易解析乱，推荐先用成熟的文档解析工具做转换，再人工抽检关键页面。如果连原文都抽错了，后续检索效果不可能好。
文本分块直接影响检索精度。常用的策略是固定窗口分块，一般500到800字一个chunk，块与块之间保留50到100字的重叠，确保跨段语义不被切断。但要根据文档类型调整：合同条款最好按条款边界切割，产品手册可以按标题层级切割，直接用固定长度切出的结果往往比较糙。
Embedding模型选型我建议直接测，别只看榜单。重点测中文相似度检索的准确性，像bge-m3这样的模型在企业场景里表现一般都不差。向量库方面，几百GB内的知识量用pgvector就行，运维省心；真到了海量数据且有复杂过滤需求，再上Milvus这类专业向量库。
3.3 检索质量怎么评估
知识库上线前一定要做效果评测，而不是靠感觉说“差不多”。我常用的方法是准备50到100条真实业务问题，为每个问题标注正确的参考文档，然后跑RAG链路统计召回率与最终答案的准确率。如果召回率不达标，优先调整分块策略或Embedding模型；如果答案表述不好但资料已经召回，则重点优化Prompt和生成参数。
这一步很多人偷懒跳过，结果上线后被业务部门反馈“胡说八道”。其实是检索连资料都没找到，模型只能靠脑补硬答。
4. 从对话到办事：Function Calling、工具调用与Agent
4.1 只有聊天机器人，撑不起真正的业务价值
如果企业AI平台只能回答“放假通知是什么”，那投入产出比很难看。真正产生价值的是让模型完成操作，比如“帮我查一下项目A的库存和交期”“把这份报销单推到审批流程”。模型要具备和业务系统打交道的能力，这就绕不开Function Calling。
所谓Function Calling，是让模型识别用户的意图，输出一个结构化的“工具调用请求”，由程序执行真正的API调用，再把结果回传给模型生成最终回答。模型不直接操作数据库，它只负责“决定调用谁、参数是什么”，具体动作由外部系统完成。这种方法更安全可控。
4.2 一个查库存功能的完整流程拆解
假设要给AI加一个“查库存”能力，流程是这样的：
- 在模型能力配置里注册一个工具
query_inventory，用JSON Schema描述参数，如product_name和warehouse_id。 - 用户说“A产品在上海仓还剩多少”，平台将工具定义和用户问题一并发送给模型。
- 模型返回一个function_call对象，内容是调用
query_inventory并带上参数{"product_name": "A产品", "warehouse_id": "SH01"}。 - 后端程序收到这个请求后，调用真实的库存系统API，拿到结果再返回给模型。
- 模型根据结果组织回答：“A产品在上海仓剩余320件。”
注意这里要处理一个坑：模型可能产生“幻觉参数”，比如把仓库名说成系统里不存在的名称。所以工具调用绝不能直接透传，后端必须做参数校验，查不到就明确返回错误信息，避免模型继续编造。
4.3 Agent编排与工具统一接入
当工具数量超过十个，就需要一个Agent编排层来管理。简单场景可以自己写规则循环，让模型自动多轮调用工具，直到收集齐答案。复杂场景建议引入现成框架，比如LangChain、LangGraph或Spring AI，用图结构把工具链路稳定编排起来。
目前很多团队的实用做法是引入MCP这类标准化协议来连接不同的工具和数据源。MCP的核心思想是把工具调用规范统一，让模型应用能以同一套方式接入数据库、文件系统和各种业务系统，避免为每一个内部系统都定制一套协议。
5. 统一API网关：企业模型平台的“流量枢纽”
5.1 不上网关，后期一定会乱
跳过网关直接对接模型API，短期开发快，长期会很痛苦。每个项目各自申请Key、各自计费，管理层看不到成本，出问题也定位不到哪条业务在打哪个模型。等应用一多，再想统一治理就难了。
所以从第一天起就要立起一个统一接入层，所有上层应用只能通过网关调用模型。网关的核心能力包括模型路由、负载均衡、限流、计量计费、审计日志和密钥管理。
5.2 网关核心能力怎么配置
- 模型路由：同一个业务前缀可以按策略路由到不同模型。比如内部IPC审核类走本地模型，开放闲聊类走大参数API。
- 限流与配额：按应用与用户维度限流，防止单个业务写死循环把预算打爆。
- 审计日志：记录每次请求的Prompt、响应、模型版本和Token消耗。这一点对合规和问题回溯很重要。
- 缓存：对重复性很高的常见问题，可以在网关层做语义缓存，明显降低成本。
LiteLLM或者one-api这类开源网关都支持上述能力，部署在一台普通服务器上就够起步。网关配好后，业务部门只需要拿到一个统一的API地址和一个网关Key，不必关心背后是哪家模型在服务。
5.3 本地vLLM服务也建议通过网关暴露
本地用vLLM部署的模型同样建议挂到网关后面，将OpenAI兼容地址作为上游模型源。这样上层应用切换模型时只需要改网关配置，不用改业务代码。我不止一次靠这个设计省下了大改代码的时间，比如某个模型效果突然变差或者被下线时，一分钟就能把流量切到备选模型上。
6. 安全、合规与成本治理：企业AI平台避不开的硬骨头
6.1 大模型安全不是只在防火墙层做文章
很多团队把安全等同于网络隔离，方向没错但远远不够。Prompt注入是目前实际业务中最常遇到的攻击面：恶意用户故意构造Prompt诱导模型输出越权内容，或尝试通过“忽略之前指令”的方式套取系统Prompt与内部知识库之外的敏感信息。
有效的防护手段包括：在网关层做敏感词与内容过滤；对知识库做细粒度的权限隔离，模型只能检索当前用户有权访问的文档范围；在系统Prompt里明确约束模型不得泄露内部指令或回答超出知识库权限范围的问题。上线前建议组织一次模拟攻击测试，专门让团队里的成员扮演不友好用户，尝试用各种方式绕过限制，再做针对性加固。
6.2 数据脱敏与权限隔离的最佳实践
即便大模型部署在企业内部，也不能让所有员工随便问所有数据。层级权限设计这种事，交给模型做判断并不可靠，建议放在网关和知识库文档的元数据层做强制约束：每个知识文档带上部门与密级标签，每个用户请求打到知识库时在检索阶段就过滤掉无权访问的内容。
对于包含手机号、身份证、银行卡信息的日志，要建立自动脱敏机制再进入模型日志存储。否则答案虽然不会直接输出明文，但日积月累会带来不必要的风险。
模型领域的安全也可以延伸到安全评测：可以引入开源的安全评测工具，或自建红队测试集，持续验证系统的安全性。这块不能只做一次，每次更换模型时都要回归。
6.3 成本治理：从笼统账单到精细化分摊
我见过一家企业第一个月API账单直接翻了八倍，原因是某个内部工具在后台无限循环调模型。成本治理的核心是“可观测”：每个请求都归属于某个应用、某个业务线，Token消耗和金额能够按应用维度拆分。
实际操作中按如下方式设置比较稳妥：模型按应用开通白名单；单应用配置每日消费上限；对高频相似请求开启语义缓存；对不追求实时效果的场景，使用便宜的轻量模型处理。长期来看，自己部署模型和调用商业API可以形成成本上的互补关系，而不是只依赖其中一种。
7. 落地路线图与避坑笔记
7.1 推荐按三阶段走，警惕一步到位心态
把企业AI全栈平台从零搭起来，我建议所有团队都按下面三个阶段推进，不要想着一步到位做“大而全的AI中台”：
- 第一阶段（1到2周）：定位一个高频且有明确业务价值的场景，比如运维知识问答或合同关键条款抽取。用最小技术栈做出可用demo，业务部门边用边提问题。
- 第二阶段（1到2个月）：把场景扩大到3到5个，建设知识库数据流水线和工具调用规范，网关在这期间必须建好并接入所有模型。
- 第三阶段（继续迭代）：形成平台的标准化接入流程，开放给更多业务团队，同时做模型效果评测体系与成本运营体系。
7.2 我在实际项目中踩过的几个大坑
下面这些坑都是我真实经历过的，写出来给大家提个醒。
第一个坑是多模态能力没验证就选型。有个项目需要解析大量带表格的合同扫描件，选型时只比了文本能力，上线后才发现本地部署的小模型对复杂表格理解很差，最后不得不紧急切换方案。在多模态场景上，建议直接拿业务真实的复杂票据、表格和手写样本做评测，不要轻信宣传口径。
第二个坑是低估了文档预处理的工作量。RAG项目里真正花时间最多的不是向量化和Prompt，而是把几万份格式混杂的文档清洗成结构化文本。早期没有做元数据管理，后期权限隔离和知识更新都很难做。文档接入最好一开始就建立“来源、部门、密级、更新日期”这些字段，否则一边是知识库越来越乱，一边是检索效果越来越差。
第三个坑是模型一换，整套链路就要跟着调。不同模型的输出格式、上下文偏好和幻觉分布差异很大，评估时不能只看单条回答好不好，而要在统一评测集上跑分对比。如果从开源小模型切到商用大模型，Prompt也需要重写一遍，不存在“提示词一套通吃”的好事。
7.3 几个越早知道越好的经验
排错的时候要先看日志再做猜测。大模型应用的问题链路很长，用户说“回答不对”，可能是Prompt指令不清晰、文档没检索到、模型吐字截断或者网关超时。要有全链路日志可以帮助我们快速定位是哪个环节有问题。
将业务指标引入评测至关重要。“回答流畅”不等于“平台有业务价值”，真正该看的是“客服转人工率是否下降”“文档检索时间减少多少”“流程自动化节省多少人天”。用这些指标向上汇报，比展示酷炫的Demo更有说服力。
持续跟踪模型迭代很重要。这两三个月就有新模型发布，内部模型效果很快会过期。所以平台上所有模型版本都要可控，老版本要保留一段时间，方便对比和紧急回滚。每个模型版本上线前都要重新跑一遍评测集和红队测试，不能默认“新版一定更好”。
7.4 关于企业AI全栈平台的最后一点提醒
从去年到现在，我最大的感受是：搭建企业AI全栈平台在技术上已经不是一件特别玄乎的事情，真正的难点反而在组织协同和工程化意识上。很多项目做着做着就烂尾，不是因为模型不够强，而是因为没有清晰的架构分层，没有统一的接入规范，没有坚持做评测与审计。
如果只能带走一条经验，我希望是：先把接口、日志、权限这些“不性感”的工程细节做扎实，再谈模型能力的发挥。给自己设定一个用业务指标说话的阶段性目标很重要，埋头搭平台搭三个月不上线，团队的热情和老板的耐心都会被耗光。
我另一个建议是尽量选用OpenAI兼容协议作为全平台统一的模型接口标准。如今无论是Ollama、vLLM还是主流商业API，对这套协议的支持都非常完善。把标准定在这里，平台就拥有了最大的兼容性和最灵活的可替换性。以后想换模型、接本地模型，只是配置变更，而不是代码重写。
最后想说，这个领域的变化很快，今天写的具体工具名称可能几个月后就有更优的选择。所以比记住某个工具更重要的是理解每个技术环节的作用：为什么要统一网关，为什么要先做RAG再做微调，为什么安全评测不是一次性的，搞懂这些底层逻辑之后，无论工具怎么变，你都有一套稳定的判断框架来应对。