构建边缘AI小语言模型

大型语言模型（LLM）在任何场合、任何设备上都可访问。

但拥有数千亿参数的LLM对于低延迟应用来说过于昂贵，而普通的SLM在保真度和一致性响应方面往往表现不佳。

为应对这一挑战，我将调优一个紧凑的Llama 3.2–3B模型，使其模仿更大型LLM的对话能力。

这涉及一个三阶段流水线——SFT、RKD和DPO——以有效地将独特的个性嵌入到模型的较小权重中。

1、我们将构建什么

我们将构建我们的数字克隆，在回答问题时模仿我们的个性。

下图展示了系统架构：

微调后的模型通过AWS LMI部署，Lambda函数作为下游服务的安全代理，或作为GGUF文件分发到边缘设备（如智能手机）。

2、架构：云边混合部署

我将采用跨云和边缘环境的混合部署策略。

该方法分为两个阶段：

• 云部署： 通过简单的API在任何设备（Web、移动、平板）上快速测试个性。
• 边缘部署： 定位为高级层，允许用户下载模型以进行100%数据隐私的离线交互。

利用Llama 3.2–3B模型可实现计算能力和紧凑占用空间之间的最佳平衡。

2.1 云端与边缘部署的比较

下表比较了云端和边缘部署的策略：

云部署可以托管大型模型，不受硬件限制，但需要稳定的互联网连接才能访问。

边缘部署无需互联网连接；但模型必须大幅压缩以适应智能手机RAM限制，且实时推理可能导致电池快速耗尽。

2.2 云部署策略——选择合适的选项

云部署技术栈根据服务模型和基础设施分为四个主要类别：

无服务器层是零维护层，SageMaker代表用户管理实例，类似于Lambda。但由于仅支持CPU且有严格的6GB RAM限制，模型必须小（< 3B参数）。冷启动时间为10-20秒。

爱好者层通过在小型ml.t3.medium或ml.m5.large实例上运行llama.cpp来避免冷启动。推理速度比GPU慢，但对于1B模型，仍可达到15+ token/秒。

本项目应用企业层以确保模型智能实时响应。

开发者笔记：

在异步推理中，当设置最小推理为零时，SageMaker会在无人访问推理时关闭GPU实例。

这会导致首条消息1+分钟的冷启动，但在流量稀疏时每月可节省数百美元。

2.3 量化

在SageMaker GPU（如T4或A10G）上，3B模型非常小，量化模型实际上适得其反。

保持BF16格式可确保模型保留DPO期间学到的所有细微差别，无任何压缩。

如果模型超过8B，vLLM与AWQ（4位）或FP8（8位浮点）等格式兼容良好，这些格式旨在让GPU张量核心比GGUF格式更快地执行计算。

2.4 边缘部署策略

对于边缘部署，模型和量化选择在很大程度上取决于边缘设备：

对于Llama 3.2 3B，使用Q4_K_S量化后仅需约3.0GB RAM，为移动系统运行其他应用留出大量空间。

3、多步骤模型调优流水线

训练序列遵循**"学习、模仿、对齐"**流程：

数据源可以是任何能满足模型在各阶段学习目标的内容。

例如，在阶段1中，可以使用MBTI结果作为专业个性的真实依据。

在任何情况下，请确保在调优模型前屏蔽敏感信息。

阶段1. 学习：SFT和QLoRA用于事实基础

第一阶段是将我的专业背景转换到模型中，使其掌握事实真相。

从简历和LinkedIn帖子等参考文档中创建至少100个问答对后，我将格式化训练数据集以遵循Llama模型系列的聊天模板：

[
    {
        "instruction": "问题_1", 
        "context": "答案_1的上下文，相关项目等",
        "response": "答案_1"
    },
...
]

然后，我将使用SFTTrainer实例从trl库执行QLoRA（量化低秩适配）：

from trl.trainer.sft_trainer import SFTTrainer
from transformers import TrainingArguments

# 实例化sft trainer
trainer = SFTTrainer(
    model=model,
    train_dataset=train_dataset['train'], # HuggingFace的Dataset
    processing_class=tokenizer,
    peft_config=peft_config,
    formatting_func=formatting_func,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        ...
    ),
)

# 训练
trainer.train()

训练后的模型和tokenizer可访问：

trained_model = trainer.model
tokenizer = trainer.processing_class

开发者笔记：合成SFT——另一种RKD形式

与手动编写问答对不同，可以提示LLM从简历等参考文档生成问答对。这是响应知识蒸馏的另一种形式，使用LLM作为教师。

阶段2. 模仿：响应知识蒸馏（RKD）用于逻辑细微差别

接下来，我将执行响应知识蒸馏（RKD），使用最新的GPT模型GPT-5.4作为教师模型。

此过程将我响应背后的逻辑提炼到学生模型（3B）中，使其掌握响应背后的推理和语言细微差别。

我将首先提示教师生成训练数据集：

阅读参考文档，生成100个遵循思维链（CoT）结构的示例： 指令：与参考文档相关的任务或问题。 思考：基于给定参考，写出我采取的内部逻辑步骤（例如，'首先，我将检查API日志查看token是否过期…'）。 响应：基于给定参考写出我选择的最终答案。

训练数据集如下所示：

[
    {
        "instruction": "一般问题_1", 
        "thought": "思维链_1", 
        "response": "响应_1"
    },
    ...
]

开发者笔记：

将所有元素控制在150个token以内，因为小模型在训练示例简洁有力时表现更好，幻觉更少。

然后，与前一阶段类似，我将使用SFTTrainer实例训练3B模型：

from trl.trainer.sft_trainer import SFTTrainer

trainer = SFTTrainer(
    model=model,
    train_dataset=train_dataset['train'],
    processing_class=tokenizer,
    peft_config=peft_config,
    formatting_func=_formatting_func,
    args=training_args,
)

trainer.train()

阶段3. 对齐：DPO用于行为和语气对齐

最后阶段是执行DPO以对齐模型的语气和对话风格。

DPO需要带有选定答案和拒绝答案的提示：

[
    {
        "prompt": "问题_1", 
        "chosen": "答案_1（符合语气和风格）",
        "rejected": "被拒绝的答案_1（听起来像AI）"
    },
...
]

生成至少100个训练数据集后，我将使用trl库中的DPOTrainer实例执行DPO：

from unsloth import PatchDPOTrainer
from trl.trainer.dpo_trainer import DPOTrainer

# 应用补丁
PatchDPOTrainer()

# 初始化trainer
dpo_trainer = DPOTrainer(
    model=model,
    ref_model=None,
    args=training_args,
    train_dataset=train_dataset['train'],
    processing_class=tokenizer
)

# 训练
dpo_trainer.train()

保存调优后的模型产物

最后，我将保存模型产物：

# 用于云部署（bf16）
model.save_pretrained_merged(
    <OUTPUT_DIR>,
    tokenizer,
    save_method="merged_16bit", # 保持模型为16位
)

# 用于边缘部署（将产物保存为gguf文件）
model.save_pretrained_gguf(
    <OUTPUT_DIR>,
    tokenizer, 
    quantization_method="q4_k_s", # llama.cpp量化以压缩文件
)

4、部署

最后，模型部署到云端和边缘设备。

在这里，我将演示使用表2.1中描述的企业层进行云部署；使用SageMaker LMI内置的vLLM引擎部署调优后的模型。

设置专用IAM角色和信任策略后，我将在SageMaker上创建模型：

aws sagemaker create-model \
    --model-name "$MODEL_NAME" \
    --execution-role-arn "$ROLE_ARN" \
    --primary-container "{
        "Image": "$IMAGE_URI", # sagemaker内置的vllm容器uri
        "Environment": { 
            "HF_MODEL_ID": "$S3_PATH", \
            "OPTION_TRUST_REMOTE_CODE": "true", \ 
            "OPTION_ROLLING_BATCH": "vllm", \
            "OPTION_TASK": "text-generation", \
            "OPTION_DTYPE": "fp16", \
            "OPTION_MAX_MODEL_LEN": "512" \
        }
    }"

当脚本调用aws sagemaker create-model时，它将必要的配置传递给GPU实例。实例启动时，它会：

1) 从IMAGE_URI拉取内置容器镜像。

2) 检查环境变量并将其应用为serving.properties参数：

• option.rolling_batch=vllm表示使用内置的vLLM引擎。
• S3_PATH作为HF_MODEL_ID表示使用存储在S3_PATH中的远程模型（调优后的），而非原始HF模型（如unsloth/Llama-3.2-3B）。

3) 初始化内置vLLM引擎并将调优后的模型作为SageMaker上的新模型部署。

开发者笔记：SageMaker标准容器 vs. LMI容器标准SageMaker容器（Hugging Face、PyTorch等）需要将模型产物压缩为tarball（model.tar.gz文件），这会触发解压缩延迟：

接收请求。 → 实例启动。 → 下载tar文件。 → 解压tar到默认目录：/opt/ml/model/。 → 加载权重。 → 执行推理。

相反，SageMaker LMI容器不需要tarball；可以直接从HF_MODEL_ID变量中的S3前缀拉取原始权重，实现更好的推理延迟：

接收请求。 → 实例启动。 → 从S3流式传输权重。 → 加载权重。 → 执行推理。

创建模型后，我将配置专用端点：

# 创建端点配置
aws sagemaker create-endpoint-config \
    --endpoint-config-name "$CONFIG_NAME" \
    --production-variants "[{
        \"VariantName\": \"variant-1\",
        \"ModelName\": \"$MODEL_NAME\",
        \"InstanceType\": \"ml.g4dn.xlarge\",
        \"InitialInstanceCount\": 1
    }]"

# 创建专用端点并附加配置
aws sagemaker create-endpoint \
    --endpoint-name "$ENDPOINT_NAME" \
    --endpoint-config-name "$CONFIG_NAME"

4.1 为什么选择vLLM？PagedAttention和流式传输

vLLM原生内置于SageMaker异步推理和LMI中，因此无需显式加载独立的vLLM包。

即使是小型3B模型，使用vLLM也是战略性的，原因有三点：

• 大规模并发： 对所有用户无延迟。
• 成本： 更充分地利用VRAM。
• 人类感觉： 文字逐词出现。

4.2 大规模并发

标准推理引擎（HuggingFace）上的延迟随用户增加而顺序增长。当用户A提出长问题时，用户B必须等待模型完成用户A的整个响应后才开始处理。

vLLM使用持续批处理，系统在用户A的段落处理到一半时，就开始生成对用户B的响应。当应用有多个用户同时与克隆对话时，vLLM确保无人感到延迟。大规模并发几乎保持平稳。

4.3 成本

vLLM的PagedAttention通过动态管理KV缓存，在长对话中无OOM风险，从而更充分地利用经济实惠的硬件。

4.4 人类感觉

vLLM构建支持高速流式传输，提供OpenAI兼容API，对克隆应用至关重要，因为文字逐词出现是生命幻觉的关键。

原文链接: Engineer High-Fidelity SLM for Edge AI with Multi-Stage Tuning Pipeline

汇智网翻译整理，转载请标明出处