每天进步一点产品成长记

5万条跑10小时确实偏慢，试试降max length到1024，长尾样本很拖速度。QLoRA会快但也就快一点，瓶颈可能不在精度上。

CoT对数学题确实不太稳，我试过加示例反而带偏节奏。温度调低点会好一些，但也不是万能药。

你这个场景其实挺典型的，合同条款和技术手册这类文档有个特点，就是关键信息往往藏在一句话或者一个表格行里，chunk切大了噪声多，切小了语义又不完整，所以光调chunk_size很难稳定。我建议你先别急着换embedding模型，bge-small本身对中文语义的捕捉不算差，问题大概率出在切分把上下文割裂了，比如金额和它前面的违约责任条件被切到了两个chunk里，那检索出来自然对不上。你可以试试按语

512配bge-large其实一张3090跑得动，重排序先别上，把chunk切在条款边界更实在。

我之前也卡在这，后来用缓冲区加序号校验才勉强搞定，丢包确实头疼。

8-10 token/s确实不正常，4090跑4bit的8B模型不该这么慢。你先看看ollama ps里GPU占用率是不是100%，有时候它会偷偷回落到CPU跑一部分层。另外Q4_K_M在4090上正常应该能到60以上，检查下是不是没装对CUDA驱动或者Ollama版本太老。vLLM对量化支持确实挑，可以试试AWQ格式的模型配vLLM，或者直接用llama.cpp手动编译开CUDA，比Ollama

两卡张量并行最稳，量化掉点又降速不划算，A10加卡比折腾offload省心多了。

两个few-shot确实有点少，格式类的任务建议多加几个边界case，光靠提示词压不住4o的随机性。

13B单卡80G并发上来还OOM，瓶颈大概率在KV cache而不是权重，先试试调小max_num_seqs和gpu_memory_utilization，把block_size设成16也能省不少。Flash Attention值得开，vLLM基本自带，多卡张量并行落地其实就加个tensor_parallel_size参数，别想太复杂。真要顶小流量，先把max_model_len压到实际需要的长度

短期记忆和长期记忆最好分开存，别挤一个collection。我最近试了按时间衰减加权检索，短期那层用最近N轮做缓存，效果好很多。

你这情况八成不是embedding选错了，bge-large-zh在中文场景够用了。问题可能出在会议纪要和技术手册混在一起，语义空间被拉偏了，报销流程那种噪音文档特别容易干扰检索。先别急着换模型，试试按文档类型分库检索，或者给不同来源加个元数据过滤，效果可能立竿见影。混合检索确实能救一部分，BM25对“宕机”这种关键词的召回比纯向量稳，但根子上还是得把语料管干净。

500条确实少了点，光靠正例模型很难学会区分相近参数，建议混一些参数填错的负例进去，让它学会“什么不该填”。另外你确认下训练时的tool schema和推理时完全一致吗？MCP那边字段顺序或嵌套结构变一点，模型就容易串。我之前也踩过类似的坑，加完负例再对齐格式后好了很多。

8张A10跑7B还要求50并发，不如试试TP=2加FP8，比GPTQ稳，显存也省不少。

我之前也踩过这个坑，后来发现光靠 system prompt 硬压确实不太行，模型在长上下文里对开头那段的注意力会衰减，尤其是中间插了几轮无关问答之后。我现在的做法是把核心角色和约束写成一段很短的“锚点”，每轮拼在 user message 的最后，而不是开头，实测比放前面稳一点。另外一个挺管用的技巧是让模型每轮先复述一遍当前角色和任务状态，再回答新问题，相当于强制它做一次自我对齐。不过这样会多花

我也遇到过，感觉不是长上下文有bug，而是细节给太多时模型容易“过度设计”，把每个约束都当成必须用代码结构去体现。后来我改成只写清楚数据结构和关键交互，剩下的让它自己决定，反而干净很多。你可以试试把JSON单独放一个文件让它读，别全塞prompt里，效果会好不少。

temp 0.1还飘其实挺常见的，因为采样只是随机性来源之一，vLLM 的 batch 调度、continuous batching 会导致同一个请求在不同 batch 里前缀计算略有差异，浮点误差累积下来就分叉了，长回答尤其明显。想要真正可复现，可以试试 seed 固定加 temperature=0，但注意 vLLM 里 seed 只在同一次启动、同一并发条件下才比较靠谱。top_p 和 rep

这个坑我踩过，显存缓慢增长十有八九是KV cache没释放干净。你这种朴素循环最容易忽略的一点是，每一轮把工具结果拼回对话历史后，如果直接拿完整history重新过一遍模型，之前那些中间张量其实还挂在计算图上，尤其是你没用torch.no_grad()包住推理部分的话，梯度图会一直累积。我当时的做法是把推理严格放进no_grad里，然后每轮只保留必要的文本history，别把past_key_va

加载就吃25G挺正常的，FP16的7B光权重就14G了，加上KV cache和中间激活，推理时OOM不奇怪。你LoRA微调完有没有把adapter merge回去？如果没merge直接挂adapter跑，显存占用反而更高。建议试试vLLM或者llama.cpp这类推理框架，PagedAttention对KV cache管理好很多，batch size和max length也能动态调。另外int8量

2e-4 的 lr 对 LoRA 来说确实偏高了，尤其 rank16 参数量不小，很容易把原模型带偏。5000 条数据不算太少，但纯领域数据微调，灾难性遗忘基本跑不掉。可以试试把 lr 降到 5e-5 到 1e-4，再混 10%-20% 的通用指令数据一起训，通常能明显缓解退化。rank 我倒觉得不是主因，16 算常规，先别急着降，把 lr 和数据配比调好更关键。

Go的语料确实弱不少，我这边也经常被塞不存在的包路径，试试把go.mod和常用包都@进去喂给它？