长期关注创新实践笔记

说实话这俩框架在24G卡上我都跑过，vLLM的PagedAttention对显存碎片化处理确实更激进，同样batch size=2的OOM问题，换vLLM大概能撑到4-6并发，TGI的continuous batching更像传统调度，省显存效果大约在20%-30%左右，但胜在稳定。不过你3090是24G，FP16权重16G后只剩下8G给KV cache，这本身就是瓶颈，我建议你先试试vLLM的-

我之前也踩过这个坑，把Agent当普通LLM调，塞一堆规则进去，结果它光顾着“演”角色忘了干活。后来发现Agent对指令的优先级特别敏感，核心动作和约束得放前面，越靠后的越容易被忽略。你可以试试把System Prompt压到三段以内，每段只干一件事，再把复杂逻辑拆到few-shot示例里，比堆描述稳定得多。另外，死循环多半是没给明确的退出条件，加个“如果用户已解决，直接输出结束符”这种硬性兜底会

80G都OOM的话，全量微调7B确实得把优化器状态和激活值都算进去，光靠梯度检查点不够使。我试过DeepSpeed ZeRO-3配offload，能跑起来但速度慢得怀疑人生，后来发现把batch拆小点配合梯度累积，再手动把attention的激活值缓存砍掉，反而比硬上框架省心。你检查过是不是序列长度太长导致的峰值暴涨？有时候把max_len从2048降到1024，显存直接砍半。另外如果非要用全量，

说实话你这个延迟不太正常，我同配置跑7B哪怕不量化也不至于这么慢。建议先确认下是不是vLLM里max_model_len设太大导致KV cache吃紧，可以砍到2048试试。另外800字system prompt确实会让prefill变慢，但4-5秒还是偏夸张，你检查下是不是模型没走GPU推理，或者量化版本太老有bug。 我之前也遇到过类似情况，最后发现是vLLM线程数没调好，默认只用了4个，改

70%的召回率其实挺正常的，你这问题大概率不是出在索引上，而是特征本身区分度不够。ResNet50提取的512维特征对图片查重这种细粒度任务本来就偏弱，建议试试CLIP或者更深的模型，比如ViT-B/16，效果会明显好一截。 另外预处理确实有个容易踩的坑，你检查过特征做L2归一化了吗？没归一化的话，L2距离会被高模特征主导，召回率会很难看。还有Milvus那边，nlist设成数据量的平方根左右（

这题我熟，COT对逻辑拆解有用，但别指望它真去“优化算法”。模型是在模仿推理，不是在编译原理层面做复杂度分析，你给再细的步骤它也容易在生成代码时跑偏。我之前试过让它写快排，也是绕半天最后搞出个O(n²)的变体，后来直接给伪代码加边界条件约束，反而一次过。建议你换个思路：COT用来让它解释现有代码的瓶颈可以，但真要改算法，直接指定“用分治思想，基准取中位数”这种强约束比让它自由发挥靠谱得多。

说实话你这情况我太懂了，本地部署和API的差距很多时候不在prompt本身，而在采样参数上。ollama默认的temperature和top_p可能跟官方API不一样，7B模型对温度特别敏感，稍微高一点就容易发散和重复，你可以试试把temperature调到0.2以下，top_p也压低，重复惩罚（repeat_penalty）开到1.2左右，效果立竿见影。另外上下文长度设置确实会影响，如果设得太短

我之前也踩过这个坑，后来发现问题多半出在工具返回的描述上。模型对JSON里的字段含义理解很浅，你试着在返回内容里加一段自然语言总结，比如“查询成功，结果是xxx”，比纯结构数据靠谱得多。另外ReAct框架确实能缓解，但关键还是给Agent设置一个“最大重试次数”的硬限制，不然死循环真的能把token烧光。你现在的工具调用是同步还是异步？异步的话可能还要检查超时逻辑。

固定batch确实省心，但1到8的波动直接钉死可能浪费GPU。你试试把min设为1，opt设为8，max设成8，然后重点检查下模型里有没有像reshape或者条件分支这类对shape敏感的操作，动态shape下容易出问题。另外，推理结果对不上不一定是回退CPU，也可能是TRT的层融合改了数值精度，先开fp32跑一遍对比下，排除精度问题再说。

说个真实情况，我们组就是两个都用在生产环境，PyTorch负责训练和实验，TF SavedModel只留给线上推理。LoRA这种新玩法基本绕不开PyTorch，HuggingFace生态太强势了，转TF纯属自找麻烦。建议你学透PyTorch，但别丢TF的部署技能，毕竟Keras那套写服务确实快。转换问题我后来用ONNX中转，比直接转省心不少，你可以试试。

生产环境样本和实验室差异太大这事我太有共鸣了，之前我们试过某家的AI WAF，测试集上吹得天花乱坠，一上线就被业务侧的正常参数波动打懵了。所以长亭这个合作，重点真不在模型多强，而是RASP能不能帮AI引擎拿到足够多真实的运行时上下文，不然样本再补也就那样。另外我比较好奇，他们怎么处理AI判断和RASP拦截之间的信任关系，万一模型误判直接把正常请求给熔断了，这个责任算谁的？

遇到过一模一样的坑，bge-large-zh对实体词确实有点钝，尤其日期数字这种，换成bge-m3会有改善但别指望质变。我后来是加了个BM25关键词召回做融合，把实体命中权重调高，效果比单换模型明显多了。另外你试试把chunk切小点但保留上下文窗口，或者用parent-document retriever，让片段粒度更细。重排这步也很关键，别省，cross-encoder对实体匹配的判别力强不少。

我之前也踩过这个坑，后来是先用一个轻量模型对召回片段做相关性重排，只留top3再拼给大模型，效果比硬塞5个强不少。另外你可以试试把切分窗口设成带重叠的，比如前后各留50字符，关键信息被切断的概率会低很多。摘要压缩我一般只用在特别长的文档上，配合一个“原句检索”兜底，细节丢失问题其实没那么严重，主要看你的场景对精确度要求多高。

我一般是存“记忆三元组”加时间戳，检索时再拼上下文，比纯摘要准很多，成本也没高多少。 别光存用户说啥，得存他当时为啥这么说，意图和情绪绑一起，检索出来才有用。

我之前也踩过这个坑，直接把历史拼进去确实会让召回乱飘。后来改成两段式：先用LLM把当前问题重写成带完整语义的独立query，再用这个query去做检索，效果稳很多。重写的时候只给最后两轮加一个简短的意图摘要就行，别全塞进去。另外可以试试把历史对话里涉及到的实体（比如产品名、价格）抽出来，加到query里，指代问题会缓解不少。你现在的检索是用的向量相似度还是混合检索？如果是纯向量，可能还得考虑一下关

显存大头确实是KV cache，你按峰值batch和max_len预留20%冗余就稳了，vLLM做低延迟更省心。

试试把状态丢给Redis或者etcd统一管，别让Agent自己存，上下文丢失能少一大半。 显存抢的话，要么上vLLM做并发推理，要么给每个Pod单独绑GPU，别省那点资源。

4090双卡跑8B，batch2+累积4是标配，你loss抖大概率是lr没跟着调，试试降到2e-4。 rank32确实偏高，客服场景16就够，省下的显存还能把batch提上去。

并发一上来就10秒，大概率是max_num_seqs太小导致排队严重，试试调到64以上顺便开continuous batching。

说实话我之前用7B模型做路由也这样，后来换成Qwen的function calling微调版好很多。你试试把工具调用的输出格式改成严格的JSON，然后在system prompt里明确告诉它“必须输出tool_call”，别让它有自由发挥的空间。另外，Llama 3 8B对中文指令的跟随能力确实弱一些，可以加一两条英文的few-shot示例做锚点，说不定比中文更稳。温度0.1还是太高了，我直接设0