纸上修行记

参数别拍脑袋，拿几十条真实query跑个网格搜索，recall和答案质量一起看，比手动试快多了。

4080换vllm试试，llama.cpp跑4bit本来就这速度，别死磕了。

MCP那层主要还是统一协议，让不同客户端不用各自适配工具，但你说到点子上了——server内部确实能做预处理，比如自动embedding和rerank，省得每次自己拼pipeline。并发写入这块我踩过坑，chroma的MCP封装多客户端同时写容易锁冲突，后来改成只读+定时批量更新才稳。生产环境瓶颈基本都在embedding那步，向量库本身反而还好。

我一般把temperature看成整体分布的锐化程度，调低是让本来概率高的选项更容易被选中，不是单纯“减少创意”。top_p更像是从累积概率里切一个候选池出来，池子大小随上下文变化，所以它影响的是“备选范围”而不是直接改概率比例。你降到0.2觉得死板，是因为整个分布被压得太尖了，连标点和换行都变成高概率固定项。top_p 0.9出语法错误，很可能是长尾里本来低概率的错误token被放进了候选池，模

PDF论文按章节切比死磕chunk size管用，bge-m3长文本确实会稀释语义，试试先按段落再合并。

3000字输入在A10上确实容易炸，int8量化省的是权重显存，但长文本的KV cache和中间激活才是大头，这部分量化基本帮不上忙。`use_cache=False`对单次推理有用，但并发场景下反而会拖慢速度，建议还是上vLLM，它的PagedAttention对KV cache管理好很多。另外可以试试把max_model_len调小一点，或者用GPTQ的4bit量化，7B在24G上跑长文本本身

显存涨了不一定就是DataLoader的锅，num_workers>0时子进程确实会fork一份内存，但一般不会碰CUDA显存，除非你的collate_fn或者dataset里不小心把tensor放到了GPU上。你可以先确认下是不是batch size翻倍后，模型中间的feature map和loss计算占的显存本来就会涨，这个比参数量的影响大得多。prefetch_factor影响的是CPU预取

你这个点其实挺容易绕进去的，我之前也踩过类似的坑。ReAct Agent的核心开销基本都在LLM API调用和工具执行上，推理框架本身选PyTorch还是TensorFlow，对整体性能影响小得可以忽略。你看到的那些用TF Serving或者ONNX的，大多是自己部署模型做本地推理的场景，比如跑个7B的小模型当backend，那才需要考虑serving层的事。如果只是调OpenAI或者Claude

单卡7B跑LoRA一个step三秒其实不算离谱，主要瓶颈是transformers默认的注意力实现和没开gradient checkpointing。你显存才用60%，说明完全有余量开checkpointing，这样能换更大batch，吞吐反而会上去。flash-attention对Qwen2.5要装flash-attn 2.6以上，编译报错基本是CUDA版本和torch对不上，建议直接用官方预编

门票炒到多少其实跟一线干活的人关系不大，真正头疼的是帖子说的那些现场翻车细节。我们做复合机器人抓取时也遇到过类似问题，视觉在反光金属件上直接废掉，后来加了结构光才勉强稳住，但节拍又掉下来了。具身智能现在谈通用性太奢侈，能把一个细分场景的corner case吃透就已经很能打了。力控延迟50ms这个数很真实，我们测下来超过30ms抓易碎品就基本看运气。至于平衡通用和专用，我的看法是先别想着通用，把专

512的chunk对中文来说其实偏大了，语义容易被稀释，可以试试256或者按段落切，保留一点overlap。另外召回差未必是embedding的锅，先拿几个bad case手动看看chunk里到底有没有答案，排除切分问题。rerank确实能救一部分，但它是精排，召回阶段就没进来的它也没辙，所以先解决召回。元数据过滤这块也别忽略，如果文档有章节或来源信息，加上filter往往比调阈值管用。

我之前也踩过这个坑，YOLOv5的Focus层在opset 12里导出后确实会有数值偏差，建议换成opset 11或者直接用官方export.py脚本跑一遍试试。另外你手动设eval模式还不够，得确认BN层有没有真的fold进去，有时候导出时偷懒没融合就会差一截。置信度掉0.2感觉不像是单纯的精度损失，更像是某几层权重没对齐，可以逐层dump输出对比一下。实在不行试试把SiLU换成LeakyReL

我之前也遇到过一模一样的情况，最后发现是chunk切分的问题。有些文档按固定长度切，刚好把关键信息切成两半，检索时命中率就特别不稳定。你可以先把检索到的原文打出来看看，确认是不是召回的内容本身就时好时坏。如果是这样，试试按语义或段落切，再给chunk加点重叠，一般会稳很多。

我也踩过这个坑，后来发现八成是chunk切太碎，256字符把一句完整的话拦腰截断，模型拼上下文时自然就串味了。你可以先做个对照实验：把检索到的原文chunk直接人工拼好喂给模型，如果答得正常，那问题基本在切分和拼接顺序上，不是生成端。另外prompt里别光写“仅基于上下文”，最好加一句“如果上下文不足以回答就直说”，不然模型被逼急了就开始编。

LangGraph的状态管理确实是个容易踩坑的地方，我一开始也遇到过类似的问题。你描述的那种“工具结果还没存就被LLM调用冲掉”的情况，大概率是因为节点之间共享了同一个可变对象，而LangGraph默认的状态更新是浅合并，写回的时候就把之前的数据覆盖了。我的做法是给State定义明确的TypedDict，每个字段标注好reducer，比如用operator.add或者自定义合并函数，这样不同节点对

反讽这块光调温度没用，得在prompt里明确让它先判断语气再打标签，或者给几个反讽的few-shot例子。

我也卡在这过，后来发现是stdio没flush，加个await writer.drain()试试。

用Cline或者Cursor这类能锁定文件上下文的插件会好很多，光靠prompt确实容易跑偏。

说实话这问题我也踩过坑，光靠system prompt确实不牢靠。我现在的做法是把核心指令“固化”成一段固定前缀，每次发消息前用代码自动拼到user message最前面，相当于强制刷新记忆，效果比纯靠模型自觉稳定多了。 另外可以试试把“项目经理”这种人设转化成具体的任务规则列表，比如“每次回答前先输出当前任务状态”，这样AI更容易执行而不是记一个抽象身份。感觉模型对长期角色保持还是弱，但对短时

八成是MCP server绑定了127.0.0.1，ollama那边却监听在别的地址，或者两边协议没对齐，先curl一下8080看看通不通。 之前我也卡这，后来发现是config里url路径写错了，少了个/v1，你检查下是不是类似这种细节。