跳到正文

2026年08月21日AI 版

6 条 · 3 个来源

头版

行业动态OpenAI

AI 期货问世
OpenAI公开讨论AI对权力与治理的影响,但理论与落地间仍有距离。

OpenAI 把风险议题的定义权先放到自己博客里:政策制定者若把“AI Futures”当治理路线图引用,就等于让模型厂商替公共机构划定风险边界;现阶段更稳的做法是只把它当议题信号,不当作合规承诺。

展开全文

依据

OpenAI 在官方博客新设“AI Futures”(AI 未来),称要公开讨论变革性 AI 对权力、治理、经济和个体自由的潜在重塑。机制是:头部实验室通过设定词汇和议题,影响公共讨论与政策框架设计;政策圈一旦引用这些概念,风险分类和优先级就由厂商参与定义。但材料显示,栏目目前只有概念阐述,没有具体路线图或实证案例,也没有说明它与 ChatGPT 等实际产品部署的关系。于是它释放的是话语信号,成本低、可进可退;外界的取舍应是引用其观点可以,但不能把未承诺的治理动作当成已承诺的合规义务。

没写清 材料没说“AI Futures”与 OpenAI 的产品部署、政策提案或内部治理流程之间有什么可核对的连接。

下一步 下一次可核对:该栏目是否发布带时间表、责任人或政策条文引用的后续文章。

行业动态

1

  1. 行业动态OpenAI

    Stampli 使用 ChatGPT Work 将启动时间缩短 68%
    省68%启动时间,代价是设计资源他移,适合急上线团队参考。

    如果你手上是固定上线日期、设计人手又已被别的项目抽走,这个案例的取舍是:把重复性设计与开发环节交给 Codex 和 ChatGPT Work,用后期人工审查换数天上线。产品与设计负责人得先在「准时发」和「少返工」之间选一个。

    展开全文

    依据

    Stampli 对外说明:在固定截止日期、设计资源已投向他处的前提下,它用 Codex 和 ChatGPT Work 把原本需要数周的发布生产压缩到数天,启动时间节省 68%。机制上,AI 工具接走的是设计或开发流程里的重复性工作,人力工时随之下降;代价不在工具本身,而在设计资源被挪走之后,产出要在后期补上更多人工审查和微调。原文还点明,节省幅度高度依赖任务的可自动化程度,所以 68% 是这一类任务上的结果,不是能照搬的通用比例。Codex 是 OpenAI 的代码生成工具,ChatGPT Work 是面向工作场景的对话式助手。

    • 启动时间节省68%
    Stampli 用 AI 工具后的启动时间节省幅度

    没写清 材料没有给出节省前的总工时,也没说被抽走的设计资源去了哪个项目,所以算不出 68% 对应的绝对天数。

    下一步 下一步可核对的是 Stampli 是否公布上线后追加的审查或返工工时。

AI工具

4

  1. AI工具Simon Willison

    ChatGPT 搜索现大规模支持 site: 运算符
    搜索引入site语法,精准度提升但依赖站点收录范围。

    这条改的是做 GEO(生成式引擎优化)监控的团队的追踪口径:当 site: 占比从 0.3%–0.5% 一步跳到 16–17%,品牌在回答里的曝光就不能再按“自然检索结果”来算,得先剔掉被站点收录范围卡住的那部分。

    展开全文

    依据

    Simon Willison 在 8 月 20 日的链接博客里引用了 Promptwatch 的聚合追踪:ChatGPT 搜索的 fanout 查询(一次提问被拆成的多条子查询)中含 site: 操作符(把检索限定在指定域名的搜索语法)的比例,连续数周停在 0.3% 到 0.5%,8 月 3 至 5 日短暂降到 0.15%——他把它读作分阶段上线或上线前实验——8 月 8 日跳到 16–17%。时间点对得上 OpenAI 8 月 6 日那则措辞含糊的公告:为 Plus 和 Pro 用户更新 GPT‑5.6 Sol 在 Chat 中的事实可靠性与回答聚焦度。机制上 Willison 猜新搜索工具的形状更像 search(query, recency, domains),域名由工具内部填,而不是鼓励用户手打字面 site:。Promptwatch 8 月 18 日的跟进报告称 ChatGPT 明显降低了这些搜索里使用 Reddit 的概率,但 Willison 查过他所知最全的泄露系统提示词合集,未见相关改动。

    • 连续数周常态0.3%–0.5%
    • 8月3–5日低谷0.15%
    • 8月8日跳升16–17%
    ChatGPT 搜索中含 site: 操作符的 fanout 查询占比变化

    没写清 Promptwatch 只统计它开了自动追踪的那部分提示,材料没说这批提示如何抽样,所以不能把 16–17% 当成 ChatGPT 全局查询的占比。

    下一步 等 Promptwatch 下一份日更报告,看 site: 占比是否仍守在 16–17%,以及 Reddit 使用率的降幅是否同期出现。

  2. AI工具Hugging Face

    LFM2.5-DSpark 推理速度提升高达 3.2 倍
    速度提升3.2倍,但需验证是否以精度或资源为代价。

    端侧或单卡部署 LFM2.5 的人,现在要按内存预算而非精度来决定挂不挂 DSpark:约 300M 参数的 draft 模型换 2.27x 到 2.67x 吞吐,代价是一小块常驻显存,而 8B-A1B 端侧只多 18%。

    展开全文

    依据

    LiquidAI 的 Leonie Monigatti、Fernando Fernandes Neto 等作者在 Hugging Face 发文,为 LFM2.5-1.2B-Instruct、LFM2.5-2.6B、LFM2.5-8B-A1B 发布 DSpark draft model checkpoint。机制上,LLM 推理的 decode 阶段受显存带宽限制(memory-bound),延迟主要来自把权重从 DRAM 搬进 SRAM,而不是算力;speculative decoding(投机解码)先用轻量 draft 模型猜若干 token,再由 target 模型一次前向全部验证,把同一份权重加载成本摊到多个 token 上。DSpark 由三部分组成:DFlash 式并行骨干、一个 Markov 链形式的轻量顺序头(补相邻 token 依赖,抬高后位接受率)、以及按置信度剪掉低置信后缀的 verifier。draft 模型各约 300M 参数、5 层、block size 9,训练时按接受率而非 loss 挑 epoch。作者给出的对照:H100 上平均 2.67x(323 → 864 tok/s),M4 Max 上平均 2.27x(61 → 139 tok/s),2.6B 在多工具场景延迟平均降 57%;但 8B-A1B 端侧平均只提升 18%,作者把它归因于 llama.cpp 的 Metal 后端 MoE 实现,以及验证 k 个 token 会激活更多专家。

    • H100 平均吞吐(5 个数据集)323 → 864 tok/s
    • M4 Max 平均吞吐61 → 139 tok/s
    • 2.6B 多工具场景延迟降 57%
    • 8B-A1B 端侧平均提升18%
    DSpark 在三款 LFM2.5 上的吞吐与延迟变化

    没写清 材料只写「a minimal memory increase」,没给 draft 模型的显存增量绝对值,所以这块钱到底多大无法替它核算。

    下一步 等 llama.cpp 的 Metal 后端更新 MoE 实现后,核对 LFM2.5-8B-A1B 端侧平均提升是否仍停在 18%。

  3. AI工具Simon Willison

    基于 Bun 1.4 新 Bun.WebView 的 shot-scraper 风格 JSON API
    用WebView替代浏览器自动化,成本或降低但兼容性需实测。

    Simon Willison 用约 150 行 TypeScript 证明 Bun.WebView 能不靠 Puppeteer、Playwright 起一个 JSON 接口;想砍掉这两个依赖的团队,先按 192MB-256MB 的容器上限和自家真实页面做兼容性实测,再决定拆不拆。

    展开全文

    依据

    Simon Willison 说,这个零依赖、约 150 行的 TypeScript 服务用 Bun 1.4 实验性的 Bun.WebView(Bun 内置的浏览器自动化 API,可走 macOS WebKit,也可通过 Chrome DevTools Protocol,即浏览器远程调试协议,驱动本地 Chromium 进程)做出 shot-scraper 风格的 JSON 接口:每个请求开一个标签页,/javascript、/screenshot、/healthz 三个端点把页面结果和错误都以 JSON 返回。他用 cgroups(Linux 的资源限制组,这里用来量容器内存上限)测出跑复杂网页要 192MB-256MB 的容器。对照 Bun 1.4 自己的数字——修复 2,900 多个 issue、从 Node.js 测试套件新增 +1,517 条测试、空闲 CPU 降 5x、内存最多降 35%——省下的是依赖与协议栈,代价落在 WebKit 那条路径上:它是官方刚开放的能力,不是被 Playwright 长期压测过的路径。

    • 跑复杂页面所需容器192MB-256MB
    • 空闲 CPU 占用降低 5x
    • 内存占用至多降低 35%
    • 新增 Node.js 测试+1,517
    Bun 1.4 的官方数字与这个原型的容器占用量级

    没写清 材料只给了单个原型的内存占用,没有同一批真实页面上 WebKit 与 Chromium 两条路径的失败率对照,省依赖之后的兼容性代价有多大,无法替 Simon 补结论。

    下一步 在同一批目标页面上,让 Bun.WebView 与现有 Playwright 脚本跑同一条 JavaScript 与截图任务,比对两边的失败率。

  4. AI工具Simon Willison

    smolmachines / smolvm 作为不受信任 Python 与 JavaScript 的沙箱
    沙箱跑不可信代码,性能与隔离取舍需实测,别当安全承诺。

    给要跑用户提交 Python/JS 的人,取舍不在「能不能隔离」而在延迟预算:交互式任务得先接受冷启动 0.6–1.5 秒,再决定是否用硬件隔离虚拟机换掉共享内核容器。

    展开全文

    依据

    Simon Willison 实测 smolvm 1.8.3:它用硬件隔离虚拟机(hardware-isolated VM,每个沙箱跑在独立内核的虚拟机里)而非共享内核容器(shared-kernel container,进程共用宿主内核)来隔离不可信代码。离线本地镜像、禁网执行、CPU/RAM 上限、guest 内超时、存储配额、只读输入挂载、可写输出挂载和 --unprivileged 都按预期工作,代价是冷启动 0.6–1.5 秒、热执行约 50 ms。他让 Claude Fable 5 在 Claude Code for web 里做这项研究,该容器自身是 Firecracker guest(Linux 6.18.5-fc-v20,4 vCPU,15GB RAM),没有 /dev/kvm,也没有 vmx/svm 标志,嵌套虚拟化不可用,smolvm machine run 直接报「kvm not available」;于是改在暴露 /dev/kvm 的 GitHub Actions ubuntu runner 上跑测试。

    • 冷启动0.6–1.5 秒
    • 热执行约 50 ms
    • 测试容器 CPU4 vCPU
    • 测试容器内存15GB RAM
    smolvm 1.8.3 的启动开销,以及无法嵌套虚拟化的测试容器规格

    没写清 材料只记录了各功能按预期工作,没有对抗性负载或逃逸尝试的实测结果,因此不能替它补上安全强度的结论。

    下一步 在暴露 /dev/kvm 的 GitHub Actions runner 上重跑同一批测试,核对 0.6–1.5 秒冷启动与约 50 ms 热执行是否复现。