一、核心概念 ——权重、架构与文件结构

1. 模型权重：你下载的到底是什么

模型 = 架构（Architecture）+ 权重（Weights）。这两者缺一不可，但它们的性质完全不同。

1.1. 常见误区：模型文件大 ≠ 模型能力强

模型的能力主要由两个因素决定：

• 参数量（Parameter Count）：模型有多少个可学习的参数
• 训练数据质量：模型"读过"多少高质量的文本

但模型文件的大小，还受到量化精度的影响。举个例子：

• 一个 7 B 参数的 FP 16 模型，文件大小约为 14 GB（7 * 2 = 14）
• 一个 70 B 参数的 INT 4 模型，文件大小约为 35 GB（70 * 0.5 = 35）

虽然后者文件更大，但 70 B INT 4 的能力远超 7 B FP 16——因为参数量相差 10 倍。所以，判断模型能力要看"参数量"，而不是"文件大小"。文件大小只是"参数量 × 精度"的结果。

1.2 两种"用脑方式"：Dense 模型与 MoE 模型

Dense 模型：全员上阵的"全才"（稠密模型）

我们前面讨论的 Qwen3-8B、Llama 3.1-70B 等模型，都属于 Dense（稠密）模型。它们的工作方式很直接：对于输入的每一个 token，模型中的所有参数都会参与计算。

用一个类比来理解：Dense 模型就像一个"全能型选手"，无论遇到什么问题——写代码、翻译、聊天、做数学题——都要调动全身所有的"脑细胞"来处理。Llama 3.1-70B 有 700 亿参数，每次推理就要计算这 700 亿个参数，一个都不能少。

MoE 模型：按需出诊的"专家团"（稀疏模型）

MoE 模型则采用了一种完全不同的策略：它拥有海量的参数，但每次只激活其中一小部分来处理当前的输入。

继续用类比来理解：MoE 模型就像一个大型医院的"专家会诊中心"。医院里有几百位专科医生（专家），但每个病人来了之后，前台（门控网络）会根据症状只派 2-8 位最相关的专家去会诊，其余医生继续待命。这样既保证了诊断质量（因为总共有几百位专家的知识储备），又控制了每次会诊的成本（只有几位专家实际工作）。

以 DeepSeek-V3 为例：它的总参数量高达 671B，但每次推理只激活约 37B 参数。这意味着你用跑 37B 模型的算力，就能享受到 671B 模型的知识储备。

Dense 模型与 MoE 模型核心对比

MoE 的内部结构：门控网络与专家

MoE 并没有改变 Transformer 的整体架构，而是修改了其中的 FFN（前馈神经网络）层。传统 Transformer 中，每一层都有一个统一的 FFN 处理所有输入；而在 MoE 架构中，这个 FFN 被拆分成了多个独立的小 FFN，每一个就是一个"专家"。

MoE 的核心组件有两个：

• 门控网络（Router）：这是 MoE 的"分诊台"。当一个 token 输入时，门控网络会计算它与各个专家的匹配度，然后选择分数最高的 Top-K 个专家（例如 Top-2 或 Top-8）。只有被选中的专家会进行计算，其他专家被跳过。
• 专家（Experts）：每个专家本质上就是一个独立的小型 FFN。不同的专家在训练过程中会自然地习得不同的知识模式——有的擅长处理语法结构，有的擅长代码逻辑，有的擅长数学推理。

现代 MoE 的关键创新：共享专家

共享专家的设计思路很直观：

• 共享专家：无论输入是什么，永远被激活，负责处理通用知识（语法、常识等）
• 路由专家（Routed Experts）：按需激活，负责处理专业知识（代码、数学、特定领域等）

MoE 的部署悖论：算得快，但装不下

理解了 MoE 的工作原理后，我们就能看到它在部署时面临的核心矛盾：虽然每次计算只用到一小部分参数，但所有参数都必须加载到内存中等待被召唤。

这就引出了 MoE 模型本地部署的关键策略——Expert Offloading（专家卸载）：

• 将共享专家和当前激活的路由专家放在 GPU 显存中（快速计算）
• 将大量休眠的路由专家放在 CPU 内存（RAM）中（等待被召唤）

对于 MoE 模型的本地部署，你的内存（RAM）容量可能比显存（VRAM）更重要。

2. 模型文件夹解剖学

2.1. 核心文件一览

2.2. config.json：模型的"蓝图"

config.json 是模型加载时的入口文件，它定义了模型的"物理规格"。当 Transformers 库执行 from_pretrained() 时，第一件事就是读取这个文件，根据其中的配置来构建模型骨架。

关键字段解读

{
  "architectures": ["Qwen 3 ForCausalLM"],
  "hidden_size": 4096,
  "num_hidden_layers": 32,
  "num_attention_heads": 32,
  "vocab_size": 151936,
  "max_position_embeddings": 32768
}

让我们逐个理解这些字段的含义：

• architectures：指定模型类型，告诉加载库应该调用哪个 Python 类来构建模型骨架
• hidden_size：隐藏层维度，决定模型的"宽度"
• num_hidden_layers：层数，决定模型的"深度"
• num_attention_heads：注意力头数量，多头注意力机制的核心参数
• vocab_size：词表大小，决定模型能"认识"多少个不同的 token
• max_position_embeddings：最大位置编码，决定模型能处理多长的上下文

实战技巧：如果你想确认下载的模型是否完整（比如层数对不对），或者想手动修改某些配置（如调整上下文窗口限制），第一件事就是查看 config.json。

2.3. tokenizer：模型的"翻译官"

Tokenizer（分词器）的作用就是在"人类语言"和"模型语言"之间架起桥梁。

Tokenizer 的工作流程

用户输入："今天天气真好"
    ↓ tokenizer.encode()
Token IDs：[1234, 567, 890, 234, 567]
    ↓ 送入模型
模型输出：[2345, 678, ...]
    ↓ tokenizer.decode()
生成文本："是的，阳光明媚..."

核心文件说明

• tokenizer.json：存储了数万个词汇到 ID 的映射表（Vocabulary）。Qwen 3 的词表大小约为 15 万，这意味着它能"认识" 15 万种不同的 token。
• tokenizer_config.json：定义了分词的规则（如是否在句首加空格）以及特殊 Token 的配置（如 <|end_of_text|> 用于标记生成的结束）。

2.4. safetensors vs bin：安全性的演进

.safetensors 和 .bin（或 pytorch_model.bin）都是存储模型权重的格式，但它们有本质的区别。现代模型几乎都使用 .safetensors 格式，这是有充分理由的。

.bin 文件基于 Python 的 pickle 序列化模块。pickle 的一个"特性"是：它允许在反序列化（加载文件）时执行任意 Python 代码。这意味着，黑客可以在 .bin 文件中植入恶意脚本，当你加载模型时，电脑就可能被控制。

为什么 .safetensors 更好？

.safetensors 是由 Hugging Face 推出的新标准，它是纯二进制格式，只存储张量数据，不包含任何可执行代码，从根本上杜绝了安全风险。此外，它还支持内存映射（Memory Mapping），可以直接将文件从硬盘映射到内存，大大缩短加载时间。

实战建议：在下载模型时，优先选择 .safetensors 格式的版本。如果只有 .bin 格式可用，要确保来源可信（官方仓库或知名发布者）。

2.5. 大模型的分片机制

如果你下载过 70 B 级别的大模型，你会发现权重文件不是一个，而是被分成了多个文件，比如：

model-00001-of-00004.safetensors
model-00002-of-00004.safetensors
model-00003-of-00004.safetensors
model-00004-of-00004.safetensors
model.safetensors.index.json

为什么要分片？

1. 文件系统限制：某些文件系统（如 FAT 32）对单文件大小有 4 GB 限制
2. 并行下载：分片后可以多线程同时下载，加快速度
3. 断点续传：下载中断后只需重新下载失败的分片

index.json 的作用

model.safetensors.index.json 是分片的"目录"，它记录了每一层权重存储在哪个文件中。加载库会先读取这个索引文件，然后按需加载对应的分片。

避坑提醒：下载大模型时，一定要确保所有分片都下载完整。如果缺少某个分片，模型加载会直接报错。使用 huggingface-cli download 或 snapshot_download() 可以自动处理分片下载和完整性校验。

2.6. generation_config.json：模型的"性格"

generation_config.json 是一个可选但重要的文件，它定义了模型生成文本时的默认行为。

{
  "temperature": 0.7,
  "top_p": 0.8,
  "max_new_tokens": 512,
  "do_sample": true,
  "eos_token_id": 151643
}

关键参数解读

• temperature：控制随机性，值越高输出越发散，值越低输出越确定
• top_p：核采样阈值，只从累积概率达到 p 的 token 中采样
• max_new_tokens：最大生成长度
• eos_token_id：结束符 ID，模型生成到这个 token 就停止

🔥 踩坑预警：很多小白抱怨模型"车轱辘话"或者"停不下来"，往往是因为 generation_config.json 中的 eos_token_id 设置错误，或者与 Tokenizer 中的定义不一致，导致模型不知道何时该停止生成。解决方案：确保 eos_token_id 与 tokenizer_config.json 中的定义一致。

3. 显存估算速算法

工具地址：https://help.aliyun.com/zh/pai/getting-started/estimation-of-the-required-video-memory-for-the-model

3.1. 静态显存：模型权重的硬性门槛

静态显存是指模型权重本身占用的显存，这是一个固定值，由模型参数量和量化精度决定。通用估算公式

静态显存 (GB) ≈ (参数量 (B) × 每参数比特数) / 8

MoE 模型的显存陷阱：用总参数量计算，而非激活参数量

在估算显存时，必须使用总参数量，因为所有专家的权重都必须加载到内存中

以 DeepSeek-V3 为例，我们来看这个差异有多大：

MoE 模型显存估算的常见误区

3.2. 动态显存：KV Cache 的隐藏陷阱

什么是 KV Cache？

模型在生成第 N 个 token 时，需要"回头看"前 N-1 个 token 的信息。为了不重复计算，模型会把之前所有 token 的 Key 和 Value 向量缓存起来，这就是 KV Cache。

KV Cache 的增长规律

KV Cache 的大小与上下文长度成线性正比。对话越长，缓存越大，显存占用越多。

估算公式（以 FP 16 为例）

3.3. 2026 主流模型显存速查表

从这张表中可以清晰地看到 Dense 和 MoE 两种架构在显存需求上的巨大差异。Dense 模型的总参数量和激活参数量相同，显存估算直接套公式即可；而 MoE 模型的总参数量远大于激活参数量，显存必须按总参数量计算，这也是为什么 MoE 模型几乎都需要借助 CPU 内存进行混合推理。

3.4. 显存不够怎么办？

二. 云端部署——AutoDL 算力租赁指南

1. 平台认知：为什么选择 AutoDL？

1.1. AutoDL 的核心定位

AutoDL 核心优势对比

2. 算力选购：创建你的第一个实例

算力市场页面展示了当前可用的所有 GPU 实例类型，包括：

• GPU 型号与显存容量
• 可用数量与空闲状态
• 每小时计费价格
• 所在地区（不同地区网络延迟略有差异）

2.1. GPU 型号选择指南

2.2. 实例创建实战步骤

步骤一：选择 GPU 型号与数量

步骤二：选择基础镜像

AutoDL 提供了丰富的基础镜像选项：

• PyTorch：广泛使用的深度学习框架，推荐选择 2.x 版本
• TensorFlow：另一主流框架
• Miniconda：纯净的 Python 环境，自行安装依赖

对于本次 Ollama 和 vLLM 部署实战，我们选择 PyTorch 2.x + CUDA 12.x 的镜像组合。

步骤三：确认配置并开机

2.3. 数据盘与系统盘的区别

重要警告：所有重要文件必须存储在 /root/autodl-tmp 目录下！存储在其他位置的文件可能在关机后丢失。

2.4. 磁盘空间管理与清理实战

步骤 1:对比 df 和 du 的差异

# 查看文件系统整体使用
df -h /root/autodl-tmp

# 查看目录实际占用
du -sh /root/autodl-tmp

判断标准：如果 df 显示的使用量远大于 du 显示的大小,说明存在已删除但被进程占用的文件!

# 安装 lsof 工具
apt update && apt install -y lsof

# 查找所有已删除但被占用的文件
lsof | grep deleted

# 只看 autodl-tmp 目录下的
lsof | grep -E "autodl-tmp.*deleted"

# 按大小排序,找出占用空间最大的
lsof | grep deleted | awk '{print $7, $9}' | sort -rn | head -10

输出示例:

python    12345  root   3w   REG  253,0  15GB  /root/autodl-tmp/model.safetensors (deleted)
vllm      67890  root   5r   REG  253,0  8GB   /root/autodl-tmp/cache/chunk_00.bin (deleted)

从输出可以看到:

• PID 12345 的 Python 进程持有 15 GB 的已删除文件
• PID 67890 的 vLLM 服务持有 8 GB 的已删除缓存

步骤 3：释放被占用的文件空间

2.5. AutoDL 磁盘清理完整脚本

#!/bin/bash
# AutoDL 磁盘空间释放完整脚本

echo "========== 步骤1:检查磁盘空间差异 =========="
DF_USAGE=$(df -h /root/autodl-tmp | tail -1 | awk '{print $3}')
DU_USAGE=$(du -sh /root/autodl-tmp | awk '{print $1}')
echo "df 显示已用: $DF_USAGE"
echo "du 显示实际: $DU_USAGE"

echo ""
echo "========== 步骤2:查找已删除但被占用的文件 =========="
DELETED_FILES=$(lsof 2>/dev/null | grep deleted | grep -c autodl-tmp)
if [ "$DELETED_FILES" -gt 0 ]; then
echo "⚠️  发现 $DELETED_FILES 个被占用的已删除文件:"
lsof 2>/dev/null | grep deleted | grep autodl-tmp | \
        awk '{printf "PID: %-8s 大小: %-10s 文件: %s\n", $2, $7, $9}'

echo ""
echo "========== 步骤3:选择清理方式 =========="
echo "选项1: 清空文件内容(进程继续运行)"
echo "选项2: 终止占用进程(需重启服务)"
echo "选项3: 手动处理(退出脚本)"
read -p "请选择 (1/2/3): " choice

case $choice in
1)
echo "正在清空已删除文件的内容..."
lsof 2>/dev/null | grep deleted | grep autodl-tmp | while read -r line; do
PID=$(echo $line | awk '{print $2}')
FD=$(echo $line | awk '{print $4}' | tr -d 'rw')
echo "" > /proc/$PID/fd/$FD 2>/dev/null && \
                    echo "✅ 清空 PID=$PID FD=$FD"
done
;;
2)
echo "正在终止占用进程..."
lsof 2>/dev/null | grep deleted | grep autodl-tmp | \
                awk '{print $2}' | sort -u | xargs kill -15
sleep 2
echo "✅ 进程已终止,空间已释放"
;;
3)
echo "退出脚本,请手动处理"
exit 0
;;
esac
else
echo "✅ 没有发现被占用的已删除文件"
fi

echo ""
echo "========== 步骤4:最终空间检查 =========="
df -h /root/autodl-tmp
du -sh /root/autodl-tmp

echo ""
echo "========== 额外清理建议 =========="
echo "1. 清理 pip 缓存:"
echo "   pip cache purge"
echo ""
echo "2. 清理 HuggingFace 缓存:"
echo "   rm -rf /root/.cache/huggingface/hub/*"
echo ""
echo "3. 清理 conda 缓存:"
echo "   conda clean -a -y"

使用方法:

# 保存脚本
cat > /root/autodl-tmp/cleanup_disk.sh << 'EOF'
# (将上面的脚本内容复制到这里)
EOF

# 赋予执行权限
chmod +x /root/autodl-tmp/cleanup_disk.sh

# 运行脚本
/root/autodl-tmp/cleanup_disk.sh

2.6. AutoDL 特定注意事项

2.7. 最佳实践：安全删除大文件的标准流程

# 1. 找到可能占用文件的进程
lsof | grep <文件名或目录>

# 2. 停止相关进程
# ⚠️ 确认后取消注释再执行
# !systemctl stop vllm       # 或 kill -15 <PID>
jupyter notebook stop     # 如果是 Jupyter

# 3. 删除文件
# ⚠️ 确认后取消注释再执行
# rm -rf /root/autodl-tmp/large_model/

# 4. 验证空间释放
df -h /root/autodl-tmp
du -sh /root/autodl-tmp

# 5. 重启服务(如需要)
systemctl start vllm

3. 环境验证

关键信息解读：

• Name: 显卡型号（如 NVIDIA GeForce RTX 4090）
• Memory-Usage: 显存使用情况（刚开机应该是 0 MB / 24576 MB）
• CUDA Version: 支持的最高 CUDA 版本

conda 环境切换

# 使用 conda 安装（推荐，更稳定）
conda install ipykernel

# 或者使用 pip 安装
pip install ipykernel

# 将环境写入 Jupyter 的内核列表
python -m ipykernel install --user --name=ai_course --display-name "Python (AI Course)"

在新写入的 conda 环境后，需要刷新 AutoDl 的页面，然后才能在 ipynb 文件中看到 conda 环境！

三：量化技术入门——让大模型在消费级显卡上起舞

1. 精度与量化基础

我们需要先理解一个基础问题：同一个模型，为什么有 FP 16、INT 8、INT 4 这么多版本？它们之间有什么区别？为什么 INT 4 版本的文件只有 FP 16 版本的四分之一大小，但效果却差不多？

这就是我们这一节要深入探讨的主题：精度（Precision）与量化（Quantization）。这是让消费级显卡（如 RTX 4090）能够运行企业级大模型的关键技术。

1.1. 数据精度的物理意义

各精度详解

• FP32（单精度）：深度学习训练的"黄金标准"，精度极高，但一个 70B 模型需要 280GB 显存，远超任何消费级显卡。
• FP16（半精度）：推理的传统选择，显存需求减半。但数值范围较小，训练时容易出现数值溢出导致 NaN。
• BF16（Brain Float 16）：Google 为 AI 设计的格式，保留了 FP32 的指数位（数值范围相同），截断了尾数位。是 Ampere 架构（RTX 30系）及以后显卡的标配，推荐在支持的硬件上优先使用 BF16。
• INT8/INT4（整数量化）：用整数来近似表示浮点数，大幅减少显存占用，是本地部署大模型的关键技术。

⚠️ FP16 vs BF16 的区别：虽然两者都占 2 字节，但内部结构不同。BF16 保留了与 FP32 相同的指数位宽度，因此数值范围更大，训练时不易溢出；FP16 的尾数位更多，数值精度更高，但动态范围较小。简单记忆：BF16 更适合训练和微调，FP16 更常用于推理。在量化场景中，两者作为"基线精度"的表现几乎一致。

1.2. 量化：以"模糊"换"空间"

量化（Quantization）的本质是：将高精度的浮点数映射为低精度的整数，从而大幅减少显存占用。这就像是把一张 4 K 高清图片压缩成缩略图——文件变小了，但主体信息还在。

量化的数学直觉

假设模型中某个权重的原始值是 0.12345678（FP 32，占 4 字节）：

• FP 16 转换：保留约 4 位有效数字，变成 0.1235（占 2 字节）
• INT 8 量化：映射到 [-128, 127] 的整数范围，可能变成 31（占 1 字节）
• INT 4 量化：映射到 [-8, 7] 的整数范围，可能变成 2（占 0.5 字节）

量化后的整数需要配合一个"缩放因子"才能还原近似的原始值。这个过程会损失一些精度，但对于大多数任务来说，这种损失是可以接受的。

量化的实际效果

70 B 模型在不同精度下的显存需求

这就是为什么 INT 4 量化如此重要：它让原本需要几十万元服务器才能跑的 70 B 模型，变成了双卡 3090 就能本地运行。

1.3. INT 4 量化的实际表现

你可能会担心：精度损失这么多，模型效果会不会大打折扣？答案是：对于大多数应用场景（对话、摘要、代码生成），INT 4 量化的效果与 FP 16 惊人地接近。

困惑度（Perplexity）—— 量化质量的核心指标

Perplexity（简称 PPL）是衡量语言模型预测下一个 Token 能力的标准指标。简单来说，它衡量模型对一段文本感到"惊讶"的程度——PPL 越低越好，低 PPL 意味着模型能准确预测接下来的内容，生成的文本更通顺、逻辑更连贯。FP16 原始模型的 PPL 是"金标准"，量化后 PPL 会略微上升。

以 Qwen3-8B 为例：

Qwen3-8B 不同精度困惑度对比

2. 量化格式详解

在下载量化模型时会发现：同样是 INT 4 量化，怎么有 GGUF、GPTQ、AWQ 这么多格式？它们有什么区别？应该选哪个？

2.1. 三大主流量化格式对比

2.2. GGUF：最灵活的通用格式

它的核心优势可以用一句话概括：显存不够，内存来凑。

GGUF 允许将一部分层加载到 GPU（显存），剩余部分留在系统内存（RAM）由 CPU 计算。

除了混合推理，GGUF 还有以下优势：

• 单文件部署：所有信息（权重、配置、分词器）打包在一个 .gguf 文件中，下载即用
• 广泛兼容：ollama、LM Studio、llama.cpp 等主流工具都原生支持
• Mac 友好：充分利用 Apple Silicon 的统一内存架构，在 Mac 上性能表现优异

K-Quants：混合精度的艺术

GGUF 的 K-Quants 技术是一种精细的块状量化方案——它的核心洞察是：并非所有权重都同等重要。

以常用的 Q 4 _K_M 为例：注意力机制中的关键权重使用 6-bit 保存，而前馈网络的权重使用 4-bit。这种"好钢用在刀刃上"的策略，使得 Q 4 _K_M 在体积与传统 Q 4_0 几乎相同的情况下，推理质量大幅提升。

2.3. AWQ 与 GPTQ：GPU 专属格式

AWQ（Activation-aware Weight Quantization）—— 激活感知量化

AWQ 是目前 vLLM 等服务端推理引擎的首选格式。它的核心洞察非常精妙：在模型的数十亿个参数中，约有 1% 的权重会产生非常大的激活值，这些被称为"显著权重（Salient Weights）"。

AWQ 的策略是：通过缩放因子保护这 1% 关键权重的精度，只压缩剩下的 99%。这就像是一个公司裁员时，核心骨干（1%）不动，只精简非核心岗位（99%）——公司的核心战斗力几乎不受影响。

• 优点：在同等压缩率下效果更好，指令遵循和代码生成能力保持较好
• 适用场景：需要高并发吞吐的 API 服务部署（配合 vLLM）、追求极致推理速度的纯 GPU 环境

四：量化实战工具链——llama.cpp、Unsloth 与 KTransformers

llama.cpp（GGUF 生态的核心引擎）、Unsloth（高效微调与量化导出）和 Ktransformers（MoE 模型的 CPU+GPU 混合推理）。

1. llama.cpp：GGUF 生态的核心引擎

你可能会好奇：这些 GGUF 文件到底是谁"制造"的？当你用 ollama run qwen3:8b 一键跑模型时，底层到底发生了什么？

答案就是 llama.cpp。它是整个 GGUF 生态的基石——GGUF 格式由它定义，GGUF 量化由它执行，GGUF 推理由它驱动。你每天在用的 ollama，底层就是 llama.cpp。

1.1. llama.cpp 是什么

llama.cpp 是一个基于 C/C++ 构建的高性能大模型推理引擎，由 Georgi Gerganov 于 2023 年创建。

llama.cpp 核心工具说明

💡 什么时候需要直接用 llama.cpp 而不是 ollama？ 当你需要：自己量化模型（ollama 只能用现成的）、精细控制 KV Cache 量化参数、搭建高并发 API 服务、或者在没有 Python 环境的嵌入式设备上运行模型时，就需要直接使用 llama.cpp。

1.2. 模型转换流水线：从 HuggingFace 到 GGUF

llama.cpp 核心应用场景

# 获取源码（AutoDL中最好在autodl-tmp路径下执行）
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# 创建并激活 conda 环境
conda create -n llama.cpp_env python=3.11 -y

# 激活环境
conda activate llama.cpp_env

# 安装转换脚本的 Python 依赖
pip install -r requirements.txt

如果你需要使用 GPU 加速推理，还需要编译 CUDA 版本：

# NVIDIA GPU (CUDA) 编译（-B build 会自动创建 build 目录）
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)

编译完成后，build/bin 目录下会生成 llama-cli、llama-server、llama-quantize 等二进制文件。

步骤二：将 HuggingFace 模型转换为 FP 16 GGUF

python convert_hf_to_gguf.py /root/autodl-tmp/models/Qwen3-0.6B \
  --outfile qwen3-0.6b-f16.gguf \
  --outtype f16

这个脚本会读取模型的 config.json、tokenizer.json 和所有 safetensors 权重文件，将它们打包成一个自包含的 GGUF 文件。--outtype f16 表示先保持 FP 16 精度，作为后续量化的"原料"。

💡 为什么不直接转成 Q 4 _K_M？ 虽然转换脚本也支持直接输出低精度，但推荐先转为 FP 16 GGUF 作为中间体，再用 llama-quantize 工具进行量化。这样可以从同一个 FP 16 源文件生成多种精度版本（Q 4 _K_M、Q 5 _K_M、IQ 4_ XS 等），而不需要每次都重新转换。

⚠️ 资源消耗提示：convert_hf_to_gguf.py 是纯 CPU 和内存（RAM）操作，不需要 GPU 显存。这意味着你可以在没有 GPU 的机器上（如 MacBook Air 或普通服务器）完成转换，然后再将 GGUF 文件上传到 GPU 机器上进行推理。但请注意，转换大模型（如 70 B）时需要较大的系统内存。

步骤三：量化为目标精度

# 量化为 Q4_K_M（常用的通用选择）
./llama-quantize qwen3-0.6b-f16.gguf qwen3-0.6b-q4_k_m.gguf Q4_K_M

执行后你会看到文件大小的显著变化：FP 16 版本约 16 GB，Q 4 _K_M 版本约 5 GB——体积缩小到原来的 1/3

步骤四：快速验证（CLI）

./llama-cli -m qwen3-0.6b-q4_k_m.gguf -p "你好" -n 20

1.3. llama-server：搭建本地 API 服务

搭建一个可以被程序调用的 API 服务。llama-server 是 llama.cpp 内置的生产级 HTTP 服务器，兼容 OpenAI API 协议，这意味着你可以用 openai Python 库直接调用，无需学习新的 API。

启动命令与关键参数

# 注意启动时命令中斜杠后不要有空格！
./llama-server \
  -m qwen3-8b-q4_k_m.gguf \    # 指定量化模型路径
  -c 8192 \                     # 上下文窗口大小
  -ngl 99 \                     # GPU 层数卸载（99 = 全部放 GPU）
  --host 0.0.0.0 \              # 监听所有 IP
  --port 8080 \                 # 端口
  -np 4 \                       # 并行槽位数
  -cb \                         # 开启连续批处理
  --cache-type-k q8_0 \         # KV Cache Key 量化
  --cache-type-v q8_0           # KV Cache Value 量化

./llama-server -m /root/autodl-tmp/models/qwen3-0.6b-q4_k_m.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080 -np 4 -cb
--cache-type-k q8_0 --cache-type-v q8_0

llama-server 核心参数说明

⚠️ 常见误区：-np 4 并不是"让模型变快 4 倍"，而是"同时服务 4 个用户"。每个用户的可用上下文长度 = -c / -np。如果 -c 8192 -np 4，则每个用户最多使用 2048 tokens 的上下文。

Python API 调用示例

from openai import OpenAI

# 指向本地 llama-server
client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="sk-no-key-required"  # 本地服务不需要真实 API Key
)

response = client.chat.completions.create(
    model="qwen3-8b",  # 模型名称可随意填写，llama-server 会忽略
    messages=[
        {"role": "system", "content": "你是一个有帮助的助手。"},
        {"role": "user", "content": "请用一句话解释什么是量化技术。"}
    ],
    stream=True
)

for chunk in response:
    print(chunk.choices[0].delta.content or "", end="")

1.4. 单模型服务架构与多模型部署

llama-server 是单模型服务——一个端口只服务于一个模型。这与 ollama（一个端口可通过 model 参数切换模型）或 vLLM（支持多模型路由）有本质区别。

┌─────────────────────────────────────────────────────┐
│                  llama-server                        │
│                                                      │
│   启动命令：                                          │
│   ./llama-server -m model_A.gguf --port 8080        │
│                                                      │
│   → IP:Port = 0.0.0.0:8080                          │
│   → 服务模型 = model_A.gguf（固定）                   │
│                                                      │
│   所有发到 8080 端口的请求，                           │
│   都会由 model_A 处理，无论 API 中 model 参数填什么    │
└─────────────────────────────────────────────────────┘

这意味着 API 请求中的 model 参数只是一个标识符，不影响实际使用的模型——端口决定模型，model 参数可以填任意字符串。你可以通过 curl http://localhost:8080/v1/models 查看当前端口绑定的模型名称。

如果你需要同时运行多个模型，解决方案是启动多个 llama-server 实例，分配不同端口

主流推理服务的模型绑定方式对比

2. Unsloth：高效微调与推理框架

Unsloth 是一个让大模型微调变得更快、更省显存的开源框架，由 Daniel Han 和 Michael Han 于 2023 年创建。它的核心理念很简单：用更少的资源，训练更好的模型。

微调大模型通常需要昂贵的多卡 GPU（如 8 张 A 100），但 Unsloth 通过内核优化，让你可以在单张消费级显卡（如 RTX 4090）上完成微调： 一键导出 GGUF：微调完成后，可直接导出为 GGUF 格式，用于 ollama / llama.cpp / KTransformers 部署

2.1. Unsloth vs KTransformers：定位对比

Unsloth 与 KTransformers 对比

2.2. 推荐工作流：从训练到部署

Unsloth 和 KTransformers 可以组成一条完整的工作流：用 Unsloth 高效微调模型，导出为 GGUF 格式，再用 KTransformers 部署到生产环境。

2.3. Unsloth 环境配置与安装

步骤一：CUDA 环境前置检查

# 1. 检查 NVIDIA 驱动
nvidia-smi

# 2. 检查 CUDA 工具包版本
nvcc --version

# 3. 检查 PyTorch 是否能识别 CUDA
python -c "import torch; print(torch.cuda.is_available()); print(torch.backends.cudnn.enabled)"

步骤二：创建环境并安装 Unsloth

# 创建 Python 3.11 环境
conda create --name unsloth_env python=3.11 -y
conda activate unsloth_env

# 安装 Unsloth（使用清华镜像加速）
pip install unsloth -i https://pypi.tuna.tsinghua.edu.cn/simple

# 1. 检查当前 PyTorch 版本（CUDA 支持状态）
python -c "import torch; print(f'torch: {torch.__version__}, CUDA: {torch.cuda.is_available()}')"

# 如果输出 "CUDA: False"，说明是 CPU 版，需要替换
# 2. 卸载 CPU 版 PyTorch
pip uninstall torch torchvision torchaudio -y

# 3. 安装 GPU 版 PyTorch（CUDA 12.1）
pip install torch==2.4.1 torchvision==0.19.1 torchaudio==2.4.1 --index-url https://download.pytorch.org/whl/cu121

# 4. 验证安装成功（应输出 "CUDA: True"）
python -c "import torch; print(f'torch: {torch.__version__}, CUDA: {torch.cuda.is_available()}')"

步骤四：验证 Unsloth 安装

# 验证 Unsloth 可正常导入
python -c "from unsloth import FastLanguageModel; print('✓ Unsloth installed successfully')"

3. 实战：将微调模型导出为 GGUF

Unsloth 的一个核心功能是一键将微调后的模型导出为 GGUF 格式，这样就能用 ollama、llama.cpp、KTransformers 等工具进行本地部署。本节我们以 DeepSeek-R1-Distill-Qwen-1.5B 为例，演示完整的导出流程。

步骤一：下载示例模型（可选）

# 使用 modelscope 下载示例模型
pip install modelscope

modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \
    --local_dir /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-1.5B

# 验证下载完整性
ls /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-1.5B/*.safetensors

步骤二：准备 llama.cpp 转换工具

# 克隆 llama.cpp 仓库
cd /root/autodl-tmp
git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp

# 编译（使用全部 CPU 核心加速）
make -j$(nproc)

# 验证编译结果
ls llama-quantize
ls convert_hf_to_gguf.py

步骤三：设置 Unsloth 环境变量

# 设置环境变量（指向 llama.cpp 目录）
export LLAMA_CPP_DIR=/root/autodl-tmp/llama.cpp

# 验证环境变量
echo $LLAMA_CPP_DIR

# 检查关键文件是否存在
ls $LLAMA_CPP_DIR/llama-quantize
ls $LLAMA_CPP_DIR/convert_hf_to_gguf.py

# 检查 CUDA 环境
import torch
print(f"PyTorch version: {torch.__version__}")
print(f"CUDA available: {torch.cuda.is_available()}")
if torch.cuda.is_available():
    print(f"CUDA version: {torch.version.cuda}")
    print(f"GPU: {torch.cuda.get_device_name(0)}")
    
# 测试 unsloth 导入是否成功
from unsloth import FastLanguageModel
print("Unsloth imported successfully!")

步骤四：转换 HuggingFace 模型为 FP 16 GGUF

cd /root/autodl-tmp/llama.cpp

# 转换为 FP16 GGUF
python convert_hf_to_gguf.py \
    /root/autodl-tmp/models/DeepSeek-R1-Distill-Qwen-1.5B \
    --outfile /root/autodl-tmp/models/output/model-f16.gguf \
    --outtype f16

转换过程可能需要几分钟，取决于模型大小。完成后会在 /root/autodl-tmp/models/output/ 目录下生成 model-f16.gguf 文件。1.5 B 模型约需 2-3 分钟。

步骤五：量化为 Q 4 _K_M（推荐精度）

# 量化为 Q4_K_M
./llama-quantize \
    /root/autodl-tmp/models/output/model-f16.gguf \
    /root/autodl-tmp/models/output/model-q4_k_m.gguf \
    q4_k_m

步骤六：测试量化模型

./llama-cli \
    -m /root/autodl-tmp/models/output/model-q4_k_m.gguf \
    -p "你好，请介绍一下自己" \
    -n 50

3. KTransformers：MoE 模型的 CPU-GPU 异构推理

在前面的 llama.cpp 部分，我们学会了用 GGUF 格式进行 CPU/GPU 混合推理——当显存不够时，把一部分层卸载到 CPU。但这种方式有一个明显的局限：CPU 上的层是"被动兜底"，没有针对模型结构做任何优化，速度会大幅下降。

这就是 KTransformers 要解决的问题。它专门针对 MoE（Mixture of Experts）架构的模型进行了深度优化，是目前用消费级显卡运行超大 MoE 模型（如 DeepSeek-V 3/R 1 671 B）的最佳方案之一

3.1. KTransformers 是什么

KTransformers 是由 kvcache-ai 团队开发的大模型高效推理框架，核心特点是通过 CPU-GPU 异构计算 实现超大模型的低显存推理。与 llama.cpp 的"层级卸载"不同，KTransformers 的策略更加精细——它利用了 MoE 模型的独特结构：

• 热门专家层（高频访问的专家）：运行在 GPU 上，享受高速计算
• 冷门专家层（低频访问的专家）：运行在 CPU 上，利用大内存容量

这种"热冷分离"的策略效果惊人：用 24 GB 显存即可运行 671 B 参数的 DeepSeek-V 3/R 1——这在传统方案中需要数百 GB 显存的多卡集群才能实现。

KTransformers 支持模型一览

💡 选型建议：如果你需要部署的是 Dense 模型（如 Qwen 3-8 B、Llama-3-70 B），应优先使用 llama.cpp；KTransformers 的优势在于用消费级显卡（如单卡 RTX 4090）运行数百 B 参数的 MoE 模型。

3.2. 安装与验证

步骤一：创建独立环境

# 创建新环境
conda create -n ktransformers python=3.11 -y
conda activate ktransformers

步骤二：安装 kt-kernel

# CPU 版本（不推荐，除非没有 NVIDIA GPU）
pip install kt-kernel

# CPU + CUDA 支持版本（有可能会不成功）
pip install kt-kernel-cuda

步骤三：安装 SGLang（可选但推荐）

# 克隆 KTransformers 定制版 SGLang
git clone https://github.com/kvcache-ai/sglang.git
cd sglang

# 安装
pip install -e "python"

步骤四：验证安装

# CLI 验证
kt version

# Python 验证
python -c "
import kt_kernel

print(f'CPU variant: {kt_kernel.__cpu_variant__}')
print(f'Version: {kt_kernel.__version__}')

from kt_kernel import kt_kernel_ext
cpu_infer = kt_kernel_ext.CPUInfer(4)
has_cuda = hasattr(cpu_infer, 'submit_with_cuda_stream')
print(f'CUDA support: {has_cuda}')
print('✓ kt-kernel installed successfully!')
"

如果安装过程中遇到问题，可以运行 kt doctor 进行环境诊断，它会自动检查 Python 版本、CUDA 可用性、CPU 特性、kt-kernel 安装状态等。

KT CLI 命令速查表

3.3. 实战：部署 Qwen 3-30 B-A 3 B MoE 模型

Qwen3-30B-A3B 作为演示模型——它是一个 30 B 参数、128 个专家的 MoE 模型，激活参数仅 3 B，非常适合用 KTransformers 进行异构推理。

⚠️ 踩坑预警：KTransformers 的 GGUF 模式需要同时下载完整的 HF 模型（含 safetensors 权重）和 GGUF 量化权重。这与 llama.cpp 只需要一个 GGUF 文件不同，是初学者最容易踩的坑。

Qwen 3-30 B-A 3 B 部署资源需求

步骤一：下载完整的 HF 模型

# 安装 modelscope CLI
pip install modelscope

# 下载完整模型（约 60GB）
modelscope download --model Qwen/Qwen3-30B-A3B \
    --local_dir /root/autodl-tmp/models/Qwen3-30B-A3B

步骤二：下载 GGUF 量化权重

# 下载 Q4_K_M 量化版本
modelscope download --model Qwen/Qwen3-30B-A3B-GGUF \
    Qwen3-30B-A3B-Q4_K_M.gguf \
    --local_dir /root/autodl-tmp/models/Qwen3-30B-A3B-GGUF

步骤三：验证文件完整性

# 检查 HF 模型目录（应包含 .safetensors 文件）
ls -la /root/autodl-tmp/models/Qwen3-30B-A3B/

# 检查 GGUF 目录（应包含 .gguf 文件）
ls -la /root/autodl-tmp/models/Qwen3-30B-A3B-GGUF/

步骤四：启动 KTransformers 服务器

python -m sglang.launch_server \
  --host 0.0.0.0 \
  --port 30000 \
  --model /root/autodl-tmp/models/Qwen3-30B-A3B \
  --kt-weight-path /root/autodl-tmp/models/Qwen3-30B-A3B-GGUF \
  --kt-method LLAMAFILE \
  --kt-cpuinfer 8 \
  --kt-threadpool-count 1 \
  --kt-num-gpu-experts 16 \
  --trust-remote-code \
  --mem-fraction-static 0.85 \
  --chunked-prefill-size 4096 \
  --kt-max-deferred-experts-per-token 2

KTransformers 服务器核心参数说明

步骤五：测试对话

# 方法 A：使用 kt chat
kt chat

import openai

client = openai.OpenAI(
    base_url="http://localhost:30000/v1",
    api_key="sk-no-key-required"
)

response = client.chat.completions.create(
    model="Qwen3-30B-A3B",
    messages=[{"role": "user", "content": "你好，介绍一下自己"}]
)
print(response.choices[0].message.content)

五：本地推理终极方案——Ollama 与 vLLM

1. 认识 Ollama：本地大模型的 Docker

1.1. Ollama 是什么？

Ollama与Docker概念对应关系

1.2. 核心设计哲学

1.3. 底层技术：llama.cpp 与 GGUF 格式

Ollama 的高性能推理能力主要归功于其对 llama.cpp 的深度封装。llama.cpp 是一个基于 C++开发的轻量级推理库，最初旨在让 Llama 模型在 Apple Silicon 芯片上高效运行，随后迅速扩展到支持 x 86 CPU 和各类 GPU。

截至 2026 年，Ollama 全面采用 GGUF（GPT-Generated Unified Format）作为其核心模型文件格式。GGUF 是 GGML 格式的继任者，专为边缘计算和本地推理优化

2. Ollama vs vLLM：两种部署方案的定位差异

2.1. 核心定位对比

Ollama 与 vLLM 核心对比

关于性能基准数据的说明：
根据 2025 年多项基准测试，在高并发场景下 vLLM 吞吐量可达 Ollama 的 2-3 倍以上，但在低并发/单用户场景下差距较小。

2.2. 选择建议

简单原则：如果目的是个人研究、调试 Prompt 或运行非生产级应用，Ollama 是首选；若需对外提供高并发 API 服务，则应转向 vLLM。

3. 自定义模型（Modelfile）

除了直接使用 Ollama 官方仓库的模型，我们还可以通过 Modelfile 自定义模型配置，或导入自己下载的 GGUF 模型权重。

3.1. Modelfile 基础语法

Modelfile常用指令

3.2. 导入本地 GGUF 模型

步骤一：创建 Modelfile 文件

cat > Modelfile << 'EOF'
FROM /root/autodl-tmp/deepseek-llm-7b-chat.Q4_K_M.gguf
SYSTEM "You are a helpful AI assistant."
PARAMETER temperature 0.7
PARAMETER num_ctx 4096
EOF

步骤二：构建自定义模型

ollama create my-deepseek -f Modelfile

步骤三：运行自定义模型

ollama run my-deepseek

4. 为什么需要 vLLM：从算力瓶颈到显存瓶颈

4.1. 推理瓶颈的转变

当前主流的生产级模型如 GPT-5.2、Claude Sonnet 4.5、Gemini 3 Pro，以及国内的 Qwen 3.x、DeepSeek-V 3.2 等，普遍支持 128 K 甚至更长的上下文窗口。

在推理阶段，核心瓶颈已从单纯的算力限制（Compute Bound）逐渐转移至显存带宽与容量限制（Memory Bound）。传统推理引擎在处理长文本和高并发请求时，面临三大问题：

• 显存碎片化严重：预分配的显存空间无法被有效利用
• 吞吐量受限：无法同时处理足够多的并发请求
• 请求调度效率低下：长请求会阻塞短请求

4.2. KV Cache：推理加速的双刃剑

在 Transformer 架构的自回归解码过程中，Key-Value (KV) Cache 用于存储历史 token 的键值对，以避免重复计算。这是推理加速的关键技术，但也是显存瓶颈的根源。

在 vLLM 出现之前，主流推理系统（如 Hugging Face Transformers）采用连续内存分配策略。系统必须根据请求的最大可能长度（如 2048 或 4096 tokens）预先分配一块连续的显存空间。

这种机制导致了极其严重的显存浪费：

1. 内部碎片（Internal Fragmentation）：如果预分配了 2048 长度的显存，而实际生成的序列仅有 100 个 token，则剩余的 95%显存被"预留"而无法被其他请求使用
2. 外部碎片（External Fragmentation）：当不同请求长度不一时，显存中会留下大小不一的空洞，难以被新的长请求利用

研究数据显示，传统系统的显存有效利用率仅为 20%至 40%。

4.3. 安装 vLLM

步骤一：创建虚拟环境

# 新建虚拟环境
cd /root/autodl-tmp
conda create -n vllm-env python=3.12
conda activate vllm-env
pip install --upgrade pip

步骤二：安装 vLLM

# 安装 vllm,并将缓存路径设置到数据盘
pip install vllm --cache-dir /root/autodl-tmp/.pip_cache

# 处理PyTorch版本问题（如需要）：
pip install vllm --extra-index-url https://download.pytorch.org/whl/cu124

# 验证安装：检查vllm版本
python -c "import vllm; print(vllm.__version__)"

4.4. 模型下载与管理

4.4.1. 使用 huggingface-cli 配合镜像站

步骤一：安装 CLI 工具

pip install -U "huggingface_hub[cli]"

步骤二：设置镜像站

# 设置huggingface镜像
export HF_ENDPOINT=https://hf-mirror.com

步骤三：执行下载

# 下载模型
huggingface-cli download --resume-download Qwen/Qwen2.5-1.5B-Instruct --local-dir /root/autodl-tmp/models/Qwen2.5-1.5B-Instruct

参数说明：

• --resume-download：支持断点续传
• --local-dir：务必指向 /root/autodl-tmp/

4.4.2. 替代方案：ModelScope

pip install modelscope
python -c "from modelscope import snapshot_download; snapshot_download('Qwen/Qwen2.5-1.5B-Instruct', cache_dir='/root/autodl-tmp/models')"

4.5. API 服务部署

# 设置OMP_NUM_THREADS，作用是限制vllm使用多少个线程，避免vllm占用过多的CPU资源
export OMP_NUM_THREADS=1

python -m vllm.entrypoints.openai.api_server \
  --model /root/autodl-tmp/models/Qwen2.5-1.5B-Instruct \
  --served-model-name qwen2.5 \
  --tensor-parallel-size 1 \
  --host 0.0.0.0 \
  --port 8000 \
  --gpu-memory-utilization 0.85 \
  --max-model-len 16384 \
  --trust-remote-code

API 服务器关键参数说明

重要说明：

• --host 0.0.0.0：必须设置，否则只能容器内部访问
• --port 8000：AutoDL 预留了 8000 和 6008 端口

外部访问：

ssh -CNgv -L 8000:127.0.0.1:8000 root@<AutoDL服务器地址> -p <SSH端口>

此时，在本地代码中直接访问 http://localhost:8000/v1 即可调用远程服务。

如需长时间稳定转发，可使用 autossh 自动重连：

autossh -M 0 -o ServerAliveInterval=60 -o ServerAliveCountMax=3 \
    -CNg -L 8000:127.0.0.1:8000 root@<AutoDL服务器地址> -p <SSH端口>