百川Baichuan2部署与微调实战：从选型到LoRA/QLoRA完整指南

说实话，从7B聊到Baichuan2，这套模型的取舍和部署坑，很多人卡在第一步就不太想动了。开源大模型的玩法不像调SD那样解压缩就能跑，它涉及显存规划、权重格式、对话模板、微调数据的组织方式，每一项踩进去都有讲究。这篇文章我会把百川系列从选型、部署到微调的完整链路拆开讲清楚，用的都是我自己和团队在单卡、多卡环境里跑过的方案，配置和代码可以直接抄。

1. 百川系列全景：版本脉络与选型思路

1.1 从Baichuan-7B到Baichuan2-13B，中间发生了什么

百川大模型是开源社区里少有把中文词表和中文对话能力做到非常成熟的位置。第一代Baichuan-7B发布的时候，最大亮点是词表做到了64000个token，这意味着同样一段中文，它切出来的token数量比很多英文为主的模型少将近一半，推理速度天然有优势。我当时拿它做过一批代码注释生成的任务，最直观的感受是：同样的1000条数据，其他模型要占用更长的序列长度，而Baichuan能塞进更短的窗口，训练吞吐量马上就拉开了。

到了Baichuan-13B，模型规模变大，在逻辑推理和复杂指令理解上有了明显进步。这个版本分Base和Chat两种形态，Base适合做续写、Embedding、领域预训练，Chat则是对齐过的对话模型。再往后Baichuan2系列，7B和13B两个尺寸，重点改进了对齐质量，指令跟随能力、抵抗幻觉的能力都上了一个台阶。Baichuan2的对话模型在生成代码、整理结构化文本这类任务上表现扎实，不会被问几句就跑偏。

这套系列的演进思路很清晰：先解决中文友好的基础问题，再解决模型规模和指令对齐问题。我们团队从第一代就开始做测试，到Baichuan2基本把它作为中小型业务的底座候选。如果你要做一个To B的中文问答系统，或者垂直领域的私有化知识助手，7B到13B这个档位刚好在效果和成本之间取得了不错的平衡。

1.2 选型建议：Base、Chat、还是量化版

很多人问，部署的时候到底选哪个版本。我的建议是先看使用场景再选：

这里有个容易犯的错：不要拿Base版本直接做对话。Base模型只学会了文本概率分布，没有对齐人类偏好，你输入"你好"，它可能回一段登录页面的说明文字。如果有对话需求，老老实实下Chat版，或者拿Base自己微调成对话格式。选Int4量化版的时候也注意，社区里有些第三方的量化权重不知道用什么数据做的，容易导致效果劣化，优先用官方镜像仓库里的量化文件。

2. 部署环境准备：显存估算与依赖安装

2.1 一张图算清楚显存：7B、13B到底吃多少卡

部署大模型第一件事不是写代码，而是算显存。我提供一个快速估算公式：模型权重显存 ≈ 参数量 × 每个参数的字节数。比如7B参数，FP16精度下每个参数占2字节，那么权重本身就占14GB；如果加上推理时的KV Cache和激活值，建议最少预留20%的余量，所以7B FP16一般推荐24GB以上显存才舒服。

13B模型FP16权重就是26GB，推理时的峰值显存往往到35GB以上，单张4090勉强能推，但如果要并发调用或者长文本对话，就要考虑两张卡或者做量化。我实测的几种方案占用如下：

如果你想在一张消费级显卡上跑13B，老老实实做4bit量化，用bitsandbytes加载nf4格式，效果损失可控。另外，判断显存够不够的最笨但有效的方式是，用nvidia-smi盯着推理过程中的显存占用，如果接近爆掉就调小max_new_tokens，因为生成越长的文本，KV Cache累积越多，显存持续增长。

2.2 环境安装与模型权重下载

部署环境我推荐直接用Python 3.10，PyTorch选择CUDA 12.1对应的版本。核心依赖是transformers、accelerate、bitsandbytes、peft这四个库。简单记录一下我常用的安装命令：

bash复制pip install torch==2.1.2 --index-url https://download.pytorch.org/whl/cu121
pip install transformers==4.37.0 accelerate==0.27.2
pip install bitsandbytes==0.43.0 peft==0.10.0

这里要注意版本匹配。transformers版本过高或者过低，都可能触发百川模型里trust_remote_code的兼容问题，我自己在4.40版本上跑Baichuan2遇到过一个奇怪的attention mask报错，退回4.37就正常了。

模型权重下载，优先用HuggingFace官方仓库，命令是：

bash复制git lfs install
git clone https://huggingface.co/baichuan-inc/Baichuan2-7B-Chat

国内服务器下载慢的话，可以配置镜像环境变量：

bash复制export HF_ENDPOINT=https://hf-mirror.com

再执行同样的clone命令，速度会快很多。下载的时候注意磁盘空间，7B的模型文件大概15GB，13B大概26GB，别下到一半把系统盘塞满了。下载完成后检查一下文件完整性，用官方提供的md5sum比对，尤其是分片文件，我遇到过一次下载中断导致权重损坏，加载时直接报size mismatch，排查半天才发现是某个分片少了几个字节。

3. 推理部署实操：从加载权重到服务化接口

3.1 原生权重加载与对话测试

部署的第一件事是验证模型能不能正常对话。百川的Chat模型加载时必须要带trust_remote_code=True，因为它用了自定义的模型结构文件。基础加载代码是这样：

python复制from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_name = "baichuan-inc/Baichuan2-7B-Chat"
tokenizer = AutoTokenizer.from_pretrained(
    model_name,
    trust_remote_code=True,
    padding_side="right"
)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    trust_remote_code=True,
    torch_dtype=torch.float16,
    device_map="auto"
)

messages = [{"role": "user", "content": "请用三句话介绍分布式系统"}]
prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True
)
inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
outputs = model.generate(
    **inputs,
    max_new_tokens=512,
    repetition_penalty=1.05
)
response = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True)
print(response)

apply_chat_template会自动套上Baichuan2的对话格式，这一步非常关键。百川2的Chat模板用了一些特殊保留token来表示对话轮次，如果不用模板拼，模型经常把多轮历史对话当成一段普通文本续写，效果很怪。

生成参数也可以根据任务调整。对话类任务我推荐top_p=0.85，temperature=0.3到0.6，这样输出稳定且不那么机械。代码生成类任务我推荐把temperature降到0.2以下，甚至可以设为0，让输出尽量确定性，减少编造API的情况。

3.2 量化部署：单卡跑13B的实用配置

要在一张24G显卡上跑13B，我直接上bitsandbytes的4bit量化。加载时指定quantization_config即可：

python复制from transformers import BitsAndBytesConfig

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True
)

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    trust_remote_code=True,
    quantization_config=quant_config,
    device_map="auto"
)

这里有个容易踩的坑：bnb_4bit_compute_dtype建议设成float16，如果设成float32，推理速度会明显下降，而且显存占用变大。use_double_quant开启后能额外省一些显存，代价是加载时间变长，但对于服务端部署来说，加载一次能用很久，这个取舍值得。

量化实测下来，生成质量和FP16差距不大，只有在特别长的专业表述里偶尔出现词语不准的情况。如果对效果要求高，可以试试在量化之后继续用LoRA微调，把关键领域的能力补回来，这也是后面要讲的重点。

3.3 部署成HTTP服务：使用vLLM还是FastAPI

单机脚本调试完成后，作为一个能跑的服务，还需要一个稳定的HTTP接口。我个人在百川模型上优先推荐vLLM，它对连续批处理和PagedAttention的支持很成熟，高并发下吞吐量比原生transformers的generate高好几倍。

vLLM加载百川的配置示例：

python复制from vllm import LLM, SamplingParams

llm = LLM(
    model="/data/models/Baichuan2-13B-Chat",
    trust_remote_code=True,
    tensor_parallel_size=2,
    dtype="float16"
)
params = SamplingParams(
    temperature=0.3,
    top_p=0.85,
    max_tokens=512,
    repetition_penalty=1.05
)
outputs = llm.generate("什么是快速排序？", params)
print(outputs[0].outputs[0].text)

vLLM有两个注意点。第一，Baichuan2-13B-Chat的remote code里一些自定义op可能和vLLM不完全兼容，如果要上生产，建议先小规模压测一下，确认没有报op not supported的问题。第二，vLLM的tensor_parallel_size设为2，至少需要两张卡，如果一张卡跑，直接设为1，模型会自动做流水并行和分页调度。

如果只是为了内部测试或者集成到已有的FastAPI服务里，没必要上vLLM这么大的框架。简单的做法是封装一个generate接口，用transformers自带的TextIteratorStreamer实现流式输出。流式输出对用户体验影响很大，特别是长回答，用户如果盯着转圈5秒还没任何字，基本就流失了。

4. 微调全流程：从数据准备到LoRA/QLoRA实操

4.1 数据格式怎么组织，决定微调成败的一半

微调百川模型，数据格式是最关键的一环。Baichuan2的Chat模型微调，官方推荐使用类ChatML的多轮对话格式，每条数据是一个消息列表，包含system、user、assistant三种角色。我自己的经验是，如果只做单轮问答，格式可以简化成input和output两列，数据是这样组织：

json复制[
  {
    "instruction": "将下面的句子翻译成英文：",
    "input": "深度学习是一个很有意思的领域。",
    "output": "Deep learning is a very interesting field."
  },
  {
    "instruction": "",
    "input": "什么是注意力机制？",
    "output": "注意力机制是一种让模型在处理序列数据时动态聚焦于重要部分的技术。"
  }
]

用datasets库加载成Dataset后，在预处理函数里把每条数据按模板拼成文本。我自己常用的模板是：

python复制def format_example(example):
    if example.get("input"):
        prompt = "用户：{}\n{}\n助手：".format(
            example["instruction"], example["input"]
        )
    else:
        prompt = "用户：{}\n助手：".format(example["instruction"])
    full_text = prompt + example["output"] + tokenizer.eos_token
    return {"prompt": prompt, "full_text": full_text}

注意eos_token一定要加在输出文本后面。很多新手微调后模型生成不会停，一直吐到max_new_tokens上限，就是因为训练时没有让模型学会在合适的位置输出结束符。另外，数据里的instruction如果为空字符串，模板里要跳过input拼接，否则会出现"用户：\nxxx"这种空行，影响训练质量。

4.2 LoRA与QLoRA微调的基本代码框架

我实际用得最多的是QLoRA，也就是在4bit量化后的模型上做LoRA。这样即便只有一张24G显卡，也能微调7B甚至13B模型。代码框架和普通LoRA差别不大，重点在target_modules的选择上。

先看整体代码：

python复制import torch
from transformers import (
    AutoModelForCausalLM,
    AutoTokenizer,
    TrainingArguments,
    BitsAndBytesConfig
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from datasets import load_dataset

# 1. 加载4bit量化模型
quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True
)

model = AutoModelForCausalLM.from_pretrained(
    "baichuan-inc/Baichuan2-7B-Chat",
    trust_remote_code=True,
    quantization_config=quant_config,
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(
    "baichuan-inc/Baichuan2-7B-Chat",
    trust_remote_code=True,
    padding_side="right"
)
tokenizer.pad_token = tokenizer.eos_token

# 2. 准备kbit训练
model = prepare_model_for_kbit_training(model)

# 3. 配置LoRA
lora_config = LoraConfig(
    r=16,
    lora_alpha=32,
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
    target_modules=["W_pack"],
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()

target_modules这里要重点关注。Baichuan2的结构和LLaMA不完全一样，7B和13B的注意力层用的是名为W_pack的合并QKV投影层。如果不加W_pack，LoRA不会注入到注意力权重里，训练半天几乎没有效果。我第一次微调Baichuan-7B就踩过这个坑，只target了q_proj和v_proj，结果loss倒是降了，生成效果毫无变化。判断target_modules是否正确，可以在执行get_peft_model后打印model.print_trainable_parameters()，如果可训练参数有几百万甚至上千万，说明注入成功，如果只有几十万，多半没匹配到。

如果使用的是Baichuan2-13B，我实测它的注意力结构里是W_pack加Wo的组合，通常["W_pack", "Wo"]两个都加上。稳妥的办法是先把模型打印出来看一眼，print(model)找到 self.W_pack这类字段名，比在网上搜资料靠谱得多。

4.3 训练参数怎么设：找一组能直接上手的配置

训练参数和模型参数的组合比较多变，关键是看显存和数据量。我常用的7B QLoRA配置如下：

python复制training_args = TrainingArguments(
    output_dir="./baichuan2-lora",
    num_train_epochs=3,
    per_device_train_batch_size=8,
    gradient_accumulation_steps=8,
    learning_rate=2e-4,
    warmup_ratio=0.03,
    logging_steps=10,
    save_steps=500,
    eval_strategy="steps",
    eval_steps=500,
    save_total_limit=2,
    fp16=True,
    gradient_checkpointing=True,
    report_to="none",
)

这里解释几个关键参数的实际意义：

• per_device_train_batch_size=8配合gradient_accumulation_steps=8，等价于batch size 64。小显存下通过累积来模拟大批量，效果往往比直接小batch更好，模型收敛更稳。
• learning_rate=2e-4是LoRA微调比较通用的起点。如果是全量微调则要降到1e-5量级，但LoRA训练的参数量小，可以用偏高的学习率。
• gradient_checkpointing=True能显著降低显存，代价是训练变慢，7B模型开启后大概多花30%时间，但省出的显存可以支撑更大的batch，整体收敛速度反而快。

训练过程中我用transformers.Trainer默认的loss观察。一个直觉参考：3条任务指令的数据量下训练2000步，loss应该从2.0左右降到0.7以下，如果2000步后loss仍然在1.5以上波动，大概率是数据格式错了或者target_modules没有匹配成功。

4.4 微调后推理与LoRA合并

训练完成后的LoRA权重默认存在output_dir里。推理有两种方式，一种是直接加载PeftModel：

python复制from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained(
    "baichuan-inc/Baichuan2-7B-Chat",
    trust_remote_code=True,
    torch_dtype=torch.float16,
    device_map="auto"
)
model = PeftModel.from_pretrained(base_model, "./baichuan2-lora/checkpoint-1000")

这种方式适合实时切换多个LoRA权重，比较灵活。另一种是将LoRA合并回原模型，得到一个完整的模型文件，方便用vLLM做服务化部署：

python复制merged_model = model.merge_and_unload()
merged_model.save_pretrained("/data/models/Baichuan2-7B-Chat-finetuned")
tokenizer.save_pretrained("/data/models/Baichuan2-7B-Chat-finetuned")

合并之后建议重新加载一遍做一次冒烟测试，确认生成效果和训练时看到的一致再丢给服务。我遇到过合并后输出异常的情况，排查下来是模型和tokenizer的保存路径不一致，加载时没有用同一个trust_remote_code=True。合并后的目录里必须同时有config.json、tokenizer_config.json和.py模型定义文件，缺一个加载都会报错。

5. 常见问题与排查技巧实录

5.1 注意力模型加载时报size mismatch

这个问题出现频率极高。加载Baichuan的权重时，如果用了错误的vocab_size或者模型结构参数，会报size mismatch for word_embeddings。原因一般是两个：一是下载的权重文件不完整，二是模型名把Base和Chat版本搞错了。

排查方法是先检查权重目录里多个pytorch_model-*.bin文件的MD5是否一致，特别是pytorch_model-00001-of-00007.bin这类分片文件。我遇到过一次某个分片下载中断导致文件只有1KB大小，AutoModel加载时直接报错shape对不上。另一个快速验证方式是不要用device_map="auto"，改成device_map={"": 0}强制单卡加载，看报错信息是否更明确。

5.2 生成文本重复，语句死循环

百川模型如果生成参数不设置repetition_penalty，大段重复的概率会比一些英文模型高，因为中文语料里天然的重复模式更多。解决办法是设置repetition_penalty=1.1左右，同时把no_repeat_ngram_size=3加上，它能从n-gram层面避免完全相同的短语反复出现。

我实测的一个参数组合：repetition_penalty=1.05到1.15之间，太高了会让模型变得啰嗦，什么话都绕着说；设置在1.1附近，既抑制重复，又不破坏表达自然度。

5.3 开发阶段想调试LoRA注入是否生效

如果你在微调后发现loss一直在2.0以上徘徊，先不要调学习率，检查model.print_trainable_parameters()的输出。如果可训练参数占比少于模型总量的0.5%，说明LoRA没有真正作用到核心层。我自己调试的时候习惯打印模型结构里每一层的名字，专门找包含lora的模块：

python复制for name, module in model.named_modules():
    if "lora" in name.lower():
        print(name)

如果打印出来的lora层有很多集中在W_pack、wo这些名字下，说明注入位置正确。如果只有lm_head下的少量lora，那就是target_modules写错了。这个排查比看loss曲线直接得多。

5.4 微调数据里有隐藏标签导致模型学到错误格式

这部分是我认为最容易忽略的问题。很多公开数据集里，output字段自己带了助手：前缀，比如"output": "助手：分布式系统是一种……"，结果训练时相当于教模型在正确位置重复一次角色名。推理时模型可能正常，但多轮对话里容易出现"助手：助手：内容"这种双重前缀。

预处理时我做了一步保险：强制把output字段里开头出现的助手：或assistant:去掉，用正则re.sub(r"^(助手|assistant)\s*[:：]\s*", "", output)处理一下。数据质量这种东西，宁可多花十分钟清洗，也不要让模型学坏。

6. 部署与微调的个性化推荐：实测更稳的组合

最后分享一个我个人的组合偏好：服务端用Baichuan2-13B-Chat做底座，先按QLoRA微调行业数据，合并后用vLLM部署；如果只有单卡，就把底座换成7B的Int4量化版，同样微调，推理时用temperature=0.3，top_p=0.85。

我踩过最多的坑是盲目追求参数量。13B的微调时间、推理延迟、显存占用都比7B高一大截，但如果任务只是常见的行政问答、客服应答这类领域，7B微调后的效果已经可以满足90%的业务需求。真正需要13B的时候，往往是有复杂逻辑推理或多步骤指令，这时效果差异才明显。

另外，微调后模型的评估不要只看loss，一定要准备一个和业务场景非常接近的评测集，用人工或者规则脚本跑一遍，对比微调前后的输出。模型训练loss低，不代表对话符合预期。我手头一个项目，微调后loss从2.1降到了0.6，但实际跑业务数据时发现模型学会了训练集里的口头禅，每句话开头都要加一句"好的，我来回答这个问题"。这种情况只能用高质量的评估集暴露出来，然后针对性过滤训练数据里的噪声。

百川系列最大的优势在于中文生态和社区支持都比较成熟，遇到问题搜索一下基本都能找到参考方案。部署微调这件事，思路比参数重要，动手比纠结更快。按上面这套流程走，一次跑通7B微调、13B量化和服务化部署，问题都不大。