生产级Agent工程手记

毕设做图像分类的话，我真心建议直接上PyTorch，别犹豫。你只学过一点Python，PyTorch的调试方式跟写普通Python代码几乎没区别，print大法就能看张量形状，而TensorFlow那个graph模式对新手来说简直劝退，尤其遇到报错时那个英文堆栈能让你怀疑人生。Keras确实已经集成进TensorFlow了，但学它其实没必要，因为PyTorch的nn.Module写起来比Keras

500条数据微调bge确实容易过拟合，我当时用2000条调出来效果也一般，不如直接上reranker立竿见影。 建议你试试冻结底层只训顶层，或者干脆放弃微调，把精力放在优化检索策略上，小规模场景真没必要折腾embedding。

这个坑我也踩过，光看模型权重确实容易乐观，实际跑起来kv cache才是吞显存的大户，尤其是文本摘要这种长序列任务，随便塞几条长文本进去显存就炸了。我建议你算的时候直接按公式：显存 ≈ 模型参数显存 + 1.2到1.5倍的序列长度×层数×头数×2字节（如果是fp16），再乘上batch size，这样基本不会翻车。INT4的5-6G只能算权重的静态占用，动态部分没算进去。vLLM和TGI我都试过，

试试把MCP工具结果作为动态参数注入RAG的prompt模板，让LLM自己整合输出，比硬拼接自然很多。

这种情况我遇到过，T4跑7B模型确实容易卡在显存带宽上，毕竟16G显存虽然够装，但T4的内存带宽只有320GB/s，生成token时计算单元经常在等数据。建议试试把vLLM的max-model-len设小一点，比如2048，或者打开--enable-prefix-caching，能省不少重复计算。另外并发高的话，可以调低--max-num-seqs，比如设成4，优先保证单次推理的响应速度。

说实话5000条QA对微调8B模型不算多，loss卡在0.9很可能是数据量不够或者任务本身太难收敛。我之前试过类似规模的数据，把rank提到16或者32之后loss明显能继续往下走，你可以先试试这个。另外学习率2e-4对于LoRA来说其实偏高了，降到1e-4甚至5e-5配合warmup可能会更稳，震荡多半是学习率和秩不匹配。还有检查下你的数据集有没有噪声或者格式不一致，比如有些答案太长或太短，这种

哈哈，这个缩写确实容易搞混，Model Context Protocol是Anthropic搞的协议，跟训练管线里的MCP不是一回事。你看到的MCP多半是Model-Centric Parallelism或者类似分布式策略的缩写，跟Hook根本是两个维度的东西——Hook是框架内给你插个回调来拿中间结果，MCP是并行训练时怎么切模型和数据。PyTorch里没有直接叫MCP的API，你想提取中间层特

4bit量化对7B模型确实有点狠，建议试试Q5_K_M或加一点LoRA微调保底效果。

说实话7B模型写代码确实容易飘，尤其是量化版，逻辑连贯性差很多。我试过用deepseek-coder-6.7B，发现把任务拆成三步走——先定义输入输出格式，再写伪代码框架，最后让模型填空——效果会好不少。另外建议你别只依赖模型，自己先列好需要的库和关键逻辑，让它补细节，这样翻车概率低很多。

确实，业务逻辑的上下文太复杂了，AI容易忽略边界情况，得把异常和状态流转写进prompt里才行。