百川13b大模型怎么用？从零部署到微调的踩坑实录

2023年7月百川智能把 Baichuan-13B 丢到开源社区那天，我正在给一个政务问答项目选底座模型。当时的处境挺尴尬：调用闭源API吧，数据不能出内网，客户第一个就把这条路堵死了；用开源方案呢，LLaMA 系中文能力惨不忍睹，ChatGLM-6B 在长文本问答上又经常"断片"。百川13b大模型是我在那个时间点能找到的、少有的13B规模、中文能打、还允许商用的选项。这篇就聊聊我这两年在推理和微调上踩过的坑。

核心结论摘要（可直接摘录）： 百川13b大模型是指百川智能2023年7月开源的130亿参数中英双语大语言模型，含 Base 与 Chat 两个版本，1.4万亿 tokens 训练，INT4 量化后单张24GB显卡即可推理，配合 LLaMA-Factory 可低成本完成 LoRA 微调，是国产大模型入门的高性价比落点。

百川13b大模型是什么？13B规模里的一个特殊选择

先把定义说清楚：百川13b大模型是指百川智能于2023年7月发布的开源模型系列，包含基础模型 Baichuan-13B-Base 和对话对齐版本 Baichuan-13B-Chat，参数规模130亿，支持中英双语和4096 token 上下文。它是王小川创办百川智能后放出的第二个开源作品，前一个是7B版本。

说实话，当时13B这个档位是有点微妙的。往上够不着100B级别那种"通用智力"，往下又比7B多出一倍参数——好处是中文任务明显更稳，坏处是消费级显卡开始有点吃力。

官方放出的评测数据还是挺能说明问题的（来自 Baichuan 官方 GitHub 技术报告，2023年7月）：

| 模型 | 参数量 | 训练数据 | 上下文 | C-Eval(5-shot) | MMLU(5-shot) | |------|--------|----------|--------|----------------|--------------| | Baichuan-13B-Base | 13B | 1.4T tokens | 4096 | 52.4 | 51.6 | | Baichuan-7B | 7B | 1.2T tokens | 4096 | 42.8 | 42.3 | | LLaMA-13B | 13B | 1.0T tokens | 2048 | 28.5 | 47.3 |

看出来了吗？LLaMA-13B 在 MMLU（英文为主）上和百川咬得挺紧，但一到 C-Eval 这种中文评测就直接被拉开二十多分。这就是那个阶段国产大模型最核心的卖点——中文语料喂得够多，中文理解就是比同期英文开源模型强。

1.4万亿tokens 和 ALiBi：技术原理拆解

本节结论先行：百川13b大模型的技术核心不在架构创新，而在数据配比和位置编码选择上的工程取舍。

架构上它没什么秘密，就是标准的 Decoder-only Transformer，词表大小64000，这个规模介于 LLaMA 的32000和后来的128K之间，对中文分词相对友好。真正值得说的是两件事：

一是训练数据。1.4万亿 tokens，中英混合，中文占比明显高于 LLaMA 系列。这里面有个细节我认为挺关键——百川官方提到对中文数据做了较重的清洗和去重。做数据的人都知道，中文互联网的重复内容和垃圾文本比例高得吓人，不狠心清洗，模型学到的就是"复读机"。

二是位置编码用了 ALiBi。这点和7B版本不太一样，7B用的是 RoPE。ALiBi 的好处是训练时短、推理时长，理论上可以一定程度的长度外推。

不过话说回来，理论支持外推和实际效果是两码事。我在实际项目里测过，上下文一旦超过4096，百川13b大模型的回答质量下降很明显，尤其是需要精确引用前文的场景。所以我一般就老老实实卡在4096以内，需要更长就上切分方案。ALiBi 给了你向外的可能性，但别把这当成免费的长上下文能力。

百川13b大模型使用教程：三种跑通方式实测对比

先说结论：个人开发首选 vLLM 或 transformers + 4bit 量化，追求极致省显存走 llama.cpp，企业多并发放 vLLM 起服务最省心。

三种方式的差异我列了个表，这是我在同一台机器上实测下来的手感：

| 方式 | 显存需求(FP16) | 部署难度 | 并发能力 | 适用场景 | |------|----------------|----------|----------|----------| | transformers 直接加载 | 约26GB | 低 | 弱 | 单次调试 | | vLLM 服务化 | 约26GB起 | 中 | 强 | 生产并发 | | llama.cpp (GGUF) | 约8GB | 中 | 中 | 无卡/低配设备 |

最基础的 transformers 加载长这样：

from transformers import AutoModelForCausalLM, AutoTokenizer import torch

model_id = "baichuan-inc/Baichuan-13B-Chat"

trust_remote_code=True 是因为百川用了自定义建模代码，不加会直接报错

tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True, use_fast=False) model = AutoModelForCausalLM.from_pretrained( model_id, trust_remote_code=True, torch_dtype=torch.float16, # 半精度，显存直接砍一半 device_map="auto" # 多卡自动分配 ).eval()

注意：Chat 版本一定要走 chat 接口，直接 generate 不会套对话模板，回复会乱掉

response, history = model.chat(tokenizer, "用一句话解释什么是大模型推理", history=[]) print(response)

这里有个新手最容易翻车的点：忘了加 `trust_remote_code=True`。报错信息还挺含糊，我见过好几个人卡在这。

生产环境我更推荐 vLLM，一条命令起个 OpenAI 兼容的接口：

python -m vllm.entrypoints.openai.api_server \ --model baichuan-inc/Baichuan-13B-Chat \ --trust-remote-code \ --dtype float16 \ --gpu-memory-utilization 0.9 \ --port 8000

起完之后用 openai 的 sdk 直接能调，迁移成本几乎为零。关于大模型服务化部署的一些通用坑，我在大模型推理部署实战里也整理过，可以对照着看。

显存不够？量化是绕不开的一步

坦白讲，我第一在单张3090（24GB）上直接加载 FP16 版本，进程刚起来就 OOM 了，13B × 2字节 = 26GB，确实装不下。量化不是可选项，是必须项。

4bit 加载的写法：

from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig import torch

model_id = "baichuan-inc/Baichuan-13B-Chat" quant_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16, bnb_4bit_quant_type="nf4", # NF4 量化，精度损失比 FP4 更小 bnb_4bit_use_double_quant=True # 双重量化，再省一点点显存 ) tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True, use_fast=False) model = AutoModelForCausalLM.from_pretrained( model_id, trust_remote_code=True, quantization_config=quant_config, device_map="auto" )

不同量化档位的显存占用大概是这样：

| 量化方式 | 显存占用 | 最低显卡建议 | 精度损失感受 | |----------|----------|--------------|--------------| | FP16 | 约26GB | A100 40G / 双3090 | 无 | | INT8 | 约14GB | 3090 / 4090 | 几乎无感 | | INT4 (NF4) | 约8-9GB | 3060 12G | 略有，长文本更明显 | | GGUF Q4_K_M | 约8GB | 支持 llama.cpp 即可 | 同 INT4 接近 |

我的经验是：做知识问答和摘要这类任务，INT4 完全够用；但如果要做代码生成或者需要严格逻辑推理的场景，能上 INT8 就别省那点显存。

百川13b大模型入门指南：用 LoRA 微调你的领域数据

推理跑通只是开始，真正让模型"懂你的业务"还得靠微调。全量微调13B对个人开发者来说基本不现实，LoRA 是最务实的选择。

我用的是 LLaMA-Factory，它对百川的支持比较完整：

CUDA_VISIBLE_DEVICES=0 python src/train.py \ --stage sft \ --do_train \ --model_name_or_path baichuan-inc/Baichuan-13B-Base \ --dataset alpaca_gpt4_zh \ --template baichuan \ --finetuning_type lora \ --lora_target W_pack \ --output_dir ./output/baichuan13b-lora \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 1e-4 \ --num_train_epochs 3.0 \ --fp16

`--lora_target W_pack` 这个参数别写错，百川的注意力权重命名和 LLaMA 不一样，写成 `q_proj` 之类的是加不上的。这个坑我调了大半天才发现。

关于 LoRA 参数配置和数据集格式的更多细节，可以参考LoRA微调实战笔记那篇，讲得比官方的 README 细。

微调完合不合并权重也是个选择题：合并了推理快但占显存，不合并省空间但每次要挂适配器。我个人的做法是——实验阶段不合并，上线前合并成完整模型。

它适合做什么，又别指望它做什么

用了这么久，我对百川13b大模型的定位很清楚了。

适合的场景：

• 中文文本分类、情感分析、信息抽取
• 短文本摘要和问答（控制在4096以内）
• 企业内部知识库的问答底座
• 低成本私有化部署，数据不出内网

别指望它做的事：

• 复杂数学推理和代码生成（这个档位确实吃力）
• 超长文档理解（4096之后衰减明显）
• 多模态任务（这是纯文本模型，多模态大模型是另一条路线）

有意思的是，很多团队一上来就想用13B干所有事，结果发现还不如老老实实上 7B 做简单任务、把预算留给关键链路。参数不是越大越好，匹配场景才对。

总结与学习路径

如果你刚开始接触国产大模型，我的建议路径是：先用 4bit 量化在单卡上把百川13b大模型跑通，理解 chat 模板和推理流程；再上 vLLM 体验服务化；最后拿自己的业务数据做一次 LoRA 微调。三步走完，大模型训练、推理、部署的基本盘就有了。

关键要点速览：

1. 百川13b大模型是130亿参数、1.4万亿tokens训练的中英双语开源模型，中文能力显著优于同期LLaMA-13B。
2. 单张24GB显卡用INT4量化即可推理，FP16需26GB。
3. 生产部署推荐 vLLM，个人调试用 transformers + bitsandbytes。
4. LoRA 微调记得 `lora_target W_pack`，这是百川特有的坑。
5. 上下文卡在4096内，别过度迷信 ALiBi 的外推能力。

回头看，百川13b大模型不是最强的，但在2023年那个开源中文模型青黄不接的时间点，它确实给了很多团队一个能落地的答案。这种"够用且能商用"的定位，价值其实比刷榜第一更大。

相关推荐

• **阅读相关专题**：想系统对比国产大模型选型，可以看看我们整理的国产大模型专题合集。
• **查看工具推荐**：部署和微调用到的推理框架、量化工具，都收录在 [VergeX AI工具导航](https://nav.vergex.cn)。
• **订阅更新**：关注 VergeX，第一时间获取大模型部署与微调的实战更新（支持邮件与微信订阅）。