2026年10月cs.LG论文风向：推理成本与模型小型化成焦点

月初固定会做一件事把 arXiv cs.LG 新挂出来的论文整个过一遍。2026 年 10 月 1 日这批稿子正好赶在假期前后投稿量比平时少了一截但整体质量不低。我花了两个晚上把摘要逐条扫下来挑出几个值得关注的方向顺手整理成这份汇总。这篇内容不只是罗列论文名字而是把我自己筛论文、判断价值、再动手复现的完整思路一并讲清楚。无论你是在校研究生、准备开题还是已经在一线做算法落地这篇应该都能帮你少走点弯路。老规矩先给结论这波投稿里和推理成本、模型小型化、数据选择相关的工作占了很大比例扩散模型依然活跃但重心已经从“画得漂不漂亮”转向“怎么更好控制”大模型智能体方向的论文数量明显增加不过真正能复现出理想效果的还是少数。后面我会逐个方向拆开说也会把实际操作中遇到的各种细节问题摊开来讲。1. 这波论文的整体风向从标题能读出什么每次批量扫论文我习惯先不看正文只看标题和摘要的用词。标题往往能反映一个阶段研究者的集体焦虑和产业需求。10 月 1 日这批 cs.LG 投稿里有几个信号非常明显。第一和推理成本相关的关键词明显变多。量化、投机解码、KV Cache 压缩、推测解码、早期退出这类词出现的频率比三个月前高了不少。说明大家已经不太满足于“把模型训出来”而是更关心“把模型跑起来要花多少钱”。第二小模型方向持续升温。很多工作在做大模型蒸馏到小模型、稀疏化、结构搜索这类事情目标很直接用更小的参数拿到接近大模型的效果。第三评测和对齐方向也在增加。自动评测框架、红队测试、安全对齐、偏好优化这些原本偏 NLP 的内容现在大量出现在 cs.LG 板块里。我自己的判断是整个领域正在进入一个“深水区”。前几年比拼的是模型上限谁参数量大谁厉害现在比的是在有限算力预算下谁能把效果和成本平衡好。这种转变也体现在投稿的工作类型上——应用型、工程型的论文越来越多纯理论推导的反而相对减少。对做工程落地的人来说是好事对想做理论研究的同学来说则意味着要更主动地去筛选。1.1 关键词热度与投稿变化我自己有个很粗糙的统计方式把这批论文的标题和摘要摘下来按关键词做归类。样本不算科学但作为个人观察足够用了。下面这个表是我统计 2026 年 10 月 1 日这批 cs.LG 论文里几个主要关键词的分布情况。关键词类别出现频率相对占比对比上一个月的趋势模型压缩与量化18% 左右明显上升训练策略与优化器15% 左右基本持平多模态与生成模型14% 左右小幅下降强化学习与智能体13% 左右明显上升理论、可解释性与表征学习12% 左右基本持平评测、对齐与安全11% 左右上升其他数据处理、元学习等17% 左右略有波动这个分布和我平时关注的方向基本吻合。模型压缩和量化类工作占比冲到第一位说明产业界的推动力确实很强。很多公司现在的处境是手里有一个效果不错的开源大模型但显卡不够或者单卡放不下所以迫切需要在部署端做文章。量化、蒸馏、结构剪枝这类技术正好卡在这个痛点上。值得多说一句的是强化学习与智能体方向的上升。这个趋势已经持续了好几个月但 10 月这波尤其明显。早期的大模型智能体工作大多停留在“给模型加个 ReAct 式 prompt让它会调工具”的层面现在已经深入到训练阶段比如用强化学习直接优化 agent 的决策策略。这背后有一个很现实的问题大模型本身很会聊天但“会干活”是另一回事。干活需要试错、需要反馈、需要把多步动作串联起来这些都是典型的强化学习问题。1.2 为什么会呈现这个风向说到底研究方向的迁移背后是资源约束。我自己在多个项目里都有体会训一个大模型的成本现在已经不是单个团队能随便扛下来的反过来部署一个大模型到生产环境推理成本同样让人头疼。于是大家不约而同转向两个方向——把模型变小或者把推理变快。这个逻辑在论文标题里看得很清楚。比如某团队投了一篇关于小模型蒸馏的工作核心做法是用大模型生成的高质量数据来微调一个小模型同时在训练中加入“拒绝采样”来过滤低质量样本。这个工作没有特别花哨的理论创新但对很多预算有限的团队来说可能比一个刷榜的大模型更实用。还有一篇关注量化感知训练的文章不是简单地在训练后做 PTQ而是把量化误差直接纳入训练过程的损失函数这种做法我在实际部署中试过效果往往比事后补救稳定得多。另外一个容易被忽略的因素是数据。高质量文本数据越来越难获取很多团队开始用合成数据、数据筛选、数据配比来做文章。这个月有几篇论文专门讨论数据选择策略比如通过梯度相似度判断哪些样本对当前训练最有帮助或者用一个小模型做数据质量打分器。这些工作看似“软”实际对训练效果的影响非常直接。我见过不少项目模型结构没变只是换了数据清洗和配比方式最终指标涨了一两个点这种情况在工业界相当常见。所以这波风向给我的整体感受是大家都在想办法“省着用钱”模型压缩、推理加速、数据提纯本质上都是为了让每一分算力、每一份数据发挥更大价值。2. 值得细读的几个方向与核心技术点看论文不能只看标题得知道这方向解决什么问题、核心难点在哪、值不值得自己花时间跟。这个月我重点跟了四个方向推理加速、扩散模型的新构型、大模型智能体、以及理论层面关于数据和规模法则的讨论。下面逐个拆开讲。2.1 推理加速量化、投机采样与缓存优化推理加速类工作的核心目标很简单在尽量不损失质量的前提下让模型响应更快、占用显存更少。10 月这批论文里我感觉最有落地价值的是三个技术点。第一是低比特量化尤其是 2 到 4 bit 的权重量化和激活量化。量化原理说穿了不难模型权重通常用 FP16 或者 BF16 存储数值精度高但占空间大。如果能把权重映射到整数范围内显存占用直接除以 4 甚至除以 8。难点在于量化误差对模型质量的影响。现在的做法已经不只是“算完再量化”而是把量化误差模拟到前向计算中让模型在训练阶段就适应低精度表示。这种量化感知训练的思路实际效果往往远好于事后量化我后面复现部分会详细说。第二是投机采样。思路非常巧妙先让一个又快又小的小模型草稿生成一串候选 token再用大模型一次验证多个 token 是否正确。因为验证是并行的所以大模型实际调用次数大幅减少整体推理速度能提升 2 到 3 倍。这个方向的问题在于草稿模型的质量直接决定了加速比如果小模型和大模型的分布差异太大反复拒绝重来反而更慢。所以这个月的论文里我看到有人尝试在推理过程中动态调整草稿模型的采样温度也有人尝试用多个草稿模型投票。这些都属于工程细节上的打磨但很实用。第三是 KV Cache 压缩。在大模型推理时每生成一个 token 都要带上之前所有 token 的 Key 和 Value 信息这部分缓存随序列增长线性膨胀成为长文本场景的主要瓶颈。这个月的论文里有做 Cache 淘汰策略的有对 KV 做低秩近似的也有把 Cache 量化到 2 bit 的。我个人比较看好低秩近似方向因为它在理论上能给出误差界而不是简单的“用着试试”。为什么这类论文最值得读因为它们的共同特点是“可以直接抄作业”。量化代码通常能直接改改上线投机采样可以和现有的服务框架集成KV Cache 压缩对做长文本应用的人来说几乎是刚需。相比之下纯理论方向的论文虽然也很重要但落地周期长不适合每个人投入精力。2.2 扩散模型的新构型从单向生成到统一生成框架扩散模型的热度这几个月略有下降但 10 月这批论文里依然有不少值得细看的。和早期“只要生成图片质量高”不同现在大家更关注怎么让生成过程可控、可加速、可统一。一个明显趋势是“一致性模型”的变体。传统扩散模型需要几十步甚至上百步迭代去噪推理速度很慢。一致性模型试图让任何一个带噪样本都能直接映射到干净样本从而实现一步生成。这个月的论文里有工作把一致性训练和目标函数重新设计在保持一步生成的前提下让生成质量接近几十步的完整扩散模型。我看了下他们的采样可视化效果确实比前几代一致性模型好不少。这类工作的价值在于如果推理步数真能压到 1 到 2 步扩散模型用在实时交互场景就不再是奢望。另一个方向是多模态的统一生成框架。以前做文生图、文生视频、图生文都是各搞一套模型这个月有几篇论文尝试用一个统一的架构把这些任务全部包进来。核心思路是把不同模态的数据都编码成离散 token然后用一个序列模型统一建模。这个思路本身不算新但这次看到的实现细节更成熟了比如对不同模态的 token 分配不同的位置编码以及如何平衡多模态数据的训练比例。说实话这种大一统框架短期内有工程风险但长远看方向是对的。我对扩散模型未来的判断是单模态的生成质量已经接近瓶颈接下来拼的是“控制力”和“速度”。如果你做的是内容生成类应用建议重点关注可控生成和加速这两个技术点而不是继续追求更大的生成模型。2.3 大模型智能体把“会聊天”变成“会干活”大模型智能体是我个人最关注的方向之一也是 10 月这批论文里数量增长最明显的板块。但要先泼一盆冷水这个方向论文多水分也大。很多工作只是把大模型接到一个工具列表上跑几个 case 就宣称是 agent这种不太值得花时间。真正有价值的智能体工作核心在解决几个实际问题。第一多步决策的稳定性。大模型在单步指令下表现很好但一旦要连续执行多步操作很容易出现“忘了上下文”“重复执行”“偏离原目标”这类毛病。有篇论文提出了一个记忆管理模块把短期记忆和长期记忆分开短期记忆负责当前任务的步骤追踪长期记忆负责跨任务的策略积累。这种思路在复杂项目中非常实用。第二从环境反馈中学习。智能体执行完一个动作后环境会返回成功或失败这种反馈是稀疏的。有篇工作使用一个独立的奖励模型来给中间动作打分然后用强化学习更新策略而不是等最终结果出来再统一给奖励。这种“过程奖励”的设计能很大程度上缓解稀疏奖励问题。不过说实话这类方法的训练成本很高需要大量带中间标注的轨迹数据一般团队不一定有资源复现。第三多个智能体协作。这个方向 10 月也有几篇不错的论文。核心问题是如何让多个 agent 之间高效通信、任务分工和结果汇总。有篇论文把 agent 之间的消息传递建模成一个小型协议用结构化消息而不是自然语言来降低通信开销。这个想法很有意思实际项目里我们遇到过类似问题——多个 agent 之间用自然语言对话上下文长度爆炸而且容易互相误解。结构化消息确实是个可行的出路。我的建议是如果你是做应用的同学智能体方向可以关注但千万别被 demo 视频迷惑。选择论文时尽量找有开源代码、有标准评测集的工作自己跑一遍看效果再判断价值。2.4 理论进展必不可少但更挑读者cs.LG 板块毕竟是机器学习理论的重要阵地10 月也有一批不错的理论文章。虽然这类论文不如应用方向那么“好读”但对你理解模型行为、判断方法上限很有帮助。这个月我看到比较有意思的是几篇关于规模法则的讨论。传统观点是“模型越大、数据越多效果越好”但这批论文开始在更精细的维度上研究数据质量如何影响规模法则的斜率在固定算力预算下应该优先加参数还是加数据有没有可能通过数据筛选让一个中等规模的模型追上一个大规模数据集训练的大模型这些问题的答案对实际训练资源配置有直接指导意义。另一块是数据影响分析。有篇论文提出了一种高效估计“某个训练样本对模型输出有多大影响”的方法。以前做数据清洗只能靠人工经验现在可以通过这种影响力分数自动找出“有毒样本”或者“最核心样本”。我在自己项目里试过类似思路发现它能有效缩小需要人工检查的数据范围比盲筛高效得多。不过我要提醒一句理论类论文的门槛确实存在如果基础不扎实不建议硬啃。可以先看引言和实验部分理解“它验证了什么规律、发现了什么现象”把推导证明留到以后需要时再看。做应用的人不需要完整推导每个定理但应该建立“理论能指导实验直觉”的意识。3. 从“看过”到“跑通”论文筛选与复现实操读论文本身只是第一步。我一直跟团队里人说一篇论文只有真正跑通了知识才算内化成自己的。10 月这批论文我不是全部复现但挑了几篇重点跟进了。下面这套流程是我个人从踩坑里总结出来的适合想做复现的同学参考。3.1 我筛选论文的一套流程我的筛选流程大概分四步整个过程控制在半天之内。第一步标题过滤。先把所有标题扫一遍淘汰明显和自己方向无关的比如纯 NLP 的语义解析、纯 CV 的低级视觉任务只留下生成模型、强化学习、模型压缩、表征学习这几类。这一步能把几百篇压缩到几十篇。第二步摘要分级。把剩下的论文摘要逐篇读一遍按“值得精读”“值得泛读”“暂时搁置”分成三档。判断标准很简单这个方法是否能解决我正在头疼的问题是否提出了一个我能理解的新思路是否有开源代码如果三者都不沾直接进“暂时搁置”。第三步代码仓库检查。对于“值得精读”的论文我会去查它对应的代码仓库。只看三点仓库最近有没有更新、readme 是不是写清楚了环境和运行命令、issue 区有没有人讨论复现问题。如果仓库内容残缺或者长期没人维护这篇论文的价值就要打折扣。第四步优先级排序。根据“投入产出比”排序——投入是复现需要的时间和算力产出是这项技术对我的项目可能带来的提升。比如低比特量化我的应用场景里显存严重不够那排序就靠前一些超大模型的世界模型类工作虽然有意思但我现有条件根本跑不起来排序就靠后。这套流程帮我省了很多时间。说实话绝大部分论文不需要完整阅读能把前言、方法概览和实验结论看明白就够了真正值得精读加复现的一个月有四五篇已经很不错了。3.2 复现前的准备工作与配置建议确定了要复现哪篇论文后先别急着 clone 代码。我吃过不少亏环境配到一半发现缺依赖、下载数据集的时候才发现网络不通、跑完才发现自己的 GPU 显存不够。所以现在复现前一定会强制自己先做一轮准备。环境方面我一般用 conda 新建独立环境避免污染其他项目。官方仓库如果给了 environment.yml直接用它没有就手动装 PyTorch 和对应 CUDA 版本。一个重要忠告PyTorch 版本不要自己随便改。很多论文代码在新版本 PyTorch 上会有一堆 API 兼容问题旧版本反而跑得好好的。配置方面我的建议是“先小后大”。先用最小可运行配置跑通官方示例确认代码和模型权重没问题再逐步放大到完整实验。下面这表是我自己常用的起步配置参考不同任务差异很大仅供参考。任务类型最低显存参考建议起步配置跑通一个小规模验证大概要多久中小模型微调24 GB 单卡单张 RTX 40902 到 6 小时7B 到 13B 模型 LoRA 微调24 GB 单卡单张 4090 或 A100数小时到 1 天7B 到 13B 模型全参微调80 GB 单卡单张 A100/H1001 到 3 天大模型量化推理实验24 GB 单卡单张 4090 即可测出效果半天内强化学习智能体训练小场景48 GB 以上双卡 3090 或单卡 A1001 到 2 天注意这个配置只能保证“把流程跑通”不代表能复现论文里的完整结果。论文里的完整实验往往动用了几十张甚至上百张卡跑了几周甚至几个月单卡复现主要是在验证方法和理解细节这个心态要摆正。3.3 跑通一篇论文的核心步骤我把复现过程拆成六个标准动作按顺序执行基本不会乱。第一步搭环境。按照官方文档把环境、依赖、预训练权重都准备好。如果仓库里没有权重下载脚本我会用git lfs从镜像站拉或者找第三方仓库的转换脚本。这个阶段慢一点没关系把底子打好。第二步跑最小示例。先在本地用最小参数量、最简数据跑通训练或推理脚本。这一步的目标是确认代码链路没有硬伤而不是追求效果。我见过很多人在这一步卡住好几天结果最后发现只是路径写错了。第三步复现核心指标。找到论文里最主要的实验表比如某个 benchmark 上的得分把官方命令和超参原封不动跑一遍。这里常见的问题是显存不够那就只能调小 batch size同时适当调大梯度累积步数保持等效 batch size 不变。第四步替换数据或场景。论文能用不代表你的场景能用。把论文里的公开数据换成你自己领域的数据跑一次看效果是否依然成立。这一步最有价值因为能真正检验方法的泛化性。第五步做消融实验。把论文里提到的关键模块逐个移除看指标怎么变。一般稍微正规点的论文都有消融实验表你把那几个关键开关切换一下能显著加深对方法本质的理解。第六步记录复现笔记。很多人忽略这一步我觉得它比跑通本身更重要。把环境配置、关键命令、遇到的报错和处理方式全部记下来。三个月后你需要回头用这个技术时笔记能帮你节省大量重新摸索的时间。3.4 对比实验与基线选择复现不仅仅是为了“跑通”更要学会怎么“比”。我在团队里经常要评审新方法的效果发现很多人在对比实验上做的很不严谨导致结论没有参考价值。核心就一句话控制变量。对比方法 A 和 B除了你想比较的那个因素其他所有设置必须完全一致。比如你对比量化前后模型效果那就必须用同一个预训练权重、同一个评测集、同一个解码参数。有个常见坑是论文新方法用了贪心解码基线方法却用了温度采样这对比出的差异根本说不清是方法带来的还是解码策略带来的。另一个坑是随机种子。深度学习充满随机性跑一次的结果不能代表真实水平。我的经验是至少跑三个不同种子取平均值和标准差。如果某篇论文只给了一个种子下的结果那它的可信度就要打个问号。另外对比实验时要尽量选择有代表性的基线。很多人喜欢拿一个很弱的基线来衬托自己方法的优势这样得出的结论在发表时能过审但对实际选型没有参考价值。我一般会选“最近一年内被广泛使用的开源方法”作为基线这样得出来的结论才真正有用。4. 复现这些论文时踩过的坑一份问题速查接下来这部分是干货中的干货。我复现论文踩过的坑比很多论文的附录还厚。这里挑几个典型的给你做个参考。4.1 数据预处理不一致导致的“虚假提升”这是个很隐蔽的坑。有次我看到一篇论文声称在某个任务上提升了 3 个点兴冲冲去复现结果怎么都到不了论文效果。后来我逐行对比了它的数据处理代码发现它在预处理时多做了一步去重过滤掉了大量重复样本。等我加上这一步指标立刻就上去了——但这个提升和论文提出的新模块毫无关系纯粹是数据清洗方式不同带来的。这次的教训让我做了个习惯复现任何论文第一件事先看数据预处理代码和论文描述是否一致。很多论文在这块写得很模糊只用一句“我们使用标准的数据清洗流程”带过实际代码里却藏了不少关键处理。如果你发现数据处理和基线不一致别急着信实验结论先修正这个问题。4.2 超参数缺省与版本不一致超参数是复现里的重灾区。很多论文只给了模型结构上的一些参数但训练细节里的 weight decay、warmup steps、学习率调度方式、梯度裁剪阈值经常藏在代码里而不是论文里。更坑的是有时候代码里的默认参数和论文写的根本不一样。我遇到过最离谱的一次一篇论文的方法描述里写的是“使用 0.1 的 dropout”代码注释里也写了 0.1但配置文件里的实际值却是 0.05。这种不一致你要是直接跑默认配置可能从起点就偏了。所以建议拿到代码后先把所有超参数列出来和论文一一核对特别是那些没有在论文正文里出现的参数。还有一个容易忽略的点是代码版本。很多人复现时直接 clone 最新代码但论文实验用的可能是某个历史 commit。万一后来有人改了代码修 bug你复现出的结果可能和论文完全对不上。现在我看到有意思的论文第一件事是提交时的 commit 编号有没有写在某个地方没有的话就看代码里的版本字符串或 README 里的更新时间尽量用论文时代的代码。4.3 评测代码不一致与指标口径训练没问题不代表复现成功评测才是最后一关。不同论文对同一个指标的评测方式可能有细微差别而这些差别会对结果产生很大影响。拿生成任务举例同样用 BLEU 指标有的论文对生成结果做了分词后再计算有的直接用 open-source 库算有的论文设置了 max_new_tokens 限制有的没有有的按句子为单位计算有的按段落计算。这些听起来都是小事实际差异可以达到几个点。我建议复现时一定使用论文作者提供的评测代码而不是自己另找一套实现。还有一个坑是“参考输出的归一化”。有些文本评测代码会把数字、大小写、标点全部归一化后再比较有些不会。你要是没注意这个细节很可能误判自己方法的真实水平。4.4 假开源与半开源怎么识别论文开源越来越普遍但开源的“诚意”差别很大。有些标着开源实际只放了个 README 和几张截图连代码文件都没有有些放了一部分推理代码但核心训练代码缺失有些代码和权重是齐的但需要特殊硬件才能跑起来。我的识别经验如下。只给权重不给代码或者只给代码不给权重的先默认当“半开源”处理除非论文里详细描述了所有细节。仓库里的 readme 如果没有任何运行命令、没有环境说明大概率是随手传的质量和可复现性都存疑。看 issue 区和 commit 历史。如果作者会在 issue 里回答复现问题说明这个项目在维护如果一年前的 issue 都没人回跑通了也尽量自己多留个心眼。特别警惕那些“只开源缩略版”的论文。比如自己在完整数据集上刷到了高分但开源的只是一个小规模玩具版本现象能复现但绝对跑不出论文指标。这种情况不算造假但水分很大。4.5 排查问题速查表最后给你一个我在项目中一直用的排查表。遇到问题先按这个顺序自查绝大多数坑都能定位到。现象可能原因排查方法解决思路显存不足batch size 太大 / 序列太长逐步减小 batch size观察显存变化减小 batch、开梯度累积、用梯度检查点训练 Loss 不下降学习率不合适 / 数据加载错误打印首几个 batch 的输入输出调整学习率、检查数据预处理、确认 label 对齐复现指标明显偏低超参不一致 / 评测方式不同逐项核对论文和代码参数统一超参、使用官方评测代码推理速度极慢量化配置没生效 / 模型跑在 FP32打印模型 dtype 和显存占用强制模型半精度或 int8 推理偶发崩溃数据存在脏样本 / 并行策略问题关闭多进程逐步排查清洗数据、调整 DataLoader 参数多卡训练时指标波动大批次大小和单卡不一致 / 同步有问题对比单卡和多卡的 loss 曲线固定种子、扩大热身步数、统一梯度累积策略这张表不是万能的但覆盖了 80% 的常见问题。剩下 20% 的“玄学问题”往往需要回退到最简版本逐行加回模块定位出是哪部分代码引入了问题。这个月刷完这批论文我最大的感受是能动手复现的论文越来越“值钱”了。很多工作虽然标题响亮但代码一摊开细节经不起推敲反过来那些代码清晰、超参齐全、能顺利跑通的论文哪怕创新点不大反而最可能在你的项目里产生实际价值。最后分享一个自己的小习惯我每个月会建一个“当月论文”的收藏夹里面按“必读”“可选”“暂时搁置”三个标签分类同时用标签记录每篇论文的复现状态。凡是我觉得值得跑的仓库都会先 fork 一份到自己名下防止作者删库或者改动。再有个小技巧特别想跑一篇论文的时候先去它的 issue 区翻一圈如果看到有人问过和你相同的问题那这篇论文的坑十有八九就在那几条 issue 里。我的经验是作者回复越积极的仓库复现成功率越高反之就要做好自己慢慢折腾的准备。论文这碗饭不在于你收藏了多少篇而在于你真正跑通了多少篇。读透一篇能落地的远好过收藏一百篇标题好看的。