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

第2章 模型数据

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

在Kubernetes上运行大型语言模型（LLMs）时，最根本的挑战之一便是管理海量模型数据。LLMs的规模可从几GB到近TB不等，要高效地将这些数据引入集群供运行时访问，需要周密规划。

这些模型的主体部分由模型参数构成，其规模可能极其庞大。 表2-1列出了若干知名可用模型的参数数量及体积，这些模型均可自行运行。 虽然存在更多模型，但从这些选项中已能看出其差异范围之广。 它们涵盖了可能不适合按需使用的大型模型，以及可在自有集群上运行且能随时轻松下载的轻量级模型。

表 2-1. 开源模型及其体积

名称	供应商	参数	规格
Llama 4 Maverick	Meta	4000亿（MoE，170亿活跃用户）	~800 GB
DeepSeek-V3	DeepSeek	6710亿（百万亿次，370亿活跃）	~700 GB
羊驼 3.1405B	Meta	4050亿	~750 GB
Qwen3-235B	阿里巴巴	2350亿（月活跃用户，22亿活跃用户）	~118 GB
密斯特拉尔 8×220亿	Mistral	1410亿（MoE，390亿活跃用户）	~88 GB
GPT-OSS 120B	OpenAI	1170亿（最大错误率，50亿活跃）	~70 GB
Gemma 2 270亿	谷歌	270亿	~54 GB
花岗岩 130亿	IBM	130亿	~26 GB
猎鹰 211B	TII	110亿	~22 GB
密斯特拉尔 7B	Mistral	70亿	~14 GB

即便更小型的模型，对Kubernetes管理员而言，在集群内高效管理时仍会带来显著挑战。 掌握如何有效存储和组织这些大型数据集，对成功运行LLM至关重要。

本章将探讨如何在Kubernetes集群中高效管理数据密集型资产。 多数情况下，机器学习模型可视为不透明的盒子，通过第1章所述的推理服务进行访问。 但了解模型分发的封装格式对成功集成仍至关重要。 下一节将概述最重要的LLM存储格式。

运行LLMs的另一关键环节在于定位模型数据及其检索方式。 "模型注册表"章节探讨的模型注册表概念，为模型发现与访问提供了实用解决方案。

最后，模型必须下载至集群才能投入使用。 "在Kubernetes中访问模型数据"章节概述了基于Kubernetes原生机制的高效模型数据获取方案。

基于此路线图，让我们首先考察LLM数据的封装与存储方式。

模型数据存储格式

使用 LLMs时，首先注意到的是其海量规模——参数数量以数十亿计。 然而Hugging Face等平台共享的模型不仅包含原始权重参数。 这些分布式模型还包含元数据，某些情况下还包含模型架构，该架构定义了神经网络层与Transformer模块的连接方式。

对操作者而言，这类分布式模型常如黑箱般难以捉摸。 但理解其存储格式至关重要——正如第一章所述，并非所有封装模型都能在任意运行时环境中运行。 某些格式兼容性极强，可适配多种运行时；而另一些则与特定运行时平台紧密绑定。

从宏观层面看，模型存储格式可分为两类：

仅权重格式

这些格式仅存储神经网络的训练参数：权重和偏置。 网络架构、超参数及元数据均被排除在外，因此运行时必须预先掌握网络重建方法才能应用权重。

自包含格式

自包含格式同时存储权重、模型架构、超参数及其他元数据。 此类格式无需预先了解网络结构即可加载运行模型，便于作为独立工件部署。 ...