Kubernetes 上的生成式人工智能 (Chinese Edition)

第四章 生产环境运行

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

至此，您可能已将首个LLM部署至Kubernetes环境运行。 它能响应请求，延迟表现或许尚可。 但生产环境的考验在于持续稳定——需在高负载下实现大规模稳定运行。

本章将聚焦这一转型过程。 我们将探讨如何在实际场景中实现LLM推理的稳定高效运行。 内容涵盖参数调优等常见议题，以及易被忽视的关键环节：运行时内存规划、将粘性请求路由至缓存预热副本、模型压缩决策，以及需要专用网络配置的高级拓扑结构。

将模型服务器视为普通容器固然诱人—— 只需设置资源限制、暴露服务接口便可草草了事。 但生成式AI工作负载具有独特特性（超大规模模型、可变请求成本、GPU密集型操作），需要专业化配置。 你将学会如何有效配置平台，同时规避那些悄然侵蚀性能、耗尽GPU预算的陷阱。

本章涵盖五大关键领域：

模型与运行时调优

模型选择、评估、压缩与基准测试

自动扩展

针对LLM工作负载的特定策略

优化超大规模语言模型启动时间

降低部署延迟

支持LLM的路由机制

智能请求分配

解耦服务

高级分布式架构

最根本的决策在于如何选择并调优模型，使其精准匹配应用场景，同时避免计算周期浪费。

模型与运行时调优

当团队着手开发首个基于生成式AI的实际应用时，最关键的考量因素 当属模型选型。 多数团队会从OpenAI的ChatGPT这类配置选项有限的托管服务起步。 但在许多场景下，本地基础设施是必备条件。 此时模型的选择至关重要。 该选择需综合考量多种因素，如任务类型、工作负载类型（实时推理与批量推理）及并发请求数量。

模型规模固然重要，但相同规模的两个模型可能采用不同的架构和训练技术，导致相同查询结果从高度准确到完全错误。

鉴于选择的重要性，确定起点颇具挑战。 可用模型数量庞大且新模型持续涌现，使筛选过程令人望而生畏。

虽不存在万能解决方案或统治所有场景的单一模型，但筛选时不应涵盖Hugging Face平台上的所有模型。 开发预测型AI模型时，常见任务包括基于准确率对比同任务训练模型，因此建立LLMs准确率的比较指标具有重要意义。

传统预测型AI模型针对特定问题进行训练，而LLMs则基于海量数据集训练，可执行多任务。要有效比较LLMs，需先确定应用场景的关键任务，再基于该任务选择准确率指标。

此阶段至关重要，它能引导模型选择基于具体指标而非人工测试。 该问题极为复杂，为此已形成语言模型评估的完整研究领域。

语言模型评估

语言模型的评估可针对 诸多维度展开，例如衡量模型知识储备的丰富程度、生成无毒语言内容的能力，乃至处理推理任务的优劣表现。 该定义并非LLMs专属；在LLM时代之前定义的众多传统语言模型同样适用此原则。

语言评估最重要的应用之一，是通过特定任务验证模型安全性，以衡量模型毒性或鲁棒性。

众多项目提供了单一或多项评估基准；其中最常用的套件是EleutherAI的lm-evaluation-harness，包含上百个开箱即用的任务。 此外还有其他库，且常有新评估技术被定义，以在日益复杂的场景中测试模型。

传统评估任务包含两部分：数据集（通常采用简化分析的多选题形式）及其对应的输出结果，以及用于计算指标的评估函数。这种格式便于领域专家审查数据集，并可轻松划分子主题以更精准地分类模型能力。

每个基准测试本质上是一套流程：通过预定义的问答对调用目标模型并分析结果，因此运行耗时（甚至数小时），且需部署模型，执行成本极高。 所幸主流模型均可在线查阅排行榜，这些平台汇总了多项基准测试结果，便于模型对比。 ...