1. 企业级 LLM 落地为什么“能跑通 Demo”和“能上生产”之间隔着一道鸿沟做过 LLM 项目的人大概都有这种体验本地拿个开源模型接上 LangChain写个 RAG 问答半天就能跑出一个像模像样的 Demo。演示的时候老板点头、同事鼓掌感觉这事成了。然后真到了要接入公司内部系统、要面对几百号人同时用、要处理权限隔离、要保证响应稳定、要控制成本的时候才发现之前那套东西几乎要推倒重来。这个系列写到第七篇我想聊的已经不是“怎么让模型回答问题”这种入门话题了而是企业级 LLM 系统在真实生产环境中到底会撞上哪些墙以及每一堵墙背后应该怎么设计。标题叫“企业级 LLM七”前面六篇分别覆盖了模型选型、RAG 基础架构、向量库搭建、Prompt 工程化、评测体系、成本控制这一篇聚焦的是一个更综合的问题当 LLM 从单点能力变成企业基础设施的一部分时整个系统的架构应该怎么组织。先把这个话题的边界说清楚。所谓“企业级”不是指模型参数有多大、GPU 有多少张而是指这套系统要满足几个硬性条件多租户隔离、权限可控、输出可审计、服务高可用、成本可预测、能力可扩展。这六条里任何一条不达标都没法真正在企业内部推广。我见过太多团队卡在“Demo 很惊艳推广没人用”的阶段根子往往不在模型本身而在这些工程侧的短板。这篇文章适合三类人看一是正在做 LLM 应用但还没上生产的工程师可以提前避开一些坑二是负责技术选型的架构师需要理解企业级 LLM 系统的全貌三是带团队做 AI 落地的技术负责人需要知道哪些环节是真正的难点。我会尽量把每个设计决策背后的“为什么”讲透而不是只给一堆配置和代码。2. 企业级 LLM 系统的整体架构该怎么拆2.1 从“模型为中心”转向“网关为中心”的思路转变大部分个人项目或者早期 Demo 的架构是“模型为中心”的应用直接调用模型 API中间最多加一层简单的封装。这种结构在单用户、低并发、无权限要求的场景下没问题但一旦进入企业环境立刻会暴露三个致命问题。第一个问题是模型耦合。应用代码里写死了某个模型的调用方式想换个模型或者加个备用模型得改一堆业务代码。第二个问题是缺乏统一管控。谁在什么时候调用了什么模型、消耗了多少 token、返回了什么内容这些信息散落在各个应用里根本没法审计。第三个问题是无法做精细化限流和成本分摊。不同部门、不同项目共用一套模型资源出了账单没法拆某个应用疯狂调用把配额吃光其他应用跟着遭殃。所以企业级架构的第一个关键决策是引入 LLM 网关作为统一入口。网关这层要承担的事情包括统一鉴权、请求路由、模型适配、限流熔断、日志审计、成本计量、缓存加速。应用侧只需要面向网关的标准化接口编程完全不关心背后是哪个模型、部署在哪里。这个思路和微服务里的 API Gateway 是一脉相承的。你可以把 LLM 网关理解成“专门为模型调用优化的 API 网关”它比通用网关多了几个能力对 token 的计量、对流式响应的处理、对 Prompt 模板的管理、对多模型的路由策略。提示网关这层不要做得太重。我见过有团队把 RAG 检索、Agent 编排全塞进网关结果网关变成了一个巨型单体改一处影响全局。网关的职责应该聚焦在“流量管控和协议适配”业务逻辑往上走。2.2 分层架构接入层、编排层、能力层、基础设施层把整个系统拆开看我习惯分成四层每层职责清晰层与层之间通过标准接口通信。接入层负责和外部交互包括 Web 前端、API 接口、企业内部的 IM 机器人、各种业务系统的回调。这一层要做的是身份认证、请求格式化、结果渲染。用户看到的界面、业务系统拿到的数据结构都在这一层处理。编排层是核心大脑负责把用户的请求拆解成一系列步骤需不需要检索知识库、要不要调用工具、走哪个 Prompt 模板、用哪个模型、结果怎么后处理。这一层通常会用 LangChain、LlamaIndex 或者自研的编排引擎来实现。Agent 的逻辑、RAG 的流程、多轮对话的状态管理都在这一层。能力层提供各种原子能力向量检索、关键词检索、图数据库查询、工具调用、模型推理、结果重排。这一层的特点是“无状态、可复用”每个能力都是独立的服务可以被编排层任意组合。基础设施层是底座包括向量数据库、关系数据库、缓存、消息队列、对象存储、模型推理服务、监控告警。这一层决定了整个系统的性能和稳定性上限。这样分层的好处是每一层可以独立演进。比如想把向量库从 Milvus 换成 Qdrant只动能力层编排层和接入层完全不用改。想加一个新的模型供应商在能力层加一个适配器就行。2.3 多租户隔离企业级绕不开的第一道坎企业环境里一套 LLM 系统往往要服务多个部门、多个项目甚至多个子公司。这就带来一个核心问题数据隔离。A 部门的文档不能被 B 部门检索到C 项目的对话历史不能让 D 项目看到这是底线要求。隔离方案有三个层次成本从低到高隔离级别实现方式隔离强度适用场景逻辑隔离同一套资源靠 tenant_id 字段过滤弱内部信任度高的团队物理隔离库级每个租户独立数据库/集合中一般企业部门间物理隔离实例级每个租户独立部署强强合规要求场景大部分企业用“逻辑隔离 库级隔离”的组合就够了。具体做法是向量库按租户分 collection关系库的表都带 tenant_id 字段缓存 key 加租户前缀模型调用时在 Prompt 里注入租户上下文。这里有个容易踩的坑向量检索的隔离不能只靠元数据过滤。有些向量库的元数据过滤是在召回之后做的意味着你检索 top 100过滤完可能只剩 3 条召回质量严重下降。正确做法是在检索阶段就把租户范围限定死用独立的 collection 或者分区。2.4 权限模型从 RBAC 到“数据 能力”双维度控制传统企业系统的权限模型是 RBAC基于角色的访问控制但 LLM 系统需要更细的粒度。因为这里有两类权限要管数据权限能访问哪些知识库、哪些文档和能力权限能用哪些模型、哪些工具、哪些 Agent。我推荐的做法是双维度权限模型。用户先通过 RBAC 确定角色角色映射到一组“数据范围”和“能力集合”。数据范围决定检索时能看到什么能力集合决定能调用哪些模型和工具。举个具体例子财务部门的普通员工数据范围是“财务知识库的公开文档”能力集合是“只能用基础模型做问答不能用代码执行工具”。财务经理的数据范围扩大到“财务知识库全部文档”能力集合增加“可以调用数据分析工具”。这种细粒度控制靠单一的 RBAC 是做不到的。实现上权限判断要放在编排层每次请求进来先解析用户身份查出数据范围和能力集合然后注入到后续的检索和调用流程中。网关层做粗粒度的鉴权编排层做细粒度的权限控制。3. 核心组件选型与实操要点3.1 LLM 网关选型自研还是用开源方案网关这块市面上有几种选择。开源的方案比如 One API、LiteLLM、Higress 的 AI 网关插件商业方案有各家云厂商的模型网关服务还有就是完全自研。我的经验是如果团队规模不大、需求相对标准优先用开源方案。LiteLLM 支持 100 多个模型供应商的统一接口配置简单社区活跃中小团队直接用能省很多事。One API 在国内用得多对国产模型支持好管理界面也完善。如果企业有特殊的合规要求或者复杂的路由策略才考虑自研。自研的成本不低光是模型适配器就要维护几十个还要处理流式响应、重试、降级这些细节。我见过有团队自研网关花了三个月最后发现功能还不如 LiteLLM 开箱即用的。选型时要重点看几个能力是否支持流式响应、是否支持 token 计量、是否支持多模型路由和降级、是否有完善的日志和监控、是否支持自定义鉴权。这几个是企业场景的刚需。3.2 向量数据库别只看 benchmark要看运维成本向量库的选型网上文章很多各种 benchmark 对比。但企业级选型性能只是一方面运维成本、生态成熟度、团队熟悉度往往更重要。我按使用场景给个粗略建议数据量在千万级以下、团队没有专职运维用 pgvector。直接跑在现有的 PostgreSQL 上不用额外维护一套系统备份、监控、权限都复用现有的。性能对大多数企业场景够用。数据量在千万到亿级、需要高性能检索Milvus 或者 Qdrant。Milvus 生态成熟、功能全Qdrant 更轻量、部署简单。需要和现有 Elasticsearch 生态整合用 ES 的向量检索功能省得再引入一套系统。需要图检索和向量检索结合考虑 Neo4j 或者 NebulaGraph 配合向量索引。这里有个实操心得向量库的选型一定要做真实数据的压测。benchmark 上的数字和你的实际数据分布、查询模式差别很大。我见过一个项目benchmark 上 Qdrant 比 pgvector 快 10 倍但实际业务数据下只快 1.5 倍因为查询模式以元数据过滤为主向量相似度计算不是瓶颈。3.3 编排框架LangChain 不是唯一答案编排层用什么框架是个见仁见智的问题。LangChain 生态最全但抽象层次多、调试困难、版本迭代快生产环境用起来经常踩坑。LlamaIndex 在 RAG 场景下更专注API 设计更清晰。还有 Haystack、Semantic Kernel 这些选择。我的建议是简单场景直接用原生 SDK复杂场景再上框架。如果你的流程就是“检索 拼 Prompt 调模型”用原生 SDK 写几十行代码就够了引入 LangChain 反而增加复杂度。只有当流程涉及多步 Agent、复杂的状态管理、多种工具编排时框架的价值才体现出来。如果一定要用框架我倾向于 LlamaIndex 做 RAGLangGraph 做 Agent 编排。LangGraph 的状态机模型比 LangChain 的 Chain 更适合复杂流程调试也更容易。3.4 模型推理服务vLLM 之外的选择模型推理这块vLLM 是目前的主流选择PagedAttention 和连续批处理让吞吐量提升明显。但企业场景下还有几个考量点。如果追求极致吞吐vLLM 或者 TensorRT-LLM。TensorRT-LLM 在 NVIDIA 卡上性能最好但编译和部署复杂。如果追求部署简单Ollama 或者 TGI。Ollama 适合小规模部署和开发环境TGI 适合生产但配置略复杂。如果要用 ONNX 部署ONNX Runtime 配合 Optimum 可以做模型转换和推理适合需要在多种硬件上部署的场景但性能通常不如专用推理引擎。如果模型不大、并发不高直接用 transformers 库加载也行省得引入额外依赖。实操中一个关键点是批处理策略。企业场景的请求往往不均匀有突发高峰。vLLM 的连续批处理能动态调整批次但需要合理配置max_num_seqs和max_num_batched_tokens。这两个参数配小了吞吐上不去配大了显存爆掉。我的经验是从小往大调观察显存占用和吞吐曲线找到拐点。4. 完整实操从零搭一套可用的企业级 LLM 服务4.1 环境准备与依赖安装假设我们要搭一套最小可用的企业级 LLM 服务包含网关、向量检索、模型推理三个核心组件。我用 Docker Compose 来编排方便演示。先准备目录结构mkdir -p enterprise-llm/{gateway,vector,model,config} cd enterprise-llm网关用 LiteLLM向量库用 Qdrant模型推理用 vLLM。先写 Docker Compose 文件version: 3.8 services: litellm: image: ghcr.io/berriai/litellm:main-latest ports: - 4000:4000 volumes: - ./config/litellm_config.yaml:/app/config.yaml command: [--config, /app/config.yaml, --port, 4000] environment: - DATABASE_URLpostgresql://user:passpostgres:5432/litellm depends_on: - postgres qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 - 6334:6334 volumes: - ./vector/data:/qdrant/storage vllm: image: vllm/vllm-openai:latest ports: - 8000:8000 volumes: - ./model/cache:/root/.cache/huggingface command: [ --model, Qwen/Qwen2.5-7B-Instruct, --max-model-len, 8192, --gpu-memory-utilization, 0.9, --max-num-seqs, 32 ] deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] postgres: image: postgres:16 environment: - POSTGRES_USERuser - POSTGRES_PASSWORDpass - POSTGRES_DBlitellm volumes: - ./config/pgdata:/var/lib/postgresql/data这里几个参数值得说明。--max-model-len 8192是模型的最大上下文长度设太大显存吃紧设太小长文档处理不了。7B 模型在 24G 显存上8192 是个比较稳妥的值。--gpu-memory-utilization 0.9表示用 90% 显存留 10% 给其他进程。--max-num-seqs 32是最大并发序列数这个值直接影响吞吐和延迟的平衡。4.2 网关配置多模型路由与限流LiteLLM 的配置文件是核心它定义了模型列表、路由策略、限流规则。写一个基础配置model_list: - model_name: qwen-7b litellm_params: model: openai/Qwen2.5-7B-Instruct api_base: http://vllm:8000/v1 api_key: dummy model_info: max_tokens: 8192 input_cost_per_token: 0.0000001 output_cost_per_token: 0.0000002 - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY model_info: max_tokens: 128000 router_settings: routing_strategy: usage-based-routing num_retries: 3 timeout: 60 fallbacks: - qwen-7b: [gpt-4o-mini] general_settings: master_key: sk-enterprise-master-key database_url: postgresql://user:passpostgres:5432/litellm litellm_settings: drop_params: true set_verbose: false cache: true cache_params: type: redis host: redis port: 6379 ttl: 3600这个配置里routing_strategy: usage-based-routing表示按使用量路由负载低的模型优先。fallbacks定义了降级链qwen-7b 挂了自动切到 gpt-4o-mini。cache开启缓存相同请求一小时内直接返回缓存结果能省不少成本。限流规则可以按用户、按团队、按模型维度配置。比如限制某个团队每分钟最多 100 次调用litellm_settings: max_parallel_requests: 100 rpm_limit: 1000 tpm_limit: 100000rpm_limit是每分钟请求数tpm_limit是每分钟 token 数。这两个值要根据实际业务量和模型承载能力来定。我的经验是先用宽松的值跑一周看监控数据再收紧。4.3 向量检索服务分租户的 collection 设计Qdrant 的 collection 设计要考虑租户隔离。有两种方案一是每个租户一个 collection二是所有租户共用一个 collection用 payload 过滤。方案一隔离彻底但 collection 数量多了管理麻烦而且 Qdrant 每个 collection 都有固定开销。方案二管理简单但过滤性能取决于索引设计。我的建议是按业务域分 collection租户用 payload 过滤。比如“财务知识库”一个 collection“技术文档”一个 collection每个 collection 里用tenant_id字段区分租户。这样 collection 数量可控租户隔离也能保证。创建 collection 的代码from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PayloadSchemaType client QdrantClient(hostlocalhost, port6333) client.create_collection( collection_namefinance_knowledge, vectors_configVectorParams(size1024, distanceDistance.COSINE), ) # 为 tenant_id 建索引加速过滤 client.create_payload_index( collection_namefinance_knowledge, field_nametenant_id, field_schemaPayloadSchemaType.KEYWORD, ) client.create_payload_index( collection_namefinance_knowledge, field_namedoc_type, field_schemaPayloadSchemaType.KEYWORD, )向量维度 1024 对应的是 bge-large 这类中文 embedding 模型。选 embedding 模型时要注意维度和模型必须匹配换了 embedding 模型就得重建整个 collection。检索时的过滤条件from qdrant_client.models import Filter, FieldCondition, MatchValue results client.search( collection_namefinance_knowledge, query_vectorquery_embedding, query_filterFilter( must[ FieldCondition(keytenant_id, matchMatchValue(valuedept_finance)), FieldCondition(keydoc_type, matchMatchValue(valuepolicy)), ] ), limit10, )这里must里的条件都是必须满足的Qdrant 会先过滤再检索保证召回质量。如果过滤条件很多可以考虑用should做加权但要注意should是“或”的关系。4.4 模型推理参数调优从显存占用倒推配置vLLM 的参数调优核心是平衡显存、吞吐、延迟三个指标。我一般按这个顺序来第一步确定模型能占用的显存上限。假设一张 24G 的卡系统和其他进程占 2G留给模型 22G。gpu_memory_utilization设 0.9实际可用约 19.8G。第二步估算 KV Cache 占用。KV Cache 大小和模型层数、隐藏维度、序列长度、并发数相关。7B 模型32 层隐藏维度 4096在 FP16 下每个 token 的 KV Cache 约 0.5MB。8192 长度的序列单条占用约 4G。如果并发 4 条就是 16G加上模型权重 14G总共 30G超了。所以要么降并发要么降序列长度。实际配置时我会先用小并发跑起来逐步加压观察显存找到稳定运行的临界点。第三步调批处理参数。max_num_seqs控制并发序列数max_num_batched_tokens控制单批次处理的 token 数。这两个参数配合使用前者影响并发能力后者影响单次计算效率。一个实测的配置参考7B 模型24G 卡参数值说明max-model-len8192最大上下文gpu-memory-utilization0.9显存利用率max-num-seqs16并发序列数max-num-batched-tokens4096单批 token 上限tensor-parallel-size1单卡这套配置下7B 模型能跑到约 2000 tokens/s 的吞吐首 token 延迟在 200ms 左右。如果业务对延迟敏感可以降max_num_seqs到 8延迟能降到 150ms 以内但吞吐减半。4.5 监控与告警别等出问题才想起来企业级系统监控是生命线。LLM 服务要监控的指标分几类性能指标QPS、P50/P95/P99 延迟、首 token 延迟、吞吐量。这些反映服务健康度。资源指标GPU 利用率、显存占用、CPU、内存、网络。这些反映资源瓶颈。业务指标token 消耗量、各模型调用占比、缓存命中率、错误率。这些反映成本和效果。质量指标用户反馈、回答采纳率、检索命中率。这些反映系统实际价值。监控工具用 Prometheus Grafana 是标配。vLLM 和 LiteLLM 都暴露了 Prometheus 格式的指标直接抓取就行。告警规则我一般设这几条P99 延迟超过 5 秒持续 5 分钟错误率超过 1%持续 3 分钟GPU 显存占用超过 95%持续 10 分钟单日 token 消耗超过预算的 80%注意告警阈值不要设得太敏感否则天天报警团队会麻木。我见过有团队把延迟告警设在 1 秒结果每天几十条告警最后没人看。阈值要基于实际业务容忍度来定。5. 常见问题与排查技巧实录5.1 模型输出不稳定同样的输入结果差异大这是最常见的问题。原因通常有三个温度参数设置不当、Prompt 不够明确、模型本身能力限制。温度参数temperature控制输出的随机性。企业场景下问答类任务建议设 0.1 到 0.3需要创意的任务可以设 0.7 到 0.9。如果设成 0 还有波动那可能是top_p或者top_k在起作用把它们也调低。Prompt 不够明确是更隐蔽的原因。比如“总结这段文字”模型不知道要多长、什么风格、给谁看。改成“用 3 句话总结以下文字面向非技术读者突出关键结论”输出就稳定多了。如果前两个都排除了那就是模型能力问题。7B 模型在复杂推理任务上确实不如 70B 稳定。这种情况要么换大模型要么把任务拆解成更小的步骤。5.2 检索结果不相关答非所问RAG 系统里检索质量决定回答质量。检索不相关通常是这几个环节出了问题。切分策略。文档切得太碎单块信息不完整切得太大噪声多。我的经验是中文文档按 300 到 500 字切分保留 50 字重叠。技术文档可以按标题层级切保持语义完整。Embedding 模型。中文场景一定要用中文优化的模型bge-large-zh、m3e、text2vec 都是不错的选择。用英文模型处理中文效果会差很多。检索策略。纯向量检索对关键词不敏感纯关键词检索对语义不理解。生产环境建议用混合检索向量检索召回 top 20BM25 召回 top 20合并去重后用 rerank 模型重排取 top 5 给模型。Rerank 模型。这一步经常被忽略但效果提升明显。bge-reranker 系列在中文场景表现不错能把相关文档排到前面。5.3 并发一高就超时服务不稳定并发问题通常出在几个地方。模型推理是瓶颈vLLM 的并发能力有限超过max_num_seqs的请求会排队。如果排队时间过长客户端就超时了。解决办法有几个一是加机器做水平扩展多张卡跑多个 vLLM 实例网关做负载均衡。二是优化批处理参数提高单卡吞吐。三是做请求队列管理超过一定等待时间的请求直接返回“服务繁忙”而不是让用户干等。向量检索也可能是瓶颈。Qdrant 单节点在千万级数据下QPS 大概几百。如果检索请求量大要么加副本要么用更轻量的索引。网关层也可能成为瓶颈。LiteLLM 是 Python 写的高并发下 GIL 会限制性能。如果 QPS 超过 1000考虑用 Go 写的网关或者在前面加一层 Nginx 做负载均衡。5.4 成本失控月底账单吓人LLM 成本主要来自 token 消耗。控制成本有几个手段。缓存。相同或相似的请求直接返回缓存结果。LiteLLM 支持精确匹配缓存也可以用 GPTCache 做语义缓存。语义缓存能把“北京天气怎么样”和“北京今天天气如何”识别为同一请求。模型分级。简单任务用小模型复杂任务用大模型。比如意图识别、分类这种任务7B 模型足够没必要用 GPT-4。在网关层配置路由规则根据请求特征自动选择模型。Prompt 优化。精简 Prompt去掉冗余的示例和说明。一个 2000 token 的 Prompt 精简到 500 token成本直接降 75%。输出长度限制。设置max_tokens参数防止模型生成过长的无用内容。问答场景一般 500 token 够了摘要场景 1000 token 够了。用量监控。按租户、按项目统计 token 消耗定期出报表。哪个项目用得多、哪个模型成本高一目了然。有了数据才能做优化。5.5 常见问题速查表问题现象可能原因排查方向解决思路输出不稳定温度参数高、Prompt 模糊检查 temperature/top_p降低随机性明确 Prompt检索不相关切分不当、Embedding 差检查切分粒度和模型调整切分换中文模型加 rerank高并发超时推理瓶颈、队列积压看 GPU 利用率和队列长度水平扩展优化批处理限流成本过高无缓存、模型过大统计 token 消耗分布加缓存模型分级精简 Prompt显存溢出序列太长、并发太高看显存占用曲线降 max-model-len 或 max-num-seqs首 token 慢批处理等待、模型加载看首 token 延迟指标降批大小预热模型缓存不生效key 设计问题、TTL 太短检查缓存命中率优化 key 生成调整 TTL6. 一些踩过坑之后的经验之谈做企业级 LLM 系统这两年有几个体会是踩了坑才明白的。第一不要追求一步到位。我见过团队一开始就想搭一套完美的架构结果三个月没上线业务方失去耐心。正确的做法是先跑通最小闭环哪怕就是“网关 一个模型 一个向量库”先让业务用起来再根据反馈迭代。企业级的能力是长出来的不是设计出来的。第二可观测性比性能更重要。系统慢一点用户能忍但出了问题找不到原因团队会崩溃。日志、指标、链路追踪这三样从第一天就要建。我现在的习惯是任何新服务上线前先确认监控面板能看到关键指标否则不上线。第三成本要提前算账。很多团队做到一半才发现按当前用量一年光模型调用费就几百万预算根本批不下来。做方案时就要估算日均请求量、平均 token 数、模型单价算出月度成本。如果成本过高提前调整方案比如换小模型、加缓存、做分级路由。第四权限设计要留扩展空间。一开始可能只有两个部门用权限模型简单。但企业里系统会蔓延半年后可能变成十个部门、几十个项目。权限模型如果一开始没设计好后期改起来伤筋动骨。建议从第一天就用“租户 角色 资源”的三元组模型扩展性好。第五和业务方对齐预期。LLM 不是万能的有些任务它做不好。上线前要和业务方说清楚哪些场景能用、准确率大概多少、什么情况下需要人工介入。预期管理做好了用户满意度会高很多。我见过项目技术做得不错但因为业务方期望过高最后评价很差。最后分享一个实用的小技巧建一个“问题案例库”。把线上遇到的 bad case 收集起来定期分析。是检索问题、Prompt 问题还是模型能力问题分类统计。这个库是优化系统最宝贵的素材比任何 benchmark 都有价值。我现在的习惯是每周花半小时过一遍 bad case经常能发现一些系统性的问题。这套架构不是终点LLM 领域变化太快今天的最佳实践明天可能就过时了。但底层的工程原则——隔离、可观测、可扩展、成本可控——是不变的。把这些原则吃透具体技术怎么变都能应对。