在消费级 GPU 上运行 671b 模型？利用 Unsloth 的量化突破，在 Aws 上运行 Deepseek R1！
Image from Amazon Nova Canvas
最近发布的深度寻求 R1 是一个 671B 参数模型，其性能可与 GPT-4 和 Claude 3 相媲美，这在 AI 社区引发了相当大的兴奋。传统上，运行这样一个庞大的模型需要像 AWS p5e 实例这样的高性能基础设施，费用为每小时 $84.8。然而，得益于 Unsloth AI 创新的动态量化方法，我们现在可以在更实惠的硬件上部署该模型，同时保持其大部分推理能力。
理解深度寻求 R1 和动态量化
深度寻求 R1 是一个具有开创性的 671B 参数模型，采用专家混合 (MoE) 架构。尽管总参数数量为 671B，但每个任务仅激活约 37B 参数，使其已经比传统架构更高效。该模型在复杂推理任务中表现出色，达到了：
- 在高级数学测试中接近 80% 的准确率
- 在编程挑战中超过 96% 的人类竞争者
- 在许多任务中与 GPT-4 和 Claude 的表现相似或更好
创新：动态量化
Unsloth 对深度寻求 R1 的量化方法特别巧妙，因为它考虑了模型独特的架构：
-
架构分析
- 前 3 层是完全稠密的（非 MoE），使用 0.5% 的权重
- MoE 层使用共享专家，占 1.5% 的权重
- MLA 注意力模块使用 <5% 的权重
- 剩余 88% 是可以进行大量量化的 MoE 权重
-
智能精度分配
- 稠密层：保持在 4–6 位精度
- 共享 MoE 专家：保持在 6 位精度
- 注意力模块：保持在 4–6 位精度
- 向下投影矩阵：在早期层中保持更高精度
- 剩余 MoE 权重：积极量化为 1.58 位
这种选择性的方法导致：
- 模型大小减少 80%（从 720GB 降至 131GB）
- 即使在最激进的 1.58 位量化下，模型输出依然良好
关键洞察是，简单地对所有层进行均匀量化会破坏模型，导致无尽的循环和乱码输出。相反，通过了解架构中哪些部分需要更高精度，Unsloth 实现了显著的大小减少，同时保持了功能性。
成本效益权衡
让我们看看价格差异：
- 在 p5en.48xlarge 上的完整 R1：$84.8/小时
- 在 g6e.12xlarge 上的 1.58 动态量化 R1：$10.493/小时
这意味着成本降低了 87%！虽然我们确实牺牲了一些性能和速度，但对于许多用例来说，这种权衡往往是值得的。
部署指南
深度寻求 R1 动态量化 1.58-bit 在 AWS 的 g6e.12xlarge 上运行。
在 Amazon EC2 上部署深度寻求 R1 有两种方法：
在深入这两种方法之前，我想感谢 Massimiliano Angelino，他的工作为我们稍后讨论的 Ollama 部署和性能分析提供了宝贵的见解。
对于这两种解决方案，第一步是创建一个能够处理大型语言模型推理的 EC2 实例。
启动 EC2 实例
首先，通过 AWS 控制台设置我们的 EC2 实例：
- 转到 EC2 控制面板并点击“启动实例”。
- 配置实例：
- 名称:
deepseek-r1-quantized - AMI: Ubuntu Server 24.04 LTS (HVM)
- 实例类型: g6e.12xlarge
- 密钥对: 创建新密钥对或选择现有密钥对
- 网络设置:
- 创建安全组
- 允许来自您 IP 的 SSH 流量
- 存储: 300 GiB gp3 (您需要为模型留出空间)
- 名称:
- 点击“启动实例”。
- 使用 您最喜欢的方法 连接到 EC2 实例。
使用 Ollama 的快速入门
这是最简单的路径，对于许多用户来说可能已经足够。感谢 Massimiliano Angelino 的工作，您可以仅通过两个命令使用 Ollama 运行 1.58 位量化版本的 深度寻求 R1：
curl -fsSL https://ollama.com/install.sh | sh
ollama run SIGJNF/deepseek-r1–671b-1.58bit
就是这样！模型将自动下载并运行。这种方法提供：
- (真的！) 最简单的设置过程
- 自动资源管理
虽然这种方法对部署的控制较少，但它非常适合：
- 简单的 API 部署
- 更喜欢便利而非精细控制的用户
这是 Ollama 文档，用于在 Linux 上将其用作服务器。
快速开始使用 llama.cpp
对于那些寻求更多控制权的部署，llama.cpp 提供了一个强大的替代方案。这种方法允许您微调模型执行的各个方面，从动态量化参数到内存管理。虽然它比 Ollama 方法需要多一些步骤，但额外的灵活性可能值得付出努力，特别是在生产环境中。
系统设置和 GPU 工具
首先，安装监控工具和 CUDA：
sudo apt-get update
sudo apt-get install nvtop
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-8
sudo apt-get install -y nvidia-open
sudo apt-get install build-essential cmake curl libcurl4-openssl-dev -y
sudo apt install nvidia-cuda-toolkit
注意：关于 cuda-toolkit 和 nvidia-open，您可以参考 以下 Nvidia 页面。
验证您的 GPU 安装：
构建 llama.cpp 以支持服务器
克隆并构建带有 CUDA 支持的 llama.cpp：
git clone https://github.com/ggerganov/llama.cpp
cmake llama.cpp -B llama.cpp/build \\
-DBUILD_SHARED_LIBS=OFF \\
-DGGML_CUDA=ON \\
-DLLAMA_CURL=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-quantize llama-cli llama-gguf-split llama-server
此构建命令创建多个可执行文件：
- llama-cli: 用于交互式命令行界面
- llama-server: 用于作为 API 服务器运行
- llama-quantize: 用于模型量化
- llama-gguf-split: 用于拆分大型模型
将可执行文件复制到可访问的位置：
cp llama.cpp/build/bin/llama-* llama.cpp
设置 Python 环境并下载模型
sudo apt-get install python3.12-venv
python3 -m venv .venv
source .venv/bin/activate
pip install huggingface_hub hf_transfer
cat << EOF > dwnmodel.py
## pip install huggingface_hub hf_transfer
import os # 可选，用于加快下载速度
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
from huggingface_hub import snapshot_download
snapshot_download(
repo_id = "unsloth/DeepSeek-R1-GGUF",
local_dir = "DeepSeek-R1-GGUF",
allow_patterns = ["*UD-IQ1_S*"], # 选择量化类型 UD-IQ1_S 进行 1.58bit 下载
)
EOF
python3 dwnmodel.py
注意：通过更改 allow_patterns = ["*UD-IQ1_S*"] 行，您可以从 Unsloth 下载所有动态量化模型。
运行模型
作为 CLI 接口
./llama.cpp/llama-cli \
--model 深度寻求-R1-GGUF/深度寻求-R1-UD-IQ1_S/深度寻求-R1-UD-IQ1_S-00001-of-00003.gguf \
--cache-type-k q4_0 \
--threads 12 -no-cnv --prio 2 \
--n-gpu-layers 62 \
--temp 0.6 \
--ctx-size 8192 \
--seed 3407 \
--prompt "<｜User｜\>创建一个 Python 的 Flappy Bird 游戏。<｜Assistant｜\>"
关键参数说明：
- n-gpu-layers 62: 将模型的 62 层全部卸载到 GPU — 如果 GPU 内存有限，请调整为更低的值。
- cache-type-k q4_0: 对 KV 缓存使用 4 位动态量化。
- temp 0.6: 推荐用于深度寻求 R1 的温度设置。
- ctx-size 8192: 设置上下文窗口大小。
- 提示格式
<｜User｜\>…<｜Assistant｜\>是特定于 深度寻求 R1 的分词器。
作为服务器
./llama.cpp/llama-server \
--model 深度寻求-R1-GGUF/深度寻求-R1-UD-IQ1_S/深度寻求-R1-UD-IQ1_S-00001-of-00003.gguf \
--cache-type-k q4_0 \
--threads 12 --prio 2 \
--n-gpu-layers 100 \
--ctx-size 8192
注意：服务器版本使用 --n-gpu-layers 100 来最大化 GPU 对并发请求的利用。这是可行的，因为模型的层数少于 100 层，因此它有效地将所有层卸载到 GPU。
使用简单的 curl 命令测试服务器：
curl -request POST \
-url http://localhost:8080/completion \
-header "Content-Type: application/json" \
-data '{"prompt": "<｜User｜\>2*2 等于多少<｜Assistant｜\>"}'
性能考虑
在 NVIDIA L40S GPU 上运行深度寻求 R1 1.58-bit 量化模型，所有层完全卸载到 VRAM 的内存消耗。
在 g6e.12xlarge 上使用 1.58-bit 量化，您可以期待：~20/25 tokens/秒的吞吐量。
虽然这比在 p5e 实例上运行的完整模型性能稍差，但有几条优化路径可供选择：
- 较少的激进量化：您可以使用 1.73-bit 或 2.22-bit 量化版本，这在增加内存使用的情况下提供更好的性能。这可能需要将更多层卸载到 CPU，但可以提供更好的输出质量。
- 实例升级：考虑使用 g6e.48xlarge（$30.131/小时），这仍然比 p5en.48xlarge（$84.8/小时）便宜得多（64%）。这使您能够：
- 处理更大的批量大小
- 运行更高精度的量化版本
- 实现更好的吞吐量
以下是快速的成本-性能比较（AWS 区域 us-west-1）：
- p5en.48xlarge（完整模型）：$84.8/小时
- g6e.48xlarge（2.51-bit）：$30.131/小时（-64% 以完整模型为参考）
- g6e.12xlarge（1.58-bit）：$10.493/小时（-87% 以完整模型为参考）
动态量化对模型性能的影响与在 p5e 实例上运行的完整版本相比，仍在社区中进行调查。尽管我们知道推理能力有所下降，Unsloth 在他们的动态量化博客中建议以下质量表：
| 专家混合 (MoE) 位数 | 磁盘大小 | 类型 | 质量 |
|---|---|---|---|
| 1.58-bit | 131GB | IQ1_S | 一般 |
| 1.73-bit | 158GB | IQ1_M | 良好 |
| 2.22-bit | 183GB | IQ2_XXS | 更好 |
| 2.51-bit | 212GB | Q2_K_XL | 最佳 |
最佳配置将取决于您的具体用例，需在以下方面进行平衡：
- 成本限制
- 所需推理速度
- 可接受的质量阈值
- 批处理需求
蒸馏与量化
最近 Massimiliano Angelino 的测试揭示了不同版本之间有趣的比较：
- 蒸馏与量化： R1-Distill-Llama-70B 在许多任务中表现优于 1.58 位量化版本，同时更具资源效率。
- 单 GPU 选项：为了最大限度地提高成本效率，R1-Distill-Llama-70B 可以在单个 GPU 上以 4 位量化运行。使用 g6e.xlarge 实例（$1.861/小时）成为较小部署的可行选项。
- Amazon Bedrock： R1-Distill-Llama-70B 可以通过自定义模型导入在 Amazon Bedrock 上部署，实现无服务器推理和按令牌计费的定价模型。
这表明，对于许多用例，特别是成本是主要关注点的情况下，蒸馏版本可能比运行量化完整模型更好。考虑你的具体需求：
- 需要最大推理能力？在 g6e.48xlarge 上使用 2.51 位量化版本以获得最佳质量/成本比。
- 想要平衡性能？选择在 g6e.12xlarge 上的 1.58 位量化版本。
- 寻求成本效率？考虑在较小实例上使用 R1-Distill-Llama-70B。
- 需要无服务器灵活性？在 Amazon Bedrock 上以按令牌计费的方式部署蒸馏版本。
有关在 AWS 服务（包括 SageMaker 和 Bedrock）上部署蒸馏版本的综合指南，请查看 Davide Gallitelli 的详细 Medium 帖子。
结论与下一步
运行深度寻求 R1 并不总是需要昂贵的专业硬件。通过动态量化，我们可以在更易获取的硬件上部署这个强大的模型，同时保持其大部分推理能力。
成本与性能之间的权衡使这种方法对于以下情况特别有吸引力：
- 开发和测试
- 小型到中型规模的部署
- 初始预算有限的项目
展望未来：SageMaker 文本生成推理
虽然上述 EC2 部署运行良好，但管理高可用性、扩展和基础设施可能会面临挑战。一旦 DeepSeek R1 的量化版本支持文本生成推理 (TGI)，在 Amazon SageMaker 上部署将带来显著优势：
- 自动扩展和高可用性
- 内置监控和日志记录
- 简化的部署和更新
- 通过自动扩展实现成本优化
- 与 AWS 安全功能的集成
在我们等待官方 TGI 支持的同时，EC2 部署仍然是测试和开发的可行解决方案。对于生产工作负载，请关注 TGI 兼容性公告，以利用 SageMaker 的托管基础设施。
致谢
这篇文章的完成离不开 Unsloth AI 的开创性工作。他们在动态量化方面的研究和开源贡献使深度寻求 R1 能够被更广泛的受众所接受。他们对模型架构的详细分析和创新的量化方法，通过他们的 博客文章 和 GitHub 仓库 公开分享，体现了 AI 社区的合作精神。
我想感谢 Massimiliano Angelino 在 Ollama 集成和不同 R1 版本性能分析方面的工作。
个人想法
作为一个广泛使用大型语言模型的人，我发现这种对尖端 AI 技术的民主化获取令人非常兴奋。虽然确实有一些用例需要完整模型的性能，但拥有一个具有成本效益的替代方案为创新和实验开辟了无数可能性。
一般免责声明
本篇文章仅用于演示和教育目的。所示的实现并未经过进一步修改和加固，不适合生产使用。在部署到生产环境之前，请确保您：
- 进行全面测试
- 执行安全评估
- 实施适当的错误处理
- 根据您的具体要求进行优化
- 遵循 AWS 和行业最佳实践
本文中表达的观点是我个人的看法，并不一定代表 AWS 或任何其他组织的观点。
