“亿”想天开AI｜LLM在eBay推理平台的工程实践与应用

“亿”想天开AI系列推文目录：

• 模型推理平台核心功能和整体架构，及主流框架支持

• 模型生命周期管理
  

• 模型端到端服务优化及资源优化

• 模型特征监控

• 大模型落地实践（本篇）

eBay推理平台为内部用户提供了自助上线模型的能力，支撑着来自不同业务线近千个活跃模型。然而，由于LLM有着强依赖GPU、模型体积大、以及迭代速度快等特点，如果想做到平台零干预、用户自助式上线LLM，经过我们的评估，发现还存在不少挑战：

• 从集群部署角度来看，不同于常规的模型推理，LLM自回归式的迭代计算高度依赖GPU资源，张量并行等推理加速机制更是依赖多卡多机部署，这意味着平台需要有灵活的GPU资源管理和部署调度能力。

• 从单机推理角度出发，LLM 推理尤其是decoding阶段是典型的GPU Memory-IO密集型场景，高效使用GPU显存能显著提升推理吞吐和缩短响应时间，对推理引擎设计实现提出了新的要求。

• 而在应用场景上，我们看到无论是文本补全(text completion)还是对话(chat)应用，LLM逐token自迭代式的预估方式也衍生出推理结果逐字呈现的诉求，这要求推理平台支持端到端的streaming能力，以适配LLM落地场景。

以上分析，我们可以进一步归纳为模型推理和部署两方面的平台工作。

• LLM推理能力的从无到有。

• LLM应用接口的增强完善。

• GPU资源管理。LLM部署的前提是有可用GPU资源，而GPU资源是稀缺的。平台需要提供高效的审计措施，提高GPU资源的可流转性，尽可能避免业务需求旺盛情况下总是一卡难求。

• 模型部署效率。LLM部署必然带来大量模型文件数据传输，模型上传下载效率需要针对性优化，以缩短用户部署模型的时间、提升用户在平台自助操作的体验。

• 模型部署灵活性。无论是硬件资源的调整（多机多卡、MIG支持），还是预估层面的参数调优（tensor-parallel / pipeline-parallel / quantization / batching等），都需要给用户提供低成本的操作空间。

下文将会围绕模型推理和部署两方面，来展开介绍我们在支持LLM（以及多模态模型）线上推理所做的工作。

为了实现一个高效的大语言模型（LLM）在线推理服务，我们主要关注以下两个核心组件：

引擎（Engine）：负责模型的管理和优化。这包括但不限于：

• 模型管理：确保模型的有效加载和更新。

• KV-Cache管理：实现缓存机制的抢占和预留策略。

• 模型优化：采用技术如模型量化，以提高推理效率和降低资源消耗。

• 批处理支持：通过batching技术提高处理效率。

服务（Server）：提供接口与服务：

• 对外接口：通过RPC或RESTful API对外提供服务。

• 对内通信：与引擎对接，优化请求的排队和调度机制。

• 监控追踪：实现细粒度的监控，包括请求级别乃至token级别的tracing和monitoring，确保服务的可靠性和透明性。

在当前市场上，存在多种成熟的LLM推理框架和解决方案（Server + Engine），例如：

• HuggingFace推出的Text Generation Inference。

• NVIDIA的Triton Server+TensorRT-LLM，提供高性能的推理服务。

• 基于Ray的RayLLM+RayServe，优化分布式处理能力。

• 加州伯克利大学推出的vLLM，展示了学术界的最新研究成果，在工业界也应用广泛。

• 其他解决方案如LMDeploy和SGLang。

选择合适的框架和技术栈，对于构建高效、可扩展的LLM在线推理服务至关重要。在推理引擎的选型上，我们选用vLLM，主要有四个原因：

• 开源：vLLM的开源特性方便了二次开发和源码级问题排查，增强了其适应性和可定制性。

• 活跃：vLLM社区对新模型的支持和新特性的迭代都非常迅速，确保了技术的前沿性和适应性。

• 性能：vLLM是首个实现了paged attention和连续批处理continuous batching的LLM推理框架，长期在大模型推理领域保持技术领先，并持续进行性能优化。

• 稳定：自2023年6月开源以来，vLLM已在多个工业级应用中证明了其稳定性和高性能。

在推理服务的封装上，我们经历了两个阶段，会在下面两节详细描述架构改造工作：

• Container Based Approach：以自研的gRPC服务为基础，封装vLLM asyncEngine，提供LLM推理能力。

• Triton vLLM backend：随着平台逐渐统一推理框架、降低维护成本，我们采用了triton vLLM backend的方案。

Container Based Approach，是eBay推理平台在过去几年，帮助用户实现模型推理的主要方式。其原理是平台提供python gRPC封装，用户提供模型加载、模型预估两个主要接口的实现，并利用平台提供的CI/CD pipeline，自主完成模型推理服务部署上云。

我们在初期采用这一方式，核心的考量为两点：

• 用户认知门槛较低。考虑到内部用户对Container Based方式较为熟悉，延续这一技术栈并扩展支持LLM推理，用户能快速试用。

• 平台技术栈与vLLM契合。Python实现为主的模型服务实现框架，使得我们能够很快适配vLLM并随之迭代。

我们知道，对于一般LLM推理过程而言，大部分开销(90%)集中在decoding阶段，而decoding阶段是一个memory IO密集的处理过程，这使得我们原本的同步Server不足以支撑发挥vLLM的最大性能优势。所以我们的第一个工作即是将Model Service升级支持异步模式，并对prometheus metrics组件进行适配。基于这一升级，无论是对外提供single response还是stream response接口，我们都可以在底层调用在线推理性能更为友好的vLLM asyncEngine。

在设计LLM应用时，逐字展示推理结果的需求常因LLM推理时间较长而提出，以优化用户体验。同时，这也体现了LLM逐token推理的特性，要求后端服务支持流式输出。

为此，我们在推理平台Gateway Service和Model Service的两层架构上，实现了端到端的Streaming接口。该架构支持在传统接口和Streaming接口之间无缝切换，满足不同场景的需求：

• Gateway Service：采用Spring Boot构建的Java服务，实现了服务器端事件（Server-Side Events, SSE）来提供对外的流式输出。同时，该服务负责与Model Service的接口对接。

• Model Service：实现为gRPC服务，利用gRPC本身的流式接口特性进行扩展。

通过这种架构设计，我们能够有效地支持LLM的逐字推理输出，同时保证系统的灵活性。

为了优化GPU资源使用，我们在Gateway Service和Model Service的两层架构中实现了请求的早期终止（early stop）功能。这一功能在代码生成或长文本生成等场景中尤为重要，可以有效减少不必要的计算和资源浪费。

• Gateway Service：负责监控上游应用的连接状态。如果检测到上游应用的连接断开，Gateway Service将主动中断与Model Service的通信。

• Model Service：对Gateway Service的状态保持监听。一旦Gateway Service中断连接，Model Service将立即取消asyncEngine的推理工作。

通过这种机制，我们确保了在客户端终止请求时，系统能迅速响应并停止所有相关计算资源的分配，从而提高整体的资源使用效率和响应速度。

《eBay模型服务性能及资源优化实践》一文，详细介绍了Model Service这一层，我们引入了NVIDIA triton server作为统一的推理服务框架。其丰富的模型框架支持、模型编排能力、深度性能优化等特性，能够很好地服务我们平台上不同业务场景的模型推理诉求，如吞吐优先的NRT场景，延迟敏感的检索场景，自定义前后处理的CV模型场景等等。

为了简化平台维护成本，我们也将LLM推理服务升级，采用Triton Server进行服务封装。与Container Based Approach相比，这次升级主要带来了以下几个优势，进一步降低了用户部署LLM的门槛。

• Schema Free: 鉴于大多数LLM推理场景的输入（如prompt、max_token_size、top_k等参数）和输出格式基本固定，用户无需重复定义LLM的输入输出schema，简化了操作流程。

• Image Free: LLM推理依赖于GPU，因此Docker镜像中需要妥善处理CUDA、cuDNN、PyTorch等依赖的版本兼容和迭代问题。我们的平台提供了标准的Docker镜像，用于开发测试和线上推理，从而免除了用户自行处理依赖和打包的复杂性。

• Code Free: 用户仅需提供模型文件的路径，无需编写任何额外代码，即可部署并运行LLM。

当然，我们仍然保留了支持那些需要定制schema或docker image的场景的灵活性，允许用户在我们的基础镜像上进行扩展，无缝部署到平台。至此，无论是LLM还是其他模型，我们统一了线上推理的服务框架，既统一用户的使用体验，也降低平台维护成本。

除了LLM，在生成式AI时代同样扮演重要角色的多模态模型的部署和推理，也是平台支持的重点。我们以Stable Diffusion为典型代表，进一步阐述相关工作。

Stable Diffusion推理过程

不同于其他模型，Stable Diffusion是一个典型的有着模型编排（Orchestration）诉求的例子，它的推理过程有如下四个子模型配合完成：

• Text Encoder: CLIP model，将prompt映射成语义向量。

• U-Net：去噪神经网络。它将加噪隐向量和时间步长作为输入条件，输出去噪结果。

• Scheduler：推理阶段学习逆向的去噪过程，从纯噪声开始，每一步去除一些噪声，最终得到干净的隐向量。Scheduler会循环调用U-Net反复进行去噪过程。

• Autoencoder：将低维latent空间向量（隐空间）解码输出图片。

解决方案：Orchestration Deploy and Serving

一般的，平台支持以下两种常见的模型部署和推理形态：

• Mono Deploy: 单模型部署，典型例子如CTR/CVR场景。

• Assemble Deploy: 带有前后处理的模型部署和推理，典型例子如CV模型，往往需要对图片做预处理（比如下载，padding），再送入模型进行推理，这些前后处理和模型推理往往是串行的。

而Stable Diffusion，对平台提出了新的模型部署和推理方式：

• Orchestration Deploy：支持多个模型部署和推理，同时包含相对复杂的自定义逻辑，如条件选择、循环操作等等。

我们的解决方案是依托Triton Server自身对多模型的管理，以及其灵活的BLS（Business Logic Scripting）能力，对推理过程进行深度定制，来完成推Stable Diffusion推理的支持：

• 主模型作为orchestrator，负责整体过程的调度。

• 其他模型作为depdent models，被注册入元数据中。部署时多模型加载到线上容器，而在推理时，由orchestrator完成多模型的协同推理过程。

GPU资源管理

GPU资源的合理使用，一方面能帮助公司控制成本，另一方面也能为业务及时进行资源输送。我们在公司异构GPU物理资源之上（V100/A100/H100/…），构建了虚拟的Resource Pool的概念。不同租户可以注册使用各自的Resource Pool，而底层可以调度到不同的GPU资源，既可以是整卡部署，也可以是虚拟化资源。

为了防止资源碎片化，我们也定义了统一的Flavor，严格控制单Pod的CPU/GPU资源配比，主要是防止出现CPU耗尽而GPU仍然空闲的浪费现象。当然对于一些CPU瓶颈的应用场景，我们也有其他优化措施进行管理，这在《eBay模型服务性能及资源优化实践》一文中已经详细说明，不再赘述。

部署参数增强

LLM的部署，其部署参数需要更为灵活的支撑，主要分两个层面的参数：

• Kubernetes资源参数：CPU/GPU/Disk资源，这些会体现在Flavor的定义中，主要是扩展对多机多卡的支持。

• vLLM runtime参数：vLLM推理引擎提供了丰富的功能支持（tensor parallel / lora / quantization等），我们也支持从前端或者API透传，作用到model service的runtime。

模型数据传输加速

由于LLM一般而言模型文件相对较大，如meta-llama/Meta-Llama-3-70B 130GB+，在平台上传和下载预估需要小时级，用户体验不佳。

当前模型上传和下载，均需经过我们的代理服务（Model Management Service），然后与底层对象存储服务交互。为了对大文件传输进行加速，一个简单的思路即是分而治之、增加并发。

• 在请求端与Model Management Service之间，支持多个模型文件的并行传输，而且大文件可以进一步分块传输。

• 在Model Management Service与对象存储之间，由于主要是网络IO操作，我们优化了数据传输的池化管理，增大并发，提升吞吐。

以上优化，可以将百GB模型的下载时间控制在15分钟左右，一定程度上缓解模型部署运行时间过长的痛点。

本文主要介绍了eBay推理平台在支持LLM部署和推理方面的工作，帮助用户打平使用LLM和non-LLM的体验。当然，目前生成式AI发展仍处于早期，迭代快、变化多，我们也在平台层面进一步优化，希望能够以低成本、高效率的方式，给用户提供极致的LLM使用体验。

• 在GPU资源优化层面，我们在推进推理框架、服务、集群多维度的改造优化，使得大模型部署能够随着潮汐流量变化自适应伸缩，GPU资源占用得到更为弹性的管理；另一方面，在LLM多卡部署的背景下，不同规格的多卡部署带来资源分配的挑战，如何有效防止资源碎片化、实现动态rebalancing（bin-packing)是LLM部署特有的挑战。

• 在LLM benchmark方面，我们也在建设标准化、自动化的性能测试和profiling工具链，提升LLM在不同serving场景性能数据的可追溯、可复现和可解释性。

• 在推广生成式AI应用落地方面，我们与内部团队合作完善Research SDK、Evaluation Studio等组件和平台，旨在帮助业务快速搭建RAG/Agent，助力迭代。

在过去的一年中，LLM已经在eBay的多个重要业务场景落地，无论是买家侧（Shop The Look）、还是卖家侧（Magical Listing），LLM都在逐步成为eBay电商业务的新亮点。我们也期待随着平台的完善发展，更多业务能够快速试用生成式AI的能力，寻找到新的生命力和增长点。