@UnslothAI: 我们与 AWS 合作，撰写了一份关于 LLM 量化和部署的完整指南。了解：• 模型格式、动态…

我们与 AWS 合作编写了一份关于 LLM 量化和部署的完整指南。了解：• 模型格式、动态量化及自行制作 • GGUF、NVFP4 或 FP8 • 正确的工具及在 Amazon SageMaker 上部署 • 基准测试质量、延迟和成本 阅读：https://aws.amazon.com/blogs/machine-learning/deploying-quantized-models-on-amazon-sagemaker-ai-with-unsloth/… — # 使用 Unsloth 在 Amazon SageMaker AI 上部署量化模型 | Amazon Web Services 来源：https://aws.amazon.com/blogs/machine-learning/deploying-quantized-models-on-amazon-sagemaker-ai-with-unsloth/ 本文与 Unsloth 的 Daniel Han 和 Michael Han 共同撰写。 部署以原始 16 位浮点精度（BF16 或 FP16）存储的大型基础模型（FM）成本高昂。它们需要大型 GPU 实例，从而推高服务成本并拖慢迭代周期。量化通过降低模型权重的数值精度（例如从 16 位降至 4 位）来解决这个问题，这能显著减少内存使用。量化的缺点是可能降低模型精度，而这正是动态量化引人注目的地方。如果操作得当，动态量化可以在保持精度的同时减少内存使用。实例成本、存储和启动时间的节省在规模扩大时会迅速叠加。在这篇文章中，你将学习四种部署模式，用于将已经使用 Unsloth(https://github.com/unslothai/unsloth) 量化的模型部署到 AWS 基础设施上。这些模式使用 Amazon Elastic Compute Cloud (Amazon EC2) 进行直接实例访问，使用 Amazon SageMaker AI 推理端点进行托管服务，以及使用 Amazon Elastic Kubernetes Service (Amazon EKS) 或 Amazon Elastic Container Service (Amazon ECS) 当推理需要融入现有容器框架时。你还将学习面向生产部署的运营实践。 ## 什么是 Unsloth 动态量化？ 正如 Unsloth 联合创始人 Daniel Han 所解释的那样(https://www.youtube.com/live/wRcByxXkJCQ&t=1577)： > “强大模型的最大问题是它非常庞大，运行它需要 1.5TB。通过一些技巧，你可以将模型大小降至 217GB。你可能会认为，既然它小了 86%，精度也会下降 86%，但事实并非如此，它只降低了 14% 的精度。我们将这种方法称为动态量化，并展示了许多基准测试，说明你可以减少模型的磁盘空间，不是将所有权重量化到 4 位等，而是让某些层保持在更高的 8 位。” 在实际应用中，量化减少了存储每个权重所用的位数。标准的 BF16 模型每个参数使用 16 位。量化到 4 位可将大小缩小 75%，但实际文件大小会因量化元数据而稍大一些。对于一个 80 亿参数的模型，这将内存占用从大约 16 GB 降至大约 5 GB。这往往就是需要多 GPU 实例和可以舒适地容纳在单个 GPU 上的区别。 Unsloth (https://github.com/unslothai/unsloth) 是一个用于微调和量化基础模型的工具。 Unsloth Dynamic (https://unsloth.ai/blog/dynamic-4bit) 是一种超越均匀压缩的量化方法。它不是对每一层应用相同的位缩减，而是分三步进行： 1. 逐层分析 – Unsloth 测量每一层对精度损失的敏感程度。 2. 动态位分配 – 重要的层（那些精度损失会导致输出严重退化的层）保持较高的精度（例如 16 位），而较不敏感的层则进行激进的量化（4 位或更低）。 3. 精度调优 – 对量化进行调优，使得组合输出质量尽可能接近原始模型，同时尽可能减小磁盘空间使用。 此过程的最终目标是使量化模型与标准模型之间的精度差异尽可能小，同时将模型大小压缩一个有意义的量。 通过开源 Unsloth 包，你可以在一个统一的工作流程中微调、运行、导出和部署模型。 当你在 AWS 上部署时，量化之所以重要，是因为它同时改变了三件事。首先，实例决策：原本需要更大 GPU 的大型模型可能在较小的 GPU 上甚至 CPU 上变得可行。其次，启动和存储特性：更小的模型文件在环境间移动、存储和提升更快。第三，部署灵活性：你可以为成本敏感的推理选择较小的模型文件，为质量敏感的推理选择更高保真度的导出，或为更高吞吐量的 GPU 服务选择合并表示。这种灵活性使得 Unsloth 在 AWS 环境中非常有用。有了它，你可以根据服务路径调整模型，而不是迫使每个部署都遵循相同的运行时间和硬件假设。 ## 使用哪种模型格式 Unsloth 部署工作流中的一个关键原则是，输出工件应驱动服务设计。基础设施选择是第二步。首先，选择工件和运行时间，然后将该运行时间放置在与你的运营模式相匹配的 AWS 服务上。 Unsloth 支持多种面向部署的输出类型： - GGUF 文件 – GGUF 是一种单一文件格式，将模型权重、分词器和元数据打包在一起，使其自包含且无需额外文件即可加载。用于轻量级运行时间，如 llama.cpp、Ollama 和 Unsloth (https://unsloth.ai/docs/new/studio/install)。在 AWS 上，这映射到 Amazon EC2 或 Amazon SageMaker AI 自定义容器。 - 合并的 safetensors 权重 –（16 位、8 位、FP8 4 位、NVFP4）可以通过 Unsloth 创建，用于更高吞吐量的引擎，如 vLLM (https://docs.vllm.ai/) 和 SGLang (https://sgl-project.github.io/)。在 AWS 上，这映射到 Amazon SageMaker AI 大型模型推理（LMI）容器、Amazon EKS 或 Amazon ECS。 ## 实用部署地图 下表将每种工件类型映射到其最适合的运行时间和 AWS 目标，以便你快速识别符合需求的部署模式。 工件 | 最适合的运行时间 | 最适合的 AWS 目标 | 使用场景 — | — | — | — GGUF | llama.cpp / llama-server 或 Unsloth | Amazon EC2 | 通过直接实例访问进行最快的手动测试 GGUF | 自定义容器中的 llama.cpp 或 Unsloth | Amazon SageMaker AI | 具有自动扩缩的托管端点，轻量级运行时间 合并的 16 位或 4 位权重 | vLLM / SGLang / LMI 后端 | Amazon SageMaker AI | 高吞吐量、批处理、自动扩缩、生产级 GPU 服务 任何容器化堆栈 | 你偏好的运行时间 | Amazon EKS 或 Amazon ECS | 推理必须融入现有容器框架 本篇文章中的每种部署模式都遵循相同的一般工作流程： 1. 在 Unsloth 中微调或下载模型。 2. 导出与你想要的运行时间匹配的模型文件。 3. 在本地或 Amazon EC2 上验证运行时间。 4. 将相同的模型文件和运行时间组合推广到托管或环境原生的部署。 这种顺序有助于避免后续出现意外行为，尤其是在内存使用、提示格式和延迟行为方面。 ## 模式 1：在 Amazon EC2 上使用 llama.cpp 和 Unsloth 的 GGUF 使用此模式可以通过直接实例访问快速验证量化级别。对于许多用例，Amazon EC2 是一个强大的起点，因为你获得了最大程度的控制权和最小程度的抽象。对几个量化级别进行基准测试，测试提示格式，比较 CPU 与 GPU 行为，并在承诺使用托管端点设计之前了解实际的内存占用。 典型的 Unsloth 导出如下所示： model.save_pretrained_gguf("gguf_model", tokenizer, quantization_method="q4_k_xl") 这将生成一个 GGUF 文件，可用于基于 llama.cpp 的本地推理。配套仓库对其量化端点使用 q4_k_xl。不同的量化方法控制文件大小和输出保真度之间的权衡：使用 q8_0 可获得更高的输出保真度，但文件大小大约翻倍；或使用 f16 获得全精度 GGUF，没有量化损失。请参阅 Unsloth GGUF 文档(https://unsloth.ai/docs/basics/unsloth-dynamic-2.0-ggufs) 获取完整的量化方法及其特性列表。 获得 GGUF 后，最小的 llama-server 启动需要以下配置： llama-server \ --model /models/my-model.gguf \ --alias my-model \ --ctx-size 8192 \ --host 0.0.0.0 \ --port 8080 unsloth run \ --model /models/my-model.gguf \ --alias my-model \ --ctx-size 8192 \ --host 0.0.0.0 \ --port 8080 此时，你的应用程序可以通过与 OpenAI 兼容的接口与模型通信： from openai import OpenAI client = OpenAI( base_url="http://<instance-ip>:8080/v1", api_key="not-required", ) response = client.chat.completions.create( model="my-model", messages=[ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "用两句话解释 AWS Graviton。"}, ], max_tokens=128, ) print(response.choices[0].message.content) > **⚠️ 重要提示：**此配置适用于隔离测试。对于生产环境，请将安全组限制为已知的无类别域间路由（CIDR）块，绑定到私有接口（例如 127.0.0.1），并将端点放在经过身份验证的 API 网关或负载均衡器后面。 这条路径之所以有吸引力，有三个原因。它易于调试，紧贴上游运行时间行为，并且为你提供了一个干净的地方来测试量化选择，然后再添加容器契约、自动扩缩策略或端点治理。Amazon EC2 也是评估实际部署问题最直接的地方： - **量化质量 –**根据你的具体评估标准，比较不同量化级别（例如 q4_k_m 与 q8_0）的输出。质量影响因模型架构和任务而异。 - **硬件要求 –**如果模型的内存占用超过可用 CPU RAM，则需要基于 GPU 的实例。检查推理期间的峰值内存使用，不仅仅是模型加载。为了获得最佳性能，请确保有足够的 RAM 或 VRAM 将整个模型加载到内存中。例如，如果模型磁盘大小为 128 GB，请确保可用 RAM 或 VRAM 超过 128 GB。 - **上下文长度权衡 –**更长的上下文窗口会增加延迟和内存消耗。使用代表性的提示长度进行测试，以找到适合你工作负载的正确平衡。 - **聊天模板验证 –**验证结构化的提示格式（将“system”和“user”等角色映射到模型期望的令牌序列）是否在训练环境之外产生一致的行为。 对于评估、内部工具、概念验证工作和早期生产试点，Amazon EC2 通常是正确的起点。 ## 模式 2：在 Amazon SageMaker AI 上使用自定义容器的 GGUF 对于快速迭代，我们推荐使用 Amazon EC2，但它不能开箱即用提供托管推理服务。当你想要一个具有自动扩缩、监控、AWS Identity and Access Management (IAM) 集成和稳定 API 表面的生产端点时，Amazon SageMaker AI 推理端点成为更好的选择。 对于 GGUF 部署，最实用的设计通常是自定义推理容器，将 GGUF 模型文件与 llama.cpp 或其他轻量级运行时间打包在一起。然后，该容器暴露 Amazon SageMaker AI 托管接口，这要求容器监听端口 8080，实现 /ping 用于健康检查，以及 /invocations 用于推理请求。 配套 GitHub 仓库(https://github.com/aws-samples/sample-quantized-ML-model-comparison) 包含此模式的完整工作示例。它部署了 Unsloth 动态量化的 Qwen3-VL-8B-Instruct（在 ml.g5.xlarge 上使用 llama.cpp 服务的 Q4_K_XL GGUF，约 $1.41/小时）与全精度 BF16 变体（在 ml.g5.12xlarge 上使用 vLLM 服务，约 $7.09/小时）的并排比较。价格为截至 2026 年 6 月的价格；请参阅 Amazon SageMaker AI 定价页面(https://aws.amazon.com/sagemaker/pricing/) 了解当前费率。 入口点脚本在内部端口上启动 llama-server，并使用 nginx 作为反向代理以满足 Amazon SageMaker AI 接口： # 使用 GGUF 模型和视觉投影仪启动 llama-server /app/llama-server \ --model /models/Qwen3-VL-8B-Instruct-UD-Q4_K_XL.gguf \ --mmproj /models/mmproj-F16.gguf \ --host 0.0.0.0 \ --port 8081 \ --ctx-size 4096 然后，Nginx 将 /ping 映射到 llama-server 健康检查，将 /invocations 映射到聊天补全端点，从而为 Amazon SageMaker AI 提供一个标准接口，同时保持运行时间轻量： # SageMaker 健康检查端点 location /ping { proxy_pass http://llama_backend/health; } # SageMaker 推理端点 -> llama.cpp 聊天补全 location /invocations { proxy_pass http://llama_backend/v1/chat/completions; proxy_read_timeout 120s; } 一个常见的架构可能如下： 1. 将最终的 GGUF 模型文件存储在 Amazon Simple Storage Service (Amazon S3) 中。 2. 启动 Amazon SageMaker AI 容器并将模型放置在 /opt/ml/model 下。 3. 针对本地模型文件启动 llama.cpp 或 Unsloth。 4. 暴露一个将 Amazon SageMaker AI 请求转换为本地推理调用的薄 API 层。 下面的架构图来自配套 GitHub 仓库，展示了示例如何部署量化 GGUF 端点（此模式）和全精度 vLLM 端点（模式 3）。流程如下： 架构图显示了两个使用 Terraform 部署的 Amazon SageMaker AI 实时端点：一个量化 GGUF 端点（由 llama.cpp 在 ml.g5.xlarge 上服务的 Qwen3-VL-8B-Instruct Q4_K_XL）和一个全精度 BF16 端点（由 vLLM 通过 LMI 在 ml.g5.12xlarge 上服务）。支持基础设施包括 Amazon ECR、AWS CodeBuild、Amazon S3 和 VPC 网络。 图：配套示例部署的架构图。 1. Terraform 配置所有基础设施，包括 Amazon Elastic Container Registry (Amazon ECR)、AWS CodeBuild 和 Amazon S3 资源。 2. AWS CodeBuild 构建自定义容器镜像并将其推送到 Amazon ECR。 3. Amazon SageMaker AI 在虚拟私有云（VPC）内创建两个实时端点：一个用于量化 GGUF 模型（模式 2），一个用于全精度模型（模式 3）。 4. 两个端点在启动时从 Amazon S3 拉取各自的模型文件。 5. Amazon SageMaker Notebook 实例提供对比较笔记本的访问，用于对两个端点进行评估。 这种模式效果很好，因为它保持了运行时间的轻量，同时让 Amazon SageMaker AI 处理生产中重要的运营问题，例如端点生命周期和自动扩缩。对于较小的模型，这条路径在基于 CPU 的端点上尤其有吸引力。对于较大的量化模型或更低的延迟要求，你可以将相同的设计迁移到基于 GPU 的端点上。 一个权衡是 llama.cpp 是推理/部署引擎，而不是整个服务系统。在 Amazon SageMaker AI 中，你仍然需要一个行为类似于 Amazon SageMaker AI 端点的容器。该包装层不需要大量的实现工作，但它是生产设计中的一个重要部分。 ## 模式 3：在 Amazon SageMaker AI 上使用 GPU 优化服务引擎的合并权重 当模型文件大小和轻量级服务是优先考虑事项时，GGUF 非常出色。当优先考虑吞吐量和 GPU 效率时，它并不总是正确的选择。在这些场景中，合并权重变得更有吸引力。合并权重是指将模型保存为