最近在根据实际业务做LLM的微调、部署、推理；过程中遇到很多的问题，在此记录下，这些问题有些解决了有些还在探索。

微调

我们的业务偏向于心理咨询问询对的场景，所以整个问询对就会很长，转换成ShareGPT格式的JSON数据后，一度达到了几十上百K，如下：

❝

其实这里是4个conversations，其实是将一次咨询按主题拆分了四块，然后合在了一起；严格来说也可以不拆出来，直接就是一个conversations，而不打散主题。但对于LLaMA-Factory微调来说，不允许微调文件只有一个conversation数据，因此才拆分了数据。

但由于数据文件过大，就会导致无法训练，直接OOM，后来换成jsonl格式的数据，还是不行，但数据大小的确是少了；如下：最后还是不能训练，最后换成了ms-swift框架微调训练。

但这是一次咨询的训练，基于这次咨询微调后的checkpoint，还需要继续训练，但显存不够了，最后OOM。

并行训练

并行训练一般是三类：数据并行、模型并行、混合并行。正常来说，显卡限制的情况下，是可以通过如上三种并行解决的。但现在的模型并行都不是标准的实现（我目前遇到的LLaMA-Factory、ms-swift等微调框架）。当然还有就是DeepSpeed等高效训练算法。

❝

但对于现在的微调框架很多并不是标准的并行算法实现。因此需要去尝试。

微调数据大小

前段时间longwriter-glm4-9b出来了，我想着微调训练下，尤其是多轮对话，咨询了下官方，给出的回答如下：因此，微调时数据的长度是很需要注意，也是需要做数据并行切分的。尽管可以通过max_length、采样策略（top_p，top_k，贪婪搜索，集束搜索）等约束，但效果还是会很受影响，主要还是在合适的微调数据长度上。

而对于这种情况下，如果微调数据不能拆分的情况下，最好的解决方案就是数据并行，即拆分数据到每个显卡上单独训练。同样，我们还是要注意单卡下，全量加载了模型参数后，再去微调的话，数据长度的限制，如下是我在LLaMA-Factory下的一个issue^[1]：

小结

微调这里，虽然有一些超参数是需要调整设置的；但我个人觉得，微调数据的长度大小，需要好好审视；而对于并行策略的应用，结合场景适用。

部署推理

对于部署来说，一般结合推理来看。在这里有如下的几个问题。

并发调用

模型部署起来后，由于一般都是基于开源模型，那么有一个问题，开源模型一般都不会处理——多用户的并行调用；尽管基于LLaMA-Factory、ms-swift等微调框架可以支持，但我们也要留意到这个问题。一般来说分为如下的情况：

1. 多用户并发调用
2. 单用户批次并行调用（即batch inference）

上下文长度

推理时，会有一个历史对话长度的问题——达到多长的对话，模型的能力将会退化；以vllm部署推理为例，一般有一个参数max_model_len控制，如下的报错也是很常见的：

❝

ValueError: The model's max seq len (19008) is larger than the maximum number of tokens that can be stored in KV cache (3840). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

受限于显存与kv cache的大小，因此就会限制推理时的历史对话长度；那么在长对话的场景下，如何解决这个问题？除了堆显存或是换一个更高效的分布式推理部署框架（算法）外，暂时没想到。而哪个分布式推理部署框架（算法）比较合适，能解决这个问题，暂时也没找到。

小结

合理的推理部署框架能解决并发调用、上下文长度的问题；这不是仅仅原生基座模型的上下文长度，而是在原生基座模型上一层的中间件限制。因此，挑选合适的算法/框架会更好的解决这些问题。