一线效率工具工具箱

FastAPI单线程跑transformers确实就这速度，换vLLM或TGI立马起飞，别折腾异步了。

你这个问题我太熟悉了，之前写ReAct循环也踩过一模一样的坑。八成不是模型本身泄漏，而是你的对话历史在无限膨胀，每轮把工具返回结果原封不动拼回去，context越拉越长，KV cache自然跟着涨。可以先用torch.cuda.memory_allocated()在每个阶段打点，看看是推理时涨还是拼历史时涨，一般能定位到。另外工具返回里如果带了一大坨JSON或者网页原文，一定要截断或摘要，不然几轮

2万条数据量其实不算大，而且alpaca格式对中文俚语这种口语化内容未必友好，试试把数据整理成纯对话流，别带太多指令模板，模型会更放松。另外rank16对语言风格迁移可能够用，但如果是想让模型记住网络梗的特定表达方式，rank加到32或者64说不定会有惊喜。学习率2e-4配3个epoch对LoRA来说有点激进，中文任务我一般先试1e-4跑1个epoch看loss曲线再决定。system promp

说实话你这个问题我上个月刚踩过一遍，13B上A100单卡跑vLLM，并发一高就炸太正常了，本质是KV cache在吃显存，不是模型权重占大头。我后来把max_num_seqs调小到32，同时把max_model_len限制到4096，瞬间就稳了，小流量下完全够用，你可以先试试这个，零成本见效最快。 GPTQ 4bit你用了但还爆，我怀疑是vLLM的量化内核没走对，得确认下是不是用的GPTQ_Ma

固定500字切确实太糙了，尤其是混合PDF和Word的时候，表格和页眉页脚会直接把语义切碎，你召回的自然全是垃圾。我之前做类似项目也踩过这个坑，后来改成按文档结构走：先解析出标题层级，用markdown的#号去标记，然后以段落为最小单位，再把同一标题下的段落拼在一起，超过token上限就按句子边界切，重叠设成1-2句而不是固定字数，效果立竿见影。 另外你说的BM25混检，这个我强烈建议加，因为向