今天是2026年10月6日周二。这份AI日报本来准备早上九点发结果我从起床开始就被一条开源模型发布的消息牵住了又在本地跑了一轮测试硬是拖到中午。今天的新闻节奏不算快但信息密度不低至少三条值得细看某实验室放出了一个参数规模很大的开源模型、一个视频生成工具更新了2.0版本、还有一个Agent框架终于把工具调用校验做进了主流程。如果你今天时间有限优先看第一和第四部分前者关系到你能用多大的上下文窗口做事情后者关系到你的推理账单。我不会把发布公告原文抄一遍那样没意义。日报的价值在于把发布信息和实测结果放在一起告诉你这到底意味着什么以及你该不该跟。下面按今天实际发生的内容来写。1. 头条L-3开源模型发布长文本进入1M窗口时代1.1 发布参数背后的技术选择上午十点左右某实验室的模型卡和权重包几乎是同时出现在社区的。模型代号L-3总参数量400B激活参数45B稀疏MoE架构上下文窗口直接拉到1M tokens。和上一代同系列模型相比最明显的变化不是参数变大而是它把长文本能力从能用推进到了能读。我一开始对这个判断存疑。之前也见过不少标称128k甚至1M窗口的模型但放长文本进去测试经常是开头和结尾记得住、中间一段完全丢失俗称大海捞针都捞不着针。L-3在技术报告里给出的做法是混合注意力滑动窗口负责捕捉局部细节固定间隔插入全局压缩头再用低秩投影把历史token压成固定数量的记忆槽位。用大白话说它不打算记住每一句话而是边读边做摘要把核心信息存在一个记忆缓存里后续需要时再按需取回。这个思路不新鲜但开源模型里敢直接做成默认能力的还不多。参数方面L-3的MoE设计让每个token只激活45B参数也就是说单次推理的计算量没有随总参数量爆炸式增长。这就让它在同样成本下能留下更多算力给长上下文处理。我看了半天技术报告觉得这个取舍是对的堆参数不如改结构聊天模型拼的是每token的有效计算量而不是总参数。1.2 我把7B蒸馏版拉回来跑了一晚上官方同时放出了一个L-3-Distill-7B的蒸馏版上下文256kDense结构不需要MoE运行时支持普通人本地也能跑。我在一台普通工作站上拉了int8量化版显存占用6.2GB左右用某种开源推理引擎跑128k长文档问答速度大约每秒18到22个token。这个速度谈不上惊艳但对个人做文档分析已经能接受毕竟不是实时对话场景。测试集我用了一个整理过的业务流程问答集里面有大量根据文档第X节的描述回答Y问题这类题目。144条题目里L-3-Distill-7B全部回答正确了一部分但更稳的是混淆项——文档里同时放了两份近似的报价条款模型能指出哪一份才是用户合同里的版本。对比同量级的开源模型这类多文档甄别题的正确率高不少。不过我还是要泼一盆冷水。官方宣传的是1M上下文可7B蒸馏版只有256k而正式版需要8卡以上的推理环境不是普通开发者的机器能跑得动的。你要真想在生产环境用400B版本得算清楚硬件成本和服务化改造成本别被开源免费三个字冲昏头脑。提示评估长文本模型时别只看上下文窗口标称值重点测试中间的随机位置插入关键信息后是否还能召回以及两段相似内容是否会被混淆。这两个指标比官方报告里的平均分数更接近真实业务。2. 视频工具Vid2实测可控运镜没有想象中那么可控2.1 2.0版本带来了什么今天的第二个大新闻来自某创意工具团队发布的多模态视频生成模型Vid2。版本号从1.8直接跳到2.0说明这是一次比较大的更新。新特性主要有四项16秒1080p单镜头输出、可控运镜推拉摇移和焦点切换、音画同步口型与字幕对齐、首尾帧参考图锁定。做短视频的人应该能理解这四项意味着什么。以前视频生成工具大多只能出3到5秒的单镜头运镜靠抽卡口型靠后期工作流里得接一堆修复环节。Vid2这次把几个关键环节合到一条生成链路里理想状态下输入一段剧本和首帧图模型自己能推出一段有剧情推进的完整镜头而不是一个静态画面的缓慢缩放。它对准的是短视频批量生产这个需求而不是炫技。2.2 实测样片的成功与翻车我下午生成了一批测试样片覆盖了室内对话、雨天街景、产品特写三类场景。直接说结论16秒长镜头是真的能生成了音画同步在对话场景下也有可用性放在短视频平台完全够看。但可控运镜是最容易翻车的地方我踩了三个坑。第一运镜描述写得越复杂主体越容易崩。我试过从人物正面缓慢推近同时焦点从背景转移到人物眼睛保持景深这种精细描述结果推到第三秒人物的脸形就变了。后来改成slow push-in on the character视觉一致性反而好很多。第二镜头平稳这四个字经常被理解成整个画面静止不动导致动态场景生成了静态背景。第三首帧参考图的影响比我预期大得多首帧放单人特写后面就很难自然切到中景模型会在每一帧里都执着地保持那张脸出镜。我整理了一份简单的实测对照表运镜类型实测成功率典型问题缓慢推近约70%推到一半主体出现形变横向摇镜约60%边缘物体出现撕裂焦点切换约40%模型容易把虚焦误解为重影跟随移动约50%相机跟随与主体运动不同步成功率是我自己定义的标准要求是16秒内主体一致且无肉眼可见断裂。这个结果说明可控运镜还处于能感知指令但要抽卡的阶段。真正的建议是让它控制一个维度比如只做推近或只做横移别把多个运镜动作塞进一个Prompt里。想拍先推近再上摇这种复合动作宁可分成两段生成再在剪辑软件里拼接补帧。提示用视频生成模型做正片之前先拿你要用的首帧图跑三四次只换Prompt不换图的测试确认生成风格稳定后再批量生产。否则你会发现自己花了大量时间在几秒样片的抽卡上。3. Agent框架AK 0.9工具调用校验层的意义与局限3.1 为什么这层校验是关键今天下午社区有几条更新的一条主线是Agent框架。某开源框架AK发布了0.9版本发布说明里没有强调新增了多少工具而是把重点放在了工具调用可靠性工程上。这个方向终于被重视了我很高兴。过去半年我在多个项目里被同一个问题折磨模型不是不会调用工具而是会乱调。举个例子模型要查一个订单状态它已经知道需要提供订单号但实际生成的参数里order_id字段拼错了或者把top_k传成一个小数工具接口直接报错。更糟糕的是模型报错之后不会反思这个参数为什么错而是继续用相同参数重试形成死循环。我亲眼看过一个任务因为模型连续调用同一个工具11次每次都因为同样的缺参错误中断白白消耗了大量token。AK 0.9引入的工具调用契约校验层就是在模型输出和工具执行之间加了一道闸门模型生成的参数必须先经过一份机器可读的参数契约检查类型不对会当场拦截并附带错误说明回传给模型让模型基于错误信息重新生成。这个机制的工程意义比修几个bug大得多因为它把模型瞎猜这个不确定性事件转化成了可校验、可重试的确定性流程。3.2 新配置与调试工具上手记录我给AK 0.9写了一份最小的工具契约配置大概是这样的结构{ tool: search_documents, args: { query: 2026年10月 AI 日报, top_k: 5 }, schema: { type: object, properties: { query: {type: string, minLength: 2}, top_k: {type: integer, minimum: 1, maximum: 10} }, required: [query] } }意思是这个工具必须接受一个长度不低于2的query参数top_k只能是1到10之间的整数。模型一旦输出top_k3.7校验层会立刻拦截并返回一条top_k需要是整数的错误信息。我写了个脚本做压力测试让模型连续跑50次检索任务旧版大概有20次会因为参数问题中断一次新版只需要在模型第一次生成错误参数时让它重新生成一次后续基本都能正确收敛。新版本还带了一个轨迹回放调试器可以这样用ak run --trace --export trace.json --max-steps 8 ak trace show trace.json --collapse-repeats第一行是运行Agent任务时导出完整轨迹限制最多8步第二行是压缩掉重复调用后查看执行轨迹。这个调试器最实用的地方在于它能直观地看到模型在哪一步开始重复尝试同一个错误参数不用再去翻几百行原始日志。但我也得说一句它的局限。循环检测目前只能抓完全相同工具完全相同参数的重复执行抓不到每次参数都变一点点的伪循环。而且预算管理器默认每任务只允许6次工具调用多步检索场景大概率会撞上限需要手工调整。所以升级框架之后别忘了重新评估你每个真实任务的预算阈值。4. KV Cache压缩为什么突然受关注先算一笔显存账4.1 长上下文推理里KV Cache的账要这么算今天好几个群里都在转一篇关于KV Cache压缩的分析。这个话题不是新的但L-3把上下文做到1M之后KV Cache的成本问题被重新摆到台面上。很多人的直觉是模型权重都能量化到几个GB上下文长一点怕什么但KV Cache和权重是两回事。权重是静态的量化一次就能长期使用。KV Cache是推理过程中动态产生的每生成一个token都要保留对应的Key和Value矩阵下次生成时继续使用所以它的大小随上下文长度线性增长。用一个8B稠密模型举例假设48层、每层8个KV头、头维度128、FP16存储。单层每个token的KV大小是2乘8乘128乘2字节约4KB48层加起来每个token约192KB。当上下文长度达到128k时KV Cache总量大概是192KB乘131072约24GB。这个数字比模型权重本身的FP16约14GB还大。也就是说上下文长了以后显存的主要开销根本不是模型而是这笔动态增长的KV Cache。这也是为什么长上下文模型很难直接部署在单张消费级显卡上——权重放得下中间状态放不下。4.2 主流的压缩方向与实测观察顺着这个账算下来KV Cache压缩就成了推理优化的兵家必争之地。目前技术圈讨论比较多的方向有三个低秩近似、token筛选、量化存储。低秩近似是把KV矩阵投影到更小的子空间用尽量少的数据表达尽量多信息的思路做压缩。token筛选是让模型判断哪些历史token重要只保留重要的部分把不重要的丢掉。量化存储最容易理解就是把FP16的KV Cache转成int8甚至int4保存用的时候再还原。压缩方案原理预期压缩率显存影响实测代价低秩近似将KV矩阵投影到低维空间约降2倍中信息丢失不可控Token筛选按重要度丢弃部分历史KV约降1.5到3倍中高长文档问答掉点约2%量化存储FP16转int8/int42到4倍低int4下知识性任务掉点约4%OffloadKV Cache移出显存理论无限低速度受带宽拖累我最近在一台单卡环境上同时测过int8和int4的KV量化。长文档问答任务中int8基本无感准确率掉不到1个百分点int4会掉4个点左右但在代码生成任务上几乎分辨不出差别。我自己的经验是代码和工具调用类任务可以放心用int4压缩KV Cache知识问答类任务最好停留在int8别为了省显存牺牲答案质量。这项技术和L-3那种混合注意力架构其实是一条路线的两个阶段。混合注意力从模型结构上减少了对全部历史KV的依赖KV Cache压缩则从存储层面减少这些KV的实际占用。两者配合起来长上下文的推理成本才有可能从线性增长降到更低的复杂度。这也是我判断今年年底之前推理成本还会再降一轮的依据。5. 今天值得记住的三个小信号5.1 一个评测基准让我重新警惕提示词方差今天有个团队发布了一套新的开放式问答评测集代号H-Bench测试方式比较特别所有题目全是开放性问答不用选择题答案由双模型交叉评分。结果跑下来几个头部模型的分数在不同提示词结构下波动非常明显同一道题换个问法得分能差到30个百分点。这提醒了一件事我们测出来的模型能力里有一部分其实是提示词运气。同一个任务用户换个问法结果就天差地别这在真实产品里是必须处理的风险。我的建议是不要在线上直接拿用户原话喂模型先用改写模型把用户输入归一化成固定的任务模板再交给主模型处理。这能显著降低提示词方差带来的质量波动。5.2 端侧语音模型和默认参数变化另外还有两个不起眼但值得记下来的细节。一个是有团队发布了新的端侧语音模型版本主打电话录音转写和说话人分离量化后显存占用最低2GB就能连续跑较长时间。这比我一年前见过的端侧语音方案轻了一倍多说明边缘设备的AI应用已经从能不能跑进入到能不能跑得久的阶段。另一个细节藏在一个模型权重卡的变更记录里默认采样温度从0.8悄悄改成了0.4。这个改动没有发公告但影响很大。温度降低意味着模型输出会更加保守、重复率略升、随机性大降更适合工具调用和结构化输出场景。这背后的趋势很明显生成式应用正在从追求创意发散转向追求稳定可用。创业团队在接入模型时应该多留意这类不声不响的默认参数变化别等线上效果变了才去翻变更日志。写到这里今天这份日报差不多可以收了。我翻了三个多小时的发布信息、实测结果和技术讨论最大的感受是2026年的AI行业已经没有多少一夜封神的新闻了更多是很多团队在同一个方向上做细致入微的可靠性修补。长文本不再只关心塞不塞得下而是关心中间的信息能不能被找到视频生成不再只关心画得真不真而是关心运镜能不能听指挥Agent不再只关心会不会调用工具而是操心调用错了怎么办。这些细节听起来不大但正是从偶尔好用走向一直好用的关键。明天有新东西我再接着写。 
长河君 · 2026/10/22 9:18:16 · 阅读 1.2k AI日报：长上下文开源模型、KV Cache压缩与Agent工具校验
今天是2026年10月6日周二。这份AI日报本来准备早上九点发结果我从起床开始就被一条开源模型发布的消息牵住了又在本地跑了一轮测试硬是拖到中午。今天的新闻节奏不算快但信息密度不低至少三条值得细看某实验室放出了一个参数规模很大的开源模型、一个视频生成工具更新了2.0版本、还有一个Agent框架终于把工具调用校验做进了主流程。如果你今天时间有限优先看第一和第四部分前者关系到你能用多大的上下文窗口做事情后者关系到你的推理账单。我不会把发布公告原文抄一遍那样没意义。日报的价值在于把发布信息和实测结果放在一起告诉你这到底意味着什么以及你该不该跟。下面按今天实际发生的内容来写。1. 头条L-3开源模型发布长文本进入1M窗口时代1.1 发布参数背后的技术选择上午十点左右某实验室的模型卡和权重包几乎是同时出现在社区的。模型代号L-3总参数量400B激活参数45B稀疏MoE架构上下文窗口直接拉到1M tokens。和上一代同系列模型相比最明显的变化不是参数变大而是它把长文本能力从能用推进到了能读。我一开始对这个判断存疑。之前也见过不少标称128k甚至1M窗口的模型但放长文本进去测试经常是开头和结尾记得住、中间一段完全丢失俗称大海捞针都捞不着针。L-3在技术报告里给出的做法是混合注意力滑动窗口负责捕捉局部细节固定间隔插入全局压缩头再用低秩投影把历史token压成固定数量的记忆槽位。用大白话说它不打算记住每一句话而是边读边做摘要把核心信息存在一个记忆缓存里后续需要时再按需取回。这个思路不新鲜但开源模型里敢直接做成默认能力的还不多。参数方面L-3的MoE设计让每个token只激活45B参数也就是说单次推理的计算量没有随总参数量爆炸式增长。这就让它在同样成本下能留下更多算力给长上下文处理。我看了半天技术报告觉得这个取舍是对的堆参数不如改结构聊天模型拼的是每token的有效计算量而不是总参数。1.2 我把7B蒸馏版拉回来跑了一晚上官方同时放出了一个L-3-Distill-7B的蒸馏版上下文256kDense结构不需要MoE运行时支持普通人本地也能跑。我在一台普通工作站上拉了int8量化版显存占用6.2GB左右用某种开源推理引擎跑128k长文档问答速度大约每秒18到22个token。这个速度谈不上惊艳但对个人做文档分析已经能接受毕竟不是实时对话场景。测试集我用了一个整理过的业务流程问答集里面有大量根据文档第X节的描述回答Y问题这类题目。144条题目里L-3-Distill-7B全部回答正确了一部分但更稳的是混淆项——文档里同时放了两份近似的报价条款模型能指出哪一份才是用户合同里的版本。对比同量级的开源模型这类多文档甄别题的正确率高不少。不过我还是要泼一盆冷水。官方宣传的是1M上下文可7B蒸馏版只有256k而正式版需要8卡以上的推理环境不是普通开发者的机器能跑得动的。你要真想在生产环境用400B版本得算清楚硬件成本和服务化改造成本别被开源免费三个字冲昏头脑。提示评估长文本模型时别只看上下文窗口标称值重点测试中间的随机位置插入关键信息后是否还能召回以及两段相似内容是否会被混淆。这两个指标比官方报告里的平均分数更接近真实业务。2. 视频工具Vid2实测可控运镜没有想象中那么可控2.1 2.0版本带来了什么今天的第二个大新闻来自某创意工具团队发布的多模态视频生成模型Vid2。版本号从1.8直接跳到2.0说明这是一次比较大的更新。新特性主要有四项16秒1080p单镜头输出、可控运镜推拉摇移和焦点切换、音画同步口型与字幕对齐、首尾帧参考图锁定。做短视频的人应该能理解这四项意味着什么。以前视频生成工具大多只能出3到5秒的单镜头运镜靠抽卡口型靠后期工作流里得接一堆修复环节。Vid2这次把几个关键环节合到一条生成链路里理想状态下输入一段剧本和首帧图模型自己能推出一段有剧情推进的完整镜头而不是一个静态画面的缓慢缩放。它对准的是短视频批量生产这个需求而不是炫技。2.2 实测样片的成功与翻车我下午生成了一批测试样片覆盖了室内对话、雨天街景、产品特写三类场景。直接说结论16秒长镜头是真的能生成了音画同步在对话场景下也有可用性放在短视频平台完全够看。但可控运镜是最容易翻车的地方我踩了三个坑。第一运镜描述写得越复杂主体越容易崩。我试过从人物正面缓慢推近同时焦点从背景转移到人物眼睛保持景深这种精细描述结果推到第三秒人物的脸形就变了。后来改成slow push-in on the character视觉一致性反而好很多。第二镜头平稳这四个字经常被理解成整个画面静止不动导致动态场景生成了静态背景。第三首帧参考图的影响比我预期大得多首帧放单人特写后面就很难自然切到中景模型会在每一帧里都执着地保持那张脸出镜。我整理了一份简单的实测对照表运镜类型实测成功率典型问题缓慢推近约70%推到一半主体出现形变横向摇镜约60%边缘物体出现撕裂焦点切换约40%模型容易把虚焦误解为重影跟随移动约50%相机跟随与主体运动不同步成功率是我自己定义的标准要求是16秒内主体一致且无肉眼可见断裂。这个结果说明可控运镜还处于能感知指令但要抽卡的阶段。真正的建议是让它控制一个维度比如只做推近或只做横移别把多个运镜动作塞进一个Prompt里。想拍先推近再上摇这种复合动作宁可分成两段生成再在剪辑软件里拼接补帧。提示用视频生成模型做正片之前先拿你要用的首帧图跑三四次只换Prompt不换图的测试确认生成风格稳定后再批量生产。否则你会发现自己花了大量时间在几秒样片的抽卡上。3. Agent框架AK 0.9工具调用校验层的意义与局限3.1 为什么这层校验是关键今天下午社区有几条更新的一条主线是Agent框架。某开源框架AK发布了0.9版本发布说明里没有强调新增了多少工具而是把重点放在了工具调用可靠性工程上。这个方向终于被重视了我很高兴。过去半年我在多个项目里被同一个问题折磨模型不是不会调用工具而是会乱调。举个例子模型要查一个订单状态它已经知道需要提供订单号但实际生成的参数里order_id字段拼错了或者把top_k传成一个小数工具接口直接报错。更糟糕的是模型报错之后不会反思这个参数为什么错而是继续用相同参数重试形成死循环。我亲眼看过一个任务因为模型连续调用同一个工具11次每次都因为同样的缺参错误中断白白消耗了大量token。AK 0.9引入的工具调用契约校验层就是在模型输出和工具执行之间加了一道闸门模型生成的参数必须先经过一份机器可读的参数契约检查类型不对会当场拦截并附带错误说明回传给模型让模型基于错误信息重新生成。这个机制的工程意义比修几个bug大得多因为它把模型瞎猜这个不确定性事件转化成了可校验、可重试的确定性流程。3.2 新配置与调试工具上手记录我给AK 0.9写了一份最小的工具契约配置大概是这样的结构{ tool: search_documents, args: { query: 2026年10月 AI 日报, top_k: 5 }, schema: { type: object, properties: { query: {type: string, minLength: 2}, top_k: {type: integer, minimum: 1, maximum: 10} }, required: [query] } }意思是这个工具必须接受一个长度不低于2的query参数top_k只能是1到10之间的整数。模型一旦输出top_k3.7校验层会立刻拦截并返回一条top_k需要是整数的错误信息。我写了个脚本做压力测试让模型连续跑50次检索任务旧版大概有20次会因为参数问题中断一次新版只需要在模型第一次生成错误参数时让它重新生成一次后续基本都能正确收敛。新版本还带了一个轨迹回放调试器可以这样用ak run --trace --export trace.json --max-steps 8 ak trace show trace.json --collapse-repeats第一行是运行Agent任务时导出完整轨迹限制最多8步第二行是压缩掉重复调用后查看执行轨迹。这个调试器最实用的地方在于它能直观地看到模型在哪一步开始重复尝试同一个错误参数不用再去翻几百行原始日志。但我也得说一句它的局限。循环检测目前只能抓完全相同工具完全相同参数的重复执行抓不到每次参数都变一点点的伪循环。而且预算管理器默认每任务只允许6次工具调用多步检索场景大概率会撞上限需要手工调整。所以升级框架之后别忘了重新评估你每个真实任务的预算阈值。4. KV Cache压缩为什么突然受关注先算一笔显存账4.1 长上下文推理里KV Cache的账要这么算今天好几个群里都在转一篇关于KV Cache压缩的分析。这个话题不是新的但L-3把上下文做到1M之后KV Cache的成本问题被重新摆到台面上。很多人的直觉是模型权重都能量化到几个GB上下文长一点怕什么但KV Cache和权重是两回事。权重是静态的量化一次就能长期使用。KV Cache是推理过程中动态产生的每生成一个token都要保留对应的Key和Value矩阵下次生成时继续使用所以它的大小随上下文长度线性增长。用一个8B稠密模型举例假设48层、每层8个KV头、头维度128、FP16存储。单层每个token的KV大小是2乘8乘128乘2字节约4KB48层加起来每个token约192KB。当上下文长度达到128k时KV Cache总量大概是192KB乘131072约24GB。这个数字比模型权重本身的FP16约14GB还大。也就是说上下文长了以后显存的主要开销根本不是模型而是这笔动态增长的KV Cache。这也是为什么长上下文模型很难直接部署在单张消费级显卡上——权重放得下中间状态放不下。4.2 主流的压缩方向与实测观察顺着这个账算下来KV Cache压缩就成了推理优化的兵家必争之地。目前技术圈讨论比较多的方向有三个低秩近似、token筛选、量化存储。低秩近似是把KV矩阵投影到更小的子空间用尽量少的数据表达尽量多信息的思路做压缩。token筛选是让模型判断哪些历史token重要只保留重要的部分把不重要的丢掉。量化存储最容易理解就是把FP16的KV Cache转成int8甚至int4保存用的时候再还原。压缩方案原理预期压缩率显存影响实测代价低秩近似将KV矩阵投影到低维空间约降2倍中信息丢失不可控Token筛选按重要度丢弃部分历史KV约降1.5到3倍中高长文档问答掉点约2%量化存储FP16转int8/int42到4倍低int4下知识性任务掉点约4%OffloadKV Cache移出显存理论无限低速度受带宽拖累我最近在一台单卡环境上同时测过int8和int4的KV量化。长文档问答任务中int8基本无感准确率掉不到1个百分点int4会掉4个点左右但在代码生成任务上几乎分辨不出差别。我自己的经验是代码和工具调用类任务可以放心用int4压缩KV Cache知识问答类任务最好停留在int8别为了省显存牺牲答案质量。这项技术和L-3那种混合注意力架构其实是一条路线的两个阶段。混合注意力从模型结构上减少了对全部历史KV的依赖KV Cache压缩则从存储层面减少这些KV的实际占用。两者配合起来长上下文的推理成本才有可能从线性增长降到更低的复杂度。这也是我判断今年年底之前推理成本还会再降一轮的依据。5. 今天值得记住的三个小信号5.1 一个评测基准让我重新警惕提示词方差今天有个团队发布了一套新的开放式问答评测集代号H-Bench测试方式比较特别所有题目全是开放性问答不用选择题答案由双模型交叉评分。结果跑下来几个头部模型的分数在不同提示词结构下波动非常明显同一道题换个问法得分能差到30个百分点。这提醒了一件事我们测出来的模型能力里有一部分其实是提示词运气。同一个任务用户换个问法结果就天差地别这在真实产品里是必须处理的风险。我的建议是不要在线上直接拿用户原话喂模型先用改写模型把用户输入归一化成固定的任务模板再交给主模型处理。这能显著降低提示词方差带来的质量波动。5.2 端侧语音模型和默认参数变化另外还有两个不起眼但值得记下来的细节。一个是有团队发布了新的端侧语音模型版本主打电话录音转写和说话人分离量化后显存占用最低2GB就能连续跑较长时间。这比我一年前见过的端侧语音方案轻了一倍多说明边缘设备的AI应用已经从能不能跑进入到能不能跑得久的阶段。另一个细节藏在一个模型权重卡的变更记录里默认采样温度从0.8悄悄改成了0.4。这个改动没有发公告但影响很大。温度降低意味着模型输出会更加保守、重复率略升、随机性大降更适合工具调用和结构化输出场景。这背后的趋势很明显生成式应用正在从追求创意发散转向追求稳定可用。创业团队在接入模型时应该多留意这类不声不响的默认参数变化别等线上效果变了才去翻变更日志。写到这里今天这份日报差不多可以收了。我翻了三个多小时的发布信息、实测结果和技术讨论最大的感受是2026年的AI行业已经没有多少一夜封神的新闻了更多是很多团队在同一个方向上做细致入微的可靠性修补。长文本不再只关心塞不塞得下而是关心中间的信息能不能被找到视频生成不再只关心画得真不真而是关心运镜能不能听指挥Agent不再只关心会不会调用工具而是操心调用错了怎么办。这些细节听起来不大但正是从偶尔好用走向一直好用的关键。明天有新东西我再接着写。