杜不知道过去大半年，我几乎每个月都要回答同一个问题：“大模型我们都验证过了，为什么到了业务侧还是用不起来？” 很多团队不是缺模型，而是缺一套能把大模型从 Demo 推到生产环境的完整链路。所谓企业AI全栈平台，不是“接一个 API、套一个聊天框”那么简单，它要贯通算力、模型、数据、应用和运营，让 AI 能力真正长在业务系统里。这篇内容是我个人从零搭建这一整套平台的经验沉淀，覆盖硬件评估、模型选型、本地部署、RAG/Agent 编排、微调上线和日常排查。适合 AI 平台工程师、技术负责人、解决方案架构师阅读，如果你正准备推企业级大模型解决方案，可以先收藏再慢慢对照落地。
1. 为什么现在需要一套企业AI全栈平台
1.1 业务侧的真实困境：模型很多，能用起来的不多
几乎每个企业都经历了类似的过程：年初买了一堆大模型 API 或者下载了开源模型，在技术团队内部做了不少 PoC，效果看起来都不错，可真让业务部门用的时候，问题就出来了。第一个问题是数据不通，模型不知道企业内部订单、工单、知识库里的内容；第二个问题是流程不通，业务人员需要一个入口，而不是命令行或 Notebook；第三个问题是权限不通，谁能调用哪个模型、能看到什么数据，完全没有边界；第四个问题是迭代不通，模型升级、提示词调整、数据集更新，全部靠手工操作，出问题也没法回溯。
这些问题不是单个模型能力不够造成的，而是缺一个“平台层”来承接。我见过不少团队在单个模型上花了很多精力，最后发现瓶颈在工程侧：没有统一的模型管理，没有规范的数据接入方式，没有可复用的 API，没有监控和灰度机制。企业AI全栈平台的价值，就是把零散的模型能力收敛成一套企业内部的 AI 基础设施，让业务线通过标准接口使用大模型，而不是每次从零搭一套。
1.2 平台需要解决的四件事：算力、数据、应用、迭代
我习惯把企业AI平台的核心职责归纳成四件事。
算力层要管好 GPU/NPU，让不同团队共享推理资源，同时能看到每个模型服务的成本消耗。数据层要做“企业私域知识和模型的连接”，常见手段是 RAG，包括文档解析、向量化、检索、重排，再深一层才是针对特定场景的微调数据管理。应用层要支持 Chatbot、Copilot、自动化工单、AI Agent 等不同形态，不能每个应用都自建一套底层。迭代层要做模型版本管理、Prompt 管理、效果评测、Badcase 回流，保证平台不是上线即静止，而是越用越准。
这四个层面互相依赖，也是“全栈”二字的含义。如果只做其中一两层，后续要补课的代价会非常高。比如只顾着把模型跑起来，没有设计好 API 网关，等业务接入到第十个应用后就会发现权限和限流完全失控。所以下面的架构我先给整体，再拆落地步骤，尽量帮你少走几趟弯路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 企业AI全栈平台的整体架构：先看清全貌再动手
2.1 从底层到前端，我的平台分层习惯
我设计平台时习惯分成六层：基础设施与资源层、模型与数据层、推理服务层、AI应用编排层、开放能力网关层、业务交互层。
基础设施与资源层包含 GPU 服务器、存储、Kubernetes 或虚拟机、对象存储，这些是所有上层能力的底座。模型与数据层负责管理基础模型、微调模型、Embedding 模型，以及企业内部的知识库数据。推理服务层承担模型的加载和对外服务，常见的有 Ollama、vLLM、Triton，这一层决定了响应速度和并发上限。AI应用编排层是核心，负责把模型能力包装成实际应用，包括 RAG 检索、Agent 工具调用、工作流设计、Prompt 模板管理。开放能力网关层为业务系统提供统一 API，做鉴权、限流、审计、灰度。最上面业务交互层则是 Web 页面、IM 机器人、工单系统插件、低代码平台等。
很多团队在初期把 2、3、4 层混在一起做，模型既加载又编排又对外暴露接口，开始时觉得方便，一旦场景多起来就非常混乱。我自己的教训是，只要超过两个业务团队要用大模型，就值得把推理服务和应用编排拆开。
2.2 技术选型逻辑：为什么先从开源模型加企业框架切入
不少朋友问我选型是不是越新越好，我的答案从来都是“看团队现状”。如果团队以 Java 为主，Spring AI 就很自然；如果以 Python 为主，LangChain/LlamaIndex 生态更合适；如果强依赖低代码流程编排，还需要引入专门的 Agent Workflow 引擎。
模型侧，我的建议是先默认选开源模型，例如 Qwen2.5-7B/14B 这类中文能力稳定的版本，优先私有化部署。原因很直接，企业内部知识库和对话记录往往涉及核心数据，直接调用外部 API 很难过合规审查；另一方面，私有化模型可以针对业务语料做定制，成本可控。但这不代表外部 API 就不能用，适合没有严格数据隔离、需要快速上线的通用场景，可以走混合路线。
完整选型的取舍，我用下面的表格说明：
| 维度 | 私有化开源模型 | 外部模型API | 混合方案 |
|---|---|---|---|
| 数据安全 | 高，数据不出内网 | 低，取决于服务商协议 | 可配置策略，敏感数据走私有化 |
| 初始成本 | 高，需要GPU采购 | 低，按Token计费 | 中等，需要对资源精细规划 |
| 上线速度 | 慢，需要部署调优 | 快，只需半天接入 | 中等，要额外开发路由规则 |
| 适用场景 | 企业私域知识、办公助手、客服机器人 | 通用问答、多语言翻译、图片理解 | 业务分链路路由，成本与安全平衡 |
2.3 从零到落地的基本路径：先“横切”后“竖切”
不建议一上来就大而全建设平台，正确切入方式应该是“先横切后竖切”。横切是先把模型服务、统一API、权限和日志做成公共能力，每一个新项目不再重复造轮子。竖切是先选一个高频业务场景，比如内部知识问答或售后客服助手，完整跑通全链路，反过来验证平台能力。
我经历过一次反例。当时团队先花两个月搭了完整的模型训练平台，功能做得非常完善，但业务并没有准备好，最后一大堆模块进入空转。后来调整为“一个场景打穿再复制”，效果反而快了很多。所以本文的落地顺序也是：先让你快速把模型服务跑起来，再做 RAG/Agent，再做微调和安全评测，最后才是规模和成本治理。
3. 从零部署：先让大模型在本地稳定跑起来
3.1 硬件评估：先算清楚显存和并发这笔账
很多项目死在第一步，不是模型不好，是服务器撑不住。企业部署模型前必须算清楚显存账。以 Qwen2.5-7B-Instruct 为例，FP16 精度下光模型权重大约需要 14GB 显存，部署 8K 上下文还需要额外的 KV Cache，建议至少准备 24GB 显存的显卡，比如 RTX 4090、L4 或 A10。如果是 14B 模型，FP16 权重约 28GB，要跑在 40GB 以上的 A100/A800/L40S 上，或者用 4bit 量化压缩到不到 10GB。
我自己常用的估算公式是：
- FP16 权重显存 ≈ 参数量 × 2 字节
- KV Cache 显存 ≈ 层数 × 头数 × 隐藏层维度 × 序列长度 × 精度系数
- 实际预留空间 = 权重显存 + KV Cache + 约 20% 冗余
如果暂时拿不准，最简单的办法是先用 4bit/8bit 量化模型跑通流程，上线前再根据实测显存扩容。记住一个原则：不要为了省成本把显卡显存压到 80% 以上，推理峰值会产生尖峰，很容易 OOM。
3.2 Ollama 快速拉起第一个模型服务
在企业内部验证阶段，Ollama 是非常合适的起点。它把模型下载、量化和本地 API 做了极致封装，一条命令就能跑起一个 OpenAI 兼容服务。
执行以下命令：
bash复制# 安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 拉取并运行中文能力不错的 qwen2.5:7b
ollama pull qwen2.5:7b
ollama run qwen2.5:7b "今天天气怎么样？"
# 启动服务（默认监听 127.0.0.1:11434）
ollama serve
如果希望局域网内其他应用访问，需要设置环境变量，例如 OLLAMA_HOST=0.0.0.0，同时一定要通过防火墙只放行公司内网 IP。Ollama 默认没有完善的鉴权，直接暴露到公网是非常危险的做法。
上层应用对接时，直接使用 OpenAI 兼容接口即可：
bash复制curl http://127.0.0.1:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen2.5:7b",
"messages": [{"role": "user", "content": "你好"}]
}'
Ollama 适合单机和小并发场景，一旦线上请求量超过几十并发，就需要切到 vLLM。
3.3 vLLM 把推理服务变成生产可用
vLLM 是目前我强烈推荐的生产级推理引擎。它通过 PagedAttention 管理 KV Cache，内存利用率比常规方案高很多，配合 Continuous Batching 能在大并发下显著降低排队时间。
安装并启动一个 OpenAI 兼容服务：
bash复制pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size 1 \
--dtype auto \
--max-model-len 8192 \
--gpu-memory-utilization 0.90
部署后同样可以用 /v1/chat/completions 路径测试，兼容之前的调用。需要注意，vllm serve 命令在启动时会加载模型权重，第一次可能要等几分钟，这是正常现象。
生产环境里我通常会关注三个参数：
- max-model-len 控制最长上下文，设太大显存会爆，一般按业务最大长度加 20% 余量设置。
- gpu-memory-utilization 建议不超过 0.92，否则容易在动态请求下触发显存不足。
- tensor-parallel-size 用于多卡并行，跨卡通信需要 NVLink。没有 NVLink 的多卡并行效果可能还不如单卡。
3.4 企业 Java 团队如何快速接入：Spring AI
很多企业后端是 Java 技术栈，如果直接让业务团队用 Python 客户端对接模型服务，开发成本会很高。Spring AI 在这两年已经比较成熟，支持 OpenAI 协议，只需要配置模型服务地址就能快速接入。
以 vLLM 或 Ollama 开出的接口为例，首先在 pom.xml 引入依赖：
xml复制<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-openai-spring-boot-starter</artifactId>
<version>当前稳定版本</version>
</dependency>
然后在 application.yml 里配置：
yaml复制spring:
ai:
openai:
base-url: http://127.0.0.1:8000/v1
api-key: unused-key
chat:
options:
model: Qwen/Qwen2.5-7B-Instruct
temperature: 0.3
max-tokens: 2048
代码里注入 ChatClient 即可调用：
java复制@Service
public class AiAssistantService {
private final ChatClient chatClient;
public AiAssistantService(ChatClient.Builder builder) {
this.chatClient = builder.build();
}
public String ask(String question) {
return chatClient.prompt(question).call().content();
}
}
这里有一个经验：企业里做技术选型，不是选最火的，而是选团队最容易长期维护的。Java 团队强行用 Python 重构服务化链路，后续运维和人才补充都会遇到阻碍。Spring AI、LangChain4j 这类框架的存在，就是让不同语言团队都能把大模型能力平滑嵌入现有体系。
4. 打通业务：RAG、Agent 与实际应用开发
4.1 RAG 是让模型拥有企业知识的最快路径
部署好模型以后，下一个需求通常是“让它知道公司资料”。我相信你很快会发现，直接问模型公司制度，它要么胡说，要么说不知道。正确做法是上 RAG，也就是检索增强生成。
我的标准 RAG 流程是：文档收集 → 格式统一与清洗 → 切片 → 向量化 → 写入向量库 → 检索 → 重排 → 注入 Prompt → 生成。文档来源包括 Word、PDF、Markdown、网页和数据库字段。这里最容易忽略的是“清洗”，一篇带大量页眉页脚、表格错位的 PDF，直接切分后检索质量会很差。
一个基于 Python 的最小实现思路如下：
python复制from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Milvus
# 1. 加载并清洗文档
loader = TextLoader("company_policy.md")
documents = loader.load()
# 2. 按语义边界切分
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=100,
separators=["\n\n", "\n", "。", "！", "？", " "]
)
chunks = splitter.split_documents(documents)
# 3. 向量化并写入Milvus
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-m3")
vector_store = Milvus.from_documents(
chunks,
embeddings,
connection_args={"host": "127.0.0.1", "port": "19530"}
)
检索端最影响体验的两个细节是 TopK 和重排。TopK 太大，无关片段会稀释答案；太小，重要信息可能被漏掉。我通常先取 20~30 个候选，再经过 bge-reranker 重排后取前 5 个放进 Prompt。不要直接拿向量相似度最高的前几个拼接，企业知识库经常有多段内容互相干扰，重排能显著提高回答准确率。
4.2 打造 Agent：从“能聊”到“能干活”
RAG 解决“知道什么”的问题，Agent 解决“能做什么”的问题。比如查订单、创建工单、生成周报，这些动作不能只靠文本问答，需要让模型学会调用工具。一个完整 Agent 核心包括三部分：意图识别、工具注册、任务规划与执行。
我常用 Spring AI 的注解式 Tool 来给模型注册工具，业务团队自己的服务类签名即可：
java复制@Component
public class OrderTools {
@Tool("根据订单号查询订单状态，参数orderId为订单编号")
public String getOrderStatus(String orderId) {
// 调用内部订单服务
return orderService.queryStatus(orderId);
}
@Tool("创建内部支持工单，参数title为标题，content为内容")
public String createTicket(String title, String content) {
// 写入工单系统
return ticketClient.create(title, content);
}
}
模型在对话过程中会根据用户问题自动决定是否调用这两个方法。这里一定要注意：涉及资金支付、删除数据、发送外部消息、批量操作等敏感动作，不能只让模型自动决定。我给平台的规矩是“高风险动作必须挂人工审批节点”，Agent 完成动作意图识别后先暂停，等待用户在界面上确认，然后才真正执行。
另外关于循环控制，也踩过不少坑。模型在复杂任务上可能出现反复调用同一个工具的环，比如一直查询、一直失败、再一直查询。我通常在 Agent 编排里加两层控制：最大调用次数限制，比如 5~8 次；工具调用结果的格式校验，如果返回“未找到订单”，就直接终止并转人工，不要继续尝试。
4.3 开发效率工具的合理使用：Cursor 与代码审查
在搭建这些代码的过程中，我确实用 Cursor 来做辅助编程，写 SQL、调试提示词模板、生成单元测试，效率很高。但有一点必须提醒，不要直接把 AI 生成的代码原样部署到企业生产环境，尤其是权限校验、支付、数据脱敏相关逻辑，必须由有经验的工程师逐行 Review。
Cursor 类工具本质上是在 IDE 里增加了一个极聪明的结对程序员，但它不理解你所在公司的数据模型和合规约束。我自己的做法是，先让它生成整体代码骨架，然后把关键业务规则的提示词写得非常具体，再人工补充边界校验。把 AI 当“初级工程师”而不是“最终决策者”，这样能获得效率提升，又不会给平台埋雷。
5. 垂直场景优化与大模型微调：什么时候调、怎么调
5.1 微调之前，先用“三步法”排除其他原因
很多团队一遇到模型回答不专业，就急着微调，结果既贵又慢。我给客户的判断流程是三层：先检查 RAG 检索是否召回正确；再检查 Prompt 是否写清格式和约束；最后才考虑微调。
如果知识库里明明有答案，但模型回答时漏掉关键条款，是检索和 Prompt 的问题。如果模型能用自然语言回答，但必须输出严格 JSON 结构且经常出错，这时候可以考虑微调来增强格式能力。如果希望能模仿企业固定话术、客服风格、历史票单处理逻辑，那微调是合适的。微调不是给模型补知识，补知识用 RAG，微调是学“表达方式”和“任务结构”。
5.2 用 LoRA 在单卡上做轻量化微调
全参数微调在资源有限的企业内不太现实，LoRA 是目前性价比最高的选择。它的原理是冻结原模型参数，只训练注入的低秩矩阵，显存占用大幅下降，很多 7B 模型在单卡 24GB 上也能完成。
训练数据建议采用对话格式，简单通用：
json复制[
{
"instruction": "请根据内部客服规范回复用户问题",
"input": "我的订单已经付款三天了，为什么还没有发货？",
"output": "您好，非常抱歉给您带来不便。为您核实到订单目前已进入仓库处理阶段，预计最迟明天18点前完成出库。"
}
]
用 PEFT 实现 LoRA 的核心代码如下：
python复制from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model, TaskType
model_path = "Qwen/Qwen2.5-7B-Instruct"
model = AutoModelForCausalLM.from_pretrained(
model_path,
torch_dtype="auto",
device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_path)
lora_config = LoraConfig(
task_type=TaskType.CAUSAL_LM,
r=16,
lora_alpha=32,
lora_dropout=0.05,
target_modules=["q_proj", "k_proj", "v_proj", "o_proj"]
)
peft_model = get_peft_model(model, lora_config)
训练时观察指标，一般分三类：训练 Loss 是否下降、验证集 Loss 是否同步下降、以及最终的 Badcase 人工评估。如果训练 Loss 在降，但业务效果没有改善，大概率是你给 LLM 的任务目标错了，或数据集质量差。LoRA 参数 r 越大，可学习容量越大，也越容易过拟合；r=8~32 是 7B~14B 模型的常见区间。
5.3 上线前必须过的安全与评测关
模型上线之前，一定要做系统化评测，不能只看两三个 Demo 顺不顺利。我建议每个模型至少准备三个测试集：通用能力测试集、垂直领域测试集、安全与对抗测试集。垂直领域测试集来源是历史客服记录、老系统里的典型工单；安全与对抗测试集则用来检验模型会不会被诱导产生违规输出、会不会错误引用无关文档、会不会在用户输入明显恶意时仍然照做。
我在实际中还坚持一个“数据卫生”原则：微调数据必须经过合法授权，并做敏感信息脱敏，不能把真实手机号、身份证号送进训练集。训练数据来源不清的模型权重尽量不要直接合并到企业内网。数据污染一旦发生，后期排查成本极高，这比损失一点模型效果更值得关注。
评测通过以后，再走灰度发布。先让 10% 流量切到新模型，看人工反馈和系统监控，确认没有异常再全量切换，同时保留旧模型回滚能力。模型版本管理这时候就很关键，一个模型服务不能总把名字写成 qwen2.5，要做到版本后缀可追踪。
6. 常见问题与排查技巧实录
6.1 一张表看清高频故障的排查方向
我把自己和同行在部署运维中经常遇到的问题整理成速查表，这比背文档要有用得多：
| 现象 | 可能原因 | 优先排查项 |
|---|---|---|
| 响应变慢，并发一高就超时 | 推理引擎没有开启连续批处理 | 确认 vLLM 是否启用，单机并发是否达到上限 |
| 回答内容与知识库矛盾 | RAG 检索到错误片段 | 先看检索结果的 Top5 是否相关 |
| 显存 OOM | 上下文长度设置过大或并发控制缺失 | 降低 max-model-len，重启后观察显存曲线 |
| Agent 总是重复调用工具 | 工具返回信息不明确 | 优化工具返回结果，增加终止条件 |
| 同样的 Prompt 每次回答不一致 | temperature 过高 | 设置为 0 或 0.1，必要时加确定性策略 |
| 微调后通用能力明显下降 | LoRA r 太大或训练过拟合 | 降低 r，增加数据多样性，控制训练轮次 |
6.2 性能优化：从能跑到高可用
平台刚起步时并发很低，很多问题不会暴露。一旦让整个公司都用，性能优化就必须跟上。我习惯按四条线推进：推理优化、检索优化、缓存优化、异步化。
推理优化主要靠 vLLM 的 Continuous Batching，把多个用户请求动态拼接到一个 batch 里，单卡吞吐量经常是朴素的 FastAPI 方案的 3~5 倍。检索优化重点在 Embedding 模型和重排模型的选择，BGE 系列和企业内部知识库适配性值得做对比测试。缓存优化也很重要，高频问题完全可以做语义缓存，相同意图的问题直接命中结果，不需要再跑一次大模型，成本降低非常明显。异步化则适用于日报生成、批量审核摘要等任务，这些场景能容忍几十秒返回，接消息队列比同步等待更适合。
真实优化过程中，要先用监控找瓶颈，不要一上来就买新卡。我见过一个系统觉得模型慢，实际瓶颈在登录鉴权接口，每次请求都同步查数据库，真正的大模型推理只占耗时三分之一。
6.3 成本治理：让业务部门不是“乱烧 Token”
企业 AI 平台上线一段时间后，成本会变成管理层最关心的问题。平台侧需要做到每个应用、每个部门都能看到 Token 消耗。我们在网关层记录了每次请求的模型名、输入输出 Token 数、调用方、耗时和成本，生成一张简单报表。
成本控制不只是技术的事，还需要一套路由策略。比如标题生成、关键词抽取这类简单任务，直接用小参数模型，完全没必要上 70B；只有复杂推理、长文本总结才路由到最强模型。还有一个经验是给对话类应用设计合理的上下文窗口，很多团队把每轮历史全部送到模型，导致 Token 翻倍增长。我一般只保留最近 6~8 轮对话，并且给用户设置单次最大 Token 数，这样单次成本可控。
6.4 数据回流：把业务反馈变成平台资产
平台要想持续变好，必须建立数据反馈闭环。我在应用侧增加了“反馈”按钮，用户可以对模型回答点有用/无用，并填写原因。后台每天把无用反馈集中起来，专家定期标注形成 Badcase 集。这个 Badcase 集有两个用途：一是回归测试，模型升级前必须跑一遍；二是挑选后进入微调数据集，让模型持续改善。
这里最容易被忽略的是“坏数据”回流。如果用户误点了有用，或者标注员只凭个人喜好判断，把这些数据直接丢进训练集反而会拉低效果。我建议 Badcase 必须经过“二次确认”再入库，比如同一问题至少两条独立反馈，或者由业务骨干审核后再进入数据集。
7. 复盘经验与收藏建议
做完整套企业AI全栈平台之后，我把最后沉淀成几条对后来者比较有帮助的经验，放在这里供你参考。
第一，不要把“模型部署成功”当项目里程碑。模型跑起来只是开始，真正的交付是业务反馈、成本数据和可复用的能力接口。第二，尽量让平台从第一天就具备灰度能力。任何模型和提示词的变更都可以走“小流量验证、逐步放量”的流程，不要直接全量替换，否则一次 Prompt 调整都可能引发线上事故。第三，AI平台的雷点大多在数据侧。权限、脱敏、数据来源授权、标注质量，这些看似枯燥的工作，恰恰决定模型效果和安全底线，值得用更高优先级对待。
最后再分享一个小技巧：架构设计时，把“API 网关层”提前到第一周做，哪怕最开始只做一个简易 Nginx 转发加 Token 日志，也比后续补要省力得多。我自己早期就是因为没有这层，每次加新应用都要重新配鉴权，维护得很痛苦。只要熬过“从零到第一个业务场景贯通”的坎，后面的扩展会顺畅很多。这套平台没有终点，它应该随着业务数据不断演进。今天能收藏的不只是指南，更是你们企业 AI 落地时减少试错的一条路线。