这周（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 一篇关于评测饱和的讨论：榜单分数涨不动之后怎么办

第三篇不是传统意义上的技术论文，更像一篇观点综述，讨论的是公开评测基准的分辨力问题。作者的核心论点是：现有基准的分数已经饱和，头部模型之间的差距小于重跑几次实验的随机波动，继续在平均分上较劲意义不大。他建议用两个替代指标：一是分析失败案例的聚类，看看模型系统性错在哪些类型的问题上；二是记录模型的行为轨迹，而不是只看最终答案对不对。

我同意一半。对研究社区来说，饱和的基准确实需要更新换代；但对大多数业务场景来说，平均分仍然是把候选模型缩小范围的第一道筛子，直接抛弃榜单分数也不现实。比较理性的做法是：用公开榜单做粗筛，用自己业务数据的失败案例聚类做细筛。

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: true

3.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、相同模型）：

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 节提到的那篇稀疏注意力工作，重点测它在推理端的实际加速比和长文本质量变化；第二，把领域数据扩充到一万条，再跑一轮课程式配比的对照实验；第三，写一个自动化的错误聚类评测脚本，把"失败案例聚类"这套方法固化下来，以后每次模型选型都能用。

按我个人经验，深度学习这行最稳定的复利，就是把每一周的踩坑和验证沉淀成自己的实验台账。技术迭代再快，这些台账里的判断力和操作习惯都不会过时。下周周报见。