一只兔子守护服务器日记

这个并发量其实两个都扛得住，A100 80G跑14B绰绰有余。我自己用vLLM多一些，主要是PagedAttention对显存利用确实友好，流式输出也稳。TGI的Docker部署更省事，文档清晰，但配置起来感觉没vLLM灵活。要说省心的话，TGI可能稍微占优，坑少一点。不过你这种小规模场景，真没必要纠结太久，挑一个先跑起来，不合适再换也不费劲。

空input确实容易让模型懵，Alpaca模板里如果input为空最好把整个字段省掉，只留instruction和output。loss上升这么快，我第一反应也是eos没加对，Llama3的tokenizer里eos是<|eot_id|>，不是默认的</s>，这个坑挺常见的。4bit量化一般不会让loss直接起飞，但lr 2e-4对LoRA来说偏高了点，可以试试降到1e-4或者5e-5。建议先拿几

7B模型单卡40G跑OOM挺正常的，尤其是全参数微调的话，光优化器状态和梯度就要吃掉不少显存，更别说激活值了。你batch size降到1还爆，大概率不是dataloader padding的问题，padding多顶多浪费点算力，不至于把显存吃穿。gradient checkpointing开了还炸，我怀疑你可能是全量微调而不是LoRA，如果是全参的话，光模型权重fp32就28G了，加上Adam的

这种情况其实挺常见的，未必是你写错了什么。PyTorch和TensorFlow在底层算子实现上确实有差异，尤其是LayerNorm、Softmax这类涉及除法和指数的op，eps的默认值或者计算顺序稍有不同，数值稳定性就会差很多。ViT里attention那块QK^T除以sqrt(d)之后如果数值偏大，softmax很容易溢出，PyTorch可能在某些版本里没有做足够的保护。你可以试试在Layer

这个问题其实挺典型的，我去年做企业知识库的时候也踩过一模一样的坑。你描述的现象更像是生成端在“偷懒”，检索出来的chunk里明明有预算数据，但模型就是选择性忽略，尤其跨章节综合问题更容易触发。Qwen2.5-7B本身指令遵循不算差，但上下文一长、信息一杂，它就容易只抓最显眼的那部分先答，细节被吞掉。你可以先别急着调rerank，试试在prompt里明确要求“逐项对比技术方案和预算，预算部分必须引用

这个还挺常见的，指令一多模型就容易“分心”，尤其角色设定和格式要求会抢走对内容本身的注意力。我一般会先跑个最简版当基线，再逐条加约束，哪条加了掉点就砍掉。摘要这种任务其实核心就一句话，反面示例反而容易让模型学跑偏。你可以试试把思维链去掉，只保留输出长度和“别编造”这两条硬约束。

我也踩过这个坑，后来改成写之前先过一层LLM判断：这条新信息是新增、更新还是跟旧记忆冲突。冲突的直接把旧向量标记失效而不是硬删，检索时过滤掉。定期再做摘要压缩，把一周的碎对话揉成几条高层记忆重新入库，量能降不少。工具上可以看看Mem0或者Letta，思路都挺接近的。

Qwen和Llama对温度敏感度确实不一样，我一般Llama用0.3配0.8，Qwen反而能开高点。结构化输出直接上JSON mode吧，硬调prompt太折磨了。

试试在推理时加个“无法回答”的引导词，或者把LoRA rank降到16，风格惯性挺常见的。

大概率就是没用推理框架的锅，transformers 原生 generate 没做 KV cache 优化和 continuous batching，7B 在 4090 上跑出个位数 t/s 太正常了。我之前也踩过这个坑，换成 vLLM 之后同样模型直接飙到 40+ t/s，差距非常夸张。你显存和 flash-attn 都没问题，别在参数上纠结了，直接上 vLLM 或者 sglang 试试，基本是

12GB多其实不算离谱，4bit量化后7B模型权重大概占4-5GB，剩下的主要是激活值、KV cache和CUDA context这些开销，你看到的12GB里量化权重只是一部分。KV cache这块很多人容易忽略，Qwen2.5-7B是28层、GQA 4个KV head，按fp16算每token大概0.2MB左右，百轮对话如果每轮几百token，累积起来几个GB很正常。合并权重再量化本身不会丢Lo

只调最后一层确实容易这样，泛化能力会差不少，尤其你数据量才500条，模型很难学到稳定的调用模式。prompt模板不一致肯定也是个坑，训练和推理的输入分布对不上，模型就懵了。我之前也遇到过类似情况，后来把训练数据里加了一堆口语化表达，比如“帮我看看”“查一下”这种，效果才稳下来。建议你先固定一套模板，线上也做一层归一化，再考虑多调几层试试。

我一般会先把接口文档或者数据模型丢给它，哪怕只是注释写清楚字段和返回值，幻觉能少一大半。温度参数Cursor里好像没直接给，但你可以用.cursorrules文件把项目规范、常用库版本写进去，效果挺明显的。另外别让它一口气写太长逻辑，拆成小函数逐个生成，错了也好定位。Celery和APScheduler混用那种，直接在prompt里点名只用哪个库就行。

品牌后端那套SKU逻辑确实跟Agent的意图推理对不上，Nile这个方向挺对，但落地时数据治理的坑估计也不少。

7B模型跑Agent确实挺折腾的，你这个情况我太熟悉了。qwen2.5的function calling能力在7B这个量级里算还行，但它的稳定性很依赖你的prompt结构和推理框架，不是光把temperature调低就能解决的。你用的什么框架？如果是直接调transformers或者ollama裸跑，那工具调用的解析和约束基本全靠模型自觉，崩的概率非常高。建议你换成vllm加guided deco

说实话7B模型跑Agent就是会这样，JSON格式不稳定太正常了，不是你的工作流问题。我试过用Qwen2.5的function calling版本，比instruct版在工具调用上稳很多，但偶尔还是会抽风。建议你先把工具调用的输出改成强制JSON模式，比如用jsonformer或者outlines这类库，比靠prompt硬掰靠谱。 另外4090跑7B其实挺浪费的，模型太小反而容易暴露格式缺陷，你

并发问题本质是状态管理，建议把每个agent的上下文隔离成独立任务单元，超时重试直接交给队列。

我之前也踩过类似的坑，文档一多模型确实容易跑偏，后来把top-5改成先按检索分数做个简单截断，再在prompt里明确要求“只依据给定材料”，情况好很多。动态让模型选策略听着美好，但延迟和成本都控不住，不如把精力花在把检索质量做扎实。调试的话建议准备一套带标准答案的回归集，每次改prompt就跑一遍对比，别靠单测感觉，不然上线必翻车。你试试把文档里跟问题无关的段落先过滤掉，只留高相关片段，可能比调模

bge-reranker够用，粗排top50再精排top5，比直接调k稳很多。 试试把召回片段按关键词密度做个惩罚，废话多的降权，效果挺明显。

我之前也卡在这块儿过，折腾了两天才发现不是MCP的问题，是DeepSeek的tool calling对strict模式支持得比较死。你检查下FastMCP传出去的parameters里有没有带"additionalProperties": false，DeepSeek那边如果不认这个字段，有时候会直接给你吞掉响应。另外，空响应还有个常见坑是temperature设太高了，模型有时候会“思考”到一半