1. 假期里不降温：2026年10月4日的几件AI圈小事

写AI日报这几年，我越来越觉得真正值得记录的，不是那些刷屏的爆款新闻，而是评论区里被人反复追问的细碎问题。2026年10月4日这一期，正好赶上假期尾巴，圈内动作却不少。这期我不打算平铺时间线，只挑三条真正影响日常使用体验的进展，把背后的技术逻辑和落地教训聊透。如果你也是每天追AI资讯的人、在本地折腾模型的玩家、或者刚入行想用AI提效的创作者，这期内容能帮你省下不少检索时间。

先说今日概览。青鸾社区放出了一个代号Dora-3B的轻量多模态模型，主打图像理解、语音输入和文本生成三合一，普通消费级显卡就能跑起来。一个叫灵石网络的小团队则开源了一套“模型路由层”参考实现，目标是帮团队把多个模型API统一到一套网关下面，按场景自动分包。某高校实验室同时公开了长文本细粒度评估集LongCheck-12K，专门用来检验模型在超长文档里找证据链的能力。三件事表面看互不相干，实际指向同一个信号：大家已经不再比谁的参数多，而是比谁的方案更省心、更容易落到日常工具链里。

1.1 青鸾社区的Dora-3B：把多模态门槛又压低了一截

Dora-3B是一个30亿参数规模的多模态模型，支持图文混合输入，简单说就是给模型一张截图、一段语音、一段文字，它能理解并回答问题。这个参数级别放在两年前只能做纯文本，现在却把视觉和语音一起塞了进去，靠的是对齐蒸馏技术：先用一个更大的7B级教师模型在海量数据上学习，再把教师模型的输出分布“教”给3B的小模型，相当于让一个经验丰富的老法师带新人，新人不需要读万卷书也能学到处理问题的手感。

开源权重和量化版本同步放出。我查了一下，INT8量化后模型约5.8GB显存占用，中端的16GB显卡能比较从容地跑起来，甚至可以同时挂上浏览器做截图解析。我拿到后第一件事是拍了三张带表格的截图喂进去，让它输出Markdown格式，结果表格边框和合并单元格都还原得不错，偶尔会有列错位，但整体可用。语音输入这块支持中文和英文短句识别，环境噪音大一点的时候也能听懂指令，只是对长语音的分段处理还需要外部工具配合。

我觉得这个模型真正的价值不在单点能力多强，而在于把“看图说话”这件事的门槛拉到了笔记本级别。以前想跑多模态，要么走云API，要么得准备大显存显卡，沟通成本很高。现在本地跑一个3B模型，至少可以胜任截图转结构化笔记、视频抽帧问答、扫描件粗排等高频场景。当然它也有明显短板，复杂数学推理和深度多轮对话仍然吃力，这部分后面我会专门展开说。

1.2 灵石网络的模型路由层：解决多模型切换的隐性成本

很多团队现在的状态不是没有模型可用，而是模型太多、选择困难。今天这个任务该用轻量模型还是大模型？图片理解走哪个接口？供应商A限流了要不要切到供应商B？如果都靠开发者在代码里写死，每次换模型都是一次发布流程，成本非常高。灵石网络这次开源的路由层，思路很直接：让业务侧只面对一个统一入口，由网关根据请求内容自动决定把任务分给哪个模型。

这套参考实现放在蓝鲸社区仓库里，包含一个轻量意图判断模块、一个模型供应商适配层和一个请求/响应日志模块。意图判断不是简单看关键词，而是先把用户请求转成向量，再用一个小分类器区分“简单问答”“长文写作”“图像理解”“代码生成”等类型，然后按提前配置的策略列表决定路由目标。整个链路不算复杂，但把以前散落在业务代码里的切换逻辑集中收口了，后续加新模型只要改配置不用改业务。

按照灵石网络给出的估算，这种路由方式配合成本优先策略，能在不明显降低回答质量的前提下，把多云API的综合开销压低30%到50%。我没有做严格的A/B测试，但把一组真实业务请求回放跑完之后，体感上确实有一半的请求被分到了轻量模型，响应速度快了不少，只有长文档总结和复杂分析才会触达大模型。对中小团队来说，这个方向比单纯追求某个模型的能力更值得投入。

1.3 LongCheck-12K：长文本评测开始较真了

同一天，某高校实验室开源了LongCheck-12K长文本评估集，包含12000条测试样本，每条文档平均长度约1.2万token，任务要求不是简单回答选择题，而是从文档里定位支持答案的证据片段，并解释证据与结论之间的关系。这和过去只看最终答案对错的评测方式很不一样。以前模型给出“正确率90%”的成绩，但没人知道它是真读懂了还是靠文档里的常见词猜出来的。

LongCheck-12K把分数拆成两个维度：证据召回率，也就是正确答案依赖的片段有没有被模型找到；定位精确率，也就是模型圈出的位置是不是真的和答案相关。这两个指标对RAG系统意义很大。传统评估只问你答没答对，不问你找没找对资料，但检索增强生成场景里，资料找错了一切都白搭。有了这套评估集，开发者在做文档问答、审计辅助、研究综述时，至少能知道自己系统的检索和推理到底哪个环节在拖后腿。

我还注意到这套评估集的另外一层价值：它设计了跨章节证据链题型，答案线索可能分布在文档开头和结尾两处，模型必须把两处信息拼起来才能作答。这种题在以往的长文本测试里很少见，但现实中看合同、读论文、翻年报，恰恰最需要这种能力。所以我认为这条资讯虽然不如模型发布热闹，长期影响可能更大。

2. Dora-3B这类“小模型”，凭什么接管日常干活

很多人一看3B参数就觉得这是玩具，我倒觉得有必要认真拆解一下，为什么这类小模型能在不少真实任务里做出接近大模型的效果。核心原因有两个，一是蒸馏技术的成熟，二是数据配比更讲究。

2.1 多模态能力的下放，靠的是蒸馏与数据配比

蒸馏不是新鲜词，但现在小模型学的不只是大模型输出的文本，还包括中间隐藏层的注意力分布。Dora-3B的公开技术说明里提到，训练时会让教师模型和学生模型同时处理图文配对样本，然后额外约束学生模型的注意力模式不要太偏离教师模型。这种做法的结果是，小模型学会了“看哪里”，而不只是“说什么”，对图像里的关键区域更敏感。

数据配比同样关键。Dora-3B的训练语料大约1.2万亿token，其中图像文本配对数据只占四分之一左右，其余是通用文本和代码。这个比例看起来“不务正业”，反而让模型在语言理解上扎实，图像部分因为有教师模型的知识迁移，也不会太弱。我个人的观察是，纯粹堆图文对数据会让模型变得只会看图不会说人话，混合语料才是多模态小模型的出路。

2.2 我实测过的三个高频场景及参数参考

这两天我拿Dora-3B跑了三个场景，都贴近日常办公。第一个是把带表格的截图转成结构化Markdown。我的操作流程是先打开本地推理服务，用接口把图片按300dpi分辨率传入，提示词写明“提取表格内容并输出为Markdown格式，不要额外解释”。实测输出基本能对齐列结构，偶尔遇到跨行合并单元格会产生误判，但整体可以直接进文档。

第二个场景是语音指令加图像片段的多模态问答。我先录了一段“这张图里有哪些电子设备”的语音，再把办公室桌面照片喂给模型，让它结合语音和图像作答。模型能准确说出显示器、键盘和路由器，但把书架上的一个音箱误认成了摆件，这属于视觉细粒度分类的典型短板。

第三个场景是PDF图文混排摘要。我把PDF页面渲染成图片，同时抽取页面的文本层，把两者一起交给模型。这样做的好处是模型既能看版式又能读原文，摘要比纯文本版本更完整。我给的参数参考是：最大生成长度1024，温度0.3，关闭重复惩罚，任务类输出效果最稳。

2.3 小模型不是万能的：两个明显的短板

用下来的直观感受是，Dora-3B在“识别-抽取-转写”这一类任务上表现靠谱，但一旦涉及多步推理就开始露怯。比如我试着让它解一道需要先设未知数再列方程的应用题，它能读懂题目，却会在计算中间步骤出错，说明3B参数规模还不足以稳定承载复杂的逻辑链。

第二个短板是多轮记忆浅。连续聊到第五轮以上，模型会忘记最初提到的关键信息，比如文件名、日期这类实体。解决办法是外部挂一个可检索的记忆库，把对话历史里的实体抽出来存进去，需要时再取回。这也是当前小模型产品化的通用套路，可以理解成给模型配了一本随身笔记本，随时翻看，而不是让它把所有内容都装在脑子里。

所以我的判断是，小模型适合做“理解与提取”类任务，大模型负责“思考与创作”类任务，两者是配合关系而不是替代关系。选型的时候不用一上来就追求最大模型，先想清楚任务属于哪一种。

3. 模型路由不是新概念，但今年的实现方式变了

模型路由这个词，搞过微服务的人都不陌生，本质就是负载均衡加策略分发。但今年有一个重要变化：路由的判断依据从“开发者指定”变成了“语义理解”。这背后的变化值得展开聊聊。

3.1 从手动指定到语义路由

以前接多个模型API，业务代码里最常见的写法是硬编码，比如“摘要任务走大模型，实体识别走小模型”。这个方案的问题在于，任务的边界不是永远清晰的。同样是用户发来的一句话，“帮我写邮件”和“帮我把这封邮件总结一下”是两件事，但关键词都有“邮件”，靠简单规则很难区分。

语义路由的做法是引入一个轻量分类模型，先把用户请求编码成向量，再和预先定义好的意图样本做相似度匹配。比如开发者在配置里给“长文总结”这一类意图准备二十条示例问法，请求进来后分类器算一下跟哪类意图最接近，再按对应的策略池挑选模型。整个过程开发者感知不到，体验就是同一个入口，背后自动切换。

我自己的实践体会是，语义路由的落地难度不在分类器本身，而在于意图样本的维护。业务会演化，新的提问方式不断出现，如果意图样本长期不更新，分类准确率就会悄悄下滑。所以路由层必须配上日志回放工具，隔一段时间把真实请求捞出来看看，哪些分错了，然后针对性补样本。

3.2 路由规则的四种写法与适用场景

我在本地搭了一套简易路由服务，测试了四种规则写法，各有适用场景：

以我目前的项目为例，采用混合路由最省心。先判断是否包含文件上传，有就直接进多模态模型；再判断字数和时效要求，短文本且当天信息就走轻量模型；都不满足时再用语义分类决定。这套配置上线后，大模型的调用量明显下降，响应速度也提升了不少。

3.3 接入模型路由层后，调试要注意的三个隐形坑

第一个坑是错误路由导致的来回切换。分类器把本应走大模型的任务判成了轻量任务，结果轻量模型答得不如预期，用户重试，又被路由回大模型，一来一回成本反而更高。我后来加了置信度阈值，分类器不确定时就别硬分，保守走大模型更稳妥。

第二个坑是流式响应格式不一致。不同模型供应商的流式输出结构存在差异，有的是增量文本，有的是按句返回。路由层如果没做统一封装，客户端收到的内容格式就会时好时坏。这块需要在适配层做标准化，把所有来源都归一到同一种事件格式。

第三个坑是不同模型对系统提示词的敏感度不同。同一个系统提示词，放到模型A身上效果很好，放到模型B身上可能完全失效。路由层不能只转发用户请求，还要会按目标模型调整提示词模板，忽略这一点，上线后会发现同样的分数在几个模型之间波动很大。建议先做离线回放，用历史请求跑一遍全部路由策略，看看每个决策的实际响应质量，再灰度放量。

4. 合成数据进入“质量审计”阶段：开源社区在补什么课

如果说前两年开源社区的主旋律是“用合成数据扩充训练集”，那今年明显多了一个新议题：如何给合成数据做质量审计。LongCheck-12K这类评估集只是冰山一角，大家开始意识到，数据不是越多越好，得先搞清楚里面有多少“脏东西”。

4.1 合成数据不能只管量，要管污染程度

合成数据的生产方式通常会套娃：先用大模型生成一批样本，再用这批样本生成下一批，如此循环。问题在于，每循环一次，错误也会被继承和放大。比如早期样本里对某个专业名词的解释是错的，后续样本会带着同样的错误继续扩散，最后模型学到的是错误共识。

我在处理数据时常用三个简单指标做快速排查：样本重复度，看有多少条数据和其他样本高度相似；困惑度评分，看模型生成的数据对真实世界语言的拟合程度；指令多样性，统计指令模板是不是只有那几十句套路。有一回我过滤完重复样本后，训练集从一百二十万条直接缩到六十万条，但后续评测效果反而小幅提升。这个结果很能说明问题：冗余低质量数据不仅费算力，还会稀释模型对有效模式的记忆。

4.2 一个可复现的三轮迭代法

如果你也在做微调数据准备，我建议试试这个三轮迭代法，不复杂但很实用。

第一轮，用一个小规模基座模型先跑一遍生成任务，把生成结果和人工标注的校验集做对比，找出错误率最高的几类样本，比如“日期计算错误”“表格结构错乱”。这一轮的目标是定位系统性问题，而不是逐条修改。

第二轮，针对错误簇做定向补充。既然模型在日期计算上容易错，那就专门构造日期相关的合成样本，覆盖星期推算、节日倒计时、时区换算等细分场景。补数据时注意多样化，别只生成一个模板，至少准备二十种不同的问法。

第三轮，用小批量消融实验验证。不要一次性把所有新数据都灌进去，而是把候选数据按比例切分，比如5%、10%、20%三组，分别微调再做评测，找出收益边际。合成数据比例建议先从30%起测，有些任务真实数据占比越高效果越好，有些任务合成数据能补充真实数据覆盖不到的长尾场景，必须实验说了算。

4.3 评估集本身也在进化：从标准答案到证据链

传统评估集的答案是固定的，模型只要答对了就算过关。但现实任务里，很多回答没有唯一答案，关键是理由是否站得住脚。LongCheck-12K这类评估集把关注点移到证据链上，题目会主动要求模型提供支持答案的原文片段，并用专门指标判断片段定位是否准确。

这种评估思路会给RAG开发带来直接影响。以前你做文档问答，只看最终回答有没有包含关键数字，结果模型经常“编”出数字，因为下游环节无法追溯。现在评估集要求检索器找到的证据片段必须出现在正确的文档位置，如果检索器只找回一段相关但非核心的文本，定位精确率就会低，提醒你检索器该调权重了。

我建议做RAG的同学别只盯着公开的跑分，可以基于LongCheck-12K的构建思路，从自己的知识库里抽一部分文档做标注，自己给自己出题。不需要做一万条，哪怕五十条高质量证据链样本，也能帮你发现索引切分策略和检索排序里的明显盲区。

5. 动手派避坑笔记：部署轻量模型时容易忽略的四个细节

看完资讯，动手实践的人会遇到更实际的问题。我自己部署过不少轻量模型，也踩过不少坑，这里整理四个最容易让人头大的细节。

5.1 量化位宽不是越低越好，要结合卡和任务

为了省显存，很多人上来就选INT4量化，结果精度掉得让人心碎。量化位宽对显存和效果的权衡，我用一张表总结一下：

我的建议是，任务里如果涉及结构化输出，尽量用INT8，别省那点显存；如果是给自己聊天用，INT4也能接受。另外，量化后务必跑一遍自己的业务测试集，不要只看通义跑分，因为量化对不同任务的影响差别很大。

5.2 上下文长度与KV Cache：显存的隐形杀手

轻量模型的参数文件看着不大，但一聊长文本就爆显存，很多人以为是模型突然变大了，其实是KV Cache在作怪。自注意力机制会在生成过程中把历史token的键值缓存下来，缓存大小随序列长度线性增长，长对话的显存占用会非常夸张。

解决办法有三个方向。一是限制max_tokens，不要一上来就允许模型生成几千字。二是能开滑窗注意力就开，只保留最近若干token的缓存，长文档场景适合这种模式。三是用增量推理，把历史对话的KV Cache复用起来，而不是每次重新计算。我通常在服务端设置最大上下文长度，同时给每个会话分配独立缓存空间，防止多个会话互相挤占。

5.3 多路并发时的排队策略：别把所有请求塞给一个进程

本地模型服务和传统Web服务不一样，GPU处理请求是串行的，并发一高，显存和计算资源被抢来抢去，最终表现就是谁都没法正常响应。我见过有人直接让所有请求同时打进来，GPU显存直接被撑爆，进程崩溃。

靠谱的做法是加一个轻量队列，控制同时候的并发请求数。比如模型单次推理占显存6GB，一张16GB显卡同时最多跑2个任务，那队列就限制并发数为1或2，多余的请求排队等待。如果能用动态批处理，把相同格式的请求拼在一起推理，吞吐量也能提不少。

5.4 日志与可观测性：小模型调试最容易忽略的一环

本地跑模型的时候，大家普遍不记日志，出问题了全靠猜。其实记录必要指标不需要复杂系统，一个本地文件就行。我每次都记录输入内容长度、输出长度、首token延迟、总生成耗时、缓存命中率、模型版本和量化方式。这样换模型后对比效果时，马上就能看到哪一轮变慢了、哪一轮变聪明了。

有人觉得这在给自己增加工作量，但我觉得这是长期维护的基本功。有一次我发现新换的模型回答质量没变，但首token延迟翻了一倍，查日志定位到是提示词被加了太多固定前缀，导致预填充时间变长。如果没日志，这个问题可能要过很久才能发现。跑模型不是新潮玩具，它就是软件工程，该有的习惯一个都不能少。

6. 小编手记：写日报三年，我筛选AI资讯的三个习惯

最后聊点私人的体会。写日报时间长了，最大的收获不是知道多少新模型，而是慢慢形成了一套筛选信息的方法。这里分享三个习惯，希望对同样被信息轰炸的你有帮助。

第一个习惯是只信可复现的进展。新闻里说“某模型效果大幅提升”，但既不放权重也不写清评测方法，这种资讯我一般当广告看。真正有价值的信息，是那些你拿到手就能自己验证的，比如Dora-3B的权重、LongCheck-12K的脚本、灵石网络的路由参考实现。能复现才有讨论的基础。

第二个习惯是把每条资讯折算成自己的使用场景。看到一个模型，我会立刻想三个问题：它跑多快？需要什么卡？最擅长替我干什么？折算完发现跟我的工作流没有交集，再热闹也不投入时间。这套过滤方式帮我省下了大量精力。

第三个习惯是定期清理信息源。关注太多渠道，每天光是扫标题就要一小时，真正有用的信息反而被淹没。我现在只保留几个更新频率低但质量高的来源，宁愿少看，也不要被噪音包围。写日报这件事说到底，是用自己的判断力替读者做一道筛选工序，判断力靠的不是看更多，而是想更深。