看到了个Fable5.1弄的神奇项目, 是一个标签打印机的固件, 作者说他在速卖通上买了个热敏标签打印机, 然后打印机耗材用光了, 他就买了点第三方的热敏纸. 结果这个标签打印机很鸡贼, 耗材是有RFID的(让我想起了空气净化器的滤芯), 检测到不是自家产品, 就降速然后降低打印质量. 由于是RFID, 于是大家的人肉破解方法是把用光的耗材的卷轴(类似卷纸芯的那根塑料轴，里边有RFID芯片), 放到打印机旁边, 然后把第三方耗材的卷轴拆掉. 这样打印机就只能感应到原厂塑料轴, 就能继续打印了. 作者气不过于是用Fable-5.1尝试破解这个打印机固件, 然后经过几次刷机后, 就成功了. 我看了下repo细节, 有挺多好玩的地方, 首先Fable-5.1成功推导出了控制打印浓度的公式: darkness=renderer_input×coefficient, 然后定位了打印浓度在内存中的位置, 然后甚至利用了 Cortex-M0 汇编代码洞跳转技术把浓度重映射的动态逻辑缝合了进去, 彻底绕过了降速和降质限制. 比较黑色幽默的是整个过程 AI 负责搞定高难度的 ARM 逆向, 数学推导和汇编注入, 而人类由于长了眼睛和手, 于是负责提供物理执行力, 也就是按电源键和看纸上的字够不够黑. 从目前来看 AI 正在把逆向工程这种原本专属于极客的"重工业技术"彻底平民化了. 照这个趋势发展下去，硬件厂商精心设计的用来搞垄断的那些防伪和硬件锁啥的, 在人人可用的代码 Agent 面前, 基本就跟纸糊的一样了. 项目在这里: (记得刷机就有变砖的风险, 谨慎操作) > #fable51# #AIAgent#

给大家带来 Hy4 preview 实测! 这次送外卖Agent测试终于下岗啦! 取而代之的是更复杂的多智能体测试, AI不但要控制游戏角色来打怪, 还要控制召唤出拉的SubAgent来协作! 而 Hy4 甚至在测试中学会了团战和堵门打法! 除此之外, 在后端 Agentic Coding 测试中, 之前 Hy3 只考了16分, 而这次 Hy4 竟然考了 10779 分! 究竟是怎么做到的? 详情请看视频! #混元4# #hy4# #hy4preview# #AIAgent# #AI写代码# #腾讯混元#

劲爆, 我给刚发布的 Apodex 1.1 出了个极其变态的实战难题, 它真的跑通了! 我直接打包了120万条日志, 里面包含真实的提权攻击的 Web Server 日志(用的是 Zenodo Dataset). 然后让他帮我把黑客的攻击方式抓出来, 还要给我写防火墙规则拦截攻击. 结果它真的做到了, 从分析到写规则一气呵成, 具体过程在这里: #Apodex# #AgentOS# #网络安全# #SystemScaling# #大模型实战#

继续给大家带来 OX-Alpha 和 DeepSeek-V4-Flash-Vision-Exp 的代码能力对比测试. 直接说结论, 从测试体验上来看 OX-Alpha 应该参数量不小, 性能很明显占优势. 但如果这俩模型真的都只有100B, 我愿称之为牛! #oxalpha# #v4flashvision# #多模态大模型# #deepseek# #deepseek多模态#

DeepSeek Harness 能拯救这次 V4-Pro 的发布吗? 给大家带来 DeepSeek-V4-Pro-0813 实测! 本期视频我们只验证4件事: deepseek-v4-pro-0813 拉了吗? v4-pro 推理强度 max 甚至不如 high 吗? 甚至打不过 v4-flash 吗? 以及 v4-pro + deepseek harness 效果会更好吗? 视频告诉你答案! #deepseek# #deepseekv4pro# #deepseekv4pro0813#

SGLang 的 DSpark 实测数据在PR里放出了, 几个测试场景基本都能达到预测3个token, 其中数学类prompt是3.37个, 日常对话是3个, 代码是3.52个(果然代码是废token比较多的). 最亮眼的是加速比了, 在1K长度prompt下加速比来到了1.81倍. 测试使用的是8卡B200, 速度来到了 297 token/s. 而不使用DSpark 则是 164 token/s. 另外作者还测试了不同并发情况下的加速比, 目前来看单并发提升是最高的, 而超过8并发则只有1.2-1.3倍的提速了, 主要还是把GPU打满了. 另外比较震惊的数据时 DSpark 的 TPOT (每个输出 Token 的耗时) 只有2.9-5.2ms, 说明了这个DSpark内置的神经网络层运行得特别快. DSpark带来的延迟基本可以忽略不计了. 注意这个PR还没合并, 如果想尝试可以单独Fork这个PR29538.

本质上草稿模型生成的高接受率的token往往都是信息熵比较低的，比如标点符号，助词，代码的容易补全的语法等。但是这些计算成本在大模型中是不变的。所以这部分一旦被接受，不会降智但能提升性能。而真正决定prompt质量的那些接受率是特别低的。所以这也是DSpark聪明的一点，它还后置了一个置信度调度器。

DeepSeek真的是性价比和技术双重斩杀线... 有同学看不懂DSpark是啥, 简单给大家写个小教程讲讲. 推测性解码(投机解码)这个技术是用来提升大模型输出速度的. 本质是让小模型给大模型接话, 大模型判断小模型说的对不对. 因为现在模型普遍卡内存带宽, 而GPU算力是富余的, 所以大模型的prefill速度(看字)比decode速度(吐字)快很多. 那么让小模型沿着大模型的思路先说一段话, 大模型判断对不对(只需要看字), 只要小模型猜对了, 那么这就利用了prefill速度, 吐字就会成倍的提升. 但问题来了, 外挂小模型也要看字(prefill), 也要占用显存, 也要吃显存带宽. 那么有没有更好的方法来解决呢? 来了, 这就是DSpark. 看我的这个图(左侧DSv4架构图是 @rasbt 大佬的), DSpark 接在了 Final RMSNorm 过程中. 不是接一个完整的小模型, 而是一个3 层的MTP(多Token预测)微型Transformer堆叠. 大模型算完前面60多层后, 刚把当前这句话的"高浓缩概念"(特征向量/隐藏状态)推到 Final RMSNorm 这个出口，还没来得及翻译成具体文字时，DSpark开始截胡: 首先是半自回归极速脑补 (MTP + Markov Head), DSpark自己有一丢丢参数, 然后它就瞬间并行猜5个字(特征向量), 然后再用自己内部的一个串行网络理顺逻辑. (注意啊,先并行然后串行消除并行导致的逻辑不连贯). 然后, 它会有一个置信度预测头, 预判自己猜的准不准, 比如5个字的后2不准就直接砍掉, 防止后续送回大模型浪费算力. 最后把留下的3个字塞回词表映射层, 把向量翻译为token. 到此为止DSpark工作就做完了. 然后就是大模型扫一遍DSpark输出的对不对(只用prefill，不decode), 一旦正确了, 就直接吐字, 这样之前模型一次只能吐一个字, 现在就能吐3个字了! 最后, 推测性解码是不会降智的, 速度能提升60%-85%! 之前是雇一个小模型帮忙写草稿, 现在则是直接脑子里植入芯片了. 目前SGLang已经有这个特性的PR了(29538), 而且DeepSeek刚在自己的HuggingFace主页发了一大堆小模型的DSpark魔改版. 大胆猜一波未来发布的模型会不会标配DSpark? #dspark# #deepseek# #投机解码# #推测性解码#

给大家带来 Flash 系列模型横评! 各个厂商除了旗舰级别模型, 也都有Flash级别的模型, 而这些模型的定位主要都是多智能体系统的驱动模型和RAG系统的驱动模型. 那么现有这些Flash模型应该怎么选? 给大家带来本篇评测! 本次主要从 Agent Loop 迭代能力, Agent 能力, 前端, 后端, 空间理解, 美学, 性价比等多个角度评测了 Gemini-3.5-Flash, Step-3.7-Flash, DeepSeek-V4-Flash 这三个模型. 从测试来看, Gemini-3.5-Flash 更适合干"漂亮活", 比如前端页面, 建模等. 而 Step-3.7-Flash 则极具性价比, 在Agent测试中取得了比旗舰模型还要高的Token效率(用最少的token干最多的事情). 所以特别适合用在Agent框架中(比如OpenClaw或者Hermes), 或者复杂的Agent系统中用来做驱动模型. DeepSeek-V4-Flash 则后端能力很不错, 很适合用来写脚本, 甚至给服务器安装一个 DeepSeek-V4-Flash 驱动的 ClaudeCode, 用来 AI-Ops. #flash模型# #step37flash# #deepseekv4flash# #gemini35flash# #AgentLoop#

本地用vLLM部署GLM-5.2的速度终于上来了! 好消息终于轮到本地部署 GLM-5.2 了! 大家都知道 GLM-5.2 这次是自带了MTP头的, 可以进行推测性解码. 但是, 这个只适用于bf16原始精度的GLM-5.2, 而这玩意原始精度要到1.5TB, 本地跑的很少有富到这个程度的, 所以大家都用各种量化版本, 毕竟4bit量化就只要430GB了. 问题这就来了, 由于 GLM-5.2 的 MTP 采用了非常特殊的 DSA (动态稀疏注意力), 导致目前几个推理引擎 (llama.cpp, vLLM, mlx) 都无法支持. 其中 llama.cpp, mlx 是完全没办法开 MTP, vLLM 只支持FP8精度的. 而SGLang 没事哈, SGLang 架构比较屌上来就支持同一个计算流使用混合精度. 所以直接用 GLM-5.2-W4AFP8 就行. 所以回到这几个不支持的推理引擎, 大部分的量化版本 GLM-5.2 开了 MTP 反而会掉速度. 甚至有的量化版本直接把MTP部分给砍了(mlx). 而社区作者dnhkng搞了个缝合方法, 最终搞出了 GLM-5.2-AWQ-INT4-FP8-MTP-delta, 即 底座用 INT4（走 Marlin 算子）+ MTP 用 FP8（保持精度）同时还能让vLLM 支持. 速度从原来的 2 token/s 直接飙升到了 43.39 token/s (绑定NUMA+MTP-3) 所以目前位置 SGLang 和 vLLM (魔改版)都能直接火力全开跑带MTP的 GLM-5.2了. 而 llama.cpp和mlx用户还需要再等等. 社区还在弄. 这个作者的blog (过程极其精彩, 有不少优化技巧): #glm52# #mtp# #dsa#

刚刚 Doubao-Seed-2.1-pro 发布啦! 给大家分享一个自我迭代 Agent 的构建技巧啊, 也是我在今天字节 seed-2.1 模型发布 demo 中用到的技巧. 这个技巧的核心就是, 干一件复杂的事情, 用两个Agent比用一个Agent要好. 简单来讲打工Agent干完活之后, 还要增加一个评审Agent, 这个Agent要给打工Agent的产出评分, 然后说明评分理由, 哪里做得好, 哪里做的不好. 然后, 一定要输出结构化的评分结果(JSON就行), 这样, 打工Agent接到评分后, 进行修改, 修改完毕再次交给评审Agent, 评审Agent再次打分, 这时候就可以跟上次的打分进行对比. 只有得分大于上次的得分, 你的框架才合并这次的修改. 这就是 Agentic 自我迭代了. 基于 AI 反馈的强化学习的雏形基本就是这样的了, 以及吴恩达提出的 Agentic Workflow 核心原则之一就是 Reflection（反思），框架让模型像人类程序员提交 PR一样：打工 Agent 提交 PR，裁判 Agent 跑测试、打分。只有 Review 通过才能 Merge 到主分支。这就是真正的“工程化迭代”了. 甚至我框架内其实就是采用的Git模式, 多个Agent进行并行评估模拟多个分支, 只有打分高的才会合并到主分支. 最终得益于 Seed-2.1 本身的自我迭代和多模态能力也很强, 在它的驱动下, 成功实现了这个【只需要上传一个城市的相册, 就能建模一整个城市】的demo. 相信在现场的同学已经看到这个 demo 了哈哈. 下一期告诉你当这个办法也失效了, 该怎么办☆. #AIAgent# #seed21# #AI自我迭代#

想买Mac运行大模型? 这是劝退贴 其实估算方法很简单, 现在买 MacStudio 哪怕运行 Qwen3.6-27B 4bit 量化版本, 然后开 DFlash 使用Qwen的内置投机解码, 也就飙到 65token/s. 而现在普遍大模型都能跑到 40 token/s. 如果专门买 MacStudio M3 Ultra 96G 运行大模型, 如果把设备售价 (32999) 换算成使用API, 以 GLM-5.2 为例, 每百万token 28块, 一台 MacStudio 的价格大概能买到 32999/28 = 1178M token. 而为了输出这些token, 买到的 MacStudio 运行 Qwen3.6-27B 要持续运行 209天. 也就是说回本周期至少是200天不间断运行. 然后运行模型才是纯赚. 这还是没算电费和不直接买API而是买套餐的情况.而且, 最重要的是这还是在运行一个只有27B的小模型. 如果真的买512G的 MacStudio (108749, 而且好像已经断货了), 然后运行量化版本的 GLM-5.2, 速度就会跌到只有 17 token/s, 回本周期大概在 7 年左右... 对于现在1.5个月模型就发新版本的情况下, 普通用户自用是绝对不划算的. 所以大部分用户买 coding plan 会更划算, 如果像我一样要测新模型, 直接租卡也会比直接买划算很多. 当然, 如果你本身就有Mac或者显卡, 那么空闲的时候(比如睡觉的时候)让它跑大模型运行任务, 反而是划算的. #本地大模型# #mac# #qwen36# #glm52#

国产模型最近这一波打得太精准了 DeepSWE benchmark 放出了榜单, 从分数上看, GLM-5.2 无疑是国产编程大模型SOTA了, 而 Kimi-K2.7-Code 则是性价比SOTA. 图上几个折线是对应模型的不同推理程度的得分情况. DeepSWE 我觉得是最近非常值得的关注的的榜单了, 这个虽然也叫xxSWE, 但是它用的不是像SWE那种github上爬取的PR或者issue, 而是完全根据开源项目人工制造的问题, 然后让大模型修改. 能最大限度避免大模型提前炼这些问题(起码需要一段时间了, 5月份刚出的) 并且修改范围也很大,SWE-Bench-verified 通常一个提交也就几十行代码, 而 DeepSWE 每个问题都要上百行提交才能解决问题, 并且很考验模型的规划能力, SWE-Bench-Verified 通常会把所有需要的工具给到错误日志啥的也有, 并且提示词也写好告诉模型该怎么用. 而 DeepSWE 纯靠模型自己摸索, 非常像现实中修改项目代码的过程. 我觉得是涵盖了一部分工程能力测试的. 另外 SWE-Bench-verified 测得大部分都是 Python, 而 DeepSWE 则涵盖了TypeScript、Go、Python、JavaScript、Rust. 所以我强烈建议关注大模型编程能力测试的同学过关注一波这个测试. #DeepSWE# #SWEBench# #glm# #kimi#

GLM-5.2 刚刚正式发布! 给大家带来实测! 直接说结论本次测试中, 提升最大的是Agent能力, 而且是有质的变化! 测试中GLM-5.2 完全不用搜索附近的位置, 就能直接去想要到达的地方. 这一切竟然是它在一开始把地图背下来了! 这在我测试的20多个模型中之前是没有一个模型能做到的, 比如之前的模型想去换电站, 那么都要搜一下附近有哪些换电站(这就会浪费一次tool_call), 而GLM-5.2直接就知道换电站的位置! 从来没用过搜索函数. 这种一开始就把需要的数据内化到上下文中, 并且能够贯穿整个1M上下文进行推理的能力真的是叹为观止. 除此之外, 本次测试后端代码的 Agentic Coding 能力也有提升, 来到了总榜的第二名. 而本次测试暴露出最大的短板则是空间理解. 其实成也萧何败也萧何, 它虽然把换电站的位置都背下来了, 但是去的换电站却不是最近的, 所以虽然记住了, 但是记住了之后在用之前再根据自己当前所在位置推理一下, 他还是没有做到的, 这也是最大的短板了, 强烈建议官方优化一波. #GLM52# #智谱# #智谱AI# #AgenticCoding# #长上下文能力#

27B小模型挑战Fable 5? 还成功了? 劲爆消息, 在 Iterative-Contextual-Refinements 这个框架的加持下, Qwen3.6-27B 跑分超过了 Anthropic Fable5! 真的不是做梦吗? 还是跑分没输过, 实战没赢过? 于是赶紧看了一下这个框架, 发现设计的很有启发性, 能学到很多东西, 给大家详细讲下. 这个框架主要提升的是软件性能优化, 即如何才能让代码性能更高. 大家如果还记得我那个 vector-db-bench, 给大模型提供了火焰图, perf, 各种测试 tool_call 让大模型自己迭代去优化代码性能. 而这个框架更进了一步, 它瞄准了小模型的最核心弱点, 参数量不足导致的"脑残", 即小模型更容易长上下文衰退或陷入局部最优. 于是这个框架出手了, 先针对技术方案, 它搞了个BFS探索模式, 在写代码的 plan 过程, 让小模型自己提出多种解决方案, 比如写个字符串匹配, 小模型直接搞了个O(N^2)的暴力搜索, 而这一步它的Agent会让小模型思考, 你能想到哪些可能的解决方案? 于是就拓展了小模型的视野, KMP, 滑动窗口等技术方案没准就出来了. 然后就是写代码的过程中使用的DFS模式, 它会借助Agent让小模型借助代码性能测试工具不断跑分, 然后让小模型反思, 有哪些性能热点可以优化, 然后进行优化. 最后, 他还有个统筹全局的路由, 不但负责在BFS/DFS过程中选取最佳的技术方案, 而且还会在DFS过程中, 总结模型优化过程中面临的问题, 再反馈到BFS过程, 告诉模型, 需要注意xxx优化是有价值的, xxx优化面临xxx问题. 从而形成优化闭环, 解决掉模型陷入死胡同不断仰卧起坐的问题. 最后, 在框架加持下, Qwen3.6-27B 在 CGRE 测试得到了95.5分, 成功超越了 Fable5(Mythos) 的94.1分! 我只能说这真的是 Agentic 工程的胜利了! 不要模型写的不好就无脑怪模型, 也要看看是不是Agent本身有问题. 那么代价是什么呢? 当然就AI硬通货是 token 了, 这个框架正是用了25-40x的token消耗完成了这一壮举. 值得学习. 框架: 论文: #mythos# #fable5#

KIMI K2.7 Code 来了, K3 还会远吗? KIMI K2.7 Code 刚刚发布! 本次 K2.7-Code 是一个编程/Agent专项模型, 其中提升最大的是 kimi 自己的测试项目 kimi-code-bench-v2, 与 k2.6 相比提升了11%! 其它几个 Agent 测试项目也有不小的提升. 不过从架构上看, 其实这个模型与 K2.6 是完全一致的. 所以它是一个后训练优化版本. 于是我给大家写了个适用场景指南: 首先编程任务无疑使用这个新模型会更合适. 另外, Agentic 任务也可以尝试切换, 比如先用AI生成, 然后需要使用 Agent 进行验证的任务, 例如简历筛选, PR 审查这类需要外部 Agent 参与进行评分或者进行数据整合/格式化的的任务也很适合切换到这个新模型. 稍后有时间给大家带来详细测试! #kimik27code# #kimik27#

魔法! DeepSeekV4 上下文内存压缩到1/10! 大家都知道 DeepSeekV4 是支持1M上下文的, 而且经过了极度优化, 如果要真的用到1M上下文, 显存占用只需要10G左右, (对比之下 DeepSeek-V3.2 大概需要84G显存). 然后我刚看到了FlashMemory这个论文, 直接能把显存占用压到 1.3GB! 甚至输出效果不降反升! 哥们你骗兄弟可以, 骗自己就没意思了, 真的吗? 压缩后反而性能上升? 我赶紧看了论文细节: 咱们先复习一下传统做法: 模型每吐出一个字，都要把之前的几十万字重新看一遍(这就是全局注意力). FlashMemory 的做法是: 预测未来需要什么, 它内置了一个神经内存索引器（Neural Memory Indexer, 其实就是个小模型了），能够主动预判接下来生成内容时需要用到历史文本里的哪些片段. 然后预先准备好这些片段, 接下来只要做到命中率超高, 那么这个提升就绝对有效. 即它的假设是, KVCache里面的东西并不是生成每个字的时候全都需要的, 只需要按需提前加载即可. 很像做作业的时候, 把参考资料摊满桌子, 然后优化了一下就是把参考资料需要用到的部分直接拍照, 用的时候看照片就行了. 那么听上去很简单, 但实际的难点在于, 训练一个专用的索引器小模型, 需要把 DeepSeek-V4模型加载到显存里一起炼. 相当耗费算力. 于是这篇论文第二个亮点来了, 它搞了个解耦训练. 他们把这个索引器当成一个标准的"双编码器（Dual-encoder，类似做搜索推荐的模型）"来单独训练. 在这个过程中，根本不需要把庞大的 DeepSeek-V4 基座模型加载到显存中. 这让训练成本断崖式下降，且兼容标准的检索（Retrieval）训练框架. (简单来讲就是它是通用方法训练的, 通过query预测需要检索哪些长句子. 所以其实是个通用模型) 听上去靠谱, 那也只是显存占用少了, 怎么就性能还提高了呢? 答案是注意力降噪. 因为每次只提取和当前生成最相关的记忆块（Chunks）放入显存，模型在运算时就看不见那些无关的冗余信息了.天然地起到了一种"去噪"作用，这也是为什么显存占用少了，模型准确率反而略微提升的原因.官方测试在长文本评测集（如 LongBench-v2 等）上的准确率平均最终提升了 0.6%. (其实还有数据如何逐出显存和如何预测数据实现预加载, 这部分也很棒, 很有启发性. 建议看原论文, 篇幅原因写不下了) 论文地址: 项目地址: #FlashMemory# #DeepSeekV4# #FlashMemoryDeepseekV4#

单卡 700TPS! Diffusion Gemma 来了! Google 刚刚发布了 Gemma 小模型的 Diffusion 版本! 大小26B, 激活参数量4B, 最重要的是, 这次还跟 NVIDIA 合作针对4090和5090优化了一波, 5090每秒能生成700+token! 给不知道什么是 Diffusion 大模型的同学科普一下, 传统大模型都是一个字一个字吐出来的, 而 Diffusion 大模型则是如同刮奖一样, 是一片一片出来的, 速度高是 Diffusion 大模型的优点. 有得必有失, 缺点当然就是输出质量没有传统大模型好了. 不过这次的 Diffusion Gemma 还是比之前的 Diffusion 文本大模型好不少, AIME 2026(数学能力测试) 能达到 Gemma4-26B-A4B 的94%的水平, 最差的是tau2 bench(考验Agent能力的测试), 也能达到82%. 这个模型大小 4bit 量化版本 16G 显存就能运行了, 另外, 我突发奇想, 这个模型能不能作为 gemma4 dense 模型的草稿模型用来投机解码? 感兴趣的同学可以试试! #diffusiongemma# #gemma# #gemma4# #google#