深夜云原生学习簿

常驻内存这点我踩过坑，模型加载一次就别乱动了，多轮对话超时多半是每次请求都重新初始化或者没做请求队列。并发我直接上asyncio+信号量限流，显存释放不干净大概率是推理时没加torch.no_grad，或者中间张量挂在全局变量上了。序列化这块如果前端不要求原始输出，走ONNX确实省心，量化后延迟能降不少，就是精度要自己验证下。FastMCP够用就别自己封HTTP了，省下来的精力拿去调模型生命周期更

7B跑代码补全确实吃力，试试换1.5B的模型或者上vLLM，延迟能降不少。

学到了，感谢分享！

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

这个思路不错，收藏了。

学到了，感谢分享！

这个思路不错，收藏了。

几十万条数据单机跑的话Qdrant确实够用了，部署就一个docker容器，过滤条件直接写payload filter，比FAISS那种自己维护id映射舒服太多。我之前也是FAISS转过来的，写入速度Qdrant单机批量插基本没啥瓶颈，Milvus那套etcd+minio+pulsar的组合小项目真没必要。唯一要留意的是Qdrant的filterable字段记得建索引，不然过滤查询会扫全量，性能差挺

A10跑7B其实不算宽裕，你这一下并发三四个人，KV cache涨得飞快，OOM太正常了。先别急着换框架，把`--gpu-memory-utilization`调到0.9，再限制下`--max-num-seqs`，基本能扛住。真要稳的话上AWQ或GPTQ量化，显存能省不少，速度掉得也不算多。换框架解决不了根本问题，瓶颈还是在显存和KV cache这块。

混合技术栈那段我也有同感，之前拿它试过Next.js加FastAPI的项目，前端组件生成挺顺，一到跨服务调试就开始打转，感觉它的self-debug还是更擅长单文件级别的修复。那个27%的提升估计测试集里纯代码任务占了大头，真实项目里的环境依赖和脏数据它未必扛得住。想问下你测的时候有没有故意给它埋点模糊需求，还是都写的比较明确的prompt？

工具描述里把使用场景写具体点，模型才知道啥时候该调，光靠prompt硬压没用。

两张A100还OOM，八成是KV cache没限住，试试gpu_memory_utilization调到0.85，再开个chunked prefill，能救回来不少。

这种情况其实挺常见的，不一定单纯是chunk或embedding的问题。你描述的关键词重合度不高但向量相似度很高，很可能是语义空间里“报销”“流程”“制度”这类词本身就容易和一堆行政类文本靠得近，尤其bge-large-zh在通用语料上训练，对你们内部术语的区分度未必够。400字chunk加50重叠对短问题来说可能还是偏大，召回片段里混进无关句子的概率不低，模型把整段编码后噪声就带进去了。可以试试

我之前也踩过这个坑，后来发现单纯靠LLM判断“任务完成”经常不靠谱，它会自我感觉良好。我现在的做法是在state里记录每个工具最近一次调用的参数和结果hash，如果连续两次完全一样就直接打断，强制走总结分支。另外给工具加个“无新信息”的返回标记也挺管用，模型看到没新东西一般就不硬试了。max_iterations当兜底就行，别当主要手段。

真实用户问题一上来就飘太正常了，你单测那几条根本覆盖不了实际query的多样性。我自己的经验是，别指望一个prompt打天下，得把知识库问答拆开看：先让模型判断问题类型，再决定要不要检索、怎么引用原文。至于“编”内容，加一句“只允许基于以下文档回答，不确定就直说不知道”通常比调temperature管用得多。分析工具的话，可以试试把失败case反过来当few-shot补进去，迭代几轮比瞎试快。

几十万条向量真没必要上Milvus，FAISS本地跑完全够用，省得折腾部署。Pinecone免费额度做原型验证没问题，但索引一多或者查询频繁就容易触顶，到时候迁移也麻烦。我建议先用FAISS把流程跑通，等量级上千万或者要多人协作了再考虑换。Milvus功能是全，但运维成本对小团队来说不太划算。

群晖防火墙默认会拦非本地网段，去控制面板把8899加进允许列表试试。

7B模型做结构化输出确实容易飘，尤其是Qwen2.5这种中文能力强的，它反而容易“自作主张”给你补全一些你没要求的东西。不过我觉得不完全是模型理解力的问题，更多是指令跟随和采样策略没配合好。你可以试试把temperature调到0.1以下，同时用vLLM或者llama.cpp的grammar约束，直接把JSON schema塞进去，这样它在解码层面就没办法输出非法格式了。另外prompt里别只说“

我踩过同样的坑，后来发现罪魁祸首是ReAct的思考循环没有状态记忆，多步任务里它经常忘了自己已经查到什么。你可以试试把中间结果强制写进prompt的scratchpad里，或者换成Plan-and-Execute那种先规划再执行的模式，稳定性会好很多。另外工具描述要写得特别明确，比如“发送邮件”得注明必须先用数据库查询拿到收件人，不然它真敢瞎编地址。

做Agent其实PyTorch生态更香，部署那层用vLLM或TGI就绕过去了，没必要为TF Serving回头补TensorFlow。