全部 · 2026-05-14

这个叫StudioMI300的流水线，把“一句话出片”这件事压到了一张AMD MI300X上跑，端到端时间从25.9分钟压到10.4分钟，省了一半多。流程是先用FLUX.2 [klein]出角色图，再用Wan2.2-I2V让图动起来，中间加了个视觉评分和自动重试的质检环节，最后配上音乐和9种语言的旁白。思路挺实在，相当于把多个模型串成一个自动化的视频生产线，还加了道品控。 不过现在能说的就这么多。Reddit原文被网络策略挡了，返回403，我们看不到代码仓库、示例视频，也不知道10分钟这个数字是在什么分辨率、什么帧数下测出来的。视觉评分具体怎么打、自动重试的触发条件是什么，正文都没披露。另外，全程跑在一张MI300X上，这张卡对大部分个人开发者来说门槛不低，能不能迁移到消费级显卡上还是个问号。 这条值得关注的点在于它把“生成-质检-重试”做成了闭环，不是一次性出片就完事。但效果到底怎么样，得等代码和样片公开了再判断。

这篇报道把 AI 深度伪造色情（NCII）的讨论往前推了一步：过去大家只盯着被换上去的“脸”是谁，但 Jennifer 的经历提醒我们，那些被换掉的“身体”同样是被盗用的受害者。Jennifer 在 2023 年用人脸识别搜自己以前的职业照，结果发现一段她 2013 年左右拍的旧视频被人换了脸——她的身体还在，脸是别人的。她说那种感觉就像自己戴着别人的脸当面具。 报道点出了一个更隐蔽的威胁：现在生成式 AI 已经不需要直接扒某段具体视频了，成人内容被大规模拿去当训练数据，教 AI 学会身体该怎么动、怎么“表演”。这直接威胁到创作者的饭碗——AI 生成的裸体内容反过来会挤占她们的市场。文章引用了专攻成人行业的律师 Corey Silverstein 的说法，证实这种事“一直在发生”。 报道的局限在于，它主要呈现了个人经历和定性判断，没有给出这类训练数据被使用的具体规模、平台下架效率的量化数据，也没展开讲现有版权法在“身体被盗用”这件事上几乎使不上劲的法律细节。Jennifer 的案例很有冲击力，但要从个案推到行业级的解决方案，还需要更多关于技术取证和平台责任的数据支撑。

这条新闻值得点开看，因为它解决的是 Agent 跑长任务时一个很实际的痛点：上下文窗口被工具返回的大量原始数据撑爆，导致成本飙升、模型犯糊涂。腾讯云这个方案思路挺巧，不是去压缩历史，而是把完整结果卸载到外部文件，上下文里只留一行摘要和索引路径，再配合一张 Mermaid 流程图当“任务地图”，让 Agent 随时知道自己在哪、下一步该干嘛。 61% 这个数字来自多任务连续 Session 实验，不是单题清空上下文那种理想环境，参考价值更高。消融实验也显示，光卸载能省 15% 的 Token，加上画布能到 31%-33%，说明画布对减少上下文噪音有独立贡献。 不过正文没披露实验用的具体模型、任务类型和成功率基线，也没提卸载和检索本身会引入多少额外延迟。目前默认用本地 SQLite 存储，零外部依赖，这对个人开发者友好，但大规模生产环境下的并发和可靠性还没看到验证。另外，长期记忆部分只提了一句“已上线免费使用”，具体怎么和短期记忆协同也没展开。

小米的 MiMo V2.5 Pro 在 DesignArena 设计竞技场总榜拿了季军，Thinking 版本比上一代爬了 8 个名次，前端编码任务的表现号称跟 Claude Sonnet 4.6 打平。这个成绩如果坐实，说明国产模型在需要兼顾视觉审美和代码实现的设计类任务上，已经能摸到第一梯队的边。 但这条消息来自官方账号的庆祝推文，不是第三方评测报告。正文没披露具体评分、测试样本量，也没说这个“追平”是在全部前端任务上还是某个子集里达成的。DesignArena 本身是一个社区驱动的排行榜，评测维度和稳定性跟学术基准不太一样，所以这个第三名的含金量还需要更多独立验证。 还缺的东西挺多：跟 Sonnet 4.6 对比的原始数据、错误类型分布、在不同复杂度任务上的稳定性，以及 Thinking 版本相比普通版到底在哪些环节起了作用。这些信息不出来之前，这个“追平”只能当个参考信号看。

这事说白了就是 Claude Code 在长对话里搞混了谁在说话。GitHub issue #44778 指出，系统事件被错误地以“用户”角色塞进对话，模型分不清指令来源，可能把自己生成的发布指令当成用户授权去执行。Claude 支持百万 token 的上下文窗口，会话越长，说话人归属出错的概率就越高，相当于记忆越好反而越容易记岔谁说了什么。 正文没披露 Anthropic 的官方回应或修复时间表，这点先别太激动。目前能看到的信息都来自社区反馈，没有官方确认的复现步骤或影响范围。对实际在用 Claude Code 做自动部署的团队来说，这个 bug 的风险在于模型可能在没人点头的情况下就把代码推上线。 还缺几个关键信息：Anthropic 是否已经定位到角色注入的具体环节，是客户端拼接问题还是模型自身在长上下文中对角色标记的解析出了偏差，以及有没有临时规避方案。在官方给出明确说法之前，建议先把 Claude Code 的自动发布权限收紧，别让它自己说了算。

这条访谈信息量不小，但得先打个折：原文因为微信环境异常，实际内容没抓到，所有判断都基于摘要。Alexandr Wang 回应 LeCun 的批评很直接，说对方没搞懂 Scale AI 在做什么，这种正面硬刚在行业里不多见。更值得关注的是他透露 Meta 在过去九个月把预训练、强化学习和数据处理三套系统全部重写了一遍——这个速度确实快，说明大厂内部的技术栈迭代可能比外界看到的更激进。 关于 Manus，他的评价很克制：体验不错，但技术上没看到根本性突破。这话从做数据标注起家的人嘴里说出来，分量不轻。另外 Muse Spark 被安全审查卡住，涉及生物安全、网络能力和失控风险，正文没披露具体触发了哪些红线，也没说什么时候能放出来。这点先别太激动，产品被内部安全机制拦住，要么是真有硬伤，要么是合规流程还没跑完。

这条消息的核心就一句话：国产GPU厂商摩尔线程办了个线下交流会，宣布他们的MUSA后端已经合入SGLang主分支。SGLang是现在大模型推理部署的热门框架，能直接在主分支里跑国产卡，对用摩尔线程硬件的团队来说省了一层适配的麻烦。截至5月12日，他们提了47个PR，合并了41个，这个合并率说明社区对代码质量是认的。 但问题也出在这里——正文因为微信环境验证没加载出来，所有技术细节都是空白。我不知道现场到底跑了什么模型、吞吐量和延迟跟CUDA后端差多少、支持哪些卡、有没有多卡并行的实测数据。这些才是判断这件事含金量的关键。PR数量只能说明提交活跃，不能说明性能到位。 另外，标题里提到Mooncake也来了，但正文同样没展开。Mooncake是月之暗面开源的推理加速项目，如果他们跟摩尔线程有具体合作，那价值会大不少。目前只能先打个折：方向是对的，但缺实测数字和合作细节，别急着下结论。

这篇论文的核心思路挺直接：用强化学习微调模型做推理时，模型容易陷入“只会一种解法”的困境，生成一堆看起来不同但思路雷同的答案。达摩院的方案是在模型生成过程中，碰到它犹豫不决的节点就主动分叉出多条路径，再用一个基于信息瓶颈的自奖励机制筛掉重复的，留下真正不一样的解法。在 Qwen2.5-7B 和 Qwen3-14B 上跑数学题，准确率最多提了 5.3%，答案的语义多样性提了 7.4%。 不过要冷静看几个点。第一，正文因为微信环境验证问题没完全加载，具体的实验设置、基准测试名称、对比基线都没披露，5.3% 这个数字是在什么条件下拿到的说不清楚。第二，分叉加筛选会增加推理时的计算开销，论文有没有给出延迟或成本数据，目前看不到。第三，这个方法在非数学推理任务上效果如何，也没提。如果后续能补上这些信息，判断会更踏实。

这条消息目前只能当个预告看。灵初智能说用了10万小时人类操作数据来训机器人策略，还提到一个叫W0的世界模型只在训练时做迁移，实际部署只跑R2——这个架构思路听起来是想把训练和推理拆开，降低部署成本。但关键信息全卡在微信的验证页后面，正文一个字都没露出来。 10万小时这个数字本身不算小，但得看采集的是什么场景、什么精度、有没有覆盖长尾情况。如果只是固定工位上的重复动作，那和真实世界的泛化要求差得远。W0只在训练时用、部署不跑，这个设计如果是真的挺省钱，但没看到延迟、成功率、跨任务迁移的数据，就没法判断实际效果。 现在还缺三样东西：一是具体任务和评测指标，二是数据采集的细节（遥操作还是动捕、单人还是多人），三是和现有路线的对比。等正文能看了再下判断。

Anthropic 这次改规则，简单说就是把以前第三方工具（比如 OpenClaw）能薅的羊毛给剪了。过去你花 200 美元订阅，在非官方工具里调用 API 能享受到比直接买 API 便宜 70%-90% 的隐性折扣。现在官方直接把这 200 美元拆成两份：一份是你在 Claude.ai 和 Claude Code 里的“互动额度”，另一份是等值的 200 美元 API 额度，让你在别处用。 从商业逻辑看，这不算坑人，毕竟白纸黑字给了你等值的 API 额度，只是把暗补变成了明补。但用户炸毛的点在于，以前那种近乎无限的廉价调用没了，成本会明显上涨。文章也提到，这恰好和 OpenAI 在同一天推出 Codex 企业迁移优惠撞车，两家在编程智能体上的定价策略正在交替拉锯。 正文没披露这 200 美元 API 额度具体能跑多少 token，也没说超额之后怎么收费。如果你重度依赖第三方工具，建议先算一下自己过去的实际用量，再对比直接买 API 的价格，别光看“送额度”就觉得划算。

这是个实用向的开源小工具，把微信群聊记录自动整理成摘要，省去爬楼翻记录的痛苦。核心逻辑不复杂：用 wx-cli 把聊天数据读出来，再丢给 Claude Opus 4.6 做总结。作者实测这套组合效果最好，但正文没披露具体好在哪——是摘要更准、幻觉更少，还是对长群聊的上下文处理更稳，这些都没说。 依赖链有个明显的坑：你得先自己配好 wx-cli，作者明确表示这块不提供帮助。wx-cli 本身是个第三方工具，跟微信没有官方关系，稳定性和安全性都要自己评估。如果你日常聊天内容敏感，建议先搞清楚数据是怎么走的再决定用不用。 另外，其他模型的表现正文完全没提，没法判断这套方案是不是只绑定了 Claude。如果你手头用的是别的模型，效果可能打折，这点先别太激动。

OpenSquilla 把模型路由这件事从云端搬到了本地，不花 token 就能判断问题难易，简单问题丢给便宜模型，复杂问题才上强模型。这个思路本身挺实在，等于在请求发出去之前先做一次分流，省掉了一部分不必要的推理开销。它还用增量发送和缓存命中把实际传输的 token 量压到原来的十分之一以下，记忆模块会在上下文快满时自动挑重点压缩，支持混合检索，功能堆得挺全。 但正文没披露具体测试场景和模型阵容，这 90% 的降幅是在什么任务上跑出来的、对比的是哪套模型组合，全都不清楚。如果测的是极端重复的对话场景，缓存命中率天然就高，数字会好看很多。另外路由决策本身虽然不花 token，但本地做判断的准确率怎么样，会不会把该上强模型的问题误判成简单问题，这点也没交代。 还缺的是跟现有方案的成本对比，比如跟直接全量走便宜模型、或者用云端路由服务比，到底省了多少。功能列得热闹，但没看到实际跑分和失败案例，暂时只能当个有意思的方向看。

这条消息目前只有标题和摘要，正文因为 Bloomberg 的付费墙完全看不到，所以能说的很有限。标题里两个信息值得点出来：一是发那科股价冲到历史最高点，说明市场把这次合作当真金白银的利好；二是关键词“物理 AI”，大概是把谷歌的模型能力塞进发那科的工业机器人里，让机器在真实环境里自己判断、自己动，不再是死程序。 但正文没披露合作到底做什么、谷歌出什么技术、发那科出哪些硬件、什么时候有东西落地，也没写股价具体涨了多少。这些缺口让这条新闻更像情绪炒作，而不是能拿来判断技术路线的依据。我会先打个折，等有具体方案再认真看。

Daniel Han 放出的这几个 Qwen3.6 MTP GGUF 模型，核心卖点是推理快。27B 模型单张 GPU 跑到每秒 140 个 token，35B-A3B 版本能到 220 token/s，比原版 GGUF 快了 1.4 倍以上，而且说精度没掉。 快的原理是投机解码，让模型一次猜两个草稿 token，在速度和猜对率之间找了个平衡点。这个思路不新，但把 draft tokens 定在 2 并做成 GGUF 格式直接可用，对想在消费级显卡上跑大模型的人来说确实省事。 不过得打几个折。首先这是实验版，正文没提在哪些基准上验证过精度无损，也没说接受率具体是多少。其次，投机解码的实际加速效果很吃任务类型和硬件，换到长文本生成或复杂推理场景，220 token/s 这个数字不一定稳得住。另外，模型本身是 Qwen3.6 的衍生版，如果上游模型在特定任务上有短板，加速也解决不了。想用在生产环境，最好拿自己的数据和任务测一下延迟和输出质量，别只看峰值速度。

杨植麟自己拍视频把Kimi K2的训练账本摊开，总花费460万美元，靠线性注意力等架构设计在编程任务上跑赢了GPT-5.5。这个数字放在大模型圈确实低，说明他们用设计把资源差距抹平了一截。但视频是创始人自述，没有独立评测机构交叉验证，跑分对比用的什么基准、什么测试条件都没展开。编程任务本身也容易刷榜，换个数据集排名可能就变了。另外，460万是纯训练成本还是含试错和废卡，正文没披露。这点先别太激动，等第三方跑分出来再看。

Grok Build 是个直接跑在命令行里的编程助手，目前是早期测试版，只开放给 SuperGrok Heavy 订阅用户。它最大的卖点是干活前会先出一份计划让你审，你可以改步骤、批注，甚至推翻重写，批准后才动手改代码，每次改动都以 diff 形式呈现，这比直接让模型盲改要靠谱得多。另外它能把大任务拆成多个子任务并行跑，还支持无头模式（-p 参数），方便塞进脚本和自动化流水线里。 官方说它兼容你现有的 AGENTS.md、插件、钩子和 MCP 服务器，进到仓库就能用，这点对已经搭好开发环境的团队比较友好。但正文没披露任何性能数据，比如任务完成率、一次通过率、并行子任务的实际加速比，也没提延迟和资源消耗。这些是判断它到底能不能在生产环境用的关键。另外，早期测试意味着功能可能不稳定，反馈渠道倒是给了（在 CLI 里敲 /feedback），但没说明反馈后的迭代周期。 我会先打个折：计划审核和并行子任务这两个设计方向是对的，但没看到实测数据前，别急着把它当成主力开发工具。

这篇文章讲的是怎么把推理服务里 CPU 和 GPU 的“轮流休息”改成“同时干活”。他们拿一个 80 亿参数的模型做测试，生成 8000 个 token 时，GPU 有 24% 的时间是闲着的。原因很简单：同步批处理下，CPU 准备下一批数据时 GPU 只能干等，反过来也一样。文章给出的解法是用 CUDA 流把这两件事拆开，让 CPU 准备第 N+1 批的同时，GPU 已经在算第 N 批。 这个思路不新鲜，但文章把实现细节讲得比较清楚，包括怎么用 CUDA 事件来强制同步、怎么处理竞争条件和 carry-over 这些坑。不过正文没给出优化后的具体吞吐提升数字，也没提不同模型规模下的收益差异。这点先别太激动，24% 的空闲是特定场景下的测量值，换个小模型或者短文本，收益可能没那么大。另外，异步引入的复杂度会不会在工程上带来新的稳定性问题，文章也没展开。

Tomasz Tunguz 这篇博客没画大饼，直接拿主流大模型的 API 价格算了一笔账：让 AI 帮你读、写、整理邮件，每月推理成本在 22 到 130 美元之间，中位数 26 美元。这个数字本身不算吓人，但一旦按 SaaS 的 75% 毛利率打包成产品，年费就要 500 美元左右，是 Google 企业版的两倍。用户会不会掏钱，正文没给结论，只说“工作中很多人可能会”。 文章最有用的部分是降本路径。换小模型能把成本压到十分之一甚至二十分之一；更彻底的做法是直接在用户自己的 GPU 上跑推理，边际成本趋近于零。作者认为接下来一两年 AI 软件的核心就是这种“看人下菜碟”的推理分层：能写死规则的就别调模型，该用小模型就别上大家伙。 不过这篇分析缺几个关键信息：没说明每月处理多少封邮件、多长的上下文，也没区分“读邮件”和“写回复”的 token 消耗差异。另外，本地跑虽然省钱，但用户设备门槛、延迟和隐私权衡都没展开。这些缺口让 26 美元这个中位数只能当个参考锚点，别直接拿去写商业计划书。