跳到正文

2026年09月22日AI 版

8 条 · 5 个来源

头版

行业动态Simon Willison

Cloudflare Python Workers 现已正式可用
正式可用意味着可上生产,但冷启动与生态兼容仍需自测评估。

让正在选型的 Python 后端团队把「Python Workers 只能做原型」从否决项里划掉,改用 WebAssembly 虚拟机里多进程与多线程都跑不起来这条硬约束,先筛掉需要并发的任务。

展开全文

依据

Cloudflare 在结束两年预览后声明「Python is now a first-class, fully supported language on the Cloudflare Developer Platform」,发布公告署名 Gyeongjae Choi、Dominik Picheta、Hood Chatham,其中 Gyeongjae 与 Hood 都是 Pyodide(把 CPython 编译成 WebAssembly 的项目)的核心维护者。机制是 Python 先经 Pyodide 编译成 WebAssembly(一种可在边缘节点执行的字节码格式),再进入 Cloudflare 基于 V8 的 workerd 运行时执行;代价写在官方 limitations 文档里:WebAssembly 虚拟机中 multiprocessing(多进程)与 threading(多线程)都不工作。本地这一侧,pywrangler(PyPI 上包名 workers-py)会跑整套栈的本地模拟,包括在 123MB 的 workerd 二进制里用 Pyodide 执行代码。

  1. Python 源码
    编译
  2. Pyodide 转 WebAssembly
    执行
  3. V8 workerd 运行时
    本地复刻
  4. pywrangler 本地模拟
Python Workers 的执行链路:源码经 Pyodide 转成 WebAssembly,落到 workerd 上跑。

没写清 材料没给冷启动延迟、支持的 CPython 版本范围,也没说依赖 C 扩展的第三方库能否在 WebAssembly 里跑通,这三点不能替它补。

下一步 对照 Cloudflare 文档 limitations 页,确认 multiprocessing 与 threading 是否仍标注为不可用。

行业动态

3

  1. Jev:面向生产而非 God 的 System One 模型 — 对话 TypeSafe AI 首席执行官 Diogo Almeida

    行业动态Latent Space

    Jev:面向生产而非 God 的 System One 模型 — 对话 TypeSafe AI 首席执行官 Diogo Almeida
    只一集播客,却把System One定位讲成生产取向,做落地的人该听。

    把模型嵌进软件依赖链的工程负责人,下次选型评审该先问「每一步决策能不能给出可校准的概率」,把它写成验收项;先看榜单分数再挑模型,等于把幻觉和人工兜底一起采购进来。

    展开全文

    依据

    TypeSafe AI 的 CEO Diogo Almeida 是 InstructGPT 论文的共同作者、OpenAI 后训练团队出身。他的说法是:ChatGPT 的成功让自回归聊天微调以外的模式全被丢掉,之后的函数调用、结构化输出、推理,都只是打在字符串序列预测范式上的补丁。他给出的替代方案叫 RLCD,即面向校准决策的强化学习(Reinforcement Learning for Calibrated Decisions):训练目标不是人类评分,也就是 RLHF(基于人类反馈的强化学习),而是在 System One 这类短任务上直接输出带认知诚实概率的答案。按他的说法,RLHF 会养出幻觉、谄媚和对人工的长期依赖;可编程验证的 RLVR 能解出 Navier Stokes,却加剧能力参差、不好接进其他软件。他要优化的不是单点正确率,而是能不能被别的程序安全调用。

    • 6 Astra137M
    • Navier Stokes74M
    • Jev 发布视频约 40M
    • GPT4o22M
    几支模型发布视频的播放量对照,Jev 约 40M

    没写清 材料没给 Jev 在真实生产负载上的可靠性数字,也没给 RLCD 的训练与推理开销,所以它在你的场景里省多少人工、错在哪一步,无法替它算。

    下一步 盯 TypeSafe 下一版模型(材料里预告的 ReasoningJev)发布时,是否同时给出概率校准的评测口径。

  2. John Ternus 能找到 Apple 的下一个重大产品吗?

    行业动态The Verge AI

    John Ternus 能找到 Apple 的下一个重大产品吗?
    库克交棒两周就发折叠屏,Ternus押注硬件救场,AI短板仍没解

    Ternus把苹果AI路线从库克式集体讨论改成CEO直接拍板,并用折叠屏iPhone Duo为AI短板买时间;开发者与供应链若继续等内部共识,排期会押错。

    展开全文

    依据

    彭博首席苹果记者 Mark Gurman 说,这场发布会“和 Tim Cook 的发布会几乎可以互换”,唯一不同是 Ternus 开场就亮出 AI 观点:先讲 intelligent personal hub(智能个人中枢)。他给的机制对照是管理风格:库克面对高管提案会不断追问,很多情况下不做一个单一决定,偏 communal decision-making(集体决策);Ternus 会直接给决定和观点。Apple Intelligence(苹果智能)自 WWDC 2024 推出已两年,Gurman 称其一直是 mishmash(杂烩),没有强叙事;Ternus 至少补上了观点。折叠屏 iPhone Duo 是首次亮相,且距他接替库克不到两周,Gurman 认为时机不是巧合。

    没写清 材料没说 Ternus 的 AI 观点具体怎么落到产品功能、算力或合作方上,也没给开发者迁移或收入数字。

    下一步 下一步看 Apple 是否公开 intelligent personal hub 的开发者接口与上线时间。

  3. 行业动态AWS Machine Learning Blog

    BMW Group 如何检测 14,000 个云账户中的成本异常
    BMW用Prophet做万级云账户成本预警,月费约50美元,适合多云团队参考。

    把云成本异常检测从月度账单复盘改成账户级实时告警前,多云团队得先定告警由谁处置——BMW 覆盖 14,000 个账户,误报会直接压到值班排班。

    展开全文

    依据

    AWS Machine Learning Blog 这篇的标题写明,BMW Group 要在 14,000 个云账户上检测成本异常。机制在于:账户数到万级以后,单账户的日成本曲线很平,一个跑飞的批处理任务混在集团总量里几乎看不出来,所以必须按账户或按业务单元分别建基线,再拿当天实际值去比基线、看偏离幅度;基线切得越细,抓得越准,告警条数也越多,误报的处置成本就从云账单转移到值班人力。这也是为什么先要定告警归属,而不是先选工具。

    • 云账户数14,000
    BMW Group 成本异常检测覆盖的云账户规模

    没写清 材料没写异常判定的阈值、误报率,也没写这 14,000 个账户按什么分组,因此无法估出实际告警量。

    下一步 可核对 BMW 或 AWS 后续是否补上误报率、或单月触发的告警条数。

AI工具

1

  1. AI工具AWS Machine Learning Blog

    在 Amazon SageMaker AI 上运行 Positron 以支持数据科学工作流
    一次工作流打通R与Python,代价是绑定SageMaker生态

    用 Positron 的团队要么继续各自维护 R 与 Python 两套环境,要么把整条数据科学工作流托管到 SageMaker AI:统一是拿到了,但退出成本由日后想迁走的那一步的人承担。

    展开全文

    依据

    AWS Machine Learning Blog 这篇公告只承诺一件事:Positron(Posit 出的数据科学集成开发环境,R 与 Python 在同一窗口跑)可以在 Amazon SageMaker AI 上运行,后者是 AWS 的托管机器学习平台,提供算力、镜像与运行环境。机制上,Positron 原本是本地优先的编辑器,一旦托管到 SageMaker,内核与算力改由 AWS 侧拉起,团队省掉的是自建 R 与 Python 双环境、双镜像的运维;让出的则是算力、身份与计费全部落进 SageMaker 的账号与权限体系,想换回自建或别家云,这套接入要重做一遍。所以变化不在编辑器层,而在选型层:拿主意的从每天写分析的人,变成管预算和合规的人,因为绑定的是账号而不是工具。

    没写清 材料只有标题级说明,没有写接入方式、可用区域和计费差异,因此无法判断迁移成本具体落在哪一步。

    下一步 可核对 AWS 官方文档里该方案的支持区域列表,以及 SageMaker 计费项是否单独覆盖 Positron 内核。

精选深读

3

  1. 精选深读Simon Willison

    Jev 推出一种新的 LLM 形态 - System One,又名 Decision Models
    只提决策模型形态却无评测数据,选型得先验证落地场景

    做风控、垃圾过滤或检索重排的团队,可以先把 Jev 放进影子评测,但别让它单独拍板;它省掉输出计费,代价是把可解释性也省掉了,出错时没有理由可查。

    展开全文

    依据

    Simon Willison 引述 TypeSafe AI 的 Jev:它把文本输入映射成带置信度的浮点决策输出,而不是文本。TypeSafe 称其为“frontier-intelligence function call”(前沿智能函数调用),即“非结构化状态进,带类型的概率决策出”。机制上,Jev 只按输入 token(文本计量单位)收费、输出免费,首模型输入价 $0.042/百万 tokens,低于 OpenAI GPT-5 Nano 的 $0.05/百万;同一文档可并行多问。但其 1.13 jaggedness 文档承认对数字、日期和对抗内容不强。Willison 还指出它更黑箱:只回浮点数,若判垃圾邮件也无法知道哪个信号触发,用于招聘排序会掩盖偏差。取舍是:高吞吐、低单次错误代价的分类可先做影子评测;需要申诉、审计或解释的决策不应让它单独拍板。

    • Jev 输入价$0.042/百万 tokens
    • GPT-5 Nano$0.05/百万 tokens
    Jev 与 GPT-5 Nano 每百万输入 token 价格对照

    没写清 材料只给了价格、样例用法和黑箱警告,没给 Jev 在垃圾过滤、检索重排等任务上的准确率、校准或偏差审计结果。

    下一步 下一步可核对 JevBench 是否公布 Jev 与 Kev 0.8B/4B/9B 的按任务准确率和校准数据。

  2. 精选深读AWS Machine Learning Blog

    xAI 的 Grok 4.6 现已在 Amazon Bedrock 中可用
    做长时代理才划算,Grok 4.6 有500K窗口和四档推理

    在 AWS 上构建代理的团队,现在要把 Grok 4.6 纳入 Amazon Bedrock 的模型选型,而不是默认走 xAI 独立接入;跟现用模型比,是否切换取决于它在既有代理评测里的表现,失败点会落在任务成功率或延迟不达标上。

    展开全文

    依据

    AWS Machine Learning Blog 说,xAI 的 Grok 4.6 已在 Amazon Bedrock 上可用。Amazon Bedrock 在原文里是构建生成式 AI 应用与代理的端到端平台;机制上,AWS 用户可在同一托管平台内选用 xAI 模型,不必为调用 Grok 单独维护 xAI 接入。原文材料只确认模型上架,没有给出窗口大小、推理档位、定价、区域或限流等可对照数字,因此不能替它补上这些规格比较。

    没写清 原文材料没有说 Grok 4.6 在 Bedrock 上的区域覆盖、定价、限流,以及与 xAI 直连的延迟差异。

    下一步 下一步可核对 Amazon Bedrock 模型目录里 Grok 4.6 是否列出具体 region 和定价页。

  3. 精选深读Hugging Face

    像物理学家一样裁剪 LLM:将块移除视为 Ising 优化问题
    把LLM块移除转成Ising优化,是剪枝新视角,但落地成本待验证

    如果团队要在 Llama-3.3-70B-Instruct 上做 50% 深度剪枝,应把选块决策从逐块打分改成先一次性算 Hessian 耦合、再交给约束二元优化求解器;多付标定与求解器工程成本,换 MMLU 相对最佳竞品块移除方法近 23 个百分点。

    展开全文

    依据

    Multiverse Computing 的 Antonio Tiene、Ali Hashemi、David Jansen、Roman Rausch 在 Hugging Face 论文页提出,把删除哪些 transformer 块从排序问题改成约束二元优化(CBO, constrained binary optimization)。他们给每块一个 0/1 变量,0 保留、1 删除;对损失做二阶泰勒展开得到近似 Hessian(海森矩阵),对角项是单块重要性,非对角项是块间耦合。最小化 xᵀH⁰x 且恰好删 M 个块,等价于在伊辛玻璃(Ising glass,全连接耦合、自旋数守恒的自旋系统)里找低能态。低能态被当作下游质量的代理,因此可跳过逐候选跑基准。Hessian 只用小标定集的前向/反向传播算一次,之后每个候选只需一次能量计算;作者报告 Llama-3.3-70B-Instruct 在 50% 压缩下,MMLU(多任务语言理解基准)比最佳竞品块移除方法高近 23 个百分点。取舍在于:精确求解可行时用精确,不可行时依赖量子或量子启发式求解器,前期工程与求解时间不是零。

    • Llama-3.3-70B-Instruct 压缩率50%
    • MMLU 相对最佳竞品块移除近 23 个百分点
    50% 压缩下 MMLU 增益对照

    没写清 材料没给标定集规模、求解器实际耗时,也没给除 MMLU 外的任务、推理延迟和内存实测,所以不能替它补上部署总成本。

    下一步 核对论文的标定集规模与求解器运行时间,并在同一 Llama-3.3-70B-Instruct 配置下复现 50% 压缩的 MMLU 增益。