实战派推理加速应用札记

让它先列依赖和函数框架再填代码，比直接要完整脚本靠谱多了。

小batch下编译开销根本摊不薄，QLoRA本身又在频繁换kernel，收益能正才怪。

2万条数据3个epoch大概率过拟合了，loss降得快不代表泛化好。参数类型填错这种问题，我更倾向是训练数据里缺“边界case”的负样本，比如同个字段在不同场景下类型不一样的情况，模型没见过就容易瞎填。另外7B做严格schema约束确实吃力，可以试试在推理层加个校验重试机制兜底，比硬调模型划算。换32B或者专门的function calling模型会有改善，但数据侧的坑不填上，大模型照样翻车。

合同这种结构化的东西按固定字数切确实容易出事，我之前也踩过这个坑。你那个重叠加到50%的思路方向是对的，但代价太大，后来我改成按条款边界切，每个条款单独成chunk，如果某条特别长再在里面做二次切分，效果比硬切512好太多。chunk大小根本不是核心问题，语义完整性才是，固定长度切分天生就会把完整语义单元拦腰砍断。评估这块我现在会拿一批标注好的query跑hit rate和MRR，对比不同切分参数

AWQ 4bit 速度变慢大概率是没开 Marlin kernel，vLLM 里加 `--quantization awq_marlin` 试试，A10 上跑 7B 的 AWQ 一般能到 FP16 的八九成速度。质量下降确实有点，但内部工具场景基本能接受，实在敏感就上两张 A10 做 TP=2，比量化省心，就是卡成本翻倍。offload 不太建议放生产，CPU 那一趟来回延迟抖动太厉害，体验会很差

几千条QA微调Embedding风险确实大，数据量太少很容易过拟合，把原本的语义空间搞乱。我之前试过先优化chunk切分和加个rerank，效果比直接微调稳得多，尤其你top5看着还行说明召回没大问题，瓶颈可能在排序或生成环节。真要微调的话，感觉至少得上万条高质量领域数据才值得赌一把，不然不如拿这几千条去调prompt或做few-shot。

我之前也碰到过类似情况，PyTorch这边确实容易在几个地方翻车。你可以先查下是不是某个BN层在特定batch上方差特别小，PyTorch默认eps是1e-5，有时候不够用。另外优化器那边，Adam的eps默认也是1e-8，跟Keras可能不一样，调大一点试试。混合精度的话，PyTorch的GradScaler没配好也会炸，可以先关掉AMP跑一遍看看。

我也遇到过，感觉是长上下文注意力稀释了，试试按模块分批喂，别一次性全塞。

先别急着换模型，多半是分块把关键信息切碎了，加个重排试试。

几十万切片Chroma扛得住，但并发一上来就难受，Milvus Lite和正式版差距主要在分布式那块。

loss降得漂亮但输出变啰嗦，这基本是过拟合的典型信号了，5000条QA对3个epoch对LoRA来说确实有点猛。建议先把epoch降到1-2，学习率试试1e-4甚至5e-5，LoRA的rank其实不是关键，8和16差别不大很正常，真正影响大的是训哪些层和alpha设置。另外你数据里如果QA风格太单一，模型很容易把那种啰嗦句式泛化到所有问题上，可以混一点通用指令数据进去缓解。

3000字输入在7B上确实挺吃显存的，int8量化省的是权重，但长文本的KV cache才是大头。你试试vLLM吧，PagedAttention对长序列和并发优化很明显，A10跑7B int8应该能撑住。另外bitsandbytes的int8更多是加载省显存，推理峰值不一定降多少，换GPTQ或AWQ会稳一些。

最近也在折腾MCP这块，说下我的实际感受。Cursor目前对MCP的支持算是最顺手的，它的agent模式可以直接调你配好的MCP server，写单测的时候能自己读你项目里的上下文，不用每次都手动@文件，那种“它知道我在干嘛”的感觉比其他几个强不少。Copilot在VS Code里虽然也能接MCP，但更多还是补全为主，agent那套相对弱一些，复杂函数重构时经常要我反复解释意图。Codeium和T

都2024年了真没必要在这上面纠结太久，你师兄们默认PyTorch不是没道理的，尤其是做图像生成这块，diffusers、timm这些库基本都是PyTorch生态的，你搞扩散模型绕不开的。TF Serving部署确实香，但那是工程落地阶段的事，你现在研二还在搭模型跑实验，Debug效率和社区资源才是第一优先级，动态图那种print就能看中间变量的爽感，谁用谁知道。我当初也是Keras转过来的，上手

先查查检索回来的片段里是不是本身就缺关键信息，模型没料只能硬编。

我一般会按标题和段落切，再把相邻的小块做个重叠，效果比死磕token数好不少。你那个财报例子，其实可以先用小chunk召回，再让模型带着问题去父级段落里补上下文，路子会顺很多。固定200或500真不够用，文档结构不一样，硬切就是给自己挖坑。

“2023年营收”召回成“2022年”这种，多半是切片把年份和数字切散了，或者embedding对数字本身就不敏感。建议先试试混合检索，BM25对这类精确关键词特别管用，再用RRF融合，比单纯调HNSW参数见效快。query扩展也可以做，但别用LLM瞎扩，容易引入噪声，不如直接抽关键词做多路召回。efConstruction影响没那么大，efSearch调高点更实际。

这事我踩过不少坑，后来发现核心问题不在Prompt写得好不好，而在于AI根本没法像人一样持续维护一个“心智模型”。你给它再多约束，它每次生成都是在局部做概率补全，类之间的调用关系、状态流转这些跨段落的依赖，它记不住也推不动。我现在做法是把任务切得更碎，一次只让它写一个函数体，输入输出用类型标注钉死，上下文我自己在代码里拼好再喂给它，反而成功率上来了。few-shot确实容易翻车，例子给多了它会把例

我一般会在system里写“优先用<context>回答，不足时明确说不知道”，但别指望模型百分百听话。实测few-shot放一两个“文档没有就承认”的例子，比光讲规则管用。还有个坑是检索质量差的时候，你prompt再漂亮也白搭，先把召回率搞上去。

试试把实际CSV的几行样例和期望输出直接喂进去，比光说需求管用多了。