全部 · 2026-05-08

Runway 这篇安全说明把防护拆成了模型开发、产品部署和持续维护三个阶段，思路很清晰。开发阶段用哈希匹配和专门分类器清洗训练数据，确保模型没学过涉及未成年人的色情内容，上线前还做对抗测试找漏洞。部署后所有用户上传内容都要过已知 CSAM 哈希库和分类器扫描，确认违规就永久封号并上报 NCMEC。2025 年全年他们提交了 516 份报告，这个数字本身不大，但正文没披露总生成量或扫描量，所以没法判断是漏检少还是真没多少人尝试滥用。 值得留意的是他们用了 C2PA 来源标记，让生成内容能追溯到工具本身，这对后续追责有帮助，但正文也承认这不是完整解决方案。整体来看，Runway 的做法跟 Thorn 的生成式 AI 安全设计原则对齐，技术栈说得比较实在，没画大饼。缺的是独立审计或第三方验证的结果，光靠自述很难判断这些分类器在实际对抗中的表现到底怎么样。

这条消息来自 Reddit 用户分享，但原文链接已经 403，我们看不到具体是怎么跑的、用了什么量化格式、推理速度多少。从标题看，一台只有 8GB 显存、32GB 内存的机器，把 Qwen 35B-A3B 这个 350 亿参数、激活 30 亿的混合专家模型跑起来了，上下文还拉到 19 万 token。如果属实，说明这个模型对消费级硬件的门槛压得很低，12GB 显存的卡更不在话下。 不过得打几个折。第一，能跑和能用是两回事，8GB 显存大概率是靠系统内存硬撑，推理速度可能慢到没法正常对话。第二，帖子被屏蔽，我们没法确认他用了什么量化手段，是 GGUF 还是别的格式，也没看到延迟和吞吐数据。第三，19 万上下文听起来很猛，但实际长文本下的注意力质量和显存占用曲线完全未知。 对想在本地玩大模型的人来说，这条消息的价值在于给了一个硬件下限的参考，但缺了最关键的性能数据。如果你手头正好有 12GB 显存的卡，可以自己试一下，别对速度抱太高期待。

这条帖子展示了一个挺狠的本地推理优化：用一张RTX 4090把Qwen3.6-27B在26万token的超长上下文下跑到每秒80到87个token，比原来的43 t/s翻了近一倍。提速主要靠两招：一是TurboQuant的TBQ4_0格式压缩KV缓存，省显存；二是MTP推测解码，让模型一次猜3个后续token，草稿接受率约73%，说明猜对的概率不低，这是速度能上去的核心。 不过得打个折。帖子正文被Reddit的安全策略挡了，我们只拿到摘要，看不到具体的显存占用、温度、功耗，也不知道80+ t/s是峰值还是稳定输出。73%的接受率在MTP里算不错，但不同任务下波动可能很大，写代码和闲聊的接受率会差不少。另外，模型是Heretic-v2这个社区微调版，不是原版Qwen，换别的模型不一定能复现这个速度。 如果你手头有4090想试试，可以先确认TurboQuant和MTP在你的推理框架里是否都支持，以及262K上下文在实际应用里是不是刚需——毕竟大部分场景用不了这么长的窗口。

Simon Willison 分享了一个反直觉的用法：让 Claude 直接吐 HTML 而不是 Markdown。他之前一直用 Markdown，因为 GPT-4 时代 8192 token 的上下文限制让 Markdown 更省 token。但 Anthropic 的 Thariq Shihipar 用实际案例说服了他——HTML 输出可以自带 SVG 示意图、可交互组件和页内导航，信息呈现效果比纯文本强太多。 文章里给了个具体例子：用 GPT-5.5 解释一个 Linux 提权漏洞的混淆 Python 代码，要求输出成带样式和交互的 HTML 页面。结果确实生成了一个结构清晰、带安全警告和分步拆解的页面。不过 Willison 也承认，模型把重点放在了 Python 代码本身，对漏洞原理的解释不够深入，这是他提示词没强调到位。 这个思路对做内部工具或快速出报告的场景挺实用，但正文没给出 HTML 输出相比 Markdown 具体多消耗多少 token，也没对比不同模型在复杂 HTML 生成上的稳定性。如果你打算在生产环境用，这点得自己测一下。

The Verge 这篇汇总把 AI 数据中心引发的冲突摊开了：43% 的美国人认为数据中心是电费上涨的主因，附近社区电费最高涨了 267%，俄勒冈州的数据中心甚至被怀疑与当地癌症和流产率上升有关。这些不是预测，是已经发生的摩擦。犹他州一个 4 万英亩的项目顶着社区反对获批，Anthropic 宣布砸 500 亿美元建数据中心，一边是抗议，一边是加码，矛盾在加速。 文章本身是动态列表，不是深度调查，每条只有标题级信息，没有展开方法论和数据来源。比如 267% 的电费涨幅是哪个时间段、对比什么基准，正文没披露。俄勒冈州的健康风险也只是“被怀疑”，因果链条没给。我会先打个折：这些数字方向是对的，但具体幅度要看原始报告才能确认。 还缺什么？缺对数据中心实际用电量的独立审计数据，也缺对“科技公司承诺自建电厂”这类说法的跟踪验证。承诺和落地之间，通常隔着几年和一堆变数。

Anthropic 跟 Akamai 签了笔 18 亿美元的计算资源大单，用来撑住自家 AI 软件越来越大的算力消耗。这个金额不小，说明头部模型公司还在猛砸基础设施，而且开始把一部分算力需求从传统云厂商往外分。 不过这条新闻能读到的信息就到这了。Bloomberg 的正文被付费墙完全挡住，我们看不到合同签了几年、买了多少 GPU 或等效算力、这些服务器会部署在哪些地区，也不知道是用于训练还是推理。18 亿这个数字单独拎出来挺唬人，但缺了交付周期和资源规格，没法判断这笔交易到底划不划算。 另外，Akamai 传统强项是 CDN 和边缘网络，在 AI 训练集群这块不是第一梯队。Anthropic 选它，可能是看中分布式推理的延迟优势，也可能只是多供应商策略的一部分。这点先别太激动，等有更多条款细节再下判断。

AllenAI 放出的 EMO 模型，核心卖点是让混合专家模型（MoE）的专家模块自己从 1 万亿 token 的数据里“长”出来，而不是按人类划好的数学、代码等学科去分。结果是，跑特定任务时你只用挑出 12.5% 的专家，性能就接近全模型水平。这听着挺省钱，因为总参数 140 亿，每次推理只激活 10 亿，再砍掉大部分专家，推理成本能压得很低。 但文章没给出具体任务上的性能对比数字，只说“接近全模型水平”，这个“接近”到底差多少，在哪些基准上测的，都没提。另外，它强调专家没按人类学科分工，那这些自己长出来的模块到底专精什么，文章只说标准 MoE 专家常去学介词、标点这类低层模式，EMO 的专家是不是真学到了更高层的技能，还得看后续验证。 目前放出了模型、技术报告和可视化工具，代码也在 GitHub 上。想试用的可以直接去 Hugging Face 拉模型，但建议先在自己关心的任务上跑一下，看看那 12.5% 的专家子集到底能不能打。

这篇演讲把做通用人形机器人的路线拆成了六个模块，核心逻辑很直白：大语言模型怎么从文本预训练走到能干活，机器人就怎么从视频预训练走到能动手。视频世界模型被当成第二预训练范式，相当于让机器人先看海量视频学物理常识；世界行动模型（WAM）负责把看到的转成动作指令；数据飞轮对标特斯拉 FSD 那套影子模式，靠真实场景回传数据持续迭代。EgoScale 和灵巧性缩放定律这两个概念试图量化训练规模跟手部操作能力的关系，但正文没披露具体公式或实验验证，这点先别太激动。物理强化学习被定位成跑通最后一公里的手段，DreamDojo 则是一个端到端的神经物理引擎，想替代传统仿真器。整体框架听起来自洽，但全文没有给出任何基准测试结果、成功率或成本数字，也没说明数据飞轮在真实硬件上的部署规模。演讲者还提了一嘴 2016 年参与 OpenAI 那台 DGX-1 签名的旧事，更多是个人叙事。我会先打个折：方向对，但缺验证，离落地还有距离。

re_gent 想解决一个实际问题：AI 编程助手（目前只支持 Claude Code）改代码时，不像人一样有清晰的 commit 记录，出了问题很难追溯。它把 AI 的每一步操作都记下来，告诉你它为什么改这个文件，还能把整个对话过程回滚到之前的状态。最实用的功能是二分法定位——如果 AI 改出了一堆 bug，可以像 git bisect 一样快速找到是哪一步操作引入的。 不过这个项目现在还太早期。正文没披露许可证，不知道能不能商用；也没写数据存在哪、是什么格式，这对想集成到现有流程的团队来说是个黑盒。42 个星标说明社区还没开始认真检验它。另外只支持 Claude Code，覆盖面太窄，如果你用的是 Cursor 或 Copilot 就用不上。 现在还缺的东西不少：一是实际场景的验证，比如在大型项目里记录完整对话会不会让存储爆炸；二是跟现有 Git 工作流的冲突怎么处理——AI 的版本记录和人写的 commit 怎么合并；三是安全方面，对话历史里可能包含敏感信息，存下来之后怎么保护。这些都没提，所以目前只能当个有趣的原型看。

这条测试结果挺直观：用一张 RTX 5090，配合 vLLM 的 DFlash 投机解码，Gemma 4 26B 的输出速度从每秒 228 个 token 提到了 578 个。测试条件是输入 256 token、输出 1024 token，只跑一个并发，投机 token 数设成 13。这个速度意味着本地跑 26B 模型已经可以做到实时对话甚至更快的批量生成，对个人开发者或者小团队来说，硬件成本压到了一张消费级显卡。 不过得注意几个限制。首先，这是单并发、短上下文的理想跑分，实际用的时候上下文一长、并发一上来，速度会掉。其次，正文没披露用了什么量化精度，如果是 FP8 甚至更低，那实际模型能力可能比满血版差一截。另外，DFlash 投机解码本身会多占一些显存，原文也没说显存占用情况，不知道 5090 的 32GB 显存还剩多少余地。 还缺一个关键信息：生成质量有没有因为投机解码而下降。速度快了，但如果回答变差，那这个加速的意义就得打折。建议等有人补上质量对比和长上下文测试再下结论。

这篇是 OpenAI 讲自己内部怎么部署 Codex 的安全实践，不是产品说明书，更像运维团队的操作记录。核心思路是把智能体关进沙箱，只让它在指定目录读写，低风险操作自动放行，高风险动作必须等人批。网络访问也做了限制，只允许访问已知的安全域名，像 pastebin.com 这种直接封掉。身份认证强制走 ChatGPT 企业账号，凭据存在系统钥匙串里，活动日志进合规平台。 我会先打个折：文章给了配置片段，但没披露任何量化指标。比如自动审批拦了多少次、误拦率多少、有没有发生过越权事件，这些关键数字全缺。它更像在说“我们有这套机制”，而不是“这套机制跑下来效果如何”。 对想抄作业的团队来说，沙箱加审批的策略方向没问题，但落地时得自己补监控和度量。另外，它提到的 auto-review 子智能体自动批低风险请求，这个设计挺实用，能减少打断频率，但正文没讲这个子智能体本身的决策准确率，这点先别太激动。

这篇博文讲的是 OpenAI 内部部署编程代理 Codex 时的四道安全锁：用沙箱圈定执行范围，高风险操作必须等人拍板；网络只开放已知域名，陌生域名要审批；身份认证强制走企业 ChatGPT 工作区，凭证存系统钥匙串；所有行为都留日志方便审计。 比较实用的是那个“自动审核”模式，低风险操作机器自己批，不用每次都打断人。但正文没披露任何评估数据——比如自动审核的准确率、误拦了多少正常操作、有没有出过安全事故。这些数字才是判断方案是否靠谱的关键。 另外，这套配置看起来是给 OpenAI 自己的企业环境定制的，没提对其他公司的适配要求或部署门槛。如果你不是 OpenAI 的企业客户，能复用多少还得自己试。