认真做商业随身笔记

8G显存跑7B量化版是能跑，但别指望体验好。我试过Qwen2.5-7B的int4用llama.cpp，能起来，就是上下文一长速度掉得厉害，并发基本别想。如果只是内部几个人偶尔问问，凑合能用，但知识库问答通常要接检索，prompt会很长，显存分分钟爆。建议要么换张12G以上的卡，要么直接上API，别在这上面耗太多时间。

我之前也踩过这个坑，后来发现纯靠调chunk size基本是死胡同。我的做法是分层切：先按标题层级切成粗块，再在粗块内部按语义切细块，检索时先命中粗块再往下钻，效果比单一粒度好不少。另外overlap别设太大，不然召回一堆重复内容反而干扰排序。你文档结构比较规整的话，强烈建议把标题路径也塞进metadata里，检索时能过滤掉很多噪音。

我之前也踩过类似的坑，工具返回格式不统一确实挺折磨模型的。我的做法是先在数据预处理阶段加一层轻量适配，比如把纯文本包装成统一的JSON结构再喂给模型，这样至少让训练目标一致一点。不过完全统一也不现实，毕竟有些工具返回的就是没法塞进固定schema，所以prompt里还是得保留格式说明，只是别写得太啰嗦，模型微调后对简短指令的敏感度会下降。嵌套JSON那种情况，我建议在训练数据里混一些解析失败的负样

你这情况挺典型的，我一开始也踩过。512字符对技术文档来说确实太碎了，尤其术语类内容，上下文被切没了，embedding自然抓不准。可以试试按段落或语义边界切，配上一些overlap，1024其实不一定丢信息，反而语义更完整。reranker建议加，先用向量粗排召回20个再用cross-encoder精排，效果提升很明显。另外FAISS本身对语义区分能力有限，也可以顺手看看是不是embedding

FP16精度掉点很常见，试试在C2f那块强制走FP32，或者换onnxruntime先验证下onnx输出对不对。

几十万切片单机跑，pgvector其实真够用，别被带偏了。我们小团队就是Postgres加pgvector起步的，后面量涨了再迁Milvus或Qdrant也不迟，迁移主要就是重灌embeddings，没想象中痛。Milvus Lite当本地开发验证行，真上生产还是别省那点部署功夫。结构化信息我一般跟原文一起塞payload或者单开字段存，检索时当filter用，别只存裸文本。

这个坑我踩过，而且踩得还挺深的。单轮表现好不代表多轮下还能稳住，因为Agent框架会在你的prompt前面塞一堆system message、工具描述、历史对话，模型的注意力早就不在你那点格式约束上了。你调temperature和加prompt约束治标不治本，模型看到几千token的上下文，那个JSON格式的“惯性”很容易被冲散。我建议你先排查一下微调数据里有没有多轮场景的样本，如果3000条全是

双卡3090跑7B和13B按理说没那么容易爆，你Agent场景估计是并发请求加上上下文越来越长，KV cache吃掉了大头。8bit量化掉质量这事儿我也遇到过，多轮对话里函数调用参数经常开始胡编，后来换AWQ 4bit反而比bitsandbytes的8bit稳，建议优先试AWQ而不是GPTQ，前者对指令跟随的损伤小一些。vLLM和TGI在Agent这种动态调用场景确实别扭，每次请求结构不一样，调度

这个坑我也踩过，而且踩得挺惨。我的感觉是问题不一定出在模板本身，而是模板把系统提示撑得太长太“满”了，多轮一叠加上去，模型注意力被前面那些角色设定和示例稀释掉，后面真正重要的指令反而压不住。few-shot确实也可能是元凶，你给的示例越具体，模型越容易把它当成“标准答案”去套，而不是理解你当前这轮的意图。我后来改成把硬约束放最前面、示例只留一两个最贴近当前场景的，其余全砍掉，多轮稳定性明显好一些。

业务代码得自己拆步骤喂它，别指望一把梭。

3090上BGE加reranker确实吃显存，试试bge-small加量化版reranker，效果差不了太多但省一半。

我去年找工作的时候也纠结过这个，后来发现面试基本都问PyTorch，实际组里也大多用PyTorch做研究迭代。TensorFlow在工业部署确实还有些存量，但新项目越来越少见了。建议主攻PyTorch，把训练和调试搞熟，部署那块可以顺带了解下TorchScript或者ONNX，不用一开始就死磕。真遇到要求TF的岗位，Keras上手很快的，别被招聘JD吓住。

我们组就是混着用的，训练侧全转PyTorch了，HuggingFace那套生态确实省事，LoRA微调基本开箱即用。TF那边就留着推理部署，SavedModel加TF Serving跑线上挺稳的，没必要硬转。转换踩坑太正常了，Embedding名字对不上算轻的，自定义层基本得手写一遍，后来我们干脆训练完导出ONNX再进TF，绕开权重转换这摊事。要是你主力搞微调，建议PyTorch学透，TF当部署工具

MCP本身不管推理，它就是个协议层，负责把模型能力以标准接口暴露给客户端，权重加载和显存调度还得靠vLLM或TorchServe那套。典型做法是拿vLLM起个OpenAI兼容的server，再写个MCP server包一层，把tool调用转发过去。其实你直接看官方那个filesystem demo改一改，把读文件换成调本地推理接口就能跑通了。

MCP本身不管推理，它就是个通信协议层，负责把工具描述暴露给客户端、转发调用请求。你本地模型还是得用vLLM或者TorchServe起个服务，然后在MCP server里写个tool去请求那个endpoint就行。我现在的搞法是vLLM跑推理，MCP server用Python SDK写，大概几十行就能跑通一个本地模型接入的例子。

我之前也踩过这坑，光靠buffer确实不行，token一爆就全乱套。后来改成滑动窗口加摘要压缩，老对话定期让模型总结成几句关键信息存起来，比硬塞历史强不少。向量检索那块建议加个重排序，不然召回质量真看运气。另外可以看看mem0或者Letta这类专门做记忆层的项目，本地跑也不算重。

我也遇到过，示例太像反而让模型偷懒照抄格式，试试把示例减到1个或换成交错不同工具。

我之前也踩过这个坑，加大窗口确实治标不治本，token烧得心疼还照样丢。后来我换了个思路，不存全文，每轮结束让模型把关键信息压成一两句话存起来，下一轮直接拼进去，效果比向量库轻量多了。工具调用那块最好单独标记清楚，不然结果真的会串。你场景不复杂的话，试试滑动窗口加摘要，应该够用。

工具描述别写太长，Agent容易看花眼。试试把每个工具的用途和触发条件写死一点，能稳不少。

AI给的代码得自己嚼碎了再咽，不然坑的都是自己。我一般只让它写测试和样板，核心逻辑还是手搓。