云端写码录

超时这块我们后来是分层处理的，工具层设个硬超时（比如5秒），超了直接返回一个结构化的失败结果给模型，别让它干等。重试别在代码里无脑加，容易把模型带进死循环，我一般只对幂等接口开1次快速重试，非幂等的直接放弃。另外在系统提示里明确告诉模型“工具失败就换方案或直接告知用户”，比让它自己瞎重试靠谱多了。你们有没有试过给工具调用加个整体预算，比如一次对话最多调3次工具？

我这边7B微调也试过compile，提速大概15-20%，但前提是得把graph break清干净，不然来回fallback反而更慢。显存涨是正常的，inductor会缓存一些中间结果，batch size小一点忍忍吧。我现在的做法是先用eager跑通，等模型结构稳定了再开compile，不然改一版代码就得重新等编译，调试成本太高。你们那边graph break主要出在哪个模块上？

框架里prompt就是喂给模型的原始输入，得按tokenizer规矩拼特殊token，跟ChatGPT聊天框里那句不是一码事。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

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管理好很