这周3.9~3.15的深度学习圈子和前几周相比少了点又出大新闻的爆炸感多了一些闷头干活的务实气氛。我把这周刷过的论文、跑完的实验、踩进去又爬出来的坑归拢了一下发现几条主线非常清晰多模态已经从刷榜转向落地长上下文不再是能不能做而是贵不贵的问题小模型在具体业务任务上开始大规模替代大模型调用。这篇周报不打算面面俱到只聊我这周真正觉得值得花时间的几件事以及一些能直接抄走的实操经验。1. 本周方向盘点多模态、长上下文与小模型精兵路线1.1 多模态从刷榜转向落地本周在多模态方向上社区讨论的热度明显从谁又在某某榜单上拿了第一转移到了工程实现上。我刷到的好几篇工作都在扣一个细节视觉编码器和语言模型之间到底该怎么对齐。前两年的主流做法是把图像切成 patch塞进一个线性映射层再接语言模型简单粗暴。但现在的讨论开始关注几个此前被忽略的点视觉特征里哪些信息对语言模型是有用的哪些只是像素级的冗余训练时视觉编码器是冻结还是解冻不同阶段应该怎么切换高分辨率图片该怎么切分才不会把注意力预算浪费在白色背景上。有个团队放出的消融实验很有意思在表格理解任务上单纯堆高分辨率输入准确率只涨了不到两个点但推理耗时翻了一倍而如果先用一个小网络做版面分析把表格区域裁剪出来再送进模型同样的分辨率下准确率涨了五个点以上。这给我的感觉是多模态下一阶段的红利很大一部分在预处理管线里而不是在模型结构里。1.2 长上下文的成本账被算得更细了这周好几篇讨论长上下文的帖子都在做同一件事算账。标准注意力机制的复杂度随序列长度平方增长这不只是纸面上的复杂度更是实打实的显存和延迟。很多人以为把上下文从 8k 撑到 128k 只是改一个参数的事实际上 KV cache 的显存占用会线性膨胀推理延迟也跟着恶化。比较务实的讨论集中在两个方向一是稀疏注意力二是 RAG 式的外部检索。有意思的是这周社区里对两者的态度不再是二选一而是开始讨论如何组合。比如在长文档问答里先用检索把相关段落抽出来拼成一个中等长度的上下文再用长上下文能力做全局推理——这样既避免了检索截断导致的信息丢失又不用真的把整本书都塞给模型。有一个帖子做了个很直观的类比长上下文是把整座图书馆搬到你桌上RAG 是先让图书管理员把可能相关的三本书拿给你。大部分场景下你要的是那三本书而不是整个图书馆。1.3 小模型的精兵路线越来越明显本周我最关注的现象是小模型在真实业务里的渗透速度。前两年大家默认效果好就得用大模型但这周看到的几个案例都在说经过认真微调的小模型在特定任务上完全够用而且成本优势是数量级的。一个典型的例子是某个文本分类场景原来每天调用云端大模型接口处理几十万条数据按 token 计费一个月下来是一笔不小的开支换成在本地用 7B 量级的开源模型做领域微调之后单条延迟从几秒降到几十毫秒并且可以把敏感数据完全留在内网。代价是前期要花一周左右的时间准备数据和调参但这个一次性投入和长期的调用成本比起来几乎可以忽略。这种精兵路线我觉得会是接下来半年很多团队的标配动作。2. 论文速读三篇值得花时间的工作本周我精读了三篇工作分别对应上面的三条主线。先把结论放在前面这三篇都不是那种改变世界级别的成果但都属于下周就能用上的类型所以我愿意把它们写进周报里。2.1 一篇关于稀疏注意力的工作把注意力拆成高频和低频这篇文章的思路是注意力分数矩阵并不是处处重要大部分 token 只需要关注邻近 token高频局部信息只有少量 token 需要看到很远的地方低频全局信息。于是作者设计了一个混合方案——局部用滑动窗口注意力全局每隔一定距离放一个锚点 token让信息通过锚点间接传播。实验做得比较扎实上下文从 8k 一路撑到 128k困惑度跟全注意力基线几乎持平但在需要精确位置定位的检索类任务上召回率有轻微下降。这个下降在我看来是可以接受的而且文章给了一个很实用的观察很多真实任务根本不需要精确定位到第几行第几列只需要知道大概在哪一段。我感兴趣的是这类方法可以直接用在现成的预训练模型推理期不需要重新训练这对部署侧来说是很大的吸引力。2.2 一篇关于数据配比的工作小模型的性能藏在数据菜单里这篇工作研究的是给定一个固定参数量的模型训练数据的配比到底该怎么定。结论看起来简单做起来并不简单——最优配比不是固定不变的而是应该随着训练进度动态调整前期多喂通用数据打基础后期多喂目标任务数据做定向强化。作者管这个叫课程式数据调度。有个实验数据让我印象很深在某个领域的分类任务上用动态配比配合困难样本增强和近重复数据去重只用原来 5% 的数据量就达到了原来 20% 数据量的效果。虽然这个结论在不同任务上的泛化程度还需要验证但数据菜单比模型结构更影响小模型上限这个观点我在这周自己的实验里也得到了印证后面第 3 节会细说。2.3 一篇关于评测饱和的讨论榜单分数涨不动之后怎么办第三篇不是传统意义上的技术论文更像一篇观点综述讨论的是公开评测基准的分辨力问题。作者的核心论点是现有基准的分数已经饱和头部模型之间的差距小于重跑几次实验的随机波动继续在平均分上较劲意义不大。他建议用两个替代指标一是分析失败案例的聚类看看模型系统性错在哪些类型的问题上二是记录模型的行为轨迹而不是只看最终答案对不对。我同意一半。对研究社区来说饱和的基准确实需要更新换代但对大多数业务场景来说平均分仍然是把候选模型缩小范围的第一道筛子直接抛弃榜单分数也不现实。比较理性的做法是用公开榜单做粗筛用自己业务数据的失败案例聚类做细筛。工作方向核心方法对推理复杂度的影影响最适合的场景稀疏注意力滑动窗口全局锚点 token近似线性显著降显存长文档问答、日志分析数据配比按训练进度动态调整数据比例只影响训练不影响推理小模型领域微调评测饱和失败案例聚类行为轨迹评估无模型选型、上线前评测3. 动手实验低资源环境下复现一次指令微调纸面上的东西聊完了说说我这周自己动手做的一件事在一张 24GB 显存的显卡上对 7B 量级的开源模型做了一次完整的指令微调。整个过程走下来我最大的感受是这套流程现在已经非常成熟真正决定效果好坏的不是模型结构而是数据处理和超参数细节。3.1 选型为什么选 7B 而不是更大首先说选型。13B 甚至 70B 的模型效果肯定更好但单卡 24GB 的显存放不下要么上多卡要么做激进量化前者增加运维成本后者影响微调稳定性。7B 配合 LoRA 这类参数高效微调方法可以比较舒服地塞进单卡训练和推理用同一套环境省掉很多部署上的麻烦。另外一个考量是迭代速度。微调是一个反复试错的过程数据改了要重跑超参数要对比如果一次训练要等一两天人很容易变得不愿意尝试新想法。7B 在单卡上的训练速度可以让我一天之内跑好几轮实验这个试错密度对最终效果的影响往往比模型本身大一两亿参数更重要。3.2 数据准备与关键超参数这次微调我用了约 2 万条指令数据其中约 5000 条是领域相关的业务数据剩下的是从公开指令数据里清洗出来的通用数据。数据处理这一步我花的时间比训练还多几个关键操作供参考去重文本层面用 n-gram 指纹去重语义层面用嵌入向量做近重复过滤这一步能明显减少训练时的过拟合。过滤噪声把包含乱码、HTML 标签、过短无信息量的样本全部剔除。配比调整基于前面读到的那篇数据配比论文我把领域数据放在训练的后半段模拟先打基础再学业务的课程式调度。训练配置如下基于常见实践供复现参考base_model: 7B_open_weight_model method: lora lora_rank: 64 lora_alpha: 128 lora_dropout: 0.05 trainable_modules: [q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj] dataset: total_samples: 20000 domain_samples: 5000 mix_strategy: curriculum_switch_at_60_percent training: batch_size: 128 # 按序列条数计梯度累积 8 步 max_seq_len: 2048 learning_rate: 2.0e-4 lr_scheduler: cosine warmup_steps: 200 epochs: 3 eval_strategy: held_out # 用业务留出集不用训练集样本 optimizer_state_save: true scheduler_state_save: true3.3 训练过程的几个观察训练曲线整体比较平稳但我注意到两个值得圈出来的点。第一个是 loss 的下降不是均匀的。前 30% 的 step 里 loss 掉得很快之后进入平台期而领域数据的 loss 在切换到课程式配比后才开始明显下降。这说明模型先学会了通用的语言模式和指令格式之后才有余力吸收领域知识这个顺序和我预期的是一致的。第二个是过拟合风险。跑完第 2 个 epoch 的时候训练 loss 还在往下走但留出集上的指标已经开始震荡。我用留出集监控了每个 checkpoint最后选了第 2 个 epoch 中段的 checkpoint 而不是最后一个。很多第一次做微调的人会直接拿最后一个 epoch 的模型上线然后发现泛化不行这个坑挺常见的。3.4 评测结果与下一步留出集上的结果比预期好领域分类任务的 F1 从基座模型的 82.1% 提升到了 91.5%生成类任务的格式正确率从不到 60% 提到了 88% 左右。虽然离云端大模型还有差距但对内部业务来说已经够用而且响应延迟降到了原来的几十分之一。下一步我打算把领域数据从 5000 条扩充到 1 万条再对比一下课程式配比和均匀混合配比的差距进一步验证那篇论文的结论在我这个场景下是否成立。4. 推理加速与部署侧的实战观察微调完之后我顺手把模型接到了推理服务里这个过程同样踩了几个值得记录的坑。推理优化这个领域纸面上讲的全是吞吐延迟量化这些词实际操作里全是琐碎但致命的细节。4.1 量化方案的取舍我先试了常见的 8-bit 权重量化效果很稳精度几乎没有可感知的损失。接着试了更激进的 4-bit 量化大部分任务也没问题但长文本生成任务上出现了明显的质量下降——具体表现是生成到后面开始重复、逻辑连贯性变差。这个现象在社区里也有不少人提过量化对长序列生成的影响比对短问答的影响更大可能跟量化误差在自回归过程中逐步累积有关。最后的取舍是短推理任务用 4-bit长生成任务换回 8-bit显存不够时优先砍并发而不是砍量化精度。下面是量化前后我在相同负载下的实测对比单卡 24GB、相同模型方案显存占用吞吐请求/分钟长文本质量短问答质量未量化接近打满基准基准基基准8-bit省约 35%提升约 40%几乎持平几乎持平4-bit省约 60%提升约 80%明显下降轻微下降4.2 批处理配置吞吐翻倍的关键刚开始我把推理服务配成单请求模式一次只处理一个用户的输入显存利用率低得可怜。后来改成动态批处理——把一定时间窗口内到达的请求攒起来一起送进模型——吞吐直接翻了一倍以上。这里的关键参数有三个最大批大小、最大等待时间和最大序列长度。前两个好理解第三个容易被忽略如果 max_tokens 设置得过大每个请求都会预留超长的 KV cache显存会被虚占导致实际能并发的请求数变少。我的建议是先统计线上请求的 p95 生成长度把 max_tokens 设置在 p95 加上一个较小的余量而不是直接给一个很大的上限。这个调整往往比优化模型本身带来的收益还直接。4.3 一个反直觉的坑预热与显存碎片推理服务上线后我注意到一个诡异的现象服务刚启动的头几十个请求特别慢之后才恢复正常。一开始以为是模型加载的问题后来才发现是 CUDA 图和相关内核在首次调用时才完成编译也就是冷启动延迟。解决办法很简单服务启动后先跑一小批假请求把路径预热再对外开放流量。另一个坑是显存碎片。跑了一段时间后明明总显存还有剩余新的请求却报 OOM。原因是长请求和短请求交替到达KV cache 的申请和释放把显存切成了碎片。解法是限制单请求的最大序列长度、提前分配好缓存空间以及定期做一次显存整理。这两个问题都属于不跑线上根本不会发现的类型写出来给大家避避雷。5. 社区讨论与争议复现难、评测饱和与炼丹焦虑这周社区里几个讨论帖的楼都盖得很高我选了三个最有共鸣的话题聊聊。5.1 开源复现的差距到底从哪里来有一个帖子在问为什么我用同样的方法、同样的数据量复现出来的效果总比论文里低一截评论区吵了很久最后沉淀下来的共识是差距主要不在模型结构而在数据。论文通常不会公开完整的清洗流程、过滤规则和数据配比而这些细节对最终效果的影响非常大。我自己也有过类似经历同一个训练脚本换了数据清洗的顺序F1 能差两到三个点。所以我现在养成了一个习惯——把数据处理的每一步都记录成配置文件包括去重阈值、过滤规则、配比比例甚至跑了哪个版本的框架。记录这个动作本身不产生效果但出了问题能定位这才是它的价值。5.2 评测指标饱和之后看什么另一个讨论帖子的核心问题是当所有模型在公开榜单上都超过 95% 的时候我们还能怎么选模型评论区的高赞回答给了个非常实操的建议把选型评测改成错误聚类。也就是拿候选模型分别跑同一批业务测试集把预测错误的样本按失败模式聚类看每个模型系统性错在哪——有的模型是数字计算容易出错有的是长尾实体识别不行有的是格式不稳定。做完错误聚类之后选哪个模型就变成了一道业务题而不是一道排行榜题。我觉得这是这周看到的最有迁移价值的方法论。它本质上是把看平均分换成了看失败模式更贴近真实上线前的选型需求。5.3 关于炼丹焦虑的一点想法第三个帖子不是技术讨论而是一种集体情绪的宣泄开源社区每周都有新模型、新技术总觉得不追就落后了。我在这个帖子里回复了一段话也放在这里分享追新是好事但要区分新和重要。绝大多数新 release 只是把过去的技术重新组合了一遍真正的新范式一年也就出现一两次。把时间花在把已有方法吃透比每周跟着换模型更划算。我自己衡量信息摄入质量的标准很简单这篇内容能不能让我在未来的实验里少踩一个坑或者多一个可复现的方案。如果一个内容只是有个新东西出来了那我顶多收藏一下不会花整块时间去跟。6. 本周踩坑记录与下周计划最后按周报惯例记录这周最想吐槽的两个坑以及下周的安排。6.1 数据加载器拖垮了整轮训练第一个坑是在一次训练中发现的GPU 利用率只有不到 60%训练速度远低于预期。一开始怀疑是模型并行配置有问题排查了半天发现根源在数据加载——加载器把数据读到 CPU 内存后没有做好预取GPU 每一步都在等数据。把加载进程数调上去、加上预取和内存映射之后GPU 利用率直接回到 95% 以上。这个坑给我的教训是开始大训练之前先花十分钟单独测一下数据管线的吞吐确认瓶颈不在数据侧再开跑。很多人一上来就盯着 loss 曲线看GPU 空转半天也没发现白白浪费时间和电费。6.2 学习率调度状态没保存恢复后 loss 飙升第二个坑和断点恢复有关。训练中途断了一次我从 checkpoint 恢复继续跑结果 loss 从 1.4 直接飙到 2.1整个训练直接废掉。排查后发现原因很蠢保存 checkpoint 时只保存了模型权重和优化器状态没有保存学习率调度器的状态。恢复之后学习率回到了初始值相当于用一个很大的学习率去继续训练已经收敛的模型loss 自然爆炸。修法也很简单保存状态时把调度器状态一起带上恢复时一并加载# checkpoint 保存时 torch.save({ model: model.state_dict(), optimizer: optimizer.state_dict(), lr_scheduler: scheduler.state_dict(), global_step: global_step, }, ckpt_path) # 恢复时 ckpt torch.load(ckpt_path) model.load_state_dict(ckpt[model]) optimizer.load_state_dict(ckpt[optimizer]) scheduler.load_state_dict(ckpt[lr_scheduler]) global_step ckpt[global_step]做完这步之后从断点恢复的训练曲线和连续训练的曲线几乎完全重合。这个坑很基础但也很容易在忙乱中漏掉写出来提醒自己也提醒读者。6.3 下周计划下周给自己安排了三件事第一复现第 2 节提到的那篇稀疏注意力工作重点测它在推理端的实际加速比和长文本质量变化第二把领域数据扩充到一万条再跑一轮课程式配比的对照实验第三写一个自动化的错误聚类评测脚本把失败案例聚类这套方法固化下来以后每次模型选型都能用。按我个人经验深度学习这行最稳定的复利就是把每一周的踩坑和验证沉淀成自己的实验台账。技术迭代再快这些台账里的判断力和操作习惯都不会过时。下周周报见。