持续研究增长增长记
Lv.1关注产品增长，长期记录数字化方案落地、项目推进与复盘和从需求到交付的完整过程。倾向用真实案例代替空泛结论，希望用清晰的方法帮助产品与业务更高效地落地。
发表的评论
A10 24G 跑 7B 全精度光权重就占 15G 左右，8192 的 KV cache 再一摊，并发三四个确实顶不住。可以先把 `--max-model-len` 降到 4096 试试，或者限一下 `--max-num-seqs`，很多时候不是模型本身的问题，是调度没控住。量化的话 AWQ 或 GPTQ 能省不少显存，精度损失在知识库问答场景基本感知不到。换框架倒没必要，vLLM 的 Paged
我踩过这个坑，后来索性在工具层做字段裁剪和摘要，只把LLM真正需要的几个字段吐回去，解析错误率直接下来了。纯代理模式听着干净，但实际跑起来LLM对着嵌套三层的JSON就是会犯晕。不过也别全包，保留原始返回的透传通道，调试和排错时真离不开。
抽取任务真不用堆那么长，字段明确加一两个示例就够了，长prompt反而容易让模型分心。
几万条这个量级其实Chroma调一调还能撑，先把持久化模式开上，hnsw参数里M和efConstruction适当调大点，再限制下查询时的nprobe，延迟能压不少。Milvus standalone确实没想象中重，docker-compose一把起，但如果你就单机跑、不想折腾etcd和minio这些依赖，为这点数据量上它有点杀鸡用牛刀。Pinecone省心是真省心，可数据出了本地就得考虑成本和隐
按标题层级递归切分确实管用，说明书这种结构别硬切，让chunk跟着语义走。rerank阈值可以动态调，别死设一个数。
2e-4配LoRA确实偏高了，先降到5e-5再跑一遍看看重复是不是缓解。QLoRA本身一般不至于让括号都不闭合，更像过拟合加遗忘。
我最近也在看这个，简单说MCP就是把工具定义从模型请求里拆出来了，以前Function Calling的schema得塞在每次对话里，现在工具能力挂在Server上，模型通过协议去发现和调用。MCP Server确实是独立进程，一般走stdio或SSE跟客户端通信，模型那边其实不直接连Server，中间得有个host层转发。痛点主要是工具复用和跨模型吧，同一套Server Claude、GPT都能
我后来也发现文档类型不统一时，固定chunk基本就是碰运气。技术手册按标题层级切、对话记录按轮次切，效果会稳不少，混在一起确实很难调。重叠率我现在只留10%到15%，太高反而容易把不相关的内容一起召回来。中文场景建议先拿bge或m3e这类模型跑一遍，分词器差异真挺大的，同一个512在有的模型里语义早断了。你可以先固定一种文档类型做对照实验，别一次调太多变量。
这个场景太典型了，我第一反应也是先怀疑query改写没做好。“退款流程”和“退货政策”在语义空间里确实很近，模型分不清也正常。可以试试把query扩写成“退款操作步骤是什么”再检索，或者加个关键词过滤把“政策”类文档降权。另外工单记录这种口语化文本，bge-m3其实还行，但产品手册那种正式表述混合起来确实容易打架，建议先分开建索引看看效果。
Claude Desktop默认给MCP的启动超时挺短的，你试试在配置里把超时调大点，或者server启动时别等Ollama预热。
几十万条向量真没必要上Milvus，FAISS本地跑就够了，省得折腾部署。Pinecone免费额度做原型验证完全够，但索引一多或者QPS上来就容易超，得盯紧账单。我建议先用FAISS或Chroma把流程跑通，等数据量上百万或者要多人协作了再考虑迁移，前期别在选型上耗太久。
几百个PDF本地Chroma完全够用，内存没那么容易炸，等真到百万级再迁云也不迟。
500字符硬切太糙了，按标题段落切会好很多，rerank优先级其实比调top_k高。
这个坑我也踩过，pydantic 2.x 那波确实把不少老项目搞崩了。我的做法是在 MCP server 那层加了个拦截，工具调用返回依赖信息的时候顺手查一下项目锁文件，版本对不上就直接拒绝写入，让模型重新生成。光靠 system prompt 真的不靠谱，上下文一长规则就被淹没了，模型注意力根本顾不过来。requirements.txt 二次校验也能用，但它是事后补救，代码都生成完了再回滚挺浪费
加个reranker吧，bge对细粒度区分确实一般，chunk也可以试试按标题切。
两张3090跑7B LoRA其实挺勉强的，加载模型就OOM多半是没量化或者把模型整到单卡上了。bitsandbytes 4bit要记得配device_map，不然默认还是往cuda:0塞，直接撑爆。batch size 4对3090来说偏大，先降到1加上gradient accumulation试试，gradient checkpointing在Trainer里开gradient_checkpoi
prompt写得好确实能少改几轮，但指望它一次成型不现实，复杂逻辑还得自己兜底。
学到了，感谢分享！
13B模型4bit量化后单卡80G还OOM，大概率是KV cache没管住，gpu_memory_utilization默认0.9，并发一高就炸了。先把max_model_len和max_num_seqs调小试试，能顶住小流量。另外enable_prefix_caching和chunked_prefill开了没？这俩对显存和吞吐帮助挺明显的，比急着上张量并行省事多了。
试试 `--gpu-memory-utilization 0.9` 并限制 `--max-num-seqs 8`，A10 24G 跑 7B 并发高确实容易炸，量化到 AWQ 会稳很多。