持续迭代商业成长记

我之前在4090上也折腾过Llama 3.1 8B的部署，FP16确实单卡24G扛不住稍微大点的并发。vLLM的PagedAttention对kv cache的显存碎片控制确实好一些，我测下来batch size能比TGI多撑个一两档，但TGI的continuous batching调度更稳，长请求混短请求的时候不太容易把显存吃满。你要是纯做对话和摘要，输入输出都不算特别长的话，vLLM可能更适合

ComfyUI和WebUI确实底层解析不太一样，不只是clip skip的事。我之前也踩过这坑，后来发现ComfyUI里CFG的生效方式和WebUI有细微差别，同样的数值实际效果并不对等。另外token权重解析、prompt的截断长度这些也会影响，尤其SDXL对prompt长度敏感，超了就开始崩。建议你把两个框架的workflow截图对比一下，别只看表面参数，有条件的话固定latent输入再测会更

3090跑13B确实尴尬，FP16直接没戏，量化到4bit是常态。我试过AWQ的4bit版本写代码，比INT8强不少，但跟原版比还是有点差距，尤其复杂逻辑容易掉链子。你这需求不如试试7B的代码特化模型，比如DeepSeek-Coder或者CodeQwen，量化后效果反而比通用13B好。vLLM对长文本帮助有限，关键还是KV cache和上下文长度控制，别一次塞太多。

纯中文场景下BGE和OpenAI的差距其实没有想象中那么大，ada-002在多语言上确实稳，但中文细粒度语义它并不占优，尤其是你们做内部文档问答，术语和专业表达多，BGE-large-zh这种在中文语料上专门训过的反而更贴。不过你光靠肉眼看召回肯定没底，建议拿几十条真实query手动标一下hit rate，哪怕粗评也比拍脑袋强。Rerank确实能补一大截，embedding粗排只要保证相关文档在前

我踩过一样的坑，光加“严格基于原文”真不够。你可以试试把chunk编号，比如[1][2]，然后要求模型每句话结尾标来源编号，这样它乱编的时候会露馅。另外加一句“如果检索内容没提到，就回答‘资料里没有’”，比只说“别瞎编”管用。开源模型对格式更敏感，最好把指令放最前面，再用###分隔上下文和问题，别混在一起。

子查询拆太碎确实容易丢主题，试试让MCP先做一轮粗排再合并，别各搜各的。

4080的显存带宽其实不差，5-7 tokens/s明显偏低了，大概率是llama.cpp的默认参数没调好。建议先试试把n_gpu_layers拉满，再把线程数设成物理核心数而不是超线程数，batch size也可以适当加大点。另外你这种内部测试场景，vLLM配AWQ量化可能更合适，连续批处理对延迟优化挺明显的，不过显存占用会比llama.cpp高一些，得自己权衡下。

千万级数据加资源有限，Qdrant基本是更稳的选择，单机部署省心，HNSW性能也够用。Milvus生态确实强，但想跑顺了往往得上集群，运维成本不低。混合检索这块Qdrant原生支持稀疏向量，接BM25或者SPLADE挺方便，Milvus得靠外挂ES那套，链路更长。你们团队要是没有专职运维，建议先用Qdrant跑起来，真到瓶颈再换也不迟。

4090跑7B FP16理论上是够的，但vLLM启动时会先预分配KV cache，你看到的几百MB是还没到那一步就崩了。试试把gpu-memory-utilization降到0.85，再确认下有没有其他进程占着卡，有时候jupyter或者之前的残留进程会偷偷吃显存。max-model-len调小确实有用，但2048还OOM的话感觉更像是环境问题，检查下torch和vllm版本对不对得上。实在不行直

7B确实容易偷懒，试试用Qwen官方推荐的tool call模板，vLLM里不会自动套，得手动传。

我遇到过类似情况，loss降到1.2其实不代表模型真学会了格式，它只是拟合了你的数据分布而已。你训练集里如果标签前面有大量解释性文本，模型就会优先学那些废话，而不是直接吐标签。建议把数据全改成纯标签输出，加个明确的停止符，比如“###”或者特殊token，推理时碰到就截断。另外学习率如果超过2e-4，LoRA很容易把格式学崩，可以降到1e-4试试。

我踩过和你一样的坑，直接塞全文短文档还行，量一大就废。向量分数别太当真，余弦相似度高不代表语义相关，尤其是合同这种专业文本。bge-small确实偏弱，换bge-m3或加个bge-reranker立马不一样，召回top20再精排效果稳很多。延迟上向量库多几十毫秒但换来的是能扩展，纯拼prompt到后面根本塞不下，准确率反而崩。

微调embedding把通用语义搞退化这事我也踩过，挺常见的。你单测相似度看着还行，很可能是因为测试样本跟训练数据分布太像，评估不出真实退化。我一般会先做个对照实验：拿微调前后的模型，在同一批没见过的query上分别算Recall@10和MRR，如果微调后掉点，基本就是训练数据构造的问题了。CSE默认是in-batch负样本，如果你的领域数据里正样本对本身就比较稀疏或者噪声大，模型很容易学到一些伪

我这边是单独起了个 embedding 服务，MCP Tool 里只做切片和请求转发，好处是模型换起来不用动 Server 代码，查询侧还能挂个缓存顶一下。Qdrant 那个第三方 embedding 插件我也看过，图省事可以用，但会跟向量库绑得比较死，调试也不太透明。延迟这块关键看你文档量和查询频率，量不大的话本地小模型加个 LRU 缓存基本够用，真扛不住再考虑上推理服务。

几万条数据Chroma完全够用了，换Milvus大概率解决不了你这个问题。检索不准八成是embedding模型的锅，中文场景尤其明显，很多通用模型对“治疗流程”和“用药禁忌”这种语义相近但意图不同的区分度不够。建议先换个针对中文优化的embedding试试，比如bge-large-zh或者m3e，成本比折腾Milvus低多了。另外切片策略也值得再看看，按语义切比按固定长度切效果会好不少。

500条数据3个epoch，学习率还开3e-4，这组合确实容易把通用知识冲掉。我之前微调也踩过这坑，后来把通用数据混到三成，学习率降到2e-4，灾难性遗忘就缓和多了。你rank=8本身没问题，但可以先试试把epoch砍到1，看看效果再慢慢加。另外有条件的话，数据量提到1500条左右，质量保持住，比单纯堆数量管用。

这问题太真实了，我也踩过坑。后来发现光贴示例不够，得把风格要求拆成“硬规则”喂给它，比如明确说禁止class组件、必须用hooks，再配合一两段你写的“标准答案”当few-shot，效果会稳很多。另外我试过在prompt末尾加一句“生成前先复述一遍你记住的风格要点”，它跑偏的概率会明显下降，你可以试试这个偏方。

工具返回结果必须截断，超过2K token直接丢，另外试试Qwen2.5的3B版，24G跑这玩意绰绰有余。

我之前也踩过类似的坑，特别是“跑偏”这个问题，后来发现根子往往不在模型本身，而在工具描述和Prompt的结构上。LangChain的Agent本质是靠LLM做“意图路由”，如果工具描述写得含糊或者互相有重叠，模型确实容易在中间步骤犯迷糊。我试过把每个工具的description改成“什么时候用+输入格式要求+预期输出”三件套，效果比加一堆few-shot强得多。至于中断，大概率是Pydantic解

温度0.2其实不算低，对这种小模型补全任务，试试调到0.1甚至0.05，采样随机性会小很多。另外Ollama默认上下文长度可能不够，函数注释和已有代码之间的关联信息被截断，也会导致输出飘，可以显式把num_ctx拉大试试。再就是量化版确实比满血版更容易出语法错误，尤其是4-bit以下，建议先用q8或fp16跑一下同一个prompt对比看看。如果还不行，可能得在注释里写得更具体，比如标明函数参数类型