云端写码录

lr 2e-4太高了，Llama3微调中文容易灾难性遗忘，降到1e-4试试，不行就换Qwen。

我遇到过一模一样的问题，后来发现是示例和检索文档在prompt里“抢戏”，模型分不清该抄谁。试试把示例放到检索内容之前，并且明确加一句“示例仅示意格式，答案必须来自下方文档”，我之前这么改完就基本不串了。另外结构化输出可以不用few-shot，直接上JSON schema或者让模型按固定字段填，反而更稳。

空input确实容易让模型犯迷糊，Alpaca模板里instruction和input拼一起时最好加个明确分隔符，不然模型分不清哪部分是问题哪部分是背景。loss从1.2涨到1.8大概率是数据格式或者label mask没设对，建议先拿几十条数据过一遍tokenizer看看实际输入长啥样。4bit量化对LoRA影响其实不大，我跑过类似的没出现loss反升，重点还是查eos有没有加、padding侧

MCP的分布式环境变量得手动对齐，torchrun默认那套它不一定认，先查下MASTER_ADDR和RANK有没有被平台覆盖。

十几个人用14B int8其实单卡A100够的，OOM多半是KV Cache没管住——max_model_len别设太大，历史上下文该截就截。我们之前也踩过坑，后来换成AWQ量化加prefix caching，RAG片段拼在system后面固定住，重复部分直接命中缓存，显存一下省了不少。两张卡张量并行当然更稳，但通信开销和部署复杂度也上来了，先试试调小gpu_memory_utilization加

这种情况太常见了，我去年做类似POC时也踩过一模一样的坑。你描述的那些现象——忽略检索数据、开始瞎猜、文档一长就幻觉——其实不是prompt姿势的问题，而是你把太多职责压给模型了。GPT-4的注意力在超长上下文里本来就是不均匀的，你塞3000字文档进去，它很可能只抓到了开头和结尾，中间的关键报表数据直接被稀释掉了。我的经验是prompt工程能解决的是“指令对齐”和“输出格式”这类问题，比如让模型按

单次Prompt确实很难把业务逻辑写周全，尤其是Excel这种细节多的场景。我一般会拆成两步：先让它给整体思路和伪代码，确认逻辑没跑偏再让它补全实现。另外把报错信息直接贴回去让它修，比一开始就追求完美Prompt靠谱多了。

工具调用这块我也踩过不少坑，加个重试和超时兜底能救回来大半。

这个坑我去年也踩过，当时用ReAct接了三四个工具，到第五步左右就开始原地打转，日志里工具名和参数反复生成但就是不触发调用。后来发现很大一部分问题是工具描述太长太模糊，模型在纠结该选哪个，尤其搜索和数据库查询功能有重叠时特别明显。建议把每个工具的description压到一两句话，参数schema尽量精简，别写小作文。另外中间结果确实要压缩，ReAct每步都把完整observation塞回prom

几百万数据、100ms延迟这个要求，Qdrant其实完全扛得住，单机跑HNSW就能压到10ms以内，部署也省心，一个docker就起来了。Milvus功能确实全，但etcd、minio、pulsar那一套组件堆起来，运维成本对小团队不太友好。HNSW的坑主要在ef和M参数，ef_search调低了召回掉得厉害，M给太大内存直接爆炸，建议先用默认值压测再微调。真要担心扩展，Qdrant现在也支持分片

我最近也踩过这个坑，后来换成小chunk检索、大chunk送模型的方式，就是先按256切做索引，命中后再把相邻的几个chunk拼回去当上下文，效果比直接调大chunk稳不少。父文档检索其实和这个思路差不多，LangChain里有现成的ParentDocumentRetriever，接起来不算麻烦。你们手册如果是章节结构清晰的，也可以试试按标题层级切，比纯token切完整性强很多。

先动切分吧，chunk太碎语义就散了，我换bge-m3加overlap后好很多。

几十万数据Qdrant够用了，过滤查询也顺手，等真到千万级再考虑Milvus也不迟。

加载就吃25G挺正常的，FP16的7B光权重就14G左右，加上KV cache和中间激活很容易就上去了。你推理OOM大概率是max length开太大或者batch没设成1，先试试把max_new_tokens压到512以内看看。另外int8量化对显存帮助有限，真要省得上4bit（bitsandbytes或者GPTQ），或者直接换vLLM，它做PagedAttention对KV cache管理好很

7B模型做function calling确实有点吃力，尤其是量化到4bit之后，指令遵循能力会明显下降。我之前用Qwen2.5-7B也遇到过类似情况，后来把量化换成bf16或者用GPTQ的8bit，工具调用准确率提升挺明显的。另外你的prompt里最好把工具描述写得更直白些，加上few-shot示例，告诉它什么情况必须调工具。温度调到0.1以下再试试，7B不是不能做Agent，但确实需要多花点心

这个问题其实挺典型的，本地部署和官方API的差距，很多时候不在模型本身，而在推理配置和量化上。你用的7B大概率是4bit量化版本，量化会明显影响指令遵循能力，尤其是“只输出答案”这种强约束，官方API通常是全精度或者更高质量的量化，表现自然不一样。另外ollama默认的temperature和repeat_penalty可能跟官方不一致，重复输出往往是repeat_penalty设太低或者上下文里

4090 24G跑7B FP16其实挺紧的，vLLM启动时会预分配KV cache，你设了0.9等于它要一口气占掉21G多，权重才14G但中间激活和CUDA graph那些加起来就爆了。先试试把gpu-memory-utilization降到0.8甚至0.75，再配合max-model-len调到4096以内看看能不能起来。nvidia-smi显示几百兆是因为报错发生在预分配阶段，进程还没真正吃满

LoRA确实能缓解遗忘，但关键还是任务配比别平均，通用数据得占大头。

刚入门，这个对我帮助很大。

这个问题我们也踩过坑，说说我们后来怎么绕的。核心思路其实是别让MCP那层去碰原始tensor，而是把它当成一个“描述层”——tool的入参里只放图像的文件路径或者对象存储的URL，真正的解码和预处理放在推理服务内部做，这样JSON-RPC只传轻量级的元数据，省掉了base64那种膨胀和反复序列化的开销。base64确实方便但真不适合大图，一张1080p的图编码完体积涨三分之一还多，高频调用的时候光