LLM 服务和优化实践 (Chinese Edition)

第 4 章. 模型 服务最佳实践

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在第 2章和第 3 章中，我们探讨了模型推理，从实现到系统设计。您了解了 LLMs 的内部运行机制，以及如何从第一性原理构建服务系统。本章将重点从如何构建服务系统，转向服务系统在现实世界中的 LLM 应用中必须如何演进。

现代 LLM 应用很少仅由单次请求-响应的模型调用构成。相反，模型通常被嵌入到代理工作流、企业平台和分层生产系统中。当这种情况发生时，模型服务就不再仅仅是一个推理问题——它变成了一个系统架构问题。本章将探讨在系统层面上会发生哪些变化。

我们将从的代理式应用入手——并非因为这是“代理章节”，而是因为代理已成为构建LLM驱动系统的核心模式。大多数现代LLM用例——知识助手、协同助手、工作流自动化、推理引擎——都遵循类似代理的结构。单次用户交互可能触发多次LLM调用、检索步骤、工具执行以及迭代推理。这些行为从根本上重塑了服务需求。

代理会增加令牌使用量，放大链式调用中的尾部延迟，引入动态计算模式，并需要跨模型和工具的协调。本书后文讨论的许多服务优化——缓存策略、批处理方法、内存管理、调度以及并行化——正是由这些代理式工作负载直接驱动的。

因此，理解代理为本章的架构最佳实践以及后续章节的优化技术提供了正确的背景。通过剖析一个有效知识代理的核心组件，我们将展示 LLM 服务如何驱动智能规划、工具使用和多步骤推理——以及这对系统设计意味着什么。

随后，我们将视野扩展，呈现企业级LLM服务平台的分层参考架构。该框架突出了区分业余堆栈与生产级系统的关键构建模块和运维考量。在此，服务不仅是模型执行，还包括编排、资源管理、可观测性、治理和成本控制。

接下来，我们将“自建与Cloud”的选择视为一个连续谱，而非二元对立。我们的目标并非推崇某一种方案，而是为您提供一种心智模型，以便根据具体情境做出决策。您将看到团队如何将开源技术栈与托管服务相结合，了解为何随着流量和成本特征的变化，“最佳”平衡点会发生偏移，以及掌握构建方法如何帮助您决定需要进行多少定制。

最后，我们将以核心性能指标——延迟、吞吐量及相关度量——作为本章所有架构决策的评估标准。这些指标为后续的优化章节奠定了基础。读完本章后，您将：

• 理解代理式工作流如何重塑服务需求

• 理解企业级分层服务架构及其权衡取舍

• 借助实用的决策框架，在“自建与Cloud”之间做出权衡

• 衡量关键指标，从而有针对性地提升性能

在掌握了这些系统级最佳实践——以及前几章的技术基础后——您已准备好进入优化阶段，我们将在此将架构转化为具体的延迟、吞吐量和成本改进。

在代理化世界中构建服务

在本节中，我们将通过一个示例代理 ，演示如何利用LLMs构建代理式用户体验，其中软件和服务既能交互运行，也能自主运行。

虽然前几章侧重于将模型作为独立的预测引擎进行服务，但现代 LLM 应用越来越多地将模型嵌入到代理系统中。在这些系统中，模型不再是每个请求仅被调用一次。相反，它可能会在一个控制循环中被反复调用，该循环会检索信息、对中间结果进行推理、执行工具并优化输出，然后返回最终答案。这种转变从根本上改变了对模型服务系统的要求。

代理既强大又复杂。单个代理可以执行复杂的任务，但在实践中，代理通常组织成代理网络或平台，其中多个代理相互构建、协作或专攻不同的功能。这种分层架构实现了非凡的自主性，但也带来了重大的设计和运营挑战——特别是对于模型服务而言。

例如，单次用户交互可能触发多次LLM调用、更长的上下文窗口、检索操作（RAG）或内存复用（CAG）。这些行为会增加令牌消耗，加剧链式调用中的延迟，并产生更动态的流量模式。因此，模型服务不再仅仅是高效运行模型——它必须支持编排、内存管理和系统级协调。 ...