背景
github issue：关于多轮对话的loss计算[1]。
该issue是之前我提给Llama-Factory的，主要是想了解下该框架微调时的Loss计算逻辑，其实就是mask的排列。一般使用Llama-Factory直接微调就完了，不需要也不会在意其内在的逻辑；但我是因为使用了Llama-Factory微调训练后，效果很差，才去了解其逻辑。我个人觉得，除却微调数据集的格式与质量外，还有两个需要关注的因素：上下文长度与Loss计算。
上下文长度
模型的输入支持的序列长度是做微调时需要了解并注意的，很多人在准备数据集后，往往会忽略数据集的大小与模型上下文长度的限制，因此导致微调训练效果不理想。
以最近开源的GLM-4-9B-Chat-1M为例，该模型支持1M的上下文输入，在目前来说算是最长的上下文序列了。
单卡下的相关测评：
GLM-4-9B-Chat-1M
| 精度 | 显存占用 | Prefilling | Decode Speed | Remarks |
|---|---|---|---|---|
| BF16 | 75 GB | 98.4s | 2.3 tokens/s | 输入长度为 200000 |
虽说模型是支持1M上下文的输入，但是从机器配置与模型性能角度来考虑，建议是200K的上下文最好；需要超过200K的上下文，则需要考虑多卡部署推理，如基于vLLM等框架。
多卡部署的情况，以基于vLLM框架为例，关键的参数如下：
fromtransformersimportAutoTokenizer
fromvllmimportLLM,SamplingParams
#GLM-4-9B-Chat-1M
#max_model_len,tp_size=1048576,4
#如果遇见OOM现象，建议减少max_model_len，或者增加tp_size
max_model_len,tp_size=131072,1
model_name="THUDM/glm-4-9b-chat"
prompt=[{"role":"user","content":"你好"}]
即在4个并行的多卡下推理，支持的最长上下文是1M。
对于max_model_len参数的单位，即最长上下文参数的单位，一般是B。1 M = 1024 KB = 1024 * 1024 B；所以这里的参数值是 1048576。
更详细的内容，可参考GLM4官方文档：readme[2]；basic_demo[3]。
Loss计算
Llama-Factory微调框架的loss计算代码路径：code[4]。
微调数据集展开后的格式为对话对，即 Q1 +A1 + Q2 +A2 + .... Q表示用户的输入内容；A表示AI的回复响应。
模型会将文本id化，即编码输入与输出。
在Loss计算的代码中，labels列表构建方式如下：
labels+=[IGNORE_INDEX]*len(source_ids)+target_ids+[tokenizer.eos_token_id]
这里的labels列表对于每一轮对话（即每对Q和A），都会添加对应的target_ids（即A的编码）和eos标记。因此，对于每一轮对话的A部分，都会计算损失。
具体来说，代码的执行逻辑如下：
对于每个对话对（Q和A）：
source_ids 对应 Q 的编码。 target_ids 对应 A 的编码。 labels 列表中添加 [IGNORE_INDEX] * len(source_ids)，表示在 Q 部分的损失被忽略。 labels 列表中添加 target_ids 和 tokenizer.eos_token_id，表示在 A 部分计算损失。 拼接后的示例： Q1 + A1 + Q2 + A2 IGNORE_INDEX * len(Q1) + A1 + IGNORE_INDEX * len(Q2) + A2
这意味着每一轮对话的 A 部分（即 A1 和 A2）都会计算损失，而不仅仅是最后一轮对话的 A 部分。
其结构图可理解为：