企业级LLM平台落地实战：从Demo到生产的六层架构与工程避坑指南

1. 企业级 LLM 落地，为什么“能跑通 Demo”和“能上生产”之间隔着一整条鸿沟

做过 LLM 项目的人大概都有这种体验：本地拿个开源模型，接上 LangChain，写个 RAG 问答，半天就能跑出一个看起来像模像样的 Demo。可一旦要把这套东西搬到企业环境里，面对几十个业务部门、上百个并发用户、一堆合规审计要求，之前那套“能跑就行”的代码瞬间就崩了。企业级 LLM 和实验室里的 LLM 完全是两码事，前者要解决的核心问题不是“模型能不能回答”，而是“回答得稳不稳、快不快、准不准、管不管得住、花不花得起”。

我前后参与过几个从零到一的企业级 LLM 平台搭建，踩过的坑从模型选型一路延伸到网关限流、Token 计费、知识库权限隔离、Agent 工具调用的幂等性。这个系列写到第九篇，我打算把之前散落在各篇里的工程细节收拢一下，重点聊企业级场景下那些“Demo 阶段根本不会遇到、生产阶段天天遇到”的问题。如果你正在负责公司内部的 LLM 平台建设，或者准备把某个 RAG 应用推给真实用户使用，这篇内容应该能帮你少走至少三个月的弯路。

先明确一下“企业级 LLM”在我这里的定义：它不是指某个具体的大模型，而是指一套围绕 LLM 构建的、能满足企业生产要求的完整技术栈。这套栈至少包含模型服务层、网关层、知识库层、Agent 编排层、可观测层和成本管控层。任何一层缺失，系统都会在某个时刻以你意想不到的方式出问题。下面我按实际落地顺序，把这六层里最关键的工程决策和实操细节拆开讲。

2. 模型服务层：企业级场景下模型选型的五个硬指标

2.1 为什么“榜单排名”在企业选型里几乎没用

Open LLM Leaderboard 这类公开榜单我每周都会看，但说实话，它对企业选型的参考价值非常有限。榜单测的是 MMLU、GSM8K 这类学术基准，而企业真实场景里跑的是“从一份 80 页的合同里抽出甲方违约责任条款并对比三个版本差异”这种任务。学术分数高的模型，在长文档结构化抽取上未必比一个中等规模但经过针对性微调的模型强。

我自己的选型流程是这样的：先根据业务场景列出 5 到 10 个真实任务，每个任务准备 20 到 50 条测试样本，然后拿候选模型跑一遍，看准确率、延迟、Token 消耗三个指标。这个过程大概需要两天，但能避免后面几个月的返工。榜单只用来做初筛，把明显不合适的模型排除掉，比如参数量太小导致中文理解能力不足的，或者上下文窗口不够处理长文档的。

2.2 显存、并发与量化：三个必须一起算的账

企业级部署绕不开显存计算。一个 70B 参数的模型，FP16 精度下光权重就要占 140GB 左右，加上 KV Cache 和中间激活值，单卡 80GB 的 A100 至少需要两张才能跑起来。如果业务要求并发 50 路，每路上下文 8K，KV Cache 的显存占用会迅速吃掉剩余空间。这时候要么上更多卡，要么用量化。

量化方案我实测下来，INT8 量化对大多数抽取和分类任务的影响在可接受范围内，精度损失大概 1 到 3 个百分点，但显存直接减半。INT4 量化就要谨慎了，生成类任务容易出现重复和逻辑断裂，尤其是中文长文本生成。我的建议是：抽取、分类、路由这类判别式任务可以用 INT4，生成和推理类任务至少保持 INT8，关键业务用 FP16。

并发能力的估算有个粗略公式：单卡吞吐量 ≈ (显存总量 - 模型权重占用) / (单请求 KV Cache 占用 × 平均并发数)。以 2×A100 80GB 跑 70B INT8 为例，权重约 70GB，剩余 90GB 给 KV Cache，8K 上下文单请求约 1.2GB，理论上能支撑 70 路左右并发。但实际还要留 20% 余量给激活值和碎片，所以标称 50 路并发是比较稳妥的。

2.3 推理框架选型：vLLM、TGI 还是 TensorRT-LLM

这三个框架我都用过，简单说结论：vLLM 的 PagedAttention 对变长请求的吞吐优化最好，社区活跃，部署简单，适合大多数企业场景；TGI 对 HuggingFace 生态兼容性最好，但吞吐略逊；TensorRT-LLM 性能最强，但编译和调优成本高，适合有专门推理优化团队的大厂。

vLLM 的部署命令大概长这样：

python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-72B-Instruct-AWQ \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 64 \ --quantization awq

这里--gpu-memory-utilization 0.90是关键参数，默认 0.9 已经比较激进，如果发现 OOM 就降到 0.85。--max-num-seqs控制同时处理的请求数，设太高会导致 KV Cache 频繁换入换出，反而降低吞吐。我一般从 32 开始压测，逐步加到 64 或 128，找到吞吐拐点。

注意：vLLM 启动时会预分配显存，如果和其他服务共享 GPU，一定要用--gpu-memory-utilization限制，否则会把整张卡吃满导致其他进程崩溃。

3. LLM 网关层：企业级流量的统一入口与管控中枢

3.1 网关到底要解决什么问题

很多人觉得网关就是个反向代理，把请求转发到后端模型服务就行。但在企业环境里，网关承担的责任远不止转发。它要处理认证鉴权、限流熔断、Token 计量、请求路由、敏感词过滤、日志审计、多模型适配这一整套事情。没有网关，每个业务应用都要自己实现这些逻辑，重复造轮子不说，安全策略还无法统一。

我见过最典型的事故是：某个业务团队直接调用模型服务的内网地址，绕过了网关的限流，结果一个批量任务把 GPU 打满，导致其他所有业务线的 LLM 功能全部超时。所以企业级部署的第一条铁律是：模型服务只对网关暴露，任何业务应用不得直连。

3.2 多模型路由策略：按任务类型分发

企业里通常不会只用一个模型。便宜的小模型处理简单分类和路由，贵的大模型处理复杂推理和生成，这是最基本的成本优化手段。网关需要支持按请求内容或元数据路由到不同后端。

路由策略我一般配三层：第一层按model字段显式指定，业务方明确知道自己要用哪个模型；第二层按任务类型自动路由，比如请求里带task: classification就走小模型；第三层是兜底，默认走主力模型。这样既给了业务方灵活性，又能在他们不指定时自动做成本优化。

3.3 Token 计量与成本分摊：财务最关心的一层

企业级 LLM 平台如果不对 Token 做计量，月底财务找过来问“这个月 AI 花了多少钱、哪个部门用的”，你答不上来就很尴尬。Token 计量要在网关层做，因为只有网关能看到完整的请求和响应。

计量逻辑不复杂：请求进来时用 tokenizer 算 prompt tokens，响应返回时算 completion tokens，然后按模型单价乘出费用，打上部门、应用、用户三个维度的标签写入时序数据库。这里有个坑：流式响应的 completion tokens 需要在流结束时统计，不能边流边算，否则会重复计数。另外不同模型的 tokenizer 不一样，网关要维护一个 tokenizer 映射表，按模型名加载对应的 tokenizer。

成本分摊表大概长这样：

3.4 限流与熔断：保护后端不被冲垮

限流策略要分两个维度：按用户/应用的 QPS 限流，和按全局 Token 消耗速率的限流。前者防止单个应用占用过多资源，后者防止整体成本失控。我一般给每个应用配一个 Token 预算，比如每分钟 10 万 Token，超了就返回 429 并提示稍后重试。

熔断则是当后端模型服务响应时间超过阈值或错误率超过阈值时，网关自动切断流量并返回降级响应。降级响应可以是一个缓存的标准答案，或者提示用户“当前服务繁忙”。这个机制在模型服务重启或升级时特别有用，能避免大量请求堆积导致雪崩。

4. 知识库与 RAG：企业级知识管理的核心工程

4.1 为什么企业知识库不是“把文档塞进向量库”这么简单

RAG 的 Demo 版本确实简单：文档切块、embedding、存向量库、检索、拼 prompt。但企业级知识库要处理的问题复杂得多。首先是权限，不同部门的文档不能互相看见，检索时必须带上权限过滤。其次是版本，同一份制度文档有 2023 版和 2024 版，检索时要优先返回最新版。再次是结构化，表格、流程图、附件这些非纯文本内容怎么处理。最后是更新，文档改了之后向量库怎么增量同步。

我踩过最大的坑是权限过滤。早期版本忘了在检索时加权限条件，结果测试时用 A 部门的账号搜出了 B 部门的薪酬文档，虽然只是测试环境，但足以说明问题的严重性。后来我们在向量库的 metadata 里强制写入dept_id和acl字段，检索时用 filter 表达式做前置过滤，确保不会召回无权限的文档。

4.2 文档切块策略：按语义切还是按固定长度切

固定长度切块（比如 512 token）实现简单，但会把一个完整的段落或表格切断，导致检索到的片段语义不完整。语义切块用 NLP 方法识别段落、标题、列表边界，切出来的块更完整，但实现复杂且依赖文档格式。

我的折中方案是：对 Markdown 和 HTML 这类有明确结构的文档用语义切块，按标题层级切；对 PDF 和 Word 这类格式先用解析工具转成 Markdown，再走语义切块；对纯文本用固定长度加重叠窗口，重叠 20% 左右保证边界信息不丢失。切块大小我一般控制在 300 到 800 token 之间，太小检索精度高但上下文不足，太大检索精度下降但上下文完整。

4.3 混合检索：向量检索加关键词检索才是企业级标配

纯向量检索在语义相似度上表现好，但对专有名词、产品型号、人名这类精确匹配的场景容易漏召回。企业知识库里大量存在“XX-2024-001 号文件”这种精确标识，纯向量检索经常找不到。所以企业级 RAG 必须上混合检索：向量检索负责语义召回，BM25 负责关键词召回，然后用 RRF（Reciprocal Rank Fusion）融合两路结果。

RRF 的公式很简单：score = Σ 1/(k + rank_i)，k 一般取 60。两路检索各返回 top 50，融合后取 top 10 送给 LLM。实测下来，混合检索比纯向量检索在专有名词查询上的召回率能提升 30% 以上。

4.4 GraphRAG 与 LLM Wiki：知识组织的进阶玩法

最近 GraphRAG 和 LLM Wiki 这两个概念很热。GraphRAG 的核心思路是把文档里的实体和关系抽出来构建知识图谱，检索时同时走图谱和向量两条路。LLM Wiki 则是用 LLM 自动把零散文档整理成结构化的 Wiki 页面，每个页面有明确的主题和交叉引用。

我在一个内部技术文档场景试过 GraphRAG，效果确实比纯 RAG 好，尤其是需要跨文档推理的问题，比如“A 系统的接口变更会影响哪些下游服务”。但构建图谱的成本不低，实体抽取和关系抽取都要调 LLM，一个 1000 篇文档的库大概要花几十万 Token 的处理费用。所以我的建议是：核心知识库值得上 GraphRAG，边缘知识库用混合检索就够了。

5. Agent 编排层：从“问答”到“办事”的关键一跃

5.1 企业级 Agent 和 Demo Agent 的本质区别

Demo Agent 通常是“给 LLM 几个工具，让它自己决定调哪个”。企业级 Agent 要考虑的问题多得多：工具调用的权限控制、调用的幂等性、失败重试、超时处理、人工审批节点、调用链追踪。我见过一个 Agent 因为工具调用没有做幂等，重试时重复提交了两次工单，虽然最后人工发现并撤销了，但这种问题在生产环境是绝对不能接受的。

企业级 Agent 的编排我一般用状态机而不是纯 ReAct。状态机的好处是每一步的输入输出都明确，容易做校验和审计。比如一个报销审批 Agent，状态机定义“解析申请→校验预算→校验合规→主管审批→财务审批→打款”六个状态，每个状态之间的转移条件明确，LLM 只在需要理解自然语言的地方介入，其他环节用确定性代码处理。

5.2 工具调用的三个安全原则

第一，最小权限。Agent 能调用的工具列表要按业务场景配置，不能给一个通用 Agent 开放所有工具。第二，参数校验。LLM 生成的工具参数必须经过 schema 校验，类型不对、范围不对的直接拒绝。第三，敏感操作二次确认。涉及资金、权限变更、数据删除的操作，必须有人工确认环节，不能全自动执行。

5.3 Agent 的可观测性：调用链追踪怎么做

Agent 的执行链路比普通 API 调用长得多，一个请求可能经过 LLM 推理、工具调用、再推理、再调用，来回五六轮。没有调用链追踪，出了问题根本不知道是哪一步卡住了。我的做法是在网关层生成一个 trace_id，贯穿整个 Agent 执行过程，每一步的输入输出、耗时、Token 消耗都记录到追踪系统里。

追踪数据我一般保留 30 天，热数据存 Elasticsearch 方便查询，冷数据归档到对象存储。查询界面支持按 trace_id、用户、应用、时间段检索，能快速定位到具体是哪一步出了问题。

6. 可观测与成本管控：让 LLM 平台“花得明白、跑得放心”

6.1 四个必须监控的核心指标

企业级 LLM 平台的监控指标不用多，但四个核心指标必须有：请求成功率、P99 延迟、Token 消耗速率、缓存命中率。成功率低于 99% 就要告警，P99 延迟超过 5 秒要排查，Token 消耗速率突增要查是不是有异常调用，缓存命中率下降要检查缓存策略。

缓存这块我单独说一下。LLM 的缓存分两种：精确缓存和语义缓存。精确缓存就是相同的 prompt 直接返回缓存结果，实现简单但命中率低。语义缓存是把 prompt 做 embedding，相似度超过阈值就返回缓存结果，命中率高但有误命中风险。企业场景里，对准确性要求高的任务用精确缓存，对客服问答这类容错率高的场景可以用语义缓存。

6.2 成本优化的五个实操手段

第一，prompt 压缩。把冗余的 system prompt 精简，把 few-shot 示例从 5 个减到 2 个，能省不少 Token。第二，模型分级。简单任务用小模型，复杂任务用大模型。第三，缓存。高频问题走缓存。第四，批处理。非实时任务攒批处理，提高 GPU 利用率。第五，输出长度限制。在 prompt 里明确要求“回答不超过 200 字”，避免模型长篇大论。

我实测过一个客服场景，用这五个手段组合优化后，月度 Token 成本从 1.2 万降到 4000 左右，降幅超过 60%，而用户满意度基本没变化。

6.3 常见问题速查表

7. 一些踩坑之后的个人体会

企业级 LLM 平台的建设，技术选型只占三成，剩下七成是工程规范和运维体系。我见过太多团队在模型选型上纠结几周，却在权限隔离、成本计量、调用链追踪这些“不性感”的事情上偷懒，结果上线后问题频出。

如果让我给正在起步的团队一个建议，我会说：先把网关和可观测性做好，再考虑上多复杂的 Agent 和 RAG。网关是流量的入口，可观测性是问题的出口，这两个做好了，后面的迭代才有基础。模型可以换，框架可以换，但这两个基础设施一旦缺位，每次换东西都是一次事故。

另外，企业级场景里“稳定”比“先进”重要得多。一个新出的框架再酷，如果社区不活跃、文档不完善、出了问题没人能帮你排查，就不要用在核心链路上。我自己的原则是：核心链路只用经过至少一年生产验证的技术，新东西先在边缘场景试。

最后分享一个很小但很实用的技巧：给每个 LLM 请求打上业务标签，比如biz=contract_review、biz=customer_service。这个标签在排查问题、分析成本、做容量规划时特别有用，而且实现成本几乎为零。很多团队等到出问题才想起来要加标签，那时候历史数据已经丢了，只能从头再来。