模型部署实践者

20 tokens/s 单看数字确实偏低，但得先确认你说的是单请求速度还是并发吞吐。如果只发一个请求、输出又比较长，7B 在 A100 上跑这个数也不算特别离谱，官方宣传的高吞吐很多是几十并发堆出来的。另外你这微调模型是不是用了 LoRA 没合并，或者 dtype 是 fp32？还有 docker 里确认下有没有真正挂到 GPU、是不是跑在 CPU 上了。

这情况挺常见的，LoRA微调确实容易把底座模型原本的上下文学习能力带偏，尤其是你训练数据全是QA对，模型可能只学会了直接答，不习惯从长文本里找答案。建议先做个对照实验：拿微调前的底座模型跑同样的检索+拼接，看它是不是能正常提取，这样就能确认是不是微调背的锅。如果确实是，比较稳的做法是重建微调数据，把检索文档拼进prompt里一起训，让模型重新学会“读文档再回答”这个模式。另外temperature

BLEU涨了不代表补全好用，代码任务更看精确匹配。试试调低rank或者加dropout，LoRA学太猛容易胡编API。

财报这种数字密集的文档，切块时最好带上表头或章节标题，不然embedding根本分不清是定义还是数据。

rank64确实偏高，风格惯性容易被放大，降到16试试。

几十万条用768维完全够了，量化到128会伤语义，不如先降维再压。

我们小集群用Milvus，资源一紧张就各种超时，Qdrant倒是稳但生态差点意思。

我这边也是Qwen2.5-7B本地跑，写结构化JSON基本放弃温度采样了，直接do_sample=false走贪婪解码，稳得一批。你说的漏字段和编参数，其实很多时候不是温度的问题，是prompt里schema描述得不够硬，模型没被“框”住。我一般会在system里把字段列表和类型写死，再给一两个完整示例，比调参管用多了。top_p我平时搭0.8左右，但只在需要一点多样性的时候才开，配合temper

我之前两种都试过，现在偏向把向量检索包成 tool，但会在 server 端做一层预处理。返回结果别直接丢原始 chunk，最好压成带标题和摘要的结构化片段，不然模型很容易被噪声带偏。提前塞 context 确实稳，但延迟和 token 浪费都挺明显，适合小库或者固定场景。

几十万数据量单机的话Qdrant确实够用，过滤查询也灵活，Milvus那套依赖装起来太折腾了。

我微调代码模型时也遇到过loss卡在1.7左右，后来发现是数据里重复片段太多，模型在背模板而不是学补全。你试试先拿几千条去重后的高质量样本跑一下，看loss能不能动起来。LoRA的rank 16其实够用了，问题大概率不在那，重点查一下数据清洗和验证集是不是同分布。另外学习率3e-4对7B模型偏高了，我一般用2e-4配cosine调度会稳一些。

这种顺序要求明确的场景别硬靠Agent自己规划，直接写个Chain把两个工具串起来更稳，ReAct真管不住调用次序。

训练模板影响真挺大的，我微调后不按格式问也翻车过。想适应多风格就在数据里混着来，别只喂一种。

几十万条其实 Chroma 够用了，检索不准大概率是 embedding 模型没选对，换个 bge 系列试试。

几千条数据训10个epoch确实容易过拟合，loss卡在2.3很可能是数据量不够加上重复训练导致的。你可以先拿几百条做个快速实验，看loss能不能降到1.5以下，如果不行大概率是数据格式或模板没对齐。LoRA微调中文LLaMA本身没问题，但对话数据最好套上对应的chat template，不然模型确实学不到啥。另外学习率1e-4对LoRA来说偏高了，试试2e-5或者3e-5，配合warmup会更稳

AgentExecutor确实不太扛并发，建议换成LangGraph自己搭调度，或者用AutoGen，轻量多了。

7B模型单轮就吃18G确实偏高，建议先查一下是不是KV cache没限制住，或者工具调用的prompt塞得太长，很多时候显存不是被权重吃掉的，而是被上下文撑爆的。我自己跑Agent的时候会把系统提示和工具描述压到最短，能省下不少。4bit量化其实对权重有效，但KV cache该占还是占，所以得配合max_model_len和gpu_memory_utilization一起调，vLLM里这两个参数卡

我之前也踩过类似的坑，微调让模型过滤噪声这个思路听起来合理，但实操起来很容易翻车。因为LLM在微调时学到的不只是“分辨噪声”，它很可能把“忽略文档”这个行为和某种格式或语气绑定在一起，导致该用正确文档的时候也犯懒。而且你训练数据里噪声文档的构造方式很关键，如果只是随机塞不相关段落，模型学到的边界会很模糊；更好的做法是构造那种“表面相关但实际答非所问”的hard negative，比如问报销流程却给

ResNet50在电商图这种细粒度场景确实有点吃力，尤其同款不同角度，纹理和局部特征容易丢。建议先换CLIP或者DINOv2这类embedding试试，1024维未必比512维的CLIP强。另外L2距离对归一化很敏感，确认下特征有没有做l2 norm，没归一化的话换cosine会稳不少。还有个容易忽略的点，topK设100但召回60%，可能候选里本来就没几个正样本，先单独验证下embedding本

多工具调用场景下KV Cache涨得特别快，因为每次工具返回的结果都会拼进上下文，第二轮直接翻倍，AWQ 4bit省的那点权重显存根本扛不住。你可以试试限制工具返回长度，或者把历史对话做摘要压缩再喂回去。显存碎片化的话，vLLM的PagedAttention或者开个`PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True`能缓解不少。另外确认下是不是每次调