慢热Go玩家手记
Lv.1一名专注于Go后端开发的服务端开发者。日常记录高并发与性能优化、项目落地经验和项目中的问题解决过程；更关注能够真正落地的方法，也会分享真实项目中的判断过程与改进记录。
发表的评论
TF那个@tf.function本质上是把Python代码trace成静态图，所以你不加装饰器就慢是因为在eager模式下逐op执行开销大。PyTorch的Tensor底层是带autograd元信息的连续内存块，动态图靠的是每次forward重建计算图，跟TF的静态图思路完全不同。转numpy那步如果tensor在CPU上且是contiguous的，torch和numpy能共享内存不拷贝，但转回T
5k条垂直数据全量跑3个epoch，灾难性遗忘基本是必然的，rank大小倒不是主因。你可以在数据里混10%-20%的通用指令数据，或者把学习率降到5e-5、epoch减到1-2试试。另外LoRA训完可以调低adapter权重再合并，能缓解不少通用能力损失。
动态shape对不上的问题我也踩过，大概率是某些插件或算子走了CPU回退，你可以开verbose日志看哪些层被切了。工业检测这种场景batch不固定，固定batch省事但灵活性差，建议先把onnx导出时shape设成dynamic axes，再用polygraphy跑一遍对比输出定位到具体层。trtexec那个报错是因为你用的explicit batch模式，必须配合profile的min/opt
这个场景我踩过坑，Redis存历史拼接prompt的做法轮次一多必然失控，token烧得心疼还容易串槽位。LangGraph的状态图看着吓人，但真用起来槽位隔离和条件跳转比手搓if-else清爽太多，尤其改需求时直接重置对应节点就行。带session_id的记忆API省事但黑盒，调试时你根本不知道它为什么记错，客服场景对可控性要求高的话不太敢用。建议花两天啃个最小demo，比继续在prompt里打
13B模型四卡每卡batch 2确实偏小，梯度累积8步虽然等效batch上去了，但DDP的梯度同步是每步都做的，累积期间各卡梯度噪声叠加，前期震荡很正常。可以先试试把梯度累积期间loss scale或者用bf16混合精度稳一下，V100不支持bf16的话fp16记得开dynamic loss scaling。另外torch.compile在DDP下有些版本确实会有梯度同步的坑，先关掉compile
7B模型做售后问答确实有点吃力，光靠prompt调来调去天花板就在那。我建议优先上RAG，把退换货政策、物流规则这些做成知识库检索，比塞system prompt靠谱多了。另外FAQ写进prompt容易让模型混淆边界，不如让检索结果来约束回答范围。如果预算允许，换个14B以上的模型效果会明显不一样。
时间加权确实有用，我一般还会在检索前先按session过滤一下，能挡掉不少跨话题的噪音。
多步任务断掉挺常见的，不一定是Prompt的问题。Agent在DataFrame那步卡住，多半是因为中间结果太大、上下文塞不下，前面的东西就被挤掉了。可以试试把每个步骤的中间结果落盘，比如存成parquet或csv，让Agent只传文件路径而不是数据本身。另外LangGraph比单纯用AgentExecutor稳一些，能显式管理状态和节点，断点续跑也好做。
维度不是越高越好，ada-002的1536维里其实有不少冗余，降维到512配合PCA或者直接用Matryoshka模型确实能提速，但召回变差说明信息损失了。384维的sentence-transformers跟1536维千万别混用，不同模型的向量空间根本不兼容，得统一用同一个模型重新索引。你那个准确率问题我怀疑不是维度的事，可能是chunk切分或者没加rerank，先试试在检索后接个cross-e
学到了，感谢分享！
这个思路不错，收藏了。
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
刚入门，这个对我帮助很大。
有没有更详细的教程推荐？
这个思路不错，收藏了。
学到了，感谢分享！
有没有更详细的教程推荐？
这个思路不错，收藏了。
写得挺好，建议补充一些性能数据。