大型模型推理容器：最新功能和性能增强-青云TOP-AI综合资源站平台|青云聚合API大模型调用平台|全网AI资源导航平台

📢 转载信息

原文链接：https://aws.amazon.com/blogs/machine-learning/large-model-inference-container-latest-capabilities-and-performance-enhancements/

原文作者：Dmitry Soldatkin, Dan Ferguson, Lokeshwaran Ravi, Sadaf Fardeen, Sheng Mouaa, and Suma Kasa

现代大型语言模型（LLM）的部署面临着由Token数量增长驱动的成本和性能挑战。Token数量与词数、图像大小以及其他输入因素直接相关，决定了每次推理请求的计算需求和成本。更长的上下文意味着更高的费用。随着前沿模型现在支持高达1000万个Token以适应检索增强生成（RAG）系统和需要广泛代码库和文档的编码代理日益增长的上下文需求，这一挑战愈发严峻。然而，行业研究表明，推理工作负载中很大一部分Token是重复的，许多提示中出现了相同的文档和文本片段。这些数据“热点”提供了优化机会。通过缓存频繁重用的内容，组织可以为长上下文推理工作负载实现成本降低和性能提升。

AWS最近发布了大型模型推理（LMI）容器的重大更新，为在AWS上托管LLM的客户带来了全面的性能改进、扩展的模型支持和简化的部署功能。这些版本专注于降低操作复杂性，同时在流行的模型架构上实现可衡量的性能增益。

LMCache支持：变革长上下文性能

LMI最新版本中引入的最重要功能之一是全面的LMCache支持，它从根本上改变了组织处理长上下文推理工作负载的方式。LMCache是一个开源的KV缓存解决方案，它提取并存储现代LLM引擎生成的KV缓存，跨引擎和查询共享这些缓存，以帮助提高推理性能。

与传统的仅前缀缓存系统不同，LMCache在服务引擎实例中重用重复文本的KV缓存，而不仅仅是前缀。该系统在块级别运行，识别文档或对话中常见重复的文本跨度，并存储其预计算的KV缓存。这种方法支持跨GPU内存、CPU内存和磁盘/远程后端的多层存储，并带有智能缓存，维护一个将Token序列映射到缓存KV条目的内部索引。LMI的最新版本引入了自动LMCache配置，简化了KV缓存的部署和优化。这种低代码无代码（LCNC）界面帮助客户在无需复杂手动配置的情况下无缝启用此高级性能特性。通过将KV缓存从GPU内存卸载到CPU RAM或NVMe存储，LMCache能够有效处理长上下文场景，同时有助于提高延迟。

对各种模型大小和上下文长度的全面测试显示出性能的提升，有助于改善长上下文推理工作负载的用户体验。对于具有重复上下文的工作负载，LMCache在处理数百万Token上下文时能实现更快的首次Token时间（TTFT）。部署LMI的组织可以在实例RAM允许的情况下配置CPU卸载以获得最佳性能，或者在需要更大缓存容量的工作负载中使用启用了O_DIRECT的NVMe。在Amazon SageMaker AI上实施基于会话的粘性路由（sticky routing）有助于最大化缓存命中率，确保来自同一会话的请求始终路由到具有相关缓存内容的实例。

LMCache性能基准测试

对各种模型大小和上下文长度的全面测试揭示了性能的提升，改善了长上下文推理工作负载的用户体验。测试方法改编了LMCache的长文档问答（Long Doc QA）基准，使其适用于LMI容器，包括三个阶段：用于冷启动初始化的预热、用于填充LMCache存储的热身回合，以及用于测量从缓存检索性能的查询回合。基准测试在p4de.24xlarge实例（8× A100 GPU，1.1TB RAM，NVMe SSD）上进行，使用了Qwen模型，包含46个10,000个Token的文档（共460,000个Token）和4个并发请求。

对于具有重复上下文的工作负载，LMCache在处理数百万Token上下文时可实现更快的首次Token时间（TTFT）。与基线（52.978秒 → 24.274秒）相比，CPU卸载在总请求延迟方面带来了2.18倍的加速，并且TTFT快了2.65倍（1.161秒 → 0.438秒）。启用了O_DIRECT的NVMe存储接近CPU性能（0.741秒 TTFT），同时支持TB级的缓存容量，总请求延迟加速1.84倍，TTFT加速1.57倍。这些结果显示TTFT降低了62%，请求延迟降低了54%，与已发布的LMCache基准测试结果非常吻合。改进百分比的差异可能归因于硬件和细微的配置差异。这些延迟的降低直接转化为成本节约，因为请求处理时间减少了54%，使得相同的基础设施能够处理两倍以上的请求量，从而使每次请求的计算成本减半。

由于每个Token所需的KV缓存内存不同，性能特征因模型大小而异。较大的模型每个Token需要更多的内存（Qwen2.5-1.5B：28 KB/Token，Qwen2.5-7B：56 KB/Token，Qwen2.5-72B：320 KB/Token），这意味着它们在更短的上下文长度下就会耗尽GPU KV缓存容量。Qwen 2.5-1.5B可以在GPU内存中存储多达260万Token的KV缓存，而Qwen 2.5-72B的限制是480K个Token。这意味着LMCache在较大模型的较短上下文长度下就能发挥价值。72B模型可以在大约50万Token时开始受益于CPU卸载，速度提高4-6倍，而较小的模型仅在超出250万Token的极端上下文长度时才需要卸载。部署LMI的组织可以在实例RAM允许的情况下配置CPU卸载以获得最佳性能，或者在需要更大缓存容量的工作负载中使用启用了O_DIRECT的NVMe。在SageMaker AI上实施基于会话的粘性路由有助于最大化缓存命中率，确保来自同一会话的请求始终路由到具有相关缓存内容的实例。

如何使用LMCache

LMI中定义了两种主要方法来配置LMCache，如GitHub文档所述。第一种是手动配置方法，第二种是在新版本的LMI中提供的自动化配置方法。

手动配置
对于手动配置，客户创建自己的LMCache配置，并在属性、文件或环境变量中指定它：

option.lmcache_config_file=/path/to/your/lmcache_config.yaml# OROPTION_LMCACHE_CONFIG_FILE=/path/to/your/lmcache_config.yaml

这种方法使客户能够控制LMCache设置，以便他们可以根据自己的具体要求自定义缓存存储后端、块大小和其他高级参数。

自动配置
为了简化部署，客户可以类似地启用自动LMCache配置：

option.lmcache_auto_config=True# OROPTION_LMCACHE_AUTO_CONFIG=True

自动配置会根据主机机器上可用的CPU/磁盘空间自动生成LMCache配置。此部署选项仅支持张量并行（Tensor Parallelism）部署，假设/tmp已挂载到NVMe存储上用于基于磁盘的缓存，并且要求maxWorkers=1。这些设置是在自动配置中假定的，其设计目的是每个容器实例仅服务一个模型。如需服务多个模型或模型副本，客户应使用Amazon SageMaker AI推理组件，这有助于在模型和模型副本之间实现资源隔离。

自动配置功能通过消除对手动YAML配置文件的需求来简化KV缓存的部署，使客户能够快速开始LMCache优化。

部署建议

基于全面的基准测试结果和部署经验，出现了一些关于最佳LMI部署的建议：

当实例RAM允许时，配置CPU卸载，帮助为大多数工作负载提供最佳性能
对于需要超出可用RAM的更大缓存容量的工作负载，使用启用了O_DIRECT的NVMe
在SageMaker AI上实施基于会话的粘性路由，以帮助最大化缓存命中率并促进一致的性能
配置卸载阈值时要考虑模型架构，因为具有不同KV头配置的模型将具有不同的最佳设置
使用自动LMCache配置来简化部署并减少操作复杂性

EAGLE投机解码带来的性能增强

LMI的最新版本通过支持EAGLE投机解码技术帮助提供了性能改进。EAGLE（Extrapolation Algorithm for Greater Language-model Efficiency，更大语言模型效率的外推算法）通过直接从模型的隐藏层预测未来Token来加速大型语言模型解码。这种方法生成草稿Token，由主模型并行验证，有助于在保持输出质量的同时减少总体生成延迟。

配置EAGLE投机解码非常简单，只需在部署配置中指定草稿模型路径和投机Token数量即可。这使得组织能够在LLM托管工作负载中获得更好的性能，对高并发生产部署和以推理为中心的模型有益。

扩展的模型支持和多模态能力

LMI的最新版本有助于为尖端的开源模型提供全面的支持，包括DeepSeek v3.2、Mistral Large 3、Ministral 3以及Qwen3-VL系列。性能优化有助于提高这些架构的大规模模型服务的吞吐量和首次Token时间（TTFT）。扩展的多模态能力包括FlashAttention ViT支持，现已成为视觉语言模型的默认后端。EAGLE投机解码的改进带来了多步CUDA图支持和Qwen3-VL的多模态支持，从而加快了视觉语言工作负载的推理速度。通过这些增强功能，组织可以更快、更高效地部署和扩展基础模型（FM），这有助于缩短上市时间，同时降低操作复杂性。

LoRA适配器托管改进

LMI的最新版本为在SageMaker AI上托管多个LoRA适配器带来了显著的增强。LoRA适配器现在是“惰性”加载的——在创建推理组件时，适配器组件几乎立即可用，但适配器的实际加载权重和向推理引擎的注册发生在第一次调用时。这种方法有助于减少部署时间，同时为多租户场景保持灵活性。

现在支持基础模型和适配器的自定义输入和输出预处理脚本，每个托管LoRA适配器的推理组件都可以有不同的脚本。这使得无需修改核心推理代码即可实现适配器特定的格式化逻辑，支持不同的适配器对同一底层模型应用不同格式化规则的多租户部署。

自定义输出格式化器提供了一种灵活的机制，用于在模型响应返回给客户端之前对其进行转换，使组织能够标准化输出格式、添加自定义元数据或实现适配器特定的格式化逻辑。这些格式化器可以在基础模型级别定义以默认应用于响应，或在适配器级别定义以覆盖基础模型的LoRA适配器行为。常见用例包括添加处理时间戳和自定义元数据、使用前缀或格式转换生成的文本、计算和注入自定义指标、为不同的客户端应用程序实现适配器特定的输出模式，以及标准化跨异构模型部署的响应格式。