本文是「LLM服务和优化：从入门到优化实战」系列的第四篇。

前三篇聚焦"推理服务怎么跑"，这一篇往外跳一层：当LLM被嵌入Agent循环、RAG管道、企业架构时，服务设计逻辑发生什么变化？本篇拆解Agent多模型协作、Tool Calling有状态循环、RAG与CAG的优化策略、企业七层服务架构，以及绕不开的Build-or-Buy决策。

1. 合集：LLM服务和优化
2. 01-模型服务基础认知：从"训练完的模型"到"可用的服务"
3. 02-LLM推理的内核与部署：从Token生成机制到vLLM实战
4. 【LLM从入门到优化实战】03-从零搭建LLM服务：Batching、Streaming与多模型架构

PART 01

Agent来了：推理服务不只是"跑一个模型"

前两篇我们讨论的推理服务，本质上是一个"输入prompt → 输出response"的单次调用模型。但现实中的LLM使用场景，正在快速从"对话式"转向"代理式"。

《Hands-On LLM Serving and Optimization》在讨论Agent推理服务时，这样定义了当前正在发生的转变：

"一个智能体世界正在到来，而且在许多方面，它已经来临：这是一波新的“tokenization”浪潮，越来越多的应用构建在大语言模型（LLM）基础设施之上，而非传统的API和服务。"

Agent不是简单的"聊天机器人"。Agent是一个能自主规划、调用工具、根据中间结果调整策略的系统。这对底层的推理服务提出了全新的要求。

1.1 一个知识Agent长什么样

此处，以简单的知识Agent为例，来说明模型服务如何为一个旨在查询和分析PDF文件中信息的知识智能体赋能。

如下图，一个知识Agent由两个模型驱动，一个支撑检索和内容匹配，一个负责推理和语言生成。在此之上，它由三个核心组件构成：协调器（Agent）统筹全局，规划器（Planner）用LLM将用户查询分解为执行计划，动作执行器（Action Executor）负责查询、摘要、分析等具体任务，同时集成了一套RAG系统处理PDF、生成嵌入并执行向量搜索。

图1 Knowledge Agent系统概览

一个具体的实战示例："知识Agent"的工作流如下：

图2 Knowledge Agent响应用户查询的内部工作流

一个Agent需要的模型远远不止一个LLM。它需要embedding模型做检索、可能需要reranker模型做精排、可能需要视觉模型做多模态感知、可能需要轻量分类模型做意图识别。推理服务必须同时支持所有这些模型的低延迟调用。

1.2 Tool Calling：Agent的核心动作

Agent区别于普通聊天机器人的一个关键能力是tool calling。Tool calling遵循一个四步循环：

这个过程天然是多轮、有状态、依赖中间结果的。每轮LLM调用都可能需要不同的上下文窗口和不同的调度策略。传统的"一条请求一条响应"的推理模型，在面对Agent循环时，需要在调度层面做更多的事情。比如在同一个会话中保持KV Cache的连续性，或者利用前缀缓存在Agent重复调用同一个系统prompt时避免重复计算。

PART 02

RAG和CAG

2.1 RAG：解决"知识不够"的问题

RAG的做法是：用户提问 → embedding模型向量化 → 向量数据库检索相关文档 → 拼到prompt里 → 喂给LLM生成回答。

图3 由索引构建和查询（检索）工作流组成的基本RAG系统

RAG解决的是 知识时效性和覆盖度 的问题。LLM的训练数据有截止日期，RAG让它可以访问最新的外部知识。但RAG的代价是：在调用LLM之前需要额外的检索步骤（embedding编码 + 向量检索），这会引入额外的延迟。

2.2 CAG：解决"重复计算"的问题

CAG（Cache-Augmented Generation）走的是另一条路。它的核心思路是：如果很多用户请求共享相同的前缀（比如同一个系统prompt，或者同一批检索文档），为什么要每次都重新计算它们的KV Cache？

图4 使用CAG的代理工作流

RAG和CAG不是互斥的，它们解决不同层次的问题：

RAG通过检索相关外部知识并扩展提示上下文来提升回答质量。CAG通过复用先前计算的上下文并减少冗余的KV缓存计算来提升服务效率。

简单来说：RAG是"让答案更准"，CAG是"让推理更快更便宜"。两者的关系不是二选一，而是叠加：一个典型的生产系统会同时用RAG丰富输入、用CAG优化执行。

图5 RAG与CAG对比

CAG的核心机制我们会在后续文章中详细展开。这里先建立的直觉是：LLM的自回归特性决定了前缀token的KV Cache一旦算好就不会变，同一个前缀在多个请求之间共享，绝对划算。

PART 03

企业级LLM推理架构：七层蛋糕

书里最有价值的观点之一是，它没有停在"推理引擎"这个层面，而是往上画了一个完整的企业七层架构。这个架构被OpenAI、Anthropic、Together AI等顶级LLM服务提供商广泛采用。

图6 企业级模型服务系统架构

从顶到底：

第一层：Public API（公共接口层）

这是客户、开发者和内部服务与LLM系统交互的唯一入口。它要做的事情远不止"接收请求然后转发"：鉴权、定价、限流、地域路由、安全防护。

关键挑战：支持数百万并发连接的同时，保证每个租户的隔离和计费准确性。这通常依赖Nginx/Envoy做ingress proxy + JWT/API Key双重认证 + Kubernetes的HPA做自动伸缩。

以下是一个具体的实现示例：

配合Kubernetes HPA配置：

和Nginx限流配置：

第二层：Resource Management（资源管理层）

管理跨地域的CPU、GPU、内存、磁盘和网络资源。核心是做容量规划：预测需求、避免过度分配。同时要支持客户优先级（关键任务走预留资源，低优先级任务走抢占式调度）。

第三层：Model Selection & Orchestration（模型选择与编排层）

这是企业架构中最被低估的一层。它的核心职责是：对每个请求，决定用哪个模型。

不是所有请求都需要最大的模型。OpenAI默认用gpt-4o-mini而非gpt-4o，就是这个逻辑。这一层还可以做更高级的编排，比如同时调用草案模型和目标模型做 Speculative Decoding（第 7 篇会详细展开）。

关键挑战：成本-质量trade-off，选便宜的模型可能答不准，选贵的模型可能成本翻倍。这一层需要根据请求的复杂度、历史数据和业务规则做动态路由。

第四层：Distributed Serving（分布式推理层）

当模型大到一张GPU放不下时，这一层负责多GPU/多节点的分布式部署。同时管理分布式缓存：KV缓存、前缀缓存、语义缓存，减少不必要的冗余计算。

第五层：Core Inference（核心推理层）

就是我们第 2、3 篇文章讲的东西：vLLM、Triton、TensorRT-LLM等框架以高性能方式执行模型。

第六层：Model Optimization（模型优化层）

量化、蒸馏、剪枝、Kernel融合等，在不重新训练的情况下提升推理效率。这是第 5、6、7 篇的核心内容。

第七层：Model Layer（模型层）

管理模型从训练pipeline到生产环境的完整流动，包括版本控制、能力分类（对话 / 推理 / 视觉 / 代码）、状态追踪（沙盒 / 实验 / 生产）。

每一层可以独立演进，不需要因为换了一个推理框架就去改动API层的鉴权逻辑。这个分层思想，是整个企业架构设计的精髓。

PART 04

六种构建方式：从"一键部署"到"裸机自建"

从最简单到最复杂，共有六种部署选项：

一个务实的建议：大多数团队不需要一开始就选最复杂的那个。选项 1 快速上线验证产品，选项 3-4 在规模变大后迁移，选项 5-6 是当成本优化成为核心竞争优势时的终局状态。

PART 05

Build or Buy？一个持续演变的决策

这不是一次性的决定。随着业务的成熟度和规模变化，最优解也会变。

作者自己的经验是：

"虽然外包解决方案是一个很好的起点，但企业必须持续评估，由内部自行提供服务能否在成本节约、安全性和灵活性方面，带来长期的竞争优势。"

一个Series A的教育创业公司，用OpenAI API快速验证产品，每月的推理费用在几千美元，完全合理。

一个CRM巨头，处理海量敏感的客户数据，每天几百万次推理请求。全外包不仅成本不可控，而且存在数据合规风险（GDPR、HIPAA）。自建推理栈是必然选择。

决策的核心变量是三个：规模 × 数据敏感度 × 团队能力。 三个中的任何一个变了，最优选择都可能跟着变。

PART 06

性能指标：用正确的尺子量LLM推理

6.1 延迟指标

PART 07

小结

这篇覆盖的内容跨度较大，从Agent到RAG/CAG到企业七层架构到Build-or-Buy到性能测量。但它们都围绕一个核心问题：LLM不是一个"被调用的函数"，而是一个"需要被设计、被运营、被优化的生产系统"。

下一篇开始，我们进入这个系列最硬核的部分：LLM推理的物理瓶颈。 GPU的内存墙到底卡在哪？算术强度是什么？模型加载的过程中，哪个环节最慢？

PS：

参考资料