📚 课程目录第4章模型加载与推理

4. 模型加载与推理

在完成FastAPI服务框架的搭建后，核心的模型推理模块便成为整个服务的“发动机”。本章将聚焦于如何高效、稳健地使用HuggingFace Transformers库完成大模型的加载、分词器（Tokenizer）的初始化与处理，以及单次推理的完整流程。我们将从底层原理出发，剖析模型加载的内存与时间开销，并给出可落地的工程化代码范式，确保你构建的API服务既具备正确的推理逻辑，又能应对高并发场景下的性能挑战。

4.1 核心原理：从预训练权重到可服务化模型

HuggingFace Transformers库将复杂的模型架构、权重管理、前向传播逻辑封装为统一的Python接口。其核心抽象是AutoModel与AutoTokenizer。当我们调用AutoModel.from_pretrained()时，库内部会执行以下关键步骤：首先，从本地缓存或HuggingFace Hub下载模型的配置文件（config.json）与权重文件（pytorch_model.bin或model.safetensors）；其次，根据配置文件动态构建模型实例；最后，将权重加载到指定的计算设备（CPU/GPU）上。这一过程涉及大量的磁盘I/O与内存分配，对于7B参数级别的大模型，加载时间可能长达数十秒，且需要数倍于模型大小的CPU内存（用于权重反序列化）和GPU显存（用于驻留权重）。

在服务化部署场景中，模型加载通常只执行一次，在FastAPI应用启动时完成。因此，我们必须在lifespan或全局变量中管理模型的生命周期，避免每个请求都重复加载模型。同时，为了降低显存占用并提升推理速度，通常采用torch.float16半精度加载，并配合device_map="auto"实现多GPU自动分配或CPU offload。

关键原理：模型加载的本质是“权重映射”过程。Transformers库通过model.state_dict()中的键值对与模型层的load_state_dict()方法完成参数绑定。理解这一点有助于我们排查“权重不匹配”错误，例如当本地模型与代码中的AutoModelForCausalLM类别不一致时，会抛出KeyError或size mismatch异常。

4.2 操作流程：模型与Tokenizer的初始化范式

下面给出一个标准的大模型加载与初始化代码模板，该模板适用于、LLaMA、ChatGLM等主流CausalLM架构模型。我们以meta-llama/Llama-2-7b-chat-hf为例，展示完整的初始化流程。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from typing import Tuple

MODEL_PATH = "/data/models/llama-2-7b-chat"  # 本地模型路径

def init_model_and_tokenizer() -> Tuple[AutoModelForCausalLM, AutoTokenizer]:
    """初始化模型与分词器，返回全局单例"""
    print("开始加载模型权重...")
    tokenizer = AutoTokenizer.from_pretrained(
        MODEL_PATH,
        trust_remote_code=True,  # 允许加载自定义代码（如ChatGLM）
        padding_side="left",     # 生成任务建议使用left padding
        use_fast=True            # 使用Rust加速版tokenizer
    )
    
    # 关键：设置pad_，避免生成时padding报错
    if tokenizer.pad_ is None:
        tokenizer.pad_ = tokenizer.eos_
    
    model = AutoModelForCausalLM.from_pretrained(
        MODEL_PATH,
        torch_dtype=torch.float16,          # 半精度加载，显存减半
        device_map="auto",                  # 自动分配到可用GPU
        trust_remote_code=True,
        low_cpu_mem_usage=True              # 减少CPU内存峰值
    )
    model.eval()  # 切换到推理模式，关闭dropout等训练层
    print(f"模型加载完成，设备分布: {model.hf_device_map}")
    return model, tokenizer

# 在FastAPI启动时调用
model, tokenizer = init_model_and_tokenizer()

在上述代码中，padding_side="left"是生成任务的关键设置。由于自回归模型在生成时需要将attention_mask中padding位置置为0，若采用右侧padding，会导致生成位置与padding混淆，产生错误输出。此外，low_cpu_mem_usage=True参数通过分片加载权重，显著降低了加载过程中的CPU内存峰值，对于7B模型可减少约20GB的临时内存占用。

4.3 单次推理流程：从文本输入到生成结果

单次推理流程可拆解为四个步骤：文本编码、张量转移、模型生成、结果解码。以下代码展示了完整的推理函数，该函数将被FastAPI的POST接口直接调用。

def generate_response(prompt: str, max_new_tokens: int = 512) -> str:
    """
    单次推理函数
    Args:
        prompt: 用户输入文本
        max_new_tokens: 最大生成新数
    Returns:
        生成的文本回复
    """
    # 1. 文本编码：将字符串转为input_ids
    inputs = tokenizer(
        prompt,
        return_tensors="pt",
        truncation=True,
        max_length=2048,          # 输入最大长度限制
        add_special_tokens=True
    )
    
    # 2. 将张量移动到模型所在设备
    device = next(model.parameters()).device
    input_ids = inputs["input_ids"].to(device)
    attention_mask = inputs["attention_mask"].to(device)
    
    # 3. 模型生成（核心推理）
    with torch.inference_mode():  # 比no_grad更严格，禁用梯度跟踪
        output_ids = model.generate(
            input_ids=input_ids,
            attention_mask=attention_mask,
            max_new_tokens=max_new_tokens,
            do_sample=True,          # 采样模式
            temperature=0.7,         # 温度参数，控制随机性
            top_p=0.9,               # 核采样
            top_k=50,                # 候选数
            repetition_penalty=1.1,  # 重复惩罚
            pad__id=tokenizer.pad__id,
            eos__id=tokenizer.eos__id
        )
    
    # 4. 解码：将生成的序列转为文本
    # 注意：只取新生成的，去掉输入的prompt部分
    new_tokens = output_ids[0][input_ids.shape[1]:]
    response = tokenizer.decode(
        new_tokens,
        skip_special_tokens=True,   # 跳过[PAD], [EOS]等特殊
        clean_up_tokenization_spaces=True
    )
    return response.strip()

在生成参数中，do_sample=True配合temperature、top_p等参数，使模型输出更具多样性。若需要确定性输出（如代码生成、数学计算），应设置do_sample=False并使用num_beams=1（贪心搜索）。torch.inference_mode()是PyTorch 2.0引入的上下文管理器，相比torch.no_grad()，它进一步禁用了自动混合精度缓存，可提升约10%的推理速度。

4.4 案例拆解：多轮对话场景下的推理优化

假设我们需要构建一个支持多轮对话的客服机器人API。初始现象是：当对话历史超过三轮后，响应延迟从800ms飙升到3秒，且显存占用持续增长。通过分析，我们发现每次请求都将全部历史对话重新编码并输入模型，导致输入数线性增长，计算量呈平方级上升。

关键输入数据：模型为7B参数，单次推理最大输入长度2048。三轮对话后，历史文本约1500 ，加上当前问题约300 ，总输入接近1800 。

分析判断：问题根源在于未利用past_key_values（KV Cache）。Transformers库的generate()方法内部虽然自动使用KV Cache，但前提是输入必须保持“连续对话”状态。我们错误地将历史对话拼接为独立句子，导致模型无法复用之前的键值对。

实际操作步骤：

修改对话管理策略：使用conversation_summary或sliding_window方法，仅保留最近两轮对话。
在推理时，将历史对话与当前问题按模板拼接，并确保input_ids是连续的序列。
启用use_cache=True（默认开启），并确保past_key_values在多次调用间传递。

结果对比：优化后，三轮对话的响应延迟稳定在1.2秒，显存占用不再随轮次增长。代价是需要额外维护对话状态的缓存对象，增加了代码复杂度。

风险提示：在多轮对话中，若直接拼接历史文本而不做长度控制，当输入超过模型最大长度（如4096）时，会触发IndexError或静默截断，导致上下文丢失。务必在编码前检查len(tokenizer.encode(history))，并设置合理的截断策略。

4.5 常见误区与工程复盘

误区	后果	正确做法
每次请求都调用`from_pretrained`	磁盘I/O与内存分配导致延迟高达数十秒，服务不可用	在FastAPI启动时加载一次，使用全局变量持有模型引用
忽略`padding_side`设置	生成结果出现乱码或位置偏移	生成任务统一使用`padding_side="left"`
使用`torch.no_grad()`而非`inference_mode()`	推理速度略慢，且无法利用某些算子融合优化	优先使用`torch.inference_mode()`
未设置`pad_`	批量推理时`generate()`抛出`ValueError`	若tokenizer无pad_，手动设为`eos_`
解码时包含输入prompt部分	返回结果包含用户输入，造成信息冗余	使用`output_ids[0][input_ids.shape[1]:]`截取新

总结复盘：模型加载与推理是FastAPI服务中最核心的性能瓶颈点。通过本章的学习，我们掌握了以下关键工程要点：第一，模型必须作为单例在应用启动时加载，并利用device_map与torch_dtype优化资源占用；第二，Tokenizer的配置直接影响生成质量，padding_side与pad_是高频踩坑点；第三，推理阶段应使用inference_mode上下文管理器，并合理设置生成参数以平衡质量与速度。在实际部署中，建议进一步结合vLLM或TensorRT-LLM等推理加速框架，可将吞吐量提升3-5倍，但本章所讲的Transformers原生流程是理解一切优化方案的基础。