移动开发学习簿

numpy数组得先转成list再返回，MCP对序列化挺挑的，我上次也踩过这坑。

这个问题我踩过类似的坑，多轮场景下直接把历史对话拼上去检索确实容易翻车，因为检索模型会把整段历史当成一个语义块去算相似度，结果“运费”这个强信号词把“退货”的弱信号盖过去了。你可以试试先做查询改写，让Agent把“那运费谁出”结合上文改写成“退货流程中运费由谁承担”这种自包含的query再去检索，效果会好不少。另外chunk 512配32重叠对客服场景偏小了，退货流程这种说明性内容经常被切断，可以

4090跑7B其实可以试试vLLM的FP8 KV cache，显存能省不少，精度损失比4bit量化小很多。AWQ确实比GPTQ稳，但建议搭配vLLM的gpu_memory_utilization调到0.9左右，留点余量给上下文。代码生成掉点的话，可以试试只在KV cache上做量化，权重保持FP16，效果会好很多。

7B这个尺寸的模型做结构化输出确实容易飘，我最近也在折腾类似的事，踩了不少坑。温度调到0.1其实作用有限，它主要影响采样随机性，但模型“想多说一句”的倾向不是靠降温能压住的。你提到把约束全堆在user消息里，这个我深有同感，换成system prompt来框定角色和输出格式之后，稳定性会好一截，因为Qwen对system的服从度明显更高。另外JSON这种需求，与其在prompt里反复强调“只输出J

你这情况大概率不是embedding的问题，而是切分粒度把语义单元打散了。试试按文档结构切，比如标题、章节、段落作为边界，再限制最大长度，比无脑500字强很多。召回后可以加个rerank模型先筛一遍，或者用相邻块合并的策略，把命中的chunk前后各带一块一起喂给LLM，语义会完整不少。

我之前也踩过这个坑，后来发现光调chunk size意义不大，关键得看你的embedding模型和检索器配合得怎么样。Markdown文档我一般按标题层级切，代码块单独拎出来，别跟正文混在一起。overlap我习惯设成chunk的15%左右，但更重要的是加个rerank，召回质量能稳很多。你可以先固定一个配置，把query和命中的chunk打出来看，比盲调数值有用多了。

我也遇到过，后来在prompt里直接贴一段符合规范的示例代码让它照着写，比讲道理管用。

7B用AWQ量化基本够写代码了，13B硬压不如换小模型调好prompt更实在。

量化到4bit还OOM的话，先看看是不是max_model_len开太大了，vLLM默认的KV cache预分配很激进，调小gpu_memory_utilization到0.85左右试试。Flash Attention主要是省计算不是省显存，真正压显存还是得靠KV cache量化或者PagedAttention那块。多卡张量并行落地其实不难，vLLM加个tensor_parallel_size=2

按目录切太粗了，试试按API接口粒度切，再给每块加上模块名和版本号做上下文，召回准很多。

用.cursorrules限定只让它新增文件，别碰已有代码，亲测管用。

4090跑70B就别想了，量化到2bit都够呛塞进去，还得留余量给上下文。7B或14B的4bit量化才是你的甜点区，Q4_K_M效果损失很小，日常代码补全基本感觉不出来。llama.cpp确实省显存，但并发和长上下文不如vLLM，vLLM吃显存换速度，24G跑14B 4bit大概能撑8k上下文。建议先拿14B的GGUF试水，别硬上70B。

建议先按章节切块提取，再汇总去重，单次全塞进去模型肯定会丢中间数据。

看到你说量化后的模型prompt效果会变，这个点我太有感触了。我之前部署Qwen-7B的时候也遇到一模一样的情况，本地fp16跑得贼稳，一上int8就各种重复和脱轨，后来发现其实是量化把模型对指令的敏感度给磨平了，尤其像“友好语气”这种软性约束，它现在需要更直白甚至带点示例的写法才能接住。 我个人觉得生产环境最大的变量其实是vLLM的continuous batching，它会把你的prompt

这问题看着太熟了，八成不是NCCL配置的锅，而是PettingZoo环境本身在子进程里没做好序列化同步。MAMujoco的全局状态如果每个进程各算各的，步调一乱就容易触发通信超时，内存溢出多半也是因为env复制了太多份。建议先试试把环境创建逻辑放到每个worker的独立函数里，别用默认的fork方式，另外给torch.distributed加个gloo后端做对照，能排除NCCL的干扰。我之前跑过类

正样本只有一个的话，我建议你试试InfoNCE加上in-batch negatives，比纯交叉熵更能拉开相对距离，尤其你负样本能随机采，这个优势挺明显的。你说的排序效果一般，可能是因为交叉熵只给了一个二分类信号，没显式建模doc之间的相对关系，所以候选一多就钝了。至于冻结层，我实践下来只冻embedding层就够了，transformer主体还是得放开，不然rerank能力上不去，但如果你担心通

两张4090跑7B其实不算宽裕，你可以试试把batch size降到1然后梯度累积开8步，效果一样但显存压力小很多。loss忽高忽低大概率是长文本截断把后半段对话语义切碎了，建议按1500tokens截断后加个特殊分隔符，或者干脆过滤掉超长样本。LoRA的rank和alpha用16/32起步就行，lr降到1e-4再看看，另外检查下数据里是不是有多轮对话标签没对齐，客服场景这种问题很常见。

说实话torch.compile在ResNet这种CNN上收益真的不大，它主要红利在Transformer和动态图结构上，我试过EfficientNet也是差不多甚至变慢。你那个dynamic shape报错大概率是dataloader里有个别tensor维度不是严格固定，比如最后一批batch size不同，建议把drop_last=True开起来或者给输入加个pad。另外编译本身有预热开销，建

正常，网上说6G是纯模型权重，你真跑起来加上长上下文和Agent工具调用，KV cache直接翻倍，12G一点都不夸张。

说实话你这个情况我太熟了，7B量化版在Ollama上跑，本身就是个“能用但别指望太聪明”的状态，尤其Coder系列对长上下文的连贯性要求高，量化一砍精度，逻辑断层就特别明显。我倒觉得不是prompt的问题，而是你拿它干的事恰好是它的弱项——从零写完整脚本需要全局规划，这恰恰是小参数模型最容易翻车的地方，补全已有代码反而靠谱得多。你可以试试把任务拆成更小的函数让它逐个生成，比如先让它写清洗逻辑，再单