IT社区推荐资讯 - ITIndex.net

全球最富有 0.1% 人口产生的碳污染超过全球最贫困 35 亿人口的总和

Thu, 29 Oct 2026 18:22:00 CST

根据乐施会（Oxfam）的一份报告，全球最富有 0.1% 人口_——大约 800 万人——产生的碳污染超过全球最贫困 35 亿人口的总和。报道敦促各国政府让富有的污染者承担代价。报告称，富人对今天极端热浪的贡献几乎是最贫困的 50% 人口中个人贡献的 400 倍。这少数人所产生的碳污染总量，超过了撒哈拉以南非洲地区——13 亿人口——的总排放量。自 1990 年以来，全球最富有的 1% 人口造成了 20% 的全球变暖。私人航空主要由超级富豪使用，是极端碳不平等的典型例证。乐施会对私人飞机追踪数据进行的分析发现：全球私人飞机在两秒钟内排放的碳污染总量，超过了全球最贫困的一半人口中个人一年的碳排放量。尽管超级富豪造成了不成比例的碳污染，但由此引发的洪水、火灾和饥荒，其后果却主要由普通民众承担。超级富豪可以通过购买私人保险，并在更安全、气候更凉爽的地方置业来获取安全保障。

PHP 嚴重的 RCE 漏洞「PHP2Shell」解法

Thu, 22 Oct 2026 19:19:00 CST

PHP 爆發出史上最嚴重的 RCE 漏洞「 php2shell」（CVE-2026-109618 與 CVE-2026-109619），評分高達 9.2分

PHP 官方公告： Security advisory: Critical remote code execution vulnerabilities, update now
CVE 漏洞細節： RCE via OOM corruption · Advisory · php/php-src · GitHub
Wiz 漏洞分析： PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet

嚴重到日本首相高市早苗都直接宣佈：

「各位，今晚有件極為緊急的請求，希望各位能配合處理」，呼籲所有公開營運的網站管理者確認是否使用PHP，並 在修補程式公開前做好準備盡速套用；如果難以在第一時間修補，暫停網站運作也是降低風險的有效做法之一

先說解法：

PHP 8.2 以上：用官方 Patch 或 Debian 官方套件 apt upgrade 即可
PHP 7.x 以下(暫解)：可以考慮此篇文章 php_uploadprogress_guard 的套件(.so)

目前 PHP 官方有出的 Patch：8.5.12、8.4.27、8.3.36、8.2.35 ( 正解是需要升級到這些版本)

針對 7.x 以下的版本，官方目前還沒有提供 Patch，所以需要另外處理，有提供 ini 檔的修改解法：(不過下面兩位專家說沒用)

session.upload_progress.enabled = Off
post_max_size = 8M or 32M (限制大小）
memory_limit = -1
max_input_nesting_level = 8 (設小一點)
expose_php = 0
PHP 8.5：fatal_error_backtraces = 0 (關閉)
PHP-FPM：pm.max_requests 設小一點

PHP Foundation 的核心開發與管理機構成員：

Gina Peter Banyard（PHP 核心開發者與文件維護者）： 「唯一的緩解措施就是直接進行修補或升級 PHP」，不存在任何十全十美的臨時替代方案
Gina Peter Banyard, a PHP core developer and documentation writer funded by the PHP Foundation, wrote: " The only thing I can say is that the only mitigation is patching / upgrading PHP." I sadly know too much.
Joe Ferguson（PHP 8.6 版本 Release 管理員）：「 ini 設定救不了你（ini settings won't save you）。」警告所有站長切 勿依賴修改 php.ini 配置來當作避風港
Joe Ferguson, the release manager for the coming PHP 8.6, put it shorter: "ini settings won't save you."

PHP 嚴重的 RCE 漏洞「PHP2Shell」解法

PHP2Shell 這次事件影響的 CVE 和詳細說明可見：

CVE-2026-109618: Remote Code Execution via Memory Exhaustion
- CVE-2026-109618：記憶體不足（OOM）時，中斷尚未完成的內部資料初始化，清理階段可能誤用無效資料
- Reported by: Calif, Wiz, OpenAI, and Quarkslab.
CVE-2026-109619: Remote Code Execution via Fatal Errors
- CVE-2026-109619：舊請求留下的全域狀態仍指向已釋放的記憶體，後續請求可能重複使用該指標
- Reported by: Wiz, Calif, and OpenAI.
詳細說明：
- PHP2Shell: When PHP Runs Out of Memory at the Wrong Moment | Imperva
- php2shell by Calif Research - A tale of two PHP remote vulnerabilities

此次建議的作法：

立即升級：確認實際在背景處理網頁流量的 PHP
版本與映像檔，套用上述安全版本並重啟工作程序（Worker / FPM）
預防性下線：若無法立即完成修補且對外曝露，多國資安單位與政府（如芬蘭、荷蘭等）建議暫時將受影響的公開網頁與服務離線
檢查日誌與後門：檢視 WAF（網頁應用程式防火牆）紀錄、伺服器排程與檔案變動，確認是否有異常請求或未授權存取痕跡
官方緊急修補版本 (2026年10月21日釋出)
- PHP 8.2 ➔ 請升級至 8.2.35
- PHP 8.3 ➔ 請升級至 8.3.36
- PHP 8.4 ➔ 請升級至 8.4.27
- PHP 8.5 ➔ 請升級至 8.5.12

OpenAI 有推出檢測工具： GitHub - openai/php2shell-checker · GitHub

PHP 官方 7.4 的 Patch： Comparing master...PHP-7.4-CVE-2026-109618-109619 · php/php-src

Debian Security Bug Tracker 的套件更新狀態：

目前看來，針對 PHP 8.2 以上的，建議直接 apt update; apt upgrade 作升級動作即可

針對 PHP 7.x 以下的解法，可以考慮此套件 php_uploadprogress_guard (Hosted Power 主機商公司 Open Source)：

GitHub - HOSTED-POWER/php_uploadprogress_guard: Protects an unpatched PHP against php2shell (CVE-2026-109618 / CVE-2026-109619): a small extension that mirrors the official fix component by component and steps aside once the engine carries it. PHP 5.6-8.5; Sury, cPanel EA4, DirectAdmin, Docker, Windows. · GitHub

php_uploadprogress_guard 套件內容：

dist 各個版本 so： https://github.com/HOSTED-POWER/php_uploadprogress_guard/tree/main/dist # 這邊有直接編譯好的 so 檔，不過我習慣還是自己編譯
Source code： https://github.com/HOSTED-POWER/php_uploadprogress_guard/blob/main/src/hp_uploadprogress_guard.c
簡單說，若無法升級 PHP，那這個套件可以暫時先頂著，但是不確定是否有全部擋到，現在最新是 v3.1.0，若有更新記得跟上去

php_uploadprogress_guard 安裝 (若使用 dist 的 so，就直接跳到 Step 8，將 *.so cp 到 /usr/lib/php/20190902/ 即可

sudo apt install php-dev
git clone https://github.com/HOSTED-POWER/php_uploadprogress_guard
cd php_uploadprogress_guard/src
phpize
./configure
make
make test
sudo make install
- Installing shared extensions: /usr/lib/php/20190902/
echo 'extension=hp_uploadprogress_guard.so' | sudo tee /etc/php/7.4/mods-available/hp_uploadprogress_guard.ini
sudo phpenmod hp_uploadprogress_guard
sudo apache2ctl configtest
sudo systemctl restart apache2.service
php -m | grep hp_uploadprogress_guard # CLI 能執行不是重點，只是參考
重點是線上要有看到 hp_uploadprogress_guard enable 等等的資訊
- php --ri hp_uploadprogress_guard # cli 但是這個不是重點

REA 逆向神器，AI 时代不再有闭源软件

Sun, 18 Oct 2026 22:16:02 CST

闭源软件还会存在。但我们已经很难继续把「没有源码」当成一道足够可靠的理解门槛。

截至 2026 年 10 月 18 日，写这篇文章的时候，REA 的 GitHub 原仓库显示约 316K Star、80K Fork（半天增加将近 1 万 Star）。社区讨论的内容中包括如何理解一个函数，延伸到了旧软件维护、跨平台实现，以及某些商业软件是否还能维持原有优势。这些数字说明项目受到广泛关注，无法证明实际使用人数，更无法证明复杂应用已经可以被完整复现。 GitHub 原仓库

当模型能够持续调用反编译器、追踪引用、检查交付包，再把结果组织成可继续查询的证据，软件的分析成本会怎样变化？技术团队此前依赖的哪些假设，需要重新评估？

这是一篇基于 REA 源码的分析文章，比读源码稍微好一些，其目的是快速了解 REA 是什么，解决了什么问题，以及如何解决这些问题的。

在开始文章之前，我们需要了解： REA 不是能独立完整逆向的工具，它只是一套模型能调用的工具（以 MCP 或 CLI 的方式），帮助 Codex 这类 Agent 调查程序。根据目标类型，调查返回模块关系、函数位置、调用线索或编译指令等信息，模型再据此解释行为、编写实现和运行检查。

逆向是什么

逆向工程从交付产物和可观察行为出发，推导程序的结构、接口与实现逻辑。输入可以是可执行文件、程序集、ASAR、APK，也可以是抓包、崩溃记录和一段运行过程。

编译会丢失部分信息。机器码通常无法直接告诉我们原始变量名、注释、项目组织和开发者意图。反编译器生成的伪代码，需要结合汇编、字符串、引用、数据布局和运行行为来解释。反编译文本足够可读，仍然可能在类型、边界和间接调用上留下问题。

因此，逆向的交付应该围绕具体问题。一个长度字段怎样编码，某个按钮怎样触发文件读写，某个版本改变了哪条分支，都能形成有限的调查范围。要求恢复一个应用的完整源码，会把目标扩大到原始工程、构建环境、资源、依赖和未观察行为，验收条件随之失去约束。

传统逆向工作流中，逆向分析者负责把这些线索连接起来：搜索字符串，定位引用，检查函数，修改假设，再设计实验。AI 参与后，大量重复查询和跨文件追踪可以交给 Agent。分析者仍需决定哪些证据足以支持结论，以及哪些未知会影响后续实现。

这里要区分「功能解释」和「复现正确」。模型能够解释一段伪代码，只完成了前者的一部分。实现通过几个样例，也只能支持已经覆盖的输入。把有限观察写成整个软件等价，会让后续开发继承一份未经验证的规格。

热度背后的需求

REA 的爆火我觉得来自两个方面：一个是逆向作为一个传统的门槛非常高的工种，当前 Agent 结合 REA 能把这个门槛降得很低；另一个是对于一个传统闭源的软件，用这套工具可以复刻一个出来，这种打破规则的禁忌也让人着迷。

REA + Agent 解决了逆向工作中的一个特别重要的问题：模型已经能读懂不少代码，工程师却仍需手动替它操作分析工具。

Ghidra、Hopper、IDA 各有自己的数据库、API 和使用方式。面对 Electron，又要处理 ASAR、模块加载、preload 和 IPC。问题一旦跨越技术层，分析者就要在多套工具之间搬运上下文，判断地址、路径和符号是否指向同一对象。

REA 把这些能力接到 CLI 和 MCP 上。人可以直接运行命令，Agent 可以调用工具，返回结果使用统一的来源和限制描述。这让调查可以围绕一个问题持续推进，减少人工整理每一次工具交互的工作。

社区期待在这里已经失控。

能够降低分析成本，与能够经济地完整复现一个大型软件，之间还有很长的距离。交互细节、异常分支、数据格式兼容和未被触发的行为，都要进入验证范围。Star 和演示很难呈现这部分成本。

GitTested 对 REA 6.2.0 的测评提供了一个约束：在四个不超过 264 KB 的去符号原生程序上，普通工具组得到 74/75 的事实检查分数，REA 组为 73/75，后者使用的 token 约为前者的 2.5 倍。这份结果针对特定版本、模型和小程序，无法外推到当前全部能力；它足以说明，增加分析工具没有自动带来更高收益。测评原文

我们做选型时，应当保留普通工具基线。复杂度较低的任务，如果文件读取、搜索和 objdump 已经能回答，额外加载大型工具目录和完整图结果，可能只是在增加任务成本。

REA 与当前的工具如何协作

REA 的生产主链没有一个必须内置的通用大模型规划器。模型通常来自 Codex、DeepSeek Harness 等调用端，负责提出下一次查询；REA 提供具体分析操作，管理目标、结果和相关资源。

当前的 6.5.0 版本总共声明了 207 个工具合约、6 个引导式 Prompt。原生路径包含函数档案、伪代码、汇编、字符串、交叉引用、调用图，以及字节和类型检查。反编译主要由外部引擎承担，REA 负责把结果转换为统一表达。

这个统一不是一模一样。不同引擎能提供的事实不同，不能为了得到整齐的返回格式，给缺失能力填上空数组。REA 会保留不可用原因和覆盖信息。调用者需要知道某个侧面没有观察到，或者该 Provider 根本不支持。

引擎选择也没有被藏起来。自动模式只有在存在唯一可用分析配置时才建立深度绑定；多个候选均可用，会报告歧义。显式选择的引擎失败，也不会悄悄换成另一个，再继续沿用原来的来源说明。

这种设计牺牲了一点使用上的顺滑，换来了可解释的结果。如果分析过程中发生了引擎切换，类型恢复、函数边界和调用关系都可能改变。让调用者作出选择，比把差异隐藏在成功响应里更适合需要复查的调查。

CLI 与 MCP 共用应用工作流，生命周期有所区别。CLI 通常执行一次便结束，MCP 可以保留目标和调查状态。连续研究同一个大目标时，会话复用与快照有价值；只有一次明确查询时，单次命令更容易控制输入和输出。

跨层分析难点

以 JavaScript 和 Electron 路径为例，其尤其能体现 REA 自身的分析工作。

一个文件导入功能可能从 renderer 进入 preload，经 contextBridge 和 IPC 到达主进程，最后调用原生扩展。搜索按钮文本只能得到入口，import 图也无法独立解释跨进程关系。

REA 会解析 AST，建立作用域、绑定、引用和模块来源，再投影为应用图与语义图。别名、解构、成员变更以及部分打包结构，都要参与判断。代码里出现同名函数，不能证明调用来自同一个模块；局部变量遮蔽之后，相同文本甚至可能对应完全不同的行为。

IPC 配对采用较保守的条件：字面量 channel 与通信模式相容，且存在唯一候选，才生成确定配对。多个候选保留歧义，动态 channel 无法证明时保持未配对。这里的静态关联也没有自动升级为运行时事实。

这种策略适合回答「 应该继续查哪里」。遇到运行时计算、动态加载或不透明影响，静态图会留下缺口。继续扩大扫描范围未必能填补缺口，可能需要转向指定动作的运行观察。

源码文本进入 AST，再变成语义 IR、应用图和 Evidence，中间表示会扩大内存需求。REA 把解析分析放在独立受控进程中，使用堆限制、超时和传输预算；部分遍历、校验和摘要计算通过协作检查点响应取消。

独立进程增加了启动、序列化和数据交接成本，却能为大 bundle 提供更清楚的资源边界。面对少量文本，普通搜索更轻；面对跨模块来源和 Electron 边界，结构化分析才可能抵消这笔开销。

能力各有边界

REA 的其他模块也遵循专题分工。

.NET 路径自己读取 PE/CLI 元数据、类型成员、IL 方法体和托管原生边界，不需要运行程序集。它适合结构调查，不能因此承诺恢复完整 C# 工程。Android 又拆成 JADX 静态代码、Apktool 资源解码、ADB 设备操作和 JEB 接入，避免把看代码与安装、启动应用混成一个权限层次。

包与资源模块负责目录、ZIP、ASAR、DMG 和架构切片的清单、摘要及提取。Apple 专题进一步处理 plist、Interface Builder、动态库解析和相关元数据。输入身份从这里建立，后面的分析才能确认读取的是同一份内容。

固件依靠 Binwalk、Unblob 等外部工具识别区域和提取内容；Flutter 路径检查构建、ABI 与 Dart AOT 线索；WASM 借助 WABT 读取验证结果、结构和 WAT；EVM 借助 EVMole 提取 selector 和推断接口。它们的输出范围各不相同，统一称为「还原源码」会抹去重要限制。

Go、Rust 模块主要读取嵌入的构建或依赖信息。SQLite 检查稳定数据库及 WAL 的私有副本。抓包和录制信号模块解释已有记录。元数据缺失，不能推出依赖不存在；某个窗口没有观察到请求，也不能推出功能从不访问网络。

这些模块的价值取决于问题。需要了解依赖时，读取元数据比启动反编译器更合适；需要解释某条数据路径时，元数据又不足以代替函数和运行观察。选工具之前，先确定哪种事实能够改变当前判断。

证据决定结论

REA 的 Evidence 记录了目标摘要、Provider、分析配置、操作参数、原始与标准化结果、位置、限制及关联证据。它让模型的解释可以回到具体来源，而不只剩一段听起来合理的文字。

其中 observed、derived、inferred 区分观察、推导和推断，表达的是知识来源，不能当成概率。观察到反编译器输出某段伪代码，与证明这段伪代码准确描述所有行为，仍然是两件事。

证据 ID 根据语义内容生成。目标的展示名称和本地路径被排除，其他参数、结果或位置中的路径依然可能影响摘要。这种身份设计方便保存和交换，也要求我们理解它证明了什么：摘要匹配可以检查内容一致性，无法替代引擎正确性和解释正确性。

快照进一步绑定目标、Provider、分析配置、操作和参数。读取实时状态的能力不能被历史缓存伪装成当前观察，依赖隐含光标或文档的查询也需要额外约束。缓存命中率只能在这些条件成立之后讨论。

未知问题有独立的版本和状态。一个问题可以被验证解决，也可以被撤回或排除在范围外。后两种状态并不提供事实已经成立的证明。对需要交付分析结论的团队，这种区分应当进入评审，而不只停留在模型提示词里。

运行才有观察

静态分析留下的关键疑问，需要通过实验减少。REA 的浏览器、Inspector、PTY、LLDB、GDB 和 Frida 等模块提供了不同观察路径，各自有明确的影响范围。

被动附着页面读取信息，与启动应用、点击按钮或加载插桩脚本，涉及不同状态变化。一次动作完成后，还要分别确认截图、DOM、网络、存储等采集项是否成功，不能用动作成功代替采集完整。

程序退出、输出关闭和清理完成，也有各自的观察条件。客户端超时可能只结束等待；后台工作仍然执行。进程 leader 退出之后，后代进程可能继续存在。PID 还可能被复用，仅凭一个数字无法确认终止权限。

REA 使用运行 token、进程身份和资源 owner 管理这些边界。共享启动过程中，一个等待者取消，不应打断其他调用者；最后一个等待者离开时，又要等生产者收尾。清理失败则保留原 owner，以便后续对尚未释放的资源重试。

这部分代码增加了状态复杂度。并发、取消和最终收尾的组合很难靠正常路径测试覆盖。但逆向任务的单次执行成本可能很高，错误地重启分析器或留下后台进程，会让下一轮调查继承无法解释的环境。长会话系统需要承担这笔工程成本。

如何使用 REA

Codex、DeepSeek Harness 与 REA 可以通过 MCP 组合。我们没有必要为了接入逆向能力，再实现一套 Agent loop。

Harness 负责模型、工具执行、上下文、会话和插件生命周期；REA 负责分析目标、引擎及证据。两边都有会话，含义不同。模型会话保存了工具结果，不代表 REA 的进程和目标状态也已经被完整保存。

在 Codex 中，可以使用 REA 的 setup 先查看注册计划，再确认应用。手动方式则通过 Codex MCP 配置启动 rea mcp，并为原生分析设置合适的调用超时。

其实也可以直接把 github 的地址给 Codex，让它给你安装。

效率必须实测

分析规模越大，越需要区分计算完成与结果可用。

完整应用图和 Evidence 可能很大。MCP 同时承载文本和结构化内容，还受到传输预算、JSON 编码以及字符串表示的限制。让模型直接接收全部结果，可能把大量成本花在无关模块上。

REA 提供概要、受支持的分页视图和证据导出。超过传输预算时，部分路径会保留完整结果，再返回可继续读取的引用。分析没有被压缩成较小的事实集合，交付方式发生了变化。

但分页也有代价。模型可能先发现工具，再读概要，再取数页，再因选择错误重试。每次回复更小，整项任务的调用次数、上下文和延迟却可能增加。REA 自己的实验记录也保留了这种混合结果，回复字节减少没有稳定证明总 token 和耗时减少。

因此，性能评估应当以同一个问题的完整过程为单位：普通工具能否回答，使用 REA 后正确性是否改善，失败和重试多少次，总 token、时间与进程族内存分别是多少。冷启动和会话复用也要分开。没有这组对照，压缩输出只能算一次局部优化。

闭源边界变化

标题中的判断需要落到可讨论的范围。闭源作为分发和商业形态会继续存在；用户能否拿到原始源码，与能否推导部分实现逻辑，正在逐渐分离。

交付到本地的字节、资源、接口和运行行为，提供了调查输入。Agent 能持续利用这些输入，减少搜索、查询、整理和局部实现的人工成本。原来因为耗时而很少被分析的功能，可能因此进入更多人的调查范围。

这种变化会削弱一部分依赖信息不对称的优势。对于可以被独立描述、输入输出有限的功能，我们需要重新估计其被理解和重写的成本。仅凭实现复杂或代码不可见，已经很难为这个估计提供足够依据。

完整产品仍有不同的成本结构。兼容性、异常处理、版本演进和持续验证不会随着函数解释一同完成。远端执行、未提供的数据和未观察路径，也不会从本地文件中自动出现。分析工具可以报告边界，无法凭空补足缺失输入。

从技术管理角度，我们应当同时调整两端：研究外部软件时，把调查问题和验收范围收紧；评估自身产品时，减少对实现隐蔽性的依赖，把可验证的行为质量和持续维护能力纳入投入判断。

REA 已经把逆向工具、结构化证据和 Agent 调用连接起来，也在代码中保留了失败、歧义和未知。我们可以利用这套能力缩短调查过程，同时要求每一次功能解释都能追溯来源，每一次复现结论都能说明覆盖范围。缺少来源或覆盖声明的结论，应继续留在调查阶段，避免直接进入实现规格和验收报告。

但是， 最后逆向商业软件是有可能触发法律风险的，以及当前社区已经有人反馈，因为逆向导致 Codex 封号。

以上。

CPU、DRAM和SSD如今占了一台主流级别笔记本电脑制造成本的68%

Sun, 11 Oct 2026 17:54:00 CST

全球笔记本电脑市场可能在2027年面临新一轮下行压力。市场研究机构TrendForce最新报告指出，随着DRAM内存、CPU和固态硬盘等核心零部件价格持续上涨，笔记本电脑行业的主要风险正在从供应不足转向成本上升对消费者需求的冲击。如果厂商不得不将更多成本转嫁给消费者，终端售价上涨可能进一步延长换机周期，导致2027年全球笔记本电脑出货量出现更大幅度的下滑。

TrendForce目前预计，2027年全球笔记本电脑出货量将出现低个位数百分比的同比下降。不过，这一预测仍存在较大的不确定性。如果DRAM和CPU价格继续维持高位，笔记本厂商被迫进一步提高零售价格，全年出货量降幅可能扩大至高个位数百分比。

这意味着，2027年笔记本电脑市场的关键问题可能不再只是厂商能否获得足够的零部件，而是消费者是否愿意接受不断上涨的产品价格。

事实上，笔记本电脑市场在2026年的表现已经受到供应链变化的明显影响。年初以来，CPU供应情况有所改善，厂商也提前采购了大量零部件，同时部分原本计划在下半年甚至2027年购买电脑的消费者，出于担心未来涨价或缺货而提前完成换机。这些因素共同支撑了2026年上半年的市场出货量。

然而，TrendForce强调，这种出货表现并不意味着终端需求已经真正恢复。部分需求只是从未来提前释放到了当前。当原本计划在2026年下半年及以后购买电脑的消费者提前完成采购，后续市场自然会失去一部分潜在买家。

与此同时，厂商此前采购的低价零部件库存正在逐渐消耗。一旦这些库存被用完，企业就必须以更高的市场价格采购CPU、DRAM和SSD，生产成本将更直接地受到零部件涨价的影响。

内存价格上涨尤其值得关注。随着人工智能产业持续扩张，大型云服务商和数据中心运营商不断增加对AI服务器的投资。这些服务器需要大量高性能内存，尤其是用于人工智能加速器的高带宽内存。内存制造商因此将越来越多的生产资源投入利润更高、需求更旺盛的产品，普通PC所需的DRAM供应也受到影响。

这种变化正在传导至消费级电脑市场。尽管普通笔记本电脑使用的内存与AI服务器所需的高带宽内存并不完全相同，但两者仍然受到半导体制造产能、生产资源分配以及整体市场供需关系的影响。AI基础设施需求不断增长，使普通电脑厂商越来越难以获得价格稳定、供应充足的内存产品。

TrendForce指出，以一款建议零售价为900美元的主流笔记本电脑为例，2026年第三季度，CPU、DRAM和SSD三类核心零部件合计已经占到整机物料清单成本的约68%。

这一比例凸显了核心零部件价格对笔记本电脑定价的巨大影响。当CPU、内存和固态硬盘占据整机物料成本的大部分时，即使其他部件的成本保持不变，这三类产品的价格上涨也足以明显推高整机制造成本。

对于笔记本电脑厂商来说，这将带来一个难以解决的经营问题：如果提高零售价格，消费者可能推迟购买；如果维持原有价格，企业的毛利率就会受到挤压；如果通过减少内存容量、降低其他硬件规格来控制成本，又可能削弱产品竞争力。

这三种选择都存在明显缺陷。

提高售价是最直接的应对方式，但笔记本电脑市场对价格十分敏感，尤其是入门级和主流消费市场。对于许多用户而言，电脑的核心需求仍然是办公、学习、网页浏览和影音娱乐。如果一台原本售价适中的笔记本电脑因为内存和处理器涨价而变得明显昂贵，消费者可能会选择继续使用旧设备，而不是立即升级。

如果厂商选择自行承担成本上涨的压力，则可能面临利润下降的问题。笔记本电脑市场竞争激烈，许多品牌长期依靠较薄的利润率运营。在核心零部件成本持续上升的情况下，企业很难无限期地吸收额外支出。

至于削减硬件规格，同样存在风险。降低内存容量、减少存储空间，或者在其他部件上进行成本控制，确实有助于降低整机价格，但也可能使产品在性能和使用体验方面落后于竞争对手。尤其是现代操作系统、办公软件和人工智能应用对内存的需求不断增长，配置过低的电脑可能更容易出现性能瓶颈。

因此，TrendForce认为，2027年笔记本电脑品牌可能很难同时维持原有价格、产品规格和盈利能力。厂商最终选择将多少成本转嫁给消费者，将成为决定市场需求表现的关键因素。

如果企业能够通过优化产品组合、调整不同价位产品的配置，并自行吸收部分成本上涨，那么2027年全球笔记本电脑出货量的降幅可能仍然维持在低个位数百分比的水平。

但如果CPU、DRAM和SSD价格继续上涨，而且厂商将大部分新增成本直接转嫁给消费者，市场需求就可能进一步走弱，全年出货量降幅扩大至高个位数百分比的风险也将随之增加。

除核心计算和存储部件外，其他零部件同样给笔记本电脑制造商带来了成本压力。印刷电路板、积层陶瓷电容器以及电源管理芯片等部件，都受到产能分配、原材料价格和地缘政治因素的影响。部分零部件不仅可能涨价，还可能出现交货周期延长的问题，增加厂商安排生产和管理供应链的难度。

其中，印刷电路板成本受到原材料价格以及设计复杂程度的影响；随着笔记本电脑采用更复杂的主板设计和更高规格的硬件，电路板的制造成本也可能随之上升。与此同时，电源管理芯片需要适应不断提高的处理器功耗，以及Wi-Fi 7、USB4等新标准带来的额外需求。

这些部件单独来看，成本变化可能不及内存或CPU明显，但当多种零部件同时涨价时，其累积效应仍会给整机制造商带来相当大的压力。

在供应方面，TrendForce预计，2027年DRAM市场仍将保持紧张状态。人工智能服务器持续消耗先进制程产能，普通PC内存的供应增长可能受到限制。这意味着，笔记本电脑厂商未必能够在2027年轻松获得价格合理、数量充足的DRAM。

相比之下，NAND闪存的供应情况可能有所改善。随着新增产能逐步投入使用，TrendForce预计，NAND闪存的供应限制有望在2027年下半年有所缓解。这可能为固态硬盘价格带来一定缓冲，但并不意味着整个存储市场都会同步恢复宽松。

DRAM与NAND闪存的供应走势存在差异，也意味着不同零部件对整机成本的影响可能逐渐分化。如果固态硬盘价格有所回落，但内存和CPU仍然昂贵，笔记本电脑制造商依旧难以大幅降低整机成本。

除零部件价格外，全球笔记本电脑制造布局也可能发生变化。

近年来，受到地缘政治风险、关税政策以及供应链多元化需求的影响，许多品牌将部分生产能力转移至中国以外的地区。越南、泰国等制造基地因此在全球笔记本电脑供应链中的地位有所提高。

不过，TrendForce指出，随着成本压力日益突出，厂商可能重新评估此前的生产布局。如果关税压力没有进一步加剧，决定生产地点的因素可能逐渐从降低政策风险转向生产成本、供应链完整程度和运营效率。

在一些新兴制造地区，生产体系仍然需要依赖从其他国家进口大量零部件。额外的物流、零部件采购和供应链管理成本，可能削弱这些地区的制造成本优势。当整机制造商面临越来越大的利润压力时，将部分生产能力重新集中到供应链更完整的地区，就可能成为值得考虑的选择。

TrendForce估计，全球笔记本电脑在中国以外地区生产的比例，可能从2025年的约24%下降至2026年的约21%，并在2027年进一步跌破20%。换言之，如果这一预测实现，中国在全球笔记本电脑制造中的占比可能重新超过80%。

这一趋势并不意味着所有厂商都会将生产全面迁回中国，而是说明企业可能重新权衡供应链多元化与生产效率之间的关系。对于不同品牌而言，最终的生产布局仍将取决于关税、制造成本、供应链成熟程度以及各地区的政策环境。

从更长远的角度来看，2027年可能成为笔记本电脑行业调整经营策略的重要一年。此前，企业主要担心能否获得足够的CPU、内存和其他关键部件；随着部分供应问题逐渐变化，成本上涨以及消费者承受能力将成为更加突出的矛盾。

对于消费者而言，这意味着未来购买笔记本电脑时，需要更加关注价格与配置之间的关系。即使某些型号仍然能够以相对稳定的价格销售，厂商也可能通过调整内存容量、存储规格或其他配置来控制成本。因此，比较不同产品时，不能只关注整机售价，还应仔细检查具体硬件配置。

对于PC厂商而言，如何在涨价、规格调整和利润之间找到平衡，将直接影响其市场竞争力。能够通过长期采购协议、优化供应链、控制运营成本以及合理规划产品组合来缓解涨价压力的品牌，可能更有能力维持市场份额。

总体来看，TrendForce对2027年笔记本电脑市场的预测并非意味着出货量必然大幅崩跌，而是强调成本上涨可能进一步压制本已受到提前采购影响的市场需求。基准情景下，全球笔记本电脑出货量预计出现低个位数百分比的下降；如果成本持续上升且大部分压力被转嫁给消费者，降幅则可能扩大至高个位数百分比。

未来一年，笔记本电脑行业真正需要解决的问题，将不只是如何生产更多设备，而是如何在内存、CPU等核心零部件价格持续波动的情况下，继续提供消费者愿意购买的产品。如果终端售价上涨过快，即使供应链能够生产足够数量的电脑，市场也可能因为消费者推迟换机而陷入更长时间的低迷。

Qwen-Image-2.1 Pro 和 Turbo API 上线千问 AI 平台

Sun, 11 Oct 2026 20:29:32 CST

10月11日消息，千问 AI 平台今日宣布，Qwen-Image-2.1 Pro 和 Turbo API 现已正式上线千问 AI 平台。开发者可以通过 API 将图像生成与编辑能力接入应用，无需自行部署模型、管理推理环境，即可围绕设计、电商、内容创作等场景搭建自己的工作流。与此同时，Qwen-Image-2.1-Turbo 模型权重同步开放。

现在，用户可以在千问 AI 平台查看 Qwen-Image-2.1 Pro 和 Turbo 的模型信息与接入说明，根据业务需求选择、测试和集成。

对于创作工具，API 可以成为从文字构思到视觉呈现的入口；对于电商和营销应用，可以围绕商品素材、场景创作和海报设计组织工作流；对于已有图片的精修与再创作，则可以通过编辑指令继续调整内容。从生成到编辑，开发者可以把这些能力融入自己的产品，让用户在熟悉的界面中完成创作。

Qwen-Image-2.1 模型最多支持 10 张参考图输入，支持通过圈选、涂抹和独立掩码明确编辑区域。与此同时，2.1 加强了人像和商品编辑中的一致性表现：在人像编辑中更好地保留面部身份特征，在商品编辑中尽可能保持文字、纹理与形态。此外，Qwen-Image-2.1-Turbo 支持 2K 图像生成与图像编辑。

Qwen-Image-2.1-Turbo 基于 Qwen-Image-2.1 的 7B 视觉生成架构，将图像生成与编辑的去噪过程缩短至 8 步，同时保留 2K 图像创作能力。

API 上线之后，图像生成与编辑可以嵌入用户已经在使用的工具中。开发者可以围绕具体需求，把素材输入、生成、预览和修改连接起来。

小米AI Cube 原型机-本地AI模型部署选择

Wed, 07 Oct 2026 08:13:57 CST

小米刚刚展示了其 AI Cube 原型机，这可能成为来自中国的严肃 GB10 竞争对手 👀 - 3 款定制芯片：Xring O3、O100、D100

- 200 TOPS NPU

- 1.22 TB/s AI 内存带宽

- 最高 160GB 统一内存

- 150W 持续功率

- 120B 模型本地运行

Xring O100：1.22TB/s + 330 t/s 在 150w AI 盒子上真是 🔥 一旦它上市，绝对会像热饼一样热卖。

Xiaomi just showed its AI Cube Prototype and this could become a serious GB10 competitor from China 👀 - 3 custom chips: Xring O3, O100, D100 - 200 TOPS NPU - 1.22 TB/s AI memory bandwidth - Up to 160GB unified memory - 150W sustained power - 120B models running locally Xring O100: 1.22TB/s + 330 t/s on a 150w AI box is 🔥 Once it hit's the marked, going to sell like hot cakes.

文本分类语言模型-Language Models for Text Classification: From Bag-of-Words to Jev

Wed, 30 Sep 2026 09:26:32 CST

词袋模型、循环神经网络、卷积神经网络、Transformer 模型、Jev 类 API 和校准的可视化指南

A Visual Guide to Bag-of-Words, RNNs, CNNs, Transformers, Jev-like APIs, and Calibration

Sebastian Raschka, PhD

Sep 29, 2026

The recently released JevAI model has been quite a cultural phenomenon in technical communities in the past 2 weeks.

While Jev aims to classify things, it’s easy to dismiss Jev as “just a classifier,” and my own view of Jev has evolved quite a bit over the past few days. In particular, my thoughts went from “classifiers used to be my bread & butter; I can easily build this myself” (more on this later) to “wow, this actually works better than I thought.”

Figure 1: Quick overview of the Jev API; more details on that later.

Sure, the latest state-of-the-art GPT and open-weight LLMs can do the same kinds of classification tasks as Jev, while also being capable of much more general decision-making. But Jev’s advantage is that it can handle those classification tasks much faster and more cheaply.

At the other end of the spectrum, for a narrow, well-defined problem, Jev probably won’t classify anything better, faster, or cheaper than a special-purpose classifier. But its selling point is that it is far more general than those task-specific models.

So, what is the methodology behind Jev (based on an educated guess), what can it do, and why is it so popular? I aim to answer all of these later in this article. However, I thought starting with a brief history of language models for decision-making would be a great way to begin. And it hopefully helps demystify some of the hype and show what Jev does very well (”Jev is essentially a text classifier,” but “Jev is also not ‘just’ a text classifier.”)

PS: I am not affiliated with Jev in any way. Also, I am not offered free access to Jev, and this is also not a product endorsement, just a technical article to offer some insights into the history of text classification to help you make sense of the recent hype.

Since this is a long article, I recommend reading it in your browser,where you can access the table of contents menu on the left side.

1. Language modeling and classification in the pre-transformer era

For completeness, before we put Jev in context (no pun intended), I thought it made the most sense to start chronologically. In this section, I want to take a brief tour of applied text classification via naive Bayes, logistic regression, and the more classic (deep) neural networks before transformer-based models came along.

1.1 Bag-of-words: naive Bayes, logistic regression, and XGBoost

Back in the day, when I was a grad student 15 years ago, even though recurrent neural networks already existed (more on that later), text classification was usually done with a bag-of-words representation because it was straightforward and could get good results on moderately sized datasets.

In short, we can think of the bag-of-words representation as a method that makes free-form text input of different lengths compatible with classic classifiers (naive Bayes, Logistic Regression, SVMs, Random Forest, XGBoost, to name a few), which expect a fixed-size input vector.

Popular real-world applications include anything from news article classification to email spam filtering. And yes, allegedly even Gmail’s original spam filter used a Naive Bayes model with a bag-of-words representation.

As a side note, I wrote about thisapproach exactly 12 years ago. It was one of the first things I shared on arXiv.

Figure 2: An old tutorialof mine from 2014 that explains naive Bayes classifiers using a bag-of-words model.

So, what exactly is this bag-of-words representation? It’s a way to convert free-form texts with different lengths, e.g.,

Training example 1: “Zentropa is the most original movie I’ve seen in years. If you like unique thrillers that are influenced by film noir, then this is just the right cure for all of those Hollywood summer blockbusters clogging the theaters these days. Von Trier’s follow-ups like Breaking the Waves have gotten more acclaim, but this is really his best work.”
Training example 2: “This film is just plain horrible. John Ritter doing pratt falls, 75% of the actors delivering their lines as if they were reading them from cue cards, poor editing, horrible sound mixing”
Training example 3: “Zentropa has much in common with The Third Man, another noir-like film set among the rubble of postwar Europe.”

into a fixed-size representation for the aforementioned “classic” classifiers. (The example above is an excerpt from the popular IMDb movie review classification dataset.)

Figure 3: An illustration of a bag-of-words representation.

A bag-of-words model starts by building the vocabulary, which consists of all unique words in the training set (optionally, one can get rid of so-called stopwords like “a” and “the”, which are words that carry little to no semantic meaning in most contexts).

A bag-of-words representation results in these fixed-size inputs by assigning each word in a vocabulary its own position in a vector. We then count how often each word occurs in a document. For example, if we have a vocabulary of 50,000 unique words, it produces a fixed-size vector with 50,000 entries, regardless of whether the input consists of only ten words or 300k words. Note that most entries are zero because each document contains only a small subset of the vocabulary. (Instead of representing the raw counts, there are also normalization schemes like TF-IDF.)

Then, once we have these word frequency vectors, we can train a classifier on a labeled training set, such as emails labeled as spam or non-spam. For example, a logistic regression model would then learn feature weights that correlate certain words (and word counts) with particular labels. For instance, certain words might increase the predicted spam probability, and others may decrease it.

This approach is computationally cheap and can work well when particular words provide strong clues about the label. In a simple classification task such as spam classification, this is often enough to get quick, reasonably accurate results.

But one of the biggest downsides of this approach is that, because of the nature of the bag-of-words representation, it loses word order. So, for example, “the dog bites the man” and “the man bites the dog” produce identical vectors despite describing different events.

(There are some workarounds to preserve some local order by adding word pairs or longer sequences, called n-grams, as features, although this increases the vocabulary size.)

Despite the shortcomings, I still think that a bag-of-words has its place in certain low-stakes applications because it’s so cheap, and a bag-of-words representation + logistic regression remains my go-to baseline for every text classification problem, since it’s so easy to implement.

Figure 4: For those interested in building a simple logistic regression classifier, I have a tutorial up here. This model achieves 89.9% accuracy (on a balanced dataset).

1.2 Deep neural networks for text classification

The aforementioned bag-of-words model would also work with (simple) deep neural networks, like multilayer perceptrons. But the downside still is that we would lose the sentence structure and word order.

However, more sophisticated neural network architectures avoid the bag-of-words workaround: convolutional neural networks (CNNs) and recurrent neural networks (RNNs), which can take word embeddings as input.

1.2.1 Word embeddings

First, before feeding the input texts into a model, we have to convert them into a suitable representation. One such representation is bag-of-words. Another is word embedding vectors. The difference is that a bag-of-words vector represents the entire text by counting how often each vocabulary word occurs, while a word embedding represents an individual word as a dense vector of learned numbers.

Figure 5: Illustration of creating word embeddings.

Word embeddings work similarly to embedding layers in LLMs, i.e., they convert input tokens into dense vectors. Embeddings can happen outside the model (e.g., two classic, popular methods for learning them are Word2Vecand GloVe), or the embedding layer can be part of the neural network architecture itself and be learned and tuned during model training.

These classic embeddings are context-independent at lookup time. The word “bank”, for example, gets the same vector in “river bank” and “bank account” (as you may know, context can be handled via concepts like attention).

For additional resources on embeddings, you may find the following ones helpful:
- Chapter 2: Working with Text Data(this is an LLM chapter but should give you the gist of embedding words or tokens; in LLM tokenizers, we split words into subword tokens; in Word2Vec, 1 word is usually 1 token.)
- Understanding the Difference Between Embedding Layers and Linear Layers(this is an illustration that shows when embedding vectors are mathematically equivalent to Linear layers and matrix multiplications.)

1.2.2 Recurrent neural networks (RNNs)

Since many of you are probably familiar with recurrent neural networks (RNNs), I will keep this section short. RNNs are a classic go-to neural network architecture for natural language processing, and popular variants go back to the 1980s and early 1990s. Transformers, which were introduced in 2017 (and using the attention mechanisms that were first introduced in RNNs; see my Understanding Large Language Modelsfor a brief timeline), then gradually replaced them in many NLP applications.

RNNs read a sequence (like text) one word at a time. At each step, they combine the current word embedding (discussed in the previous section) with a hidden state from the previous step. We can think of the hidden state as a fixed-size vector that summarizes the text processed so far, so this makes word order matter, because rearranging the words changes the sequence of state updates.

Figure 6: Illustration of an RNN classifier.

Note that the figure above shows the RNN in the unrolled representation. I.e., the RNN reuses the same layer stack for each input, hence the term “recurrent”. And since it’s “recurrent”, the input text can have an arbitrary length. The figure below illustrates the “recurrence” with the unrolled representation side by side. Note that both show the identical architecture, it’s just a different visualization.

Figure 7: Rolled and unrolled illustration of the same RNN.

RNNs were notoriously hard to train, and there are important improvements to RNNs, like Long short-term memory(LSTM) networks, introduced in 1997, and gated recurrent units(GRUs), introduced in 2014, which use learned gates to control how information is retained and updated. (There is also the more recent xLSTM: Extended long short-term memory, introduced in 2024).

Also, state-space models are inspired by this idea of a fixed-size hidden state updated sequentially, which is cheaper than transformer attention. However, the bottleneck is still how much information the hidden state can retain, and it still has to be processed sequentially. (Fun fact: attention was first developed for RNNs before the transformer architecture came along, but it’s a story for another time; I’ve written about it in my Understanding Large Language Modelsarticle.)

The bottom line is that RNNs can be used to train text classifiers. Coming back to the IMDb movie review dataset, the bag-of-words classifier with logistic regression achieved about 89.9% accuracy (on a balanced dataset), while an LSTM RNN achieved only 85.66% accuracy. Yes, RNNs can be harder to train (stay tuned for the ULMFiT method below, which trains an RNN with much higher accuracy).

Figure 8: A simple RNN with LSTM tutorial. This model achieves 85.66% accuracy (on a balanced dataset); the higher training accuracy indicates substantial overfitting.

Note that this RNN was trained from scratch. A better approach is to pre-train the model on a larger dataset first, then fine-tune it on this target dataset (classically, we call this approach “transfer learning”).

In the natural language processing domain, one of the most influential papers proposing this approach is ULMFiT(2018), which achieved an impressive 95.4% test accuracy on IMDb.

Figure 9: Annotated figure from the ULMFiTpaper.

1.2.3 Convolutional neural networks (CNNs)

You probably know convolutional neural networks (CNNs) from their use in computer vision. However, it is also possible, although historically less common, to use them for text.

Figure 10: Illustration of a convolutional neural network (CNN) to classify images.

As shown in the image classification example in the figure above, CNNs apply learned filters to image patches (windows). Similarly, in the natural language domain, we can apply learned filters to windows of adjacent word embeddings.

Figure 11: A CNN for text classification, step by step. Only 1 filter (channel) for simplicity.

As illustrated in the figure above, a convolutional filter with a window size of three uses the same weights for each adjacent group of three words. Then, as it slides over the inputs, it moves the filter one word at a time across “the movie had surprisingly good acting”. So, this gives four windows (ignoring padding for simplicity):

1: “the movie had”
2: “movie had surprisingly”
3: “had surprisingly good”
4: “surprisingly good acting”

So, in the last layer, before the classification head, we can either flatten or global max pool the results before connecting it to the classification head. While flattening preserves all information, it would produce differently sized vectors depending on the text input length. (E.g., if “the movie had surprisingly good acting” were longer, we would have longer feature maps.) So, to make it input-length agnostic, global max-pooling would be a better option here.

In short, we can visualize the text CNN as shown below.

Figure 12: CNN for text classification with multiple filters (channels).

Also, what’s nice is that the filter computations across positions can run in parallel, which avoids the step-by-step dependency of an RNN.

For a quick comparison, on the aforementioned IMDb dataset, my experiments show that such a CNN gets about 90.07% accuracy (but note that this is highly architecture-dependent; for example, you may know from computer vision contexts that accuracies can vary widely). (E.g., the good old AlexNet had a ~62.5% top-1 accuracy on ImageNet, and a ConvNeXt V2-H gets 88.9%.)

Figure 13: A CNN trained to classify IMDb movie reviews; it gets 90.07% accuracy on this balanced dataset. You can find the source code here.

2. Transformers

In 2017, the original transformer architecture was introduced in the Attention Is All You Needpaper. Since this topic has been covered so extensively (by me and others), I will focus on the classification-relevant aspects. But for those interested in the attention mechanism and other architecture details, please see my related articles:

The Big LLM Architecture Comparison

Sebastian Raschka, PhD

July 19, 2025

Read full story

A Visual Guide to Attention Variants in Modern LLMs

Sebastian Raschka, PhD

Mar 22

Read full story

The key point is that the original transformer architecture was an encoder-decoder setup used for language translation, but it can be easily adapted for text classification tasks, as I’ll illustrate in the following sections.

Figure 14: The original transformer architecture from Attention Is All You Need.

2.1 Encoder-style language models

I remember all too well the first years after the original transformer architecture release. They were pretty much defined by the rivalry between two different approaches:

Encoder-style models like BERT, primarily developed by Google;
Decoder-style models like GPT, primarily developed by OpenAI.

Encoder-style models were natural text classifiers, whereas GPT models could do zero- and few-shot classification as an emergent property, but their strength was more in generative tasks.

But let’s start with encoder-style models and how to fine-tune and use them to classify text.

One universal aspect of using transformers, whether encoder- or decoder-style, is that we work with models pre-trained on large text corpora, and, in addition to using them as zero- or few-shot classifiers, we can fine-tune them on the target dataset (similar to ULMFiT, as mentioned in the RNN section earlier).

As shown in the figure excerpt from the BERT paper(2018) below, BERT-/encoder-style models have a classification token at the first position that we can conveniently fine-tune for this.

Figure 15: Annotated figure from the original BERT paper.

While BERT models are not nearly as popular as autoregressive GPT-style transformers, thankfully some people still update and modernize them occasionally. One recent example that is often my go-to for classification tasks is the 2024 ModernBERTmodel.

As shown below, on the IMDb movie reviews, ModernBERT gets approximately 95% accuracy with very little fine-tuning effort.

Figure 16: Different LLMs fine-tuned to classify IMDb movie reviews; you can find the source code here. (I did very little hyperparameter tuning, and this can potentially be improved by 1-2% further; however, one of the points here is also that one can get really good results with pretty minimal effort.)

2.2 Decoder-style LLMs

LLMs like GPT are decoder-style, autoregressive transformers that are the center of all attention (no pun intended) for generating text and code.

However, as I explained in chapter 6 of my Build A Large Language Model (From Scratch)book, as a gentle introduction to fine-tuning (before covering instruction fine-tuning), we can also repurpose these for text classification.

Sure, we can also prompt an LLM directly, as shown in the screenshot below.

Figure 17: Prompting an LLM to classify a movie review.

However, if we want structured outputs and we have a specific target domain in mind, this is unnecessarily brittle and inefficient.

Instead, we can replace the output layer with a leaner classification head, as illustrated below:

Figure 18: Swapping the output layer of a GPT-style model with a leaner classification head.

Now, fine-tuning has a few caveats. For instance, because of the autoregressive attention mask, we have to be careful about how we design fine-tuning so that the classification token has information about all other tokens in the sequence.

Figure 19: Attention masks in BERT and GPT.

If you are interested in further technical details, please see my recent end-to-end Building an AI Text Detector From Scratcharticle:

Building an AI Text Detector From Scratch

Sebastian Raschka, PhD

Aug 15

Substack recently launched its AI detector feature in the UI, which is super interesting.

Read full story

Overall, though, the advantage of using GPT-style LLMs over e.g., BERT variants is that there are so many modern open-weight architectures out there to adopt. Anything between the small Qwen 3 0.6B models to the latest Kimi, GLM, or DeepSeek models. (Of course, using such >1B parameter models for classification could be a bit overkill from an efficiency perspective, but hey, it’s possible.)

Figure 20: On the aforementioned IMDb movie review dataset, a relatively small GPT-2 124M model gets approximately 92% accuracy; a larger and newer LLM (like a recent Qwen3 variant) would likely perform better.

2.3 Encoder-decoder style architectures

While the original transformer architecture (an encoder-decoder) was split into two paradigms, encoder-style models like BERT and decoder-style LLMs like GPT, there were also efforts to use encoder-decoder-style variants, with the most recent variant (somewhat unexpectedly) being DeepSeek V4.1 Flash. (However, in this case, it’s a causal encoder not a bidirectional one as in T5.)

Keeping the focus on encoder-decoder architectures for classification, probably the most prominent candidate is Google’s 2019 T5 (Text-to-Text Transfer Transformer).

Architecturally, the differences between T5 and the original transformer include updates to the architecture (as summarized below), as well as changes to training. The original transformer was trained to do language translation (in a supervised fashion); T5 uses pre-training on unlabeled text with span corruption, where the encoder receives text with missing spans and the decoder generates those missing spans.

Figure 21: T5 architecture changes to the original transformer architecture. (The architecture drawing is taken from Attention Is All You Need.)

Now, we can use T5 similar to the other RNN, CNN, and transformer approaches above, by adding a classification head.

Additionally, we can also (train to) have the decoder output the class label prediction (like “positive” or “negative” in the IMDb movie review dataset case), similar to regular LLMs. Let’s call this approach text-to-text classification.

While GPT-style LLMs are trained on massive amounts of text, they usually perform text-to-text classification well out of the box, as shown earlier (the figure below is inserted here again for convenience).

Figure 22: Text-to-text classification with a GPT model.

However, in the case of T5, it is common to further fine-tune the decoder to do well on these types of tasks in a given target domain.

For T5, both approaches work. Here’s a summary:

Figure 23: Classification head vs text-to-text approaches.

3. Jev overview

So far, we have seen that there are plenty of approaches to text classification, from traditional methods like logistic regression and naive Bayes with bag-of-words representations to prompting the latest frontier LLMs like GPT-6 or fine-tuning any open-weight LLM with a classification head (or text-to-text classification).

At first, I (almost) dismissed it as “just a classifier,” something that I build routinely for classification tasks with natural language inputs (e.g., see my AI Detector articleas a recent public example).

3.1 Jev vs existing text-to-text classification

Before continuing this discussion, though, let’s start with a quick Jev overview. Jev is a new model released by TypeSafe AI, which just came out of stealth a few weeks ago and got a lot of attention (at first, it seemed a bit bizarre because it looks just like a classifier).

Jev is a proprietary model (although the release was followed by a huge number of quick open-source clones, but we will get to this later) that is relatively cheap to use and claims to be on par with GPT-5.6 Luna (for decision-making) while being orders of magnitude faster and cheaper:

Figure 24: Benchmark from TypeSafe AI blog.

Here, regarding GPT-Luna, think of this as the text-to-text classification approach discussed earlier.

So why all this hype? I think it’s partly because of the nice API and that it performs so well on all kinds of tasks, so it doesn’t require custom fine-tuning.

For example, I can use it to categorize support tickets/emails (I made a video version to show the response time):

Or, I can have the same model play Tetris in real-time (here, I am using the Choice API):

Maybe the best way to succinctly explain it (before getting into technical details) is as follows: Like ChatGPT in 2022 was exciting because it was a general-purpose chat model that could generate all kinds of texts, one of the reasons the tech community is excited about Jev is that it is the ChatGPT moment for classification, where it can cheaply classify all kinds of text inputs without having to fine-tune a custom classifier for each task.

(As of this writing, there’s not much known about the architecture and exact training algorithm, except that one of the founders said it was trained via “Reinforcement Learning for Calibrated Decisions”, but more on that later.)

3.2 The Jev API

Over the past few years, we’ve gotten used to throwing bigger, better, and more expensive GPT-style LLMs at all kinds of problems, and for targeted decision-making or classification tasks, a cheap & fast approach like Jev may feel refreshing to most. Especially for one-off tasks where collecting training data and fine-tuning a custom ModernBERT sounds too tedious, we might just throw a Luna-like model at it.

But on top of being popular for its versatility (that is, performing well on different target domains out of the box), Jev also has a relatively nice API which we can use via curl in the terminal or via its Python API.

In short, there are three main API types illustrated below. Let’s start with the Choice API, which is convenient for multi-class classification.

Figure 25: Jev’s Choice API. Use this for multi-class classification.

Next is the Noul API, which is simpler and assigns a “yes” probability to a question.

Figure 26: Jev’s Noul API. Use this for binary classification or multi-label classification (with multiple Noul questions).

Lastly, the Score API assigns a score based on a rubric level (in the example below, 0, 1, 2).

Figure 27: Jev’s Score API. Use this for ordinal classification.

To sum it up, the different APIs and use cases are as follows.

Figure 28: Jev API cheat sheet.

3.3 Jev classifying IMDb

To make these APIs more concrete, and to answer the question of how well Jev might do on the aforementioned IMDb dataset, we can run it with either the Choice or Noul API.

Let’s start with the Choice API first. Each review would be formatted as follows:

          export TYPESAFE_API_KEY="YOUR_API_KEY"

curl -sS https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-1.13.0",
    "state": "The acting was excellent and the story kept me engaged throughout. I would happily watch this movie again.",
    "questions": {
      "sentiment": {
        "type": "choice",
        "instructions": "What is the overall sentiment of this movie review?",
        "criteria": {
          "negative": "An overall unfavorable opinion of the movie",
          "positive": "An overall favorable opinion of the movie"
        }
      }
    }
  }'

This Choice API is convenient if we want to use explicit labels for binary (here) or multi-class problems.

An actual response might look as follows:

          {
  "model": "jev-1.13.0",
  "answers": {
    "sentiment": {
      "type": "choice",
      "choice": "positive",
      "confidence": 1.0,
      "probabilities": {
        "negative": 0.0,
        "positive": 1.0
      }
    }
  },
  "usage": {
    "input_tokens": 342,
    "output_tokens": 32
  }
}

Along with the "choice": "positive"label, we also get the confidence for this prediction, which can be really useful in real-world applications, as well as the probabilities for each class. (The confidence field summarizes how concentrated the probability distribution is. It is different from the probability assigned to the winning class.) One of the selling points of Jev is that, according to the documentation, these are well-calibrated (but more on calibration later).

Alternatively, we can also use the Noul API here to classify the reviews. Using the same movie review classification context, the format would be as follows:

          curl -sS https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-1.13.0",
    "state": "The acting was excellent and the story kept me engaged throughout. I would happily watch this movie again.",
    "questions": {
      "is_positive": {
        "type": "noul",
        "instructions": "Does this review express an overall positive opinion of the movie?",
        "criteria": {
          "true": "An overall favorable opinion of the movie",
          "false": "An overall unfavorable opinion of the movie"
        }
      }
    }
  }'

And the answer via the Noul API is:

          {
  "model": "jev-1.13.0",
  "answers": {
    "is_positive": {
      "type": "noul",
      "noul": 0.98
    }
  },
  "usage": {
    "input_tokens": 328,
    "output_tokens": 21
  }
}

(Interestingly, it gives 0.98 instead of 1.0 for the positive class, even though it’s the same text.)

We can also apply the Noul API to multiple classes by asking one question per class, for example:

“Is this article about finance?”
“Is this article about politics?”
“Is this article about technology?”

Here, each question (independently from each other) returns a probability, and these probabilities don’t have to sum to 1. So, for a multi-class classification where each text can have multiple labels, we may prefer Noul, and for classification problems with only one final answer, Choice adds more convenience.

Now, running Jev with either Choice or Noul on the 25,000 movie reviews on the test set gave the following results:

Choice:
- Accuracy 96.47% (24,117 correct)
- Total runtime: 22 minutes 24 seconds
- 15,456,663 input tokens, $0.6492 total cost
Noul:
- Accuracy 96.20% (24,050 correct)
- Total runtime: 23 minutes 3 seconds
- 15,106,663 input tokens, $0.6345 total cost

Note that the small difference in performance and runtime between Choice and Noul could be due to random fluctuation since, similar to other LLMs, the runs are not fully deterministic.

For instance, I ran the Choice API a second time over the same test set and got slightly different results, as shown below.

Figure 29: Repeated Jev runs.

(The non-determinism when serving LLMs and other models at scale is likely due to batch-dependent GPU kernel execution changing the order of floating-point operations, as laid out in a nice blog postby Horace He last year.)

Anyways, the results look quite good overall (caveat: we don’t know if the IMDb test set was part of the training set).

For reference, a ModernBERT model took

23 min to fine-tune on the training set;
7 min to evaluate on the test set.

For comparison, the best ModernBERT model has similar accuracy, as shown below (I expect you can still get 1-2% higher accuracy with additional hyperparameter tuning). Note that this was run on a DGX Spark, and it’s possible to get faster inference performance with quantization and faster hardware.

Figure 30: ModernBERT versus Jev.

But our ModernBERT model can’t play Tetris, for example, or do anything else besides movie classification without us fine-tuning it for the new task. But we could then throw a GPT-5.6 Luna or GPT-6 Luna model at it (which is a bit slower and also more expensive).

A classic rule of thumb was:

Use a cheap LLM (like GPT-6 Luna) for one-off decision-making tasks;
Fine-tune a custom classifier if we want to do this task repeatedly.

Now, something like Jev could take the place of the above to a) reduce latency and save money over Luna and b) save us the work of fine-tuning a custom model. (Although if we have a very high-volume task and we want to maximize speed and accuracy on a very specific task, it, of course, still makes sense to fine-tune.)

4. BERT- and GPT-style models with Jev API

Of course, we could also be adding a Jev-like API on top of a (Modern)BERT or any GPT-style model. Adding a Jev-like API is pretty straightforward. In fact, as soon as Jev was released, I built a Jev-like ModernBERT model to show how simple it is to build your own Jev model.

I decided not to release my Jev clone because I changed my mind in the meantime. I.e., it’s trivial to put a Jev-like API on top of ModernBERT, and it’s trivial to fine-tune it on a bunch of classification tasks. But it’s not trivial to make this model work well on all different kinds of tasks (like Tetris) without extensive training and testing. (Also, there are already enough quick Jev clones riding on the hype train by now; the world doesn’t need another quick clone, but a strong open-weight version would be nice, of course.)

However, if you are interested in how that retrofitting would work, here is a quick overview. For example, we can implement a Jev-like Choice API by adding a small classification head to any BERT-, GPT-, or T5-style model as illustrated earlier. But instead of having the output nodes in this head match the number of classes, we have it with only 1 output node, as illustrated for the modified GPT model below.

Figure 31: GPT model where we replace the output layer (which maps to the whole vocabulary) with an output head with only one node.

Earlier, we discussed fine-tuning these models for a specific task like movie review classification with a pre-defined number of class labels (here, “positive” and “negative”). With this “1 output node” setup, we can actually extend this to a flexible and arbitrary number of classes.

To extend this to an arbitrary number of classes (let’s consider the 3-class case of categorizing a customer ticket into the three categories “billing”, “technical”, “account”), we can do so as shown in the figure below.

Figure 32: Using a BERT- or GPT-style model with a Jev-like choice API.

As shown in the figure above, for each candidate option, we feed the model the input text, the task instructions, and the candidate’s description. The classification (scoring) head maps the output representation to a single scalar score. We then apply softmax across the candidate scores to obtain a probability distribution and return the highest-probability option.

The main point here is that the proposed head has one output per class. Each class description produces its own representation, which the same head scores via the output layer (which is essentially a logistic regression model):

where

s _iis the scalar score for class label i;
wis a learnable weight;
bis a learnable bias unit;
h _iis the output of the transformer before the classification head.

For Ncandidates, this produces Nscores. Softmax then returns Nprobabilities. The learned parameters and stay the same when Nchanges.

Note that for h _i:

BERT-style encoder models use the final hidden state of the [CLS]token (optionally passed through a pooling layer);
GPT-style autoregressive models typically use the final non-padding token’s hidden state, which we need because of the autoregressive nature as discussed earlier (the last non-padding token can attend to the preceding text, instructions, and candidate description).

Then, we fine-tune the model and the scoring head jointly using cross-entropy loss against the correct option. Since all candidates share the same scoring head, we can change the number and descriptions of the options without changing the architecture. But again, how well this works on unfamiliar tasks depends on the training data.

By the way, why BERT- or GPT-style transformer-based models over simpler RNN and CNN architectures mentioned earlier? From a technical perspective, the approach outlined above works with either. But transformer-based models scale really well, meaning they can be pre-trained on larger datasets and benefit more than other models. Also, they can make good use of the information provided in the context (thanks to attention). So, if we want our model to generalize well to different target tasks without explicit fine-tuning on each one, pre-training a transformer-based model on a high-quality dataset likely gets us closer than RNN- or CNN-based models.

5. Jev architecture and training algorithm

So, how come Jev does so well on so many different tasks (from movie reviews to something arbitrary like playing Tetris)? Unfortunately, the architecture, algorithm, and training data details are not public. Also, keep in mind there’s a whole team and multi-million-dollar company behind it that specialized in and worked really hard on this model; we can’t expect to match that level of performance by training a ModernBERT-like model for a week on some open datasets.

That being said, if I had to make an educated guess, architecture-wise, I’d guess that they are using something small similar to ModernBERT, hence, the low latency.

For the training data, as mentioned before, the TypeSafe AI CEO saidthe following:

100% of our data is synthetic (but not the type of crap that is just spit out from an LLM obviously)

So, yeah, I think most of the effort went into curating this dataset. It’s something I’ve also been preaching to students and collaborators for many years. As a short anecdote, about 8 years ago, I was collaborating with another professor in the social sciences department and helped to design the experimental setup for a text classification problem. Her student spent many days hyperparameter tuning both a bag-of-words baseline and a BERT model to eke out ~2-5% accuracy. Then I suggested we each sit down for a few days to hand-label more data (I think our original dataset was around 300 samples, and we doubled the size), which resulted in a >10-20% accuracy boost. Yes, it’s important to plot learning curvesfor that purpose :).

Figure 33: Rule of thumb showing that often more data helps more than additional hyperparameter tuning.

Finally, the training algorithm. Again, the details are not known, but TypeSafe AI’s blog post statesthat they were using a new algorithm called Reinforcement Learning for Calibrated Decisions (RLCD):

“We built a new stack entirely focused on automation: with a new model architecture, parallel sampler for maximum efficiency, and training method we call Reinforcement Learning for Calibrated Decisions (RLCD).”

This method is not public. A published method with a similar calibration objective is RLCR (Reinforcement Learning with Calibration Rewards), from the 2025 paper Beyond Binary Rewards: Training LMs to Reason About Their Uncertainty. Before providing more details, the next section gives a brief overview of calibration in general.

5.1 On calibration

Calibration is not a new topic and a step I recommend for any production model where you want to use and evaluate the class-membership probabilities. In short, calibration adjusts the model’s probability estimates so they better match observed class frequencies.

For example, consider once more our IMDb movie classification problem. A model might assign a review 74% positive and 26% negative. These are probability estimates, but the model may be overconfident or underconfident. We cannot assume that the numerical values are reliable without evaluating calibration. I.e., predictions of 74% positive and 54% positive both yield the class label “positive” at a 50% threshold, although the model expresses more confidence in the 74% case.

Figure 34: Illustration of how calibration works.

Calibration techniques use a separate labeled dataset, e.g., a held-out validation set, to adjust these probability estimates. After successful calibration, among many reviews assigned a positive probability of approximately 74%, roughly 74% should actually be positive. For more information, I recommend the good old scikit-learn documentation.

There are many approaches for this. For example, one that I used in my AI detector projectis temperature scaling. Temperature scaling divides the model’s logits by a temperature ( T) value before applying softmax. We learn T(a positive number) by minimizing the cross-entropy loss on the calibration dataset while keeping the model weights fixed. A temperature above 1 reduces confidence in the highest-probability class, while a temperature between 0 and 1 increases it. We then use this same temperature for new predictions. Because this scaling preserves the ordering of the logits, the predicted class remains unchanged when we select the highest-probability class.

5.2 Reinforcement learning with calibration rewards (RLCR)

Jev’s RLCD training method remains proprietary, but a related idea we can discuss is Reinforcement Learning with Calibration Rewards(RLCR), which was introduced in the 2025 Beyond Binary Rewards: Training LMs to Reason About Their Uncertaintypaper. (Note that there is no officially established connection between the two methods, but I am assuming that they could be related.)

Reinforcement learning with verifiable rewards (RLVR) typically rewards a correct answer with 1 and an incorrect answer with 0. (For a comprehensive explanation and implementation, I recommend checking out my Build A Reasoning Model (From Scratch) book:)).

In short, RLCR adds an additional penalty for inaccurate confidence estimates.

So, in the conventional RLVR method, the reward Ris either 0 or 1 based on the answer correctness (we are ignoring an optional formatting reward and length penalty here, for simplicity).

In RLCR, the model generates reasoning and an answer, which is followed by an uncertainty analysis and a numerical confidence ( q). This modified reward is

$R = c - (q - c)^2,$

where is 1 for a correct answer and 0 otherwise. For example, an incorrect answer with 90% (0.9) confidence receives a reward of -0.81, since

$0 - (0.9 - 0)^2 = -0.81.$

At 20% confidence, the reward is -0.04. And a correct answer at 90% confidence earns 0.99. (Readers familiar with evaluating calibrated models may notice that the squared-error term is the Brier penalty for the stated probability that the answer is correct.)

Figure 35: RLCR overview.

Note that the same (here, Qwen2.5-7B) model generates the uncertainty analysis and q as part of its response.

The uncertainty analysis is a written assessment of where its answer could be wrong. After answering, the model examines missing evidence, ambiguous wording, questionable assumptions, or possible reasoning errors. The paper’s prompt asks it to identify specific uncertainties rather than propose corrections.

Also, the system prompt explicitly asks for q, a number between 0 and 1 inside tags. It represents the model’s estimated probability that its answer is correct. The system generates all these parts sequentially in the same response.

For illustration purposes, the model answer could be as follows:

                  <think>...reasoning about the question...</think>
<answer>positive</answer>
<analysis>
The passage mentions a positive movie review, but the connection to the second paragraph is unclear.
</analysis>
<confidence>0.6</confidence>

Below is an annotated figure from the paper that illustrates how it improves the expected calibration error over regular RLVR with temperature scaling.

On HotpotQA, RLCR reduces expected calibration error (ECE) from 0.37 to 0.03 compared with RLVR, with similar accuracy (62.1% versus 63.0%). Across six other datasets, average ECE falls from 0.46 to 0.21, while accuracy rises from 53.9% to 56.2%. These are the results in the paper’s Table 1(a).

Figure 36: RLCR results from the Beyond Binary Rewards: Training LMs to Reason About Their Uncertaintypaper.

Conceptually, the “Classifier” in “RLVR + Classifier” is a supervised binary classifier that predicts whether the generated answer is correct.

For Jev, I could apply calibration rewards directly to typed decisions, without generating reasoning text. For example, we could equip a GPT-style model with the classification head illustrated in Section 2.2 and adapt the RL training objective to reward accurate decisions and calibrated probabilities. We would train the backbone and classification head together. This would be an adaptation inspired by RLCR, and it remains unclear whether Jev’s RLCD works this way.

Alternatively, since Direct Policy Optimization (DPO) is a cross-entropy (CE) alternative to Reinforcement Learning with Human Feedback (RLHF), we could also directly minimize CE + Brier loss on the classifier’s probabilities. I did this with the ModernBERT model, and there was a modest improvement over regular temperature scaling.

Figure 37: ModernBERT improvements via RLCR-inspired Brier-loss optimization. The ↑ symbol means higher is better. The ↓ symbol means lower is better.

5.3 Side note: Is calibration necessary?

Cross-entropy already encourages accurate probability estimates. Under ideal conditions, that is enough to obtain calibrated predictions without an additional penalty.

I.e., using a simple coin flip example analogous to the movie review classification, the two classes are “heads” and “tails.” If it’s a biased coin that lands heads 80% of the time (in expectation), the true probabilities are 80% heads and 20% tails. On a representative training set, when we optimize cross-entropy, the model will already learn these as a side-effect of minimizing cross-entropy (negative-log-likelihood).

So, in short, if the model learns the true class probabilities, its predictions are calibrated and an additional penalty is unnecessary. (And Brier loss has the same theoretical optimum as cross-entropy, as described in Strictly Proper Scoring Rules, Prediction, and Estimationby Gneiting and Raftery, 2007.)

In practice, however, we never train to the real optimum (in expectation) but train on a finite dataset.

So, once a neural network correctly classifies most training examples, it can further reduce cross-entropy on the training set by becoming more confident. These confidence estimates may then generalize poorly to the test set and new data.

For example, in On Calibration of Modern Neural Networks, Guo et al. (2017) observed “neural networks can overfit to NLL without overfitting to the 0/1 loss.”

That means test accuracy can still improve while test cross-entropy worsens. So overfitting can show up in the probability estimates even when classification accuracy continues to improve.

Adding Brier loss changes how prediction errors are weighted during training. But whether this improves calibration needs to be checked on held-out data, of course. (The modest improvement in my experiment is an empirical observation for this setup, and we should not assume that adding Brier will always help.)

In my experiments (see previous figure), adding the Brier loss to cross-entropy provided only a very small additional calibration benefit.

But the motivation is more direct in RL contexts, such as described in RLCR, where we measure answer correctness and don’t already minimize cross-entropy. So, in RL contexts, the Brier term adds an incentive to report accurate confidence alongside the reward for answer correctness.

6. Who is Jev for?

Now that we covered Jev in reasonable detail, who is Jev for? Based on my assessment, it’s a pretty big target audience that intersects between people who a) want to save time by not having to fine-tune a custom classifier for every decision task and b) want to save money over using “the big guns” like GPT-6 and similar LLMs.

There are also lots of interesting use cases to think of. In the section below is a short list of ideas.

6.1 Jev use cases

The list of use cases is seemingly endless. Sure, there are flashy examples like having it play video games like Tetris (as I showed in my earlier video above to demonstrate the low latency of the API). However, sorting emails is a more practical choice for most. For example, one could use Jev as an additional spam filter, prioritization, and so on.

But beyond things like that, it could also serve as a tool to augment LLM-agent harnesses. Here it could be used as

a pre-screener for regular LLM-agent harnesses to scan our contexts for prompt injection;
select the reasoning effort level for a model;
select a skill.md from your registered skill library;
use it as a judge for evaluation or self-refinement;
find relevant files for context building.

The list is practically endless. Someone even posted a survey on arXivanalyzing 2,170 Jev-related projects that have sprung up recently in just a few days.

6.2 About Jev clones and local Jevs

Since Jev’s launch, 100s, if not 1000s, of quick Jev clones have sprung up. Most of the ones I checked out were just quick examples fine-tuning a ModernBERT or Qwen model with SFT and adding a Jev-like API.

Based on what I can tell, none of them achieves the same level of performance as Jev on such a breadth of tasks. Comparing these projects to Jev is like comparing Alpaca (the early instruction-finetuned LLM based off of the original LLaMA open-weight model) to GPT-6. Sure, it may work similarly in spirit, but your mileage will vary on real-world tasks.

No offense, but they seem like quick projects to jump on the hype train, and I don’t want to plug a specific one here.

One exception here might be the GLiNERproject, which has been around for ~3 years ago, and while it’s not fundamentally the same, it can be used for similar things. However, based on a benchmark, Jev is definitely stronger.

Figure 38: GLiNER vs Jev comparison via https://github.com/AbdelStark/jev-benchmarks/blob/main/results/reports/btzsc-pilot-v1.md

Anyways, there is definitely a genuine need and desire for a good open-weight alternative to Jev. The reason is not necessarily cost (because Jev is so cheap) but privacy. (Also, if Jev is already that fast over the internet, imagine how fast it could be on beefy local hardware.)

So, of course I’d like a DeepSeek (or Kimi, or GLM, or MiMo) moment for Jev. I am sure people are working on this, but it will take some time. TypeSafe AI worked on this for many months with a dedicated team of experts. It’s unrealistic to expect to replicate that development and evaluation work in a week. (However, since this is a smaller and more efficient model than a 1-trillion-parameter model, by nature, it hopefully won’t take that long.)

Update 1 (29 September, 10:20 am PT):OpenAI just announcedthe Decision API at their DevDay 2026 conference (29 September). It appears to be a Jev-like model directly integrated into their platform.

Decisions API enables real-time decision-making by focusing Luna’s intelligence on a specific set of user-defined questions with finite pre-defined answers. Developers supply context using text or images, and get back answers they can use to classify content, route requests, or choose an agent’s next action.

Available in limited preview today with a broad release planned in the coming days.

Figure 39: OpenAI’s Jev-like Decision API announced at the OpenAI Dev Day.

Update 2:A reader shared the Contrastive Language Modelsproject with me in the comments below. It’s one of the nicer-looking Jev-likes. When I tried it, its IMDb test accuracy is just 82.90% (over 96.47% in Jev), and it fails the Tetris test.

Another reader wrote in about Laya, another strong contender. It did better at IMDb (92.33% test accuracy) but then failed the Tetris testeven worse.

So, my point still stands. There are many solid alternatives. But what makes Jev so popular is not a unique idea (as mentioned before, classifiers existed for a long time) but the fact that it performs so well at so many diverse tasks. The only task where it allegedly doesn’t do well (as a reader told me) is legal reviews in non-English languages. (But the weak multilingual performance can be circumvented by connecting it to a cheap translation model, e.g., GPT -6 Luna with a small latency overhead.)

Conclusion

All in all, at first glance, Jev doesn’t seem to offer anything fundamentally new. After all, one might say that “it’s just a classifier” (with a nice API on top of it). However, it works surprisingly well across a huge range of tasks. In that sense, it’s the plug-and-play version of dedicated classifiers.

Sure, experts will still fine-tune specialist models, but the bar to justify fine-tuning a specialized model is now much higher, since it’s easy to just throw a Jev or Jev-like at it and get good-enough results.

Also, I don’t expect Jev and Jev-likes to unlock new capabilities or solve previously unsolvable tasks. However, if we make such models part of our agent harnesses to aid the expensive GPT-6 or Opus 5.5 models in decision-making within that harness, using agent harnesses could become much faster and cheaper in the future.

If you found this article useful, consider becoming a paid subscriberto Ahead of AI. Your support helps me spend more time on the experiments and detailed illustrations behind articles like this.

You can also support my work through my books, Build a Large Language Model (From Scratch)and Build a Reasoning Model (From Scratch), if you’d like to implement these concepts yourself.

Thanks for reading and supporting my independent research!

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR

Mon, 24 Aug 2026 04:45:00 CST

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR #8172，聊聊写 Agent 的那些烂坑

现在的 Agent 圈子很浮躁。

大家喜欢看炫酷的控制台动效，喜欢接几十个工具，喜欢等下一个更强的大模型。

但只要你把 Agent 放进真实的工程环境跑几天，就会发现现实很残酷：

跑了十分钟的任务，网络一抖或者内存一爆，进程挂了，会话直接报废。
执行一个 npm test，吐出三万行日志，上下文当场被撑爆，模型开始胡言乱语。
为了让用户实时插话，框架往会话中间塞了一条消息，底层的 KV Cache 全废了，Token 费用翻了五倍，响应慢得像蜗牛。
搞多 Agent 并发，多个任务抢着写同一个状态文件，数据直接写坏。

模型不是瓶颈，Demo 也没有意义。包裹在模型外面的 Harness（执行底盘）太烂，才是 Agent 落不了地的根本原因。

最近， Pi（ pi.dev / earendil-works/pi） 发布了 harness-v2.md 规范，随后合入了 PR #8172。这是一份没有废话的工业级 Agent 底盘设计。

1. Pi 是谁？

在开源 Agent 项目里，Pi 很低调，但地位很硬。

核心作者与团队：Mario Zechner（GitHub: @badlogic，著名开源游戏引擎 libGDX 的缔造者，典型的老派系统级程序员）与核心团队成员 David Brailovsky（ @davidbrai）、Vegar Stikbakke（ @vegarsti）。在设计文档中甚至明确写着： “如果设计不成立，停下来在 Discord 上找 Mario 商讨。”
PR #8172 作者：Adam Teale（ @adamteale）。这个仓库门槛极高，非协作者提 PR 会被 Bot 秒关，只有 Maintainer 明确给 lgtm 才能进入流程。代码质量把控极严。
项目定位： “Primitives, not features”（只做原语，不做死板特性）。它不搞花哨的 UI，只提供 @earendil-works/pi-agent-core（运行时）、 pi-ai（模型层）和 pi-tui（终端差分渲染）。像 OpenClaw 这类复杂的自主 Agent 框架，底层直接依赖 Pi 的 SDK。

2. 竞品锐评：市面上的 Harness 错在哪？

把 Pi 的设计和主流竞品放在一起看，很多流行框架的做法其实很业余。

锐评 LangChain / LangGraph：自找麻烦的“图状态机”

LangGraph 试图用有向图和 Generator 状态机去模拟每一步执行，搞出一堆复杂的类型转换和模板代码。一旦中途报错，状态机极难恢复。

Pi 的选择：Pi 早期也写过一套 Generator 状态机（ harness-v2-generator.md），后来直接废弃。Mario 的理由很简单： 直线的 async/await 最容易调试和理解。 不需要把代码切成碎块，只要把副作用边界划清就行。

锐评 DeepSeek Harness (dsh)：粗暴丢数据的截断器

处理工具返回的超大文本时，DeepSeek 的 Harness（dsh）采用固定截断策略（保留头 4096 字符、尾 1024 字符，中间直接扔掉）。

PR #8172 的爆破：PR #8172 作者 Adam Teale 指出： dsh 的做法是永久丢失数据。 报错堆栈的关键信息通常就在中间，扔掉之后模型就彻底瞎了。PR #8172 提出了 Spill-copy-on-prune：裁剪 Context 的同时，把完整内容写入磁盘文件，并保留精确的字符偏移。模型不仅知道中间被裁了，还能用 grep 去磁盘文件里把那几行找出来。

锐评 AutoGPT / CrewAI：没有容灾的纸糊玩具

这些项目擅长展示“多智能体开会”，但根本没有真正的持久化与崩溃恢复（Durability）。任务跑了 30 步，第 29 步崩溃，整局重来。

3. Agent 开发者天天踩的五个坑，Pi 怎么解？

坑 1：中途插消息，KV Cache 当场报废

现象： Agent 正在跑工具，用户发了一条修正指令（Steer）。很多框架直接把这条消息插到对话历史里。大模型的 Prompt Cache 依赖严格的前缀匹配。你在中间动一个字，后面的缓存全部失效。费用暴涨，延迟翻倍。

Pi 的解法：Append-Only Context（只增上下文） Pi 确立了一条铁律： 上下文只能在尾部增长。

运行中产生的配置变动、用户插话、延迟写入，先暂存到内存队列。
等当前回合（Turn）跑完，到达 Checkpoint（检查点） 时，统一追加到上下文末尾。
缓存前缀永远不变，KV Cache 命中率永远最高。

坑 2：进程挂了，留下半截死状态

现象：模型发起了两个工具调用，第一个执行完了，进程崩溃。重启后，对话历史里有调用指令却没有工具返回，下一次请求直接报 API 格式错误。

Pi 的解法：WAL 意图日志与预分配 ID Pi 借用了数据库系统的 Write-Ahead Logging 思想：

执行工具前：先写一条 step_attempt 意图记录到磁盘，里面包含预先分配好的结果 ID（ resultEntryId）。
执行完成后：用这个 ID 写入真实的工具结果。

  interface StepAttemptRecord extends RecordBase {
  type: "step_attempt";
  runId: string;
  step: "assistant" | "compaction" | "branch_summary";
  attempt: number;        // 重试次数写在磁盘上，进程重启也不会无限重试
  resultEntryId: string; // 预先指定的 Entry ID
}

系统重启时，恢复程序扫描日志。如果发现有意图记录但没有对应的结果，就能精准知道崩溃发生在哪个位置：能重试的自动重试，不能重试的自动写入一条 "interrupted" 占位， 绝不会出现残缺的孤儿状态。

坑 3：超大输出撑爆上下文，盲目截断导致模型幻觉

现象：执行一个命令吐出 50KB 日志，塞进上下文直接超限；如果直接把中间砍掉，模型看不到错误信息，开始胡乱猜测。

Pi 的解法（PR #8172 三级无损管道）：

> 50K 字符：内容全部写入磁盘文件（ ~/.pi/agent/cache/tool-spill/），上下文里只给简短预览和文件路径。
> 8K 字符：
- 完整内容写入磁盘。
- 上下文保留头 4096 字符 + 尾 1024 字符。
- 在字符串索引 0 处写入标记 [pruned — full at /path...]，并标明被裁剪的精确范围 [start, end)。
防死循环：模型调用读取工具去读溢出文件时，Pruner 自动放行，绝不二次截断。

实战测试数据（基于 GLM-5.3 和 DeepSeek-V4-Flash 的 19 次真实测试）：

未命中缓存的 Prefill Token 减少 72% ~ 88%。
每轮请求上下文占用减少 26% ~ 35%。
幻觉测试通过率 100%（0/9 幻觉），模型能通过精确偏移用 grep/ sed 从磁盘精准读回丢失的日志。

坑 4：多任务并发，状态文件被写烂

现象：多 Agent 系统让多个子任务并发修改同一个状态文件，在 Node.js 或 Python 异步环境下极易产生写覆盖和文件损坏。

Pi 的解法：Lanes（泳道）与不可变树 Pi 把会话结构分成了两层：

   会话树（只增、共享、无状态）:   a ─── b ─── c ─── d
                                       └─── e ─── f
 
 泳道（各自独立）:               main ──> 指向 d
                                slack_thread_1 ──> 指向 f

底层树（Tree）：所有节点只增不减，所有泳道共享，只读不改。
泳道（Lane）：相当于 Git 分支。每个 Lane 只有自己的指针和操作队列，两个 Lane 并行工作完全不需要加锁互斥。
单写者（Single Writer）：整个会话只有一个写入器，所有并发写操作通过单调递增的序列号排队追加。

坑 5：异步 Check-Then-Act 竞态

现象：代码判断“当前任务已结束”，准备关闭会话；就在这一瞬间，用户发来了 abort 或新消息。时序交错，导致中止失败或消息丢失。

Pi 的解法：Lane Mutation Line（泳道原子排队线） Pi 用一条极简的 Promise 链解决了所有竞态问题：

  let tail: Promise<unknown> = Promise.resolve();

function mutateLane<T>(job: () => Promise<T>): Promise<T> {
  const result = tail.then(job);
  tail = result.then(() => undefined, () => undefined);
  return result;
}

状态检查和落盘写入，必须打包成一个同步 Job 放进队列执行。
网络请求、模型调用、工具执行在队列外面跑，跑完了再排队写状态。
任何两个并发操作，在时间线上永远只有 [先 A 后 B] 或 [先 B 后 A]，没有第三种可能。

4. 确定性测试：线上代码怎么写，测试就怎么跑

很多框架的单测都是在 Mock 数据，一到线上就出 Bug。

Pi 定义了一个纯粹的副作用接口 Effects（ fx）：

  interface Effects {
  appendEntry(...): Promise<Entry>;
  appendRecord(...): Promise<T>;
  streamAssistant(...): Promise<SettledAssistantMessage>;
  executeTool(...): Promise<{ result: AgentToolResult; isError: boolean }>;
}

Agent 的所有逻辑，只能通过 fx 操作外部世界。

这带来了一个巨大的优势：

生产环境（ drive: "automatic"）： fx 直通系统，异步全速运行。
测试环境（ drive: "manual"）：每一个操作都会在 fx 边界停住。测试脚本可以像单步调试器一样，一步一步推着 Agent 走——可以在执行工具前强制断电，也可以在两个工具调用中间强行插入中断信号。

测试测的，就是线上跑的原版代码。

5. 总结

做 Agent，写 Prompt 只是第一步。

当系统进入真实工程，决定生死的是这几件事：

保住 KV Cache：不要随意插队改前缀。
做好 WAL 与崩溃恢复：把每一次动作先记下来再执行。
无损管理上下文：大输出落盘，保留偏移，给模型找回数据的能力。
管好并发与时序：单写者、只增树、排队写。

把这些脏活累活做干净，Agent 才能从玩具变成工具。

微软官方开源：一键把全新 Windows 11 变成干净、清爽的开发机

Sun, 27 Sep 2026 20:13:10 CST

重装 Windows、换新电脑，或者新建一台虚拟机，在安装好系统之后，最麻烦的还是配置环境：关闭 Widgets 和各种推荐，打开文件扩展名，装 Git、VS Code、Python、Node.js，再配置 WSL、Ubuntu……

这些事情都不难，就是又多又碎，又容易遗漏。

前段时间，微软开源了一个神奇的工具： Windows Developer Config，按照微软自己的说法就是：

一次操作即可将一台全新的 Windows 11 电脑变成一个干净、无干扰的开发工作站

标准安装

这款叫做 Windows Developer Config 的开源工具，用起来简单粗暴，只需要在 PowerShell 中运行：

irm https://aka.ms/devconfig/standard/setup.ps1 | iex

就可以实现：

删除/关闭

减少开始菜单、Windows Search 中的推荐和干扰内容
调整文件资源管理器中的最近项目、推荐等内容
减少部分 Windows 默认界面中的干扰项

安装/配置

VS Code、Git、GitHub CLI、GitHub Copilot CLI
Python 3.14 + uv
Node.js LTS + nvm
.NET SDK 10
Windows Terminal、PowerShell 7、Oh My Posh
WSL + Ubuntu
PowerToys、Coreutils for Windows、Windows App CLI
配置 Cascadia Mono NF 字体、深色模式、长路径等 Windows 设置

这是一套完整的开发环境，再也不需要手动设置了。

完整安装

而如果使用更激进的 Full 配置：

irm https://aka.ms/devconfig/full/setup.ps1 | iex

就可以实现：

关闭/调整

关闭 Widgets 小组件
关闭 Windows Search 中的 Web 搜索结果
关闭 搜索亮点（Search Highlights）
关闭开始菜单中的 推荐内容
关闭开始菜单中的 账户通知
关闭文件资源管理器「快速访问」中的 常用文件夹
关闭「快速访问」中的 最近文件
关闭文件资源管理器中的 推荐文件、云端文件
关闭文件资源管理器中的 同步提供商提示
隐藏 蓝牙托盘图标
关闭 PowerToys Always On Top 的通知
Edge 新标签页改成 空白页
跳过 Edge 首次运行欢迎界面
全局开启 勿扰模式，关闭 Toast 通知

安装

Windows Terminal
Intelligent Terminal
PowerShell 7
Git
GitHub CLI
Azure CLI
GitHub Copilot CLI
Visual Studio Code
.NET SDK 10
Python 3.14
uv
Node.js LTS
nvm for Windows
Coreutils for Windows
Oh My Posh
Windows App CLI
PowerToys
WSL + Ubuntu

同时配置：

开启 Developer Mode
开启 Windows Sudo
开启 Win32 长路径支持
开启 Remote Desktop
显示文件扩展名
显示隐藏文件
文件资源管理器默认打开「此电脑」
标题栏显示完整路径
任务栏右键增加「结束任务」
Windows 和应用切换为 深色模式
PowerShell 7 设为默认终端配置
配置 Oh My Posh
安装并使用 Cascadia Mono NF 字体
配置 GitHub Copilot Terminal Profile

WSL Comfort：顺手配置 WSL

Windows Developer Config 还提供了一套 WSL Comfort 工具，专门用来把刚装好的 WSL 命令行环境配置得更顺手。

只需要运行：

.\wsl-comfort\install.ps1

就会进入交互式设置，让你：

选择 zsh 或 bash，
自动安装常用工具： Starship、fzf、ripgrep、fd、bat、eza、zoxide、jq、Homebrew 等
配置 Cascadia Code Nerd Font 和 Windows Terminal 的 WSL Profile

还支持 -NonInteractive 无人值守安装。

另外，其中负责 Linux 环境配置的 comfort-shell-bootstrap.sh 也可以脱离 WSL，单独用于普通的 Ubuntu 主机。

也就是说，你可以非常容易的将同一套终端环境，复用到多台设备上。

只装需要的开发环境

对于不需要一键预装一大堆开发软件的用户来说，还有一个 Single-language workloads 功能，可以按需配置某一种语言或开发环境。

目前包括 TypeScript、Python、Go、Rust、Java、PHP、.NET、SQL、PowerShell、WinForms、WinUI 3、Windows App CLI 等。

例如，只需要 Python：

.\Workloads\python\install.ps1

就会自动安装 Python 3.14 + uv。

只需要 Java：

.\Workloads\java\install.ps1

则会安装 Microsoft Build of OpenJDK 25 LTS。

这样无论是准备一台完整的 Windows 开发机，还是只想快速搭一套 Python、Java、Rust 开发环境，都可以直接使用现成的配置。

获取

GitHub

怎么样，是不是有一种微软秘密武器的感觉？

开放权重模型逐渐形成了生态-软硬件、量化、Agent、推理引擎、后训练

Thu, 24 Sep 2026 11:43:22 CST

开放权重模型的竞争，已经不只是比谁 Benchmark 更高了。 Nathan Lambert 最新这篇文章，把能力、价格、下载量、真实调用和学术采用放到了一起看。一个很明显的变化是，中国开放权重模型已经形成了自己的生态。按他的统计，中国模型在 Hugging Face 的累计下载量约 32 亿，是美国的两倍；OpenRouter 上开放模型每周使用量已经从一年前约 1T Token 涨到 80T，其中中国模型占比超过 80%。学术圈也很明显。Qwen 现在出现在约 30% 的 AI 论文里，中国开放权重模型整体已经超过 40%。更关键的是，Lambert 估计最强的中国开放权重模型距离美国闭源前沿只差大约 2–5 个月。这当然是他的估计，但已经足够说明变化有多快。所以我现在更在意的不是「开放模型能不能追上闭源」。而是谁的模型会成为别人做研究、搭 Agent、做产品时默认踩着的那一层。一旦形成这种习惯，影响的就是整个开发生态。文章： interconnects.ai/p/the-current-…

不要被 AI 炒作愚弄

Wed, 23 Sep 2026 23:29:02 CST

Anthropic 声称其模型 Claude Mythos 在发现软件漏洞上胜过大多数安全专家。随后发生了 OpenAI–Hugging Face 安全事件，此后 Anthropic（自豪）和 Meta（不情愿）也披露了各自模型的类似事件。紧接着 Anthropic 宣称其模型取得了数学领域的突破；OpenAI 也声称自己取得了数学突破。Anthropic 工程师 Jacob Coxon 在宣布离职时引发了广泛关注，他声称该公司与 OpenAI 正“冲向自我进化的超级智能，并拿我们的生命在赌博”。媒体大肆报道了这些事件，且沿用了相关公司赋予其软件的拟人化叙事——即把软件描绘成不仅功能强大，而且已初具通用人工智能（AGI）雏形的产物。但深入研究的专家则给出了不同的答案，虽然这些发现并不能吸引眼球。网络安全专家指出，涉及模型的安全事件更多是 OpenAI 的疏忽大意，未能采取基本的安全措施，而不是“模型失控”或“AI 智能体创造文明”。OpenAI 模型在解决数学难题上的突破其原创性也相当可疑。数学家公开对 AI 企业利用其专业领域进行炒作提出了警告。AI 公司通过炒作模型失控也将自己置身事外，将责任归咎于大模型而不是公司本身，逃避应承担的责任。以 OpenAI 为例，当该公司开发的恶意软件被用于入侵另一家公司时，媒体、名人和议员谈论是“失控模型”而不是 OpenAI 的责任，仿佛大模型真的会自动发动攻击，公众的注意力被转移到虚构的“超级智能”的恐惧之上。我们不要被 AI 公司的炒作所愚弄。

Jev 工程学：为 coding agent 而作

Wed, 23 Sep 2026 16:00:35 CST

Jev 工程学：为 coding agent 而作

2026 年 Jev 工程实践工作笔记副标题：TypeSafe 创始人的 Jev 构建蓝图 A Synthesis for Study · Based on design notes by Diogo Almeida (TypeSafe) 独立汇编，2026 年 9 月。与 TypeSafe 无隶属关系，亦未获其背书。

本文是原文 PDF的完整中文翻译，保留原有结构与全部七张插图。

本仓库现在有两份文档

本页（根目录）：第三方根据笔记 汇编整理的工作笔记——结构正式、有图表、「六个症状」已表格化

source-notes/：作者的 原始设计笔记——保留了原始项目符号结构、随手记的链接，以及尚未定型的口语化表达

两份对照读，能看到从笔记到成文的加工过程。原始笔记里有汇编版没有的内容（如 SLOP 子任务拆解、附录 2 引用的原始推文、以及作者的推理过程）。

图 1. Jev harness。显式状态（左）以可寻址、带类型的块存储。Jev（右）回答每一轮的问题：显示哪些块、是否复用缓存、用哪个模型和工具、以及一条命令能否执行。上下文组装层与路由器驱动运行时，运行时以「片段优先」的方式披露数百个工具，并在安全策略下把工作路由到前沿模型、子 agent、廉价模型或后台模型。

摘要

Coding agent 简单得出人意料。大多数就是一个模型加少量工具的 while 循环，而模型本身之外几乎没有什么有意义的创新。

这份笔记综合了 TypeSafe 创始人 Diogo Almeida 的设计笔记，讲的是围绕 Jev 构建 coding agent 的思路——Jev 是 TypeSafe 的决策模型，把结构化状态转换成类型化输出，例如 choice、score 和 noul 决策。

笔记从一个挑衅性的问题开始： 如果语言模型没有 KV cache，你会怎么设计一个 coding agent？

这个问题暴露了当前 agent 不加审视就继承的六个设计选择： 亏损的路由、挤占上下文的工具调用、盲目压缩的 compaction、几乎不触发的子 agent、丢弃状态的重启、以及电池之争。

我们呈现笔记提出的替代架构：一个围绕显式、带类型状态构建的 harness，由 Jev 做每一轮的决策。其中上下文块按查询逐个打分，路由定价时计入重新处理的成本，工具分级披露，指令按条件加载，只读的后台任务共享一次检索。

我们还演算一遍路由算术、真实 agent 会话的 token 经济学，以及按文件敏感度（而不仅是难度）路由的安全论证。

索引词：Jev、TypeSafe、coding agent、harness 工程、KV cache、上下文工程、模型路由、子 agent、工具调用、compaction、AGENTS.md、后台 agent。

I. 为什么还要再做一个 agent

笔记以四个工作假设开场。

第一，coding agent 很简单，尤其是 agent 的部分：一个循环、一个模型、少量工具。

第二，现有 agent 中最好的部分可以复用。前沿模型都能通过 API 拿到，开源项目提供了灵感和甚至 UI 组件，而只有少数领域（比如 MCP 服务器的认证）才带有真正的复杂性。

第三，第一方 agent 的成本优势可能在缩小，因为用量正从捆绑订阅转向按量付费的 API 定价。

第四，也是最重要的，有些能力只能原生构建。它们无法作为插件交付给别人的 agent，因为它们要求控制 每一轮上下文是如何被组装的。

第四个假设就是论点。 如果 agent 只是一个循环，那么杠杆不在循环里。杠杆在于循环每一轮喂给模型的东西。

A. Jev 站在哪里

Jev 不是写代码的模型，它是旁边那层决策层。

harness 把当前应用状态（目标、上下文、规则、可用动作、之前的动作）和一个预定义问题交给 Jev，Jev 返回一个类型化答案：choice、score 或 noul，每个都带概率。然后由前沿模型、子 agent、工具和确定性代码去做实际工作。

因为输出是类型化的而不是自由文本，harness 可以验证它、施加阈值、基于它分支，而不必解析散文。

这份笔记里每一个原生功能，底层都是在高频决策点上问 Jev 一个问题。 每个会话被问上千次，那些小决策才是杠杆所在。

B. 组织起一切的那个问题

笔记描述了一个他喜欢问其他工程师的问题： 如果语言模型没有 KV cache，你会怎么设计 coding agent？

KV cache 是 agent 被建成「只追加对话记录」的原因。复用缓存前缀很便宜；改动上下文早期的东西会让缓存失效，迫使模型重新处理改动之后的一切。 这个单一的经济事实塑造了当前 agent 的几乎每一个设计决策——而且通常没人把这件事说出来。

想象把缓存拿掉，会做两件事。它允许一种为 Jev 设计的、状态显式的架构—— 上下文是被组装的，而不是被累积的。同时它揭示为什么「把简单活路由给便宜模型」这种直觉上正确的想法在实践中会失败。

笔记管这叫 「KV cache 的暴政」。

II. KV cache 的六个症状

症状	为什么存在	代价
1. 路由失效	交还给大模型时需要重新处理上下文	混合路由比纯前沿更贵
2. 工具挤占上下文	schema 必须待在系统消息里	token 花在无关工具上；选择质量下降
3. Compaction	假设所有未来轮次共享同一份状态	查询无关的压缩丢掉了后面需要的东西
4. 子 agent 稀少	决定传什么上下文进去、什么合并回来很难	几乎没有自动并行
5. 重启	有状态的对话记录会随时间腐坏	相关的旧状态跟着坏状态一起被丢弃
6. 电池之争	每个内置能力都永久消耗上下文	在易用与强大之间被迫二选一

A. 路由不工作

直觉方案是让前沿模型规划、把执行交给便宜模型、再让前沿模型回来审查。笔记用 Opus（$5 输入 / $25 输出每百万 token）和 Sonnet（$3 / $15）的标价算了这笔账。设 X 是上下文 token，Y 是生成的输出 token，Z 是工作中额外读入的 token（比如命令输出和文件读取）。

      路径 1  纯 Opus
  生成        25·Y
  读取        5·Z
  合计        25Y + 5Z

路径 2  Opus → Sonnet → Opus
  Sonnet 载入上下文         3·X
  Sonnet 生成               15·Y
  Sonnet 读取               3·Z
  Opus 重新加载变化的部分    5·(Y+Z)
  合计                      3X + 20Y + 8Z

当会话很长（X 大）、或工作读取远多于写入、或两者兼有时，路径 2 更贵。 代入一个合理的会话形态 X = 0.65、Y = 0.12、Z = 0.23，纯 Opus 是 4.15，路由路径是 6.19。

留在前沿模型上的成本，大约是那条本该省钱的路径的三分之二。

图 2. 路由陷阱。把执行委派给便宜模型，会在下行时加一次上下文载入、在回程时加一次重新处理，两者加起来超过了每 token 的折扣。

教训不是「路由是错的」，而是 按 token 定价、而不是按上下文重建定价的路由是错的。路由只有在两个条件下才可行： harness 能给便宜模型一个小而专用的上下文（而不是完整记录），且回程不强迫前沿模型重读助手产出的一切。

B. 工具调用是个奇怪的取舍

工具必须提前在系统消息里声明，带着完整的参数 schema，不管这轮用不用得上。这消耗大量上下文，而且笔记的判断是： 它并不产生特别聪明的工具选择。

工作假设是：模型在「高基数」（一次给太多工具）和「离策略工具调用」（工具的使用模式与训练时见过的不符）的某种组合上挣扎。

这可能就是为什么 skills——加载一句短描述、细节延后——常常胜过裸工具列表和 MCP 服务器。

C. Compaction 存在

如果每个未来轮次都想要同一份共享状态，compaction 就完全合理。笔记质疑的正是这个假设。

Compaction 试图做通用压缩，这既难又有损。而查询感知的压缩容易得多：如果你知道下一个问题是什么，你就知道该留什么。

在问题已知之前写下的摘要，一定会丢掉问题需要的东西。

D. 子 agent 很平庸

模型并行的程度低于预期。怀疑的原因在状态管理： 决定父上下文的哪些部分要传进去、每个子 agent 的发现中哪些要合并回来。

当这个决策既昂贵又容易出错时，模型就会回避它。

E. 重启存在

重启会话是对话记录漂移或损坏时的标准补救。 但它把坏状态和好状态一起丢掉了。

有了可寻址状态，替代方案是干净启动、按需只重新加载仍然相关的旧块。

F. 电池并非内置

关于 agent 是否该内置能力，有一场持续的争论。今天它是在「易用」（重度内置的 agent 在一端）和「强大」（Claude Code、Codex 这类高级用户工具在另一端）之间的取舍。

这个取舍存在，仅仅因为每块电池都永久消耗上下文。把那个成本拿掉，争论就消解了。

III. token 到底花在哪

在重新设计 harness 之前，先搞清楚一次会话里哪个部分吃掉了预算。下表估算典型 CLI coding agent 会话中，各子任务占总处理 token 的份额。 这是输入密集视角，所以重复读取每次计数。

子任务	约占	说明
读文件内容	30–40%	最大项；文件作为上下文被反复读取
搜索代码库	10–18%	grep、glob、列表；输出噪音大
命令输出	10–20%	堆栈和日志在失败时爆开
系统提示、工具 schema、AGENTS.md	5–12%	每一轮都付的固定开销
对话重放放大器	—	为什么上面每一项都被重复计数
推理与规划	5–15%	困难调试时更高
写和编辑代码	4–10%	diff 和 str_replace 编辑很紧凑
向用户解释	2–5%	CLI agent 默认简洁

图 3. 检索占主导。读取、搜索和命令输出合计约占处理 token 的三分之二；写代码不到十分之一。

最触目惊心的是倒数第二行：写代码，也就是 coding agent 存在的理由，是其中最小的开支项之一。读取和搜索占主导。

独立的分析指向同一方向： 微软的 fastcontext 项目报告，在 GPT-5.4 的轨迹里，读取和搜索占所有工具调用轮次的 56.2%、占主 agent 总 token 的 46.5%。

如果这能推广，coding agent 里最大的效率收益不是更好的模型或更好的 diff 格式，而是更聪明的检索。

IV. 基础层：权限与工具路由

有两项改进可以集成到任何现有 agent 里，无论原生与否。

A. 可编程权限

每一条 agent 运行的命令都提出「它到底该不该跑」的问题。Claude 的 auto 模式用分类器回答这个。 笔记提议走得更远：权限表达为对「什么允许、什么不允许」的可编程查询，而且在风险足够高时做更深的检查——比如在执行前读取 Python 或 shell 文件的内容，而不是只批准命令名。

policy "exec":deny   if command touches ~/.ssh or .env*deny   if script contents contain network egressand task.scope != "deploy"ask    if command writes outside repo rootallow  if command in read_only_setallow  if tests/ and exit code is expected

B. harness 作为工具路由器

不是把每个工具 schema 都暴露给模型，而是让 harness 坐在意图和调用之间。 模型用纯文本描述它想干什么。harness 然后用一串类型化的 Jev 调用来选出最合适的那个工具（或前几名候选），并构造参数。

模型永远不必在上下文里持有几百个 schema，而错误的参数类型会变成验证错误，而不是静默失败。

V. 元注意力：把上下文本身当成决策

核心提议去掉了「上下文是静态的」这个观念。

对每一个用户查询，harness 问 Jev 两件事：

第一，之前的上下文有多好——复用现有 KV cache 是对的吗，还是从头重建更便宜也更好？ 这被框定为一个显式的、成本感知的决策，而不是默认行为。

第二，如何构造一个包含所有相关的、且不含任何多余的新上下文。

最简单的形态是：对每一个上下文块做一次 noul——每次工具调用的输入、每次工具调用的输出、每一段内部推理、以及可能每一次与用户的交流。 后续版本把分数换成可见性级别。

图 4. 可见性阶梯。同一个块可以被隐藏、简短总结、详细总结或完整展示，取决于当前查询。 这就是查询感知的压缩——compaction 所缺的那个属性。

收益是： compaction 背后的想法活下来了，但它的主要缺陷消失了。Compaction 在知道问题之前压缩一次；阶梯在知道问题之后按查询压缩。

一个 2400 行的 grep 结果，对某个问题可以是十二条相关命中，对下一个问题可以是不可见的——而它从未从状态里被删除。

笔记还加了一个值得注意的视觉想法： 如果 harness 能热力图显示 grep 输出里哪部分相关，它就能按预算允许的程度随意过滤那份输出。而且，笔记观察到， 它看起来也会很酷。

VI. 路由与子 agent 重访

一等公民的动态上下文，是让路由重新可行的原因。

一旦 harness 能为子任务构造一个小而相关的上下文，把这个子任务交给更便宜或更快的模型就不需要便宜模型载入整个会话， 而结果可以作为被评分的块合并回来，而不是一份前沿模型必须重读的记录。

同一机制解锁了子 agent。 笔记的猜测是：今天子 agent 成本的大部分，是决定传什么上下文的工作——相比之下，用户敲一条简单指令反而容易。

如果构造那个上下文变得便宜且自动，子 agent 就能用得频繁得多。

它还打开了一个面向用户的控制： 多花钱换更快或更好的结果，还是保守运行、尽量少花。

A. 极端并行

如果派发任务变得便宜，很多任务会同时跑，harness 就继承了并发系统的全部问题： 同步原语、agent 间通信、多个 agent 共享状态时的写冲突。

笔记建议用带锁的共享状态。 而显式区分读与写让它变得可处理，因为只读任务永远不会争锁。

B. 目标去重

对 /goal 这类目标驱动的循环，一个悬而未决的问题是：agent 会不会重复劳动。

一个缓解措施： 在派发任何子任务之前，把它注册为子目标，并与所有历史子目标去重。已经做过的、或正在飞行中的工作，永远不会被启动两次。

VII. 工具与技能，从第一性原理出发

笔记主张在「今天总是加载的工具」和「按需加载的 skills」之间加一层。

模型无法提出一个它不知道存在的动作，所以它需要短片段来描述有什么可用，类似于 skill 描述。 但这些片段不必住在系统消息里——它们可以在相关时动态加载。

它们背后是「在需要时倾倒出可用动作的完整 schema」的能力，类似一个工具搜索工具。

把这一切绑在一起的要求是：这些东西在不再需要之后，都不能污染上下文。

图 5. 三级披露。模型看到一张廉价的全局地图，只为它选中的东西付细节的钱，用完之后把细节从上下文中丢掉。

如果这能成，第二节里的电池之争就消失了：当一个内置能力在被使用之前几乎不花成本，agent 就能带着几百个工具和几千页文档发布。

笔记还点出第二个好处： 近乎零成本的集成是强有力的联合营销渠道，而且它们让事情「就是能用」。

A. 更好的电池

很多社区工具承诺帮助 agent，实际上并没有。笔记举了一个工具输出压缩器作为例子，并猜测原因： 模型并不原生理解这些工具。

一个原生 harness 可以发布第一方的提示词，教模型如何使用每一个工具——实际上相当于每个工具配一个内置的子 agent 或 skill。而它干净的上下文意味着工具的自定义逻辑不会污染会话的其余部分。

这里也有营销角度： 为你当前流行的工具发布集成，能让 agent 保持在对话之中。

VIII. 条件化指令

今天的 AGENTS.md 是全量加载的。笔记提议按条件加载。

改前端代码就加载风格指南；在某个子目录里工作就加载那个目录的坑文件（ 而且笔记建议每个子目录都该有一个）。

图 6. 条件化 AGENTS.md。指令附着到条件上而不是会话上，而且条件片段会被钉住，使 compaction 无法把它摘要掉。

这像 skills，但笔记画出了一个区别： skills 通常意味着「现在做这个」。条件化指令意味着「把这段记在某处」。

第二种还需要一个 skills 没有的属性：免疫于压缩。一个在长会话早期加载的 skill 最终会被压缩或摘要掉； 而一个绑定到条件的指令会在条件成立时被重新加载。

笔记在普通聊天里观察到同样的需求：请求摘要应该拉入一个偏好的格式；请求用自己风格写作应该拉入样本和一份「不要什么」的清单；请求代码应该拉入风格指南和一条「不要加一百万条断言」的提示。

A. 结构化 skills

取决于 harness 变得多可编程，skills 可以携带行为变更而不只是指令，类似 Claude Code 的 skill hooks 但更强大。

笔记指出的当前 hook 系统的一个限制是：一旦加上，hook 就永久留在会话里。结构化 skills 会随触发它们的条件附着和脱离行为。

B. 递归语言模型

一个相关方向是递归语言模型（recursive language models）的方法，它把 agent 更多的状态当作显式变量而不是对话记录文本。

一个状态保存在具名变量里的世界，可能比「状态就是上下文窗口里恰好剩下的那些东西」的世界干净得多。

IX. 安全感知的路由

今天的路由围绕难度和成本。 笔记加了第三个轴：信任。

一些通过低价供应商提供的开放权重模型比前沿 API 便宜得多，而笔记提出的担忧是： 经过某些端点的数据可能不再私有。

提议是给每个子任务一个「可能触碰哪些文件」的估计，把策略附着到文件类型上，并据此路由。

可能触碰的文件	策略	可用模型
公开文档、开源依赖	开放	任意，最便宜的优先
应用代码	标准	经过审查的供应商
密钥、env、基础设施配置	受限	只用第一方前沿模型
专有研究代码	自定义	排除指定供应商

最后一行反映了一个更广的观点： 难度和成本不是路由的唯一理由。

一个团队可能因为自己在做模型研究而避开某家供应商的模型，或因为安全工作而避开某些供应商。 一旦路由是策略驱动的，这些偏好就变成配置而不是纪律。

X. 后台处理

笔记识别出几种流行 agent 工作流里的一个共同模式：

构建随工作进展而并行更新的 HTML 页面
「理解而非生成才是新瓶颈」的论点
在后台生成 eval
用几张图加极少的字解释系统的 ELI5 技能
让 agent 维护一个小型已部署的进度页面，带截图和笔记， 可以在长任务期间从手机查看

还有一个相关的生产模式： 把线上流量镜像到候选模型，自动生成约一天的 eval，然后才决定是否切换。

它们的共同点是： 在后台运行、作为正常工作流的扩展、而且都是当前代码库状态的只读函数。跨模型审查（让一家供应商的 agent 审查另一家的产出）属于同一模式。

图 7. 显式状态上的后台处理。找出与某个改动相关什么的这项昂贵工作，只做一次，由每个只读后台任务共享。

这正是 Jev 论点兑现的地方。以 Jev 为中心的 harness 必须精确知道上下文里有什么、以及每个操作是读还是写。 找出与某个代码改动相关的信息，是件不平凡的工作。

如果这份检索在所有后台任务间共享、而不是每个任务重复一遍，运行它们就会便宜得多，也就能经济地跑更多。考虑到第三节的发现——检索占主导地位—— 共享它就是最大的单项节省。

把读写显式区分开，用笔记的话说， 最终应该给 agent 超能力。

XI. 电池候选清单

笔记最后列了几个可以被原生集成的开源项目，每个都附了「以 Jev 为中心的 harness 会怎么用它」的设计说明。

项目	角色	原生角度
headroom	上下文压缩器	用分类器检查压缩是否保住了需要的事实
rtk	工具输出压缩	第一方提示，让模型理解它
ast-grep	结构化搜索	加载一次手册，生成 N 个查询，按相关性过滤
ast-outline	结构化大纲	层级调用：选出要检查的子树
fastcontext	仓库探索子 agent	路由到它，或用结构替代它的搜索
fff	路径与内容搜索	内存索引、频率排序，长会话里比 ripgrep 快

XII. 结论

设计笔记提出的论点 说起来容易、做起来难：

coding agent 是简单的循环，而杠杆不在循环里。杠杆在于 harness 每一轮放在模型面前的是什么——而今天这个决定是由默认值做的，由一份围绕 KV cache 经济性塑造的、只追加的对话记录做的。

把缓存拿掉当作思想实验，六个熟悉的行为就变了样：

路由失败是因为上下文被重新处理，不是因为便宜模型弱
工具挤满窗口是因为它们必须提前声明
Compaction 丢信息是因为它在问题已知之前压缩
子 agent 稀少是因为传状态很难
重启把好状态和坏状态一起丢掉
电池之争之所以存在，只是因为每个内置能力永久消耗上下文

所提议的 harness 用一个动作应对全部六项： 让状态显式且带类型，让 Jev 按查询决定上下文、路由、工具和权限。

块在可见性阶梯上被打分。路由按上下文重建定价。工具分级披露。指令附着到条件上。后台任务共享一次检索。

这些都不需要更好的模型。它需要把上下文窗口当作一件被有意组装的东西，而不是一件偶然累积的东西。

来源说明

独立汇编，供研究之用。与 TypeSafe 无隶属关系，亦未获其背书。Jev 依据 TypeSafe 材料描述为一个返回带概率的类型化 choice、score 和 noul 决策的决策模型。

核心论点、路由算术、六个症状以及所提议的功能，来自 TypeSafe 创始人 Diogo Almeida 提供给汇编者的设计笔记。

读取与搜索的份额数字（GPT-5.4 轨迹中占工具调用轮次的 56.2%、占主 agent token 的 46.5%）如微软 fastcontext 项目所报告。

token 份额表是对 CLI coding agent 会话的示意性估计。递归语言模型：A. Zhang, 2025。工具引用：headroom、rtk、ast-grep、ast-outline、fastcontext、fff（GitHub）。模型标价取自笔记所用，可能已经变动。所有图表均为原文所绘。

关于本翻译

原文： assets/original.pdf（12 页，WeasyPrint 生成）
原文纯文本： assets/original-text.txt
插图：从原 PDF 的矢量图表按 300 DPI 精确裁切，共 7 张，位于 figures/
翻译保留原章节编号与结构；英文原文的排版错误（如小标题的大小写异常 sIX sYMPTOMs OF THE Kv CACHE）在译文中已按正常书写呈现
上游原始笔记： source-notes/（本文档所依据的设计笔记，及其中文翻译）

人工智能软硬件推理优化进行中-Inside the Inference Hardware Revolution Of 2026 - IEEE Spectrum

Wed, 16 Sep 2026 09:30:27 CST

IEEE Spectrum《The AI Inference Revolution Is Here》（Matthew S. Smith，2026年9月15日）核心内容总结

文章指出，2020年以来AI的重心在于训练更大的模型，而到2026年，推理（inference）已取代训练成为行业焦点。原因有三：模型真正变得好用、用户激增；如今大量模型是"推理模型"，会通过思维链多次自我提问，高推理强度时输出的文本量可达低强度的约20倍；以及智能体（agentic AI）让推理从实时问答变成全天候自主运行。

技术上，推理与训练的计算特征不同。由于模型是自回归的，生成每个新词元都要读取全部权重和此前的上下文。回复分为两个阶段：预填充（prefill）并行处理整个提示词、计算注意力，适合GPU；解码（decode）逐词元生成，每预测一个词元都要从内存中读出整个模型，再加上KV缓存的开销。数据搬运所需带宽常常超出硬件能力，导致计算单元空转——有研究发现运行开源大模型的英伟达H100有50%到80%的时间处于闲置状态。

因此内存成为主战场，各家路线各异：d-Matrix把计算芯片直接堆叠在DRAM之上，将数据传输距离压缩到微米级；Majestic Labs则改进内存接口，用专有铜链路与聚合芯片连接远至约一米外的廉价DRAM，单机架可支持高达128TB内存，远超英伟达GB300 NVL72约20TB的HBM3E；SK海力士等则押注已量产的HBM4。

巨头选择"分工组合"：英伟达用Rubin GPU处理计算密集的预填充，用片上SRAM丰富的Groq 3 LPU处理内存密集的解码；AWS则将Trainium与Cerebras晶圆级引擎配对，后者把整片晶圆做成单芯片，集成超过4万亿个晶体管和44GB片上SRAM。

软件侧，量化（如NVFP4、MXFP4）以极小的精度损失换取数倍性能；Tensordyne用对数数系以加法替代乘法，Etched则把Transformer架构直接固化进硅片。文章最后认为，不会有单一赢家——推理硬件将像当年的CPU一样，沿多条路径并行演进。

Since about 2020,AI has largely focused on training bigger and better models. Large language models (LLMs) ballooned from millions of parameters to trillions. This proved effective: The largest version of OpenAI’s GPT-3, released in 2020, correctly answeredjust 43.9 percent of questions on a popular knowledge-and-reasoning benchmark. Just four years later, GPT-4o reacheda score of 88.7 percent on the same exam, effectively matching those of human experts.

Advanced AI labs are still training ever larger models, but that training has somewhat receded to the background of the AI conversation. In 2026, inference—the use of trained models to produce code, write essays, or make images of ourselves as elves—has come to the forefront.

“It’s like training is yesterday’s news,” says Matt Kimball, principal data-center analyst at Moor Insights & Strategy. “All that any chief information officer wants to talk about is inference.” Nvidia CEO Jensen Huang, speaking at the company’s GTC 2026 conference, touted this change as the “ inflection point of inference.”

Part of what’s caused the shift is very simple: LLMs are becoming useful, so people are using them. On top of that, many models on the market today are reasoning models. In response to a user’s query, they run inference not just once but multiple times, reprompting themselves in a process called chain of thought. Reasoning models generate longer outputs, and models with high reasoning effort can produce up to 20 timesas much text as those with low or no effort. Adding even more to the world’s inference workload, the rise of agentic AIhas resulted in inference running not just as a real-time response to a user’s query but also around the clock, working autonomously toward a user-defined goal.

Amazon’s Trainium chip was originally designed for AI training. However, Amazon Web Services chose to break up AI inference into two parts, with Trainium running the more computationally complex portion and Cerebras’s wafer-scale engine taking on the more memory-intensive portion. Amazon

The resulting explosion in inference demand has led to unexpected alliances among tech giants. OpenAIand Amazonhave deployed chips the size of a dinner platedesigned by Cerebras, despite Amazon having its own Trainiumchips. Nvidia boughtkey talent and intellectual property from AI-inference startup Groqin a controversial deal worth US $20 billion. And Anthropicis payingLLM competitor SpaceXAIover a billion dollars per month to lease spare compute.

Although they might seem similar, AI training and AI inference are computationally different. These big moves from tech giants signal that in order to support the inference demand, we’re going to need a very different mix of hardware than experts may have expected even a couple of years ago.

How does AI inference differ from AI training?

An untrained LLM is like a jumble of Scrabble tiles on a table. Instead of single letters, though, the tiles show fragments of words, called tokens. Everything you’d need to write almost anything is present, but nothing makes sense.

Training a model organizes this jumble using a guessing game played at scale. The model is shown real text with the next token hidden and asked to predict what comes next. After each guess, the correct token is revealed and then compared to the prediction, and the difference is used to calculate the model’s accuracy. The game is played not with a single sentence but over billions of passages.

While a real game of Scrabble can be played over a bag of chips and a few drinks, AI training is computationally intense. The model updates its parameters through backpropagation, a process that repeatedly calculates how each of a model’s billions or trillions of parameters should shift to make the next prediction better. This is why tech giants are buildinglarger data centers than ever before.

Eventually the model’s creator decides further training isn’t worth the cost, and the guessing game stops. Backpropagation ends, the parameters are frozen, and the LLM becomes a pretrained model. Fine-tuning—a short training run on smaller, more specialized data—adds final tweaks, and the model is deployed.

Nvidia’s Groq 3 language-processing unit minimizes data movement by placing on-chip SRAM memory and computational blocks in the order they are needed on-chip.

Nvidia

Next comes inference. This is the process of using the deployed model, which, now that it’s been trained, has learned to spit out Scrabble tiles—tokens—in a sensible order.

You might think that AI inference is less computationally demanding because the backpropagation calculations used to update parameters are eliminated. But Sudeep Bhoja, founder and CTO of the inference-hardware company d-Matrix, explains that inference adds new challenges.

The models are “autoregressive” in nature. That is, the next output depends on the previous one. “So to generate the next token, you have to read all of the weights and all of the [context] from the previous token,” explains Bhoja. The context includes all of your prompts, all of the LLM’s replies, and all of the files you upload. It’s a lot of data and a lot of processing.

An LLM generates its reply in two phases: prefill and decode. Prefill is the model reading a prompt. It processes every token at once, computing how each token relates to all the others. This operation is called attention, and it’s a defining characteristic of the transformer architecture behind modern LLMs. It allows them to respond to a word in its sentence, paragraph, and larger context rather than on its own. Think of it like arranging Scrabble tiles before you place them in a game. Many players move tiles around to imagine how they connect. Self-attention plays a similar role, though instead of moving physical tiles, each token sends a query to the others and receives a score indicating the token’s relevance.

These queries result in two types of vectors: the keys and values. They are typically placed in a store called the KV cache. This isn’t strictly required, as a model could instead recompute these vectors with each new token it generates. But nearly all LLMs use a KV cache to reduce how much computing they do. The KV cache is stored in memory and becomes a scratchpad to which the LLM can return to understand a conversation, and though it starts small, it can swell to dozens of gigabytes.

Prefill is a problem that can be easily divided up and worked on in parallel. This is why GPUs became the dominant AI accelerator as LLMs surged in popularity. Graphics rasterization (computing the color of every pixel on a screen) is also massively parallel, so GPU architectures were a natural fit.

Cerebras’s wafer-scale engine chips maximize memory bandwidth by keeping everything—both memory and computational units—side by side on the dinner-plate-size chips.

Cerebras

Next comes decode. Here, the model generates its reply one token at a time. At each step it takes the most recent token, weighs it against everything in the KV cache, uses that information to predict the next token, and adds the new token’s key and value to the cache. Then it repeats in sequence, token by token.

This is where the autoregressive nature of the model works against inference speed. Predicting each token requires reading the entire model from memory, and that model consists of possibly tens to hundreds of gigabytes of parameters (the numbers representing what the model learned in training). Crucially, this is in addition to the memory required to store the KV cache.

As a result, the movement of all this data through memory often requires more bandwidth than inference hardware has available. So at least some of the computing parts of a GPU sit idle as it waits for data. Researchers foundthat Nvidia H100 GPUs running open-source LLMs sit idle 50 to 80 percent of the time.

Memory’s role in inferencing

Shahriar “Sha” Rabii, former head of silicon engineering at Meta and cofounder of the AI startup Majestic Labs, says idled processors are why many companies that are trying to improve AI-inference performance are laser-focused on memory. “With the GPU-based approach, you end up greatly over-provisioning compute and starved on memory. That’s driving the big [memory] scale out,” he says.

Bhoja’s d-Matrix and Rabii’s Majestic Labs both focus on this memory bottleneck. However, their companies imagine different solutions.

d-Matrix’s second-generation AI accelerator, Raptor, aims to improve inference performance by minimizing the distance between compute and memory. The GPUs in most current AI-inference deployments do this by placing high-bandwidth memory (HBM) around the perimeter of the GPU. Each HBM is a stack of DRAM dies linked together and connected to a superfast interface to the GPU. This is great for training, but for inference, the amount of memory you can stack this way and the bandwidth it can provide leave something to be desired.

d-Matrix’s stacked-die architecture

Memory bandwidth—how quickly data can be read from memory to logic—is a major bottleneck in AI inference. The startup d-Matrix is increasing that bandwidth by stacking the logic die directly on top of the memory, in this case DRAM. This allows for lots of extremely short interconnects.

Chris Philpot

d-Matrix’s Raptor removes that bottleneck by stacking an AI accelerator on a DRAM die. Instead of stacking memory, d-Matrix stacks memory and compute. Bhoja says this reduces the distance that data must travel to “micrometers instead of millimeters.” Like building a skyscraper, going vertical makes it possible to do more inside the same physical footprint.

Majestic takes the opposite approach. Instead of trying to minimize the length that data must travel between compute and memory, the company is focused on improving the memory interface to accommodate longer wire traces while keeping bandwidth high. Longer wires allow Majestic to connect memory stacks that aren’t directly next to the GPU, removing the space limitation of HBM.

“A memory interface has a very short physical distance it can operate over. In the case of HBM, it’s up to 2 or 3 millimeters. You have this shoreline around the periphery, which is the only place where you can put HBM,” says Rabii.

Majestic claimsits memory interface can transmit bits as far as about a meter. That’s achieved with a proprietary copper link and a memory-aggregator chip that coordinates data. “The aggregator is the endpoint for the high-speed interface and a way to fan out to many, many commodity DRAM chips,” says Rabii. Because of this, Majestic can support up to 128 terabytes of DRAM memory in a single server rack—a significant increase over Nvidia’s GB300 NVL72 rack, which has about 20 TB of HBM3E.

Majestic Labs’ memory-aggregation architecture

Majestic Labs plans to satisfy AI’s memory appetite via a proprietary interconnect and a memory-aggregator chip, allowing a single rack access to up to 128 terabytes of cheap DRAM memory.

Chris Philpot

d-Matrix and Majestic have one thing in common: Instead of HBM, they both use off-the-shelf DRAM. This is the most common type of computer memory in the world; it’s in everything from smartphones to cars. Memory analyst Jim Handysays HBM costs two to three times as much as DRAM. d-Matrix and Majestic chose DRAM in part because of this price advantage. However, the proponents of HBM, which include memory giants like Samsungand SK Hynix, aren’t sitting idle.

HBM4, the latest version of HBM memory, is now in production and will be used by Nvidia’s Vera Rubin GPU, which is expected to ship in the second half of 2026. Hoshik Kim, head of memory-systems research at SK Hynix, says HBM4 “will decisively break the memory bottlenecks constraining AI inference today” by doubling HBM’s maximum memory bandwidth and increasing the amount of HBM memory per stack.

Combining chips for faster inference

The big players—Nvidia and Amazon—are going for an all-chips-on-deck approach. Nvidia’s GPUs and Amazon’s Trainium training accelerators are still great for part of the inference workload: the prefill stage, where all the context keys and values are calculated. But to accelerate decode, the part where new tokens are generated, they are looking to new, memory-centric architectures from smaller players.

In Nvidia’s case, the smaller player was Groq (not to be confused with Grok, the family of LLMs trained by SpaceXAI). Nvidia purchased intellectual property and hired talent from Groq at the end of 2025, and just three months later at the Nvidia’s GTC 2026 conference, Jensen Huang unveiledthe Nvidia Groq 3 language-processing unit ( LPU). Groq’s architecture relies on memory—in its case, SRAM—built directly into the chip’s architecture.

Unless you’re a chip architect, or a hardcore PC gamer,you probably never give SRAM a thought. SRAM has the benefit of being tightly integrated into a compute chip’s architecture—it’s on the same piece of silicon as the processor—and has the drawback of being less dense and more expensive than DRAM. Most chips include only a few dozen megabytes of SRAM. AI inference, however, has ignited new interest in SRAM as a means of bringing the model weights stored in memory closer to compute.

Ian Buck, vice-president and general manager of hyperscale and high-performance computing at Nvidia, says the LPU has a much different set of priorities than the company’s GPUs. The LPU has far less raw computing power than a standard GPU, but it gains 500 megabytes of on-die SRAM connected directly to its floating-point math units. “The benefit is the memory bandwidth. The LPU has seven times the memory bandwidth of the GPU,” he says.

Between the Rubin GPU and the Groq LPU, prefill and decode can both be accelerated to get the best of both worlds, the theory goes. “We do all the attention math and context processing on the Vera Rubin [GPU] rack,” explains Buck. “For all the expert calculations…the matrix multiplications, we do that part on the LPU.” The company packs 256 LPUs into the Groq 3 LPX, a system the size of a data-center rack.

Nvidia’s two-chip approach to inference

Nvidia also plans to split the inference workload across two chips. The company’s newest Rubin GPUs will tackle the compute-intensive prefill phase, while the Groq 3 language-processing unit (LPU), with lots of on-chip SRAM, will handle the memory-intensive decode phase.

Chris Philpot

Amazon Web Services (AWS), for its part, struck a dealwith Cerebras, to pair the Trainium accelerator with Cerebras’s Wafer-Scale Engine 3 (WSE-3). Cerebras takes a similar approach to Groq, though at a much larger scale. WSE-3 turns an entire silicon wafer into a single chip that contains over 4 trillion transistors. The design doesn’t connect to external memory but instead etches 44 gigabytes of SRAM into each wafer. “We store the [model] weights on the SRAM,” says James Wang, formerly director of product marketing at Cerebras who has since moved to SpaceXAI. “So that’s easily 40 to up to 80 billion parameters that we can support on one chip.”

Amazon plans to use AWS Trainium chips for prefill, and Cerebras for decode. But Cerebras’s chips can also go it alone in inference. WSE-3 was deployed by OpenAI to power GPT-5.3-Codex-Spark, a variant of the company’s coding mode, outputting over 1,000 tokens per second. For comparison, OpenAI’s standard GPT-5.4 deployment outputs 50 to 125 tokens per second.

Amazon Web Services’ two-chip inference strategy

Amazon Web Services combined their Trainium chips with Cerebras’s dinner-plate-sized wafer-scale engine (WSE) to tackle different parts of AI inference. Trainium chips handle the computationally intensive prefill phase, while the WSE, with interleaved on-chip SRAM memory, handles the memory-bandwidth-limited decode phase.

Chris Philpot

Cerebras can also tackle prefill without moving the workload to different specialized chips. For this, it networks together multiple WSE-3 chips to form a single pool of memory. Cerebras has demonstrated it can serve models with up to 1T parameters, such as MoonshotAI’s Kimi 2.6, though Wang says “the architecture has no innate limitation in terms of how many parameters it will do.”

Despite these differences in strategy, Nvidia and AWS seem to agree that the future of AI inference will be solved by a systems approach that pools different kinds of chips together to tackle the largest LLMs. Or, as Buck says: “To do modern AI inference, you need all the chips.”

Learning to do more with less (bits)

Nvidia became the world’s most valuable tech company because it designed the world’s most desired GPUs. But not all of the attention is focused on improving AI-inference hardware. AI researchers are also learning how to optimize LLM software and hardware in tandem to make the best use of the memory and compute components.

Most computers store numbers in a 32-bit or 64-bit format. These determine how many bits are available to represent a single number. If too few bits are available, the number can’t be stored without losing information. The quality of an LLM benefits from more-precise number formats, but this creates a problem for inference performance. More-precise numbers aren’t free. The bits that describe them take up more space in memory and require more silicon and energy to compute.

Gilles Backhus, cofounder of the AI-accelerator company Tensordyne, says this creates a tension between model size and number precision. “Would you prefer a model that is size xbut runs in 8-bit, or would you prefer a model that is twice the size but runs in 4-bit?” The size of each model will be roughly the same in terms of memory and compute, “but the 4-bit approach gives you twice as many synapses, if you will. And people are figuring out that [the 4-bit approach] is worth it.”

The process of converting an LLM from a more-precise number format to a less-precise format is called quantization, and it’s been in use for several years. However, researchers are finding new ways to quantize models down while retaining a large majority of the model’s quality.

Nvidia recently created a new 4-bit number format, NVFP4, for this purpose. AMD, Intel, and Qualcommhave instead rallied around a competing 4-bit number format called MXFP4that Nvidia also contributed to developing. “It’s the black art of AI,” says Buck, of Nvidia. When Nvidia quantized DeepSeek-R1 from FP8 to NVFP4, scores on seven major benchmarks degraded by less than one percent while performance improved by three times, the company says.

Quantization is likely just the tip of the spear, as AI researchers and startups are investigating a diversity of opportunities for optimization, some of which could dramatically change the silicon found in AI-inference hardware.

Tensordyne’s unique approach to AI inference combines a logarithmic number format with bespoke hardware in the company’s Napier chip. Tensordyne

Tensordyne is expected to accelerateAI inference with a logarithmic number system that leans on a property of logarithms: The log of A times B equals the log of A plus the log of B. So, storing numbers as their exponents lets the chip add where it would otherwise multiply. That matters in silicon because multiplier circuits draw more power and use more die area than adders do. Tensordyne says its rack-scale hardware, called Napier, can produce up to 1,300 tokens per second per user, and can do so while using less than a tenthas much power as comparable Nvidia hardware.

Etched, a startup based in San Jose, Calif., is even designing AI accelerators that translate the transformer architecture used by LLMs directly into silicon. Rather than building general-purpose GPUs, the company is wiring up the connections needed for efficient transformer calculations into its chip, making the chip much less flexible but more efficient for the tasks most performed by current LLMs. The company says its first AI accelerator, Sohu, can run Meta’s Llama70B model at a stunning 500,000 tokens per second, though this approach also means it won’t be able to run LLMs that move away from a typical transformer architecture.

Whether these ideas will prove fruitful remains to be seen. Etched just shippedtheir first rack in August. Tensordyne believes its first hardware will be available in 2027. Even so, these startups show how the demand for inference performance is fueling unconventional ideas.

Inference is everyone’s game

The sheer variety of approaches to AI-inference acceleration—stacking compute on memory, extending interfaces from millimeters to meters, using an entire silicon wafer for SRAM, squeezing models into 4 bits—raises a question: Which is going to win, and which is going to lose?

But that’s likely not the right question, experts say. The demand for AI is currently insatiable, and while fears of an AI bubble stalk the industry, it has yet to hamper growth.

On the contrary, Kimball of Moor Insights & Strategy thinks inference could drive intense demand for AI hardware in the long term, because it’s not obvious where that demand will end. “You could add a million agents into your organization,” he says. “These things work 24 hours a day; they don’t go home at five at night like we do.”

If AI inference remains as desirable as Kimball expects, the evolution is likely to follow the same trajectory as the CPU. The CPU didn’t improve along a single axis but instead across multiple frontssimultaneously. Once transistor scaling slowed, chip and system architecture innovations of all kinds proliferated. The list of individual innovations that led to today’s ubiquitous, powerful personal compute could fill dozens of books.

A few decades from now, the history of AI inference innovation will show similar depth.

From Your Site Articles

养狗有助于降低老人患认知症风险

Mon, 14 Sep 2026 18:49:35 CST

日本国立环境研究所等机构从 2016 年起，历时 7 年半对约 1.1 万名老年人开展了调查。他们在学术期刊上发表了研究成果。养狗的老年人因认知症需要接受护理的风险比从未养狗的人群低 48%。研究认为，遛狗带来的身体活动以及社交往来起到了积极作用。曾经养过狗的人患认知症的风险也低于从未养过狗的人群。虽然该差异在统计学上并不显著，但推测养狗时期建立的人际联系等因素可能带来了积极影响。研究还表明，养狗能拉动经济。若养狗人群增加，宠物食品、宠物保险、宠物寄养等相关商品与服务的需求预计随之上涨。

Cloudflare 免费服务使用指南

Mon, 14 Sep 2026 21:22:19 CST

Cloudflare 的免费套餐因其慷慨的额度，在开发者社区中常被戏称为“赛博大善人”，它提供的服务远不止基础的 CDN 加速。

Cloudflare 提供的免费服务

Cloudflare 免费层能覆盖的内容，按「值得用」排序：

优先级	用途	免费层是否够用	关键限制
1	域名 DNS 托管 + 免费 HTTPS	完全够用	无实质限制
2	CDN 缓存 + 基础 DDoS 防护	完全够用	无流量计费
3	静态站托管（Pages）	完全够用	500 次构建/月
4	内网服务暴露（Tunnel + Access）	完全够用	50 用户上限
5	域名邮箱转发（Email Routing）	完全够用	只能转发，不能发信
6	反爬 / 验证码（Turnstile）	完全够用	20 个 widget
7	边缘 API（Workers）	小流量够用	10 万请求/天、10ms CPU
8	对象存储（R2）	小文件量够用	10 GB 存储、零出口费
9	数据库（D1 + KV）	原型够用	500 万行读/天
10	AI 推理（Workers AI）	只够试玩	1 万 Neurons/天

一句话判断标准： 只分发不计算，免费层几乎无限；一旦要算、要存、要实时，就会撞墙。

为什么值得用：免费层的底层逻辑

理解 Cloudflare 的定价哲学，比背额度表有用得多。

它把成本结构拆成两块：

成本类型	定价态度	原因
带宽 / 分发 / 连接	几乎免费送	边缘节点带宽边际成本极低，且流量能反哺网络规模
CPU 时间 / 存储 / 写入	严格按量计费	这是真实的可变成本

这解释了为什么 Pages 敢写「无限带宽、无限请求」，而 Workers 只给 10 毫秒 CPU——带宽对它来说接近免费，CPU 不是。

对应的三条推论：

静态内容越重，越占便宜。图片站、文档站、博客、下载站放在这里，成本趋近于零。
动态逻辑越重，越容易付费。视频转码、爬虫、长任务、复杂数据库查询，很快就会越过免费线。
免费层的天花板由并发而非流量决定。1000 请求/分钟的突发限制，比每天 10 万次的总量更早撞上。

免费额度是硬限制。超出后请求直接失败并返回错误码（Workers 是 1015 / 1027），不是排队也不是降速。这意味着它适合个人站、演示、原型，不适合当作有 SLA 承诺的生产依赖。

免费产品地图

Cloudflare 免费层大致分五层。理解分层，就知道该在哪个位置放什么。

域名层：DNS + TLS + CDN + DDoS

能力	免费层说明	核实状态
权威 DNS	Anycast 全网解析，支持 API 与常见记录类型	已核实
免费 TLS 证书	自动签发、自动续期，覆盖根域与泛域名（泛域名需付费）	已核实
CDN 缓存	静态资源缓存、缓存规则、Cache Rules 基本能力	已核实
DDoS 防护	L3/L4 不限量清洗，L7 基础防护	已核实
WAF	自定义规则、免费托管规则集、IP 访问规则、UA 封禁	已核实
速率限制	Free 计划 1 条规则	已核实

这一层是免费层的入口，也是性价比最高的一层。绝大多数人只需要做一件事：把域名 nameserver 改成 Cloudflare 的。

托管层：Pages + Workers

项目	Workers Free	Pages Free
请求	100,000 次/天（账号内所有脚本合计）	静态请求不限量
CPU 时间	10 ms / 次调用	静态资源无 CPU 消耗
突发限制	1,000 请求/分钟	静态资源不适用
脚本 / 项目数	最多 100 个 Worker 脚本	每账号 100 个项目
内存	每 isolate 128 MB	—
构建	—	500 次/月，1 并发，单次超时 20 分钟
自定义域名	可用	每项目 100 个
站点文件数	—	20,000 个，单文件 ≤ 25 MiB
日志	200,000 条/天	—

关键点：Pages 的静态资源请求不占用 Workers 配额；只有 Pages Functions 才计入 Workers 那 10 万次/天。

数据层：KV + D1 + R2 + Queues + Durable Objects

服务	免费额度	定位	核实状态
Workers KV	读 100,000/天、写 1,000/天、删除 1,000/天、列表 1,000/天、存储 1 GB	配置、会话、读多写少的缓存	已核实
D1	读 500 万行/天、写 100,000 行/天、总存储 5 GB	SQLite 兼容关系库	已核实
R2	存储 10 GB-month/月、A 类操作 100 万/月、B 类操作 1000 万/月、出口流量免费	对象存储，对标 S3	已核实
Queues	10,000 次操作/天、消息保留 24 小时	异步任务、削峰	已核实
Hyperdrive	100,000 次数据库查询/天	加速访问外部 Postgres/MySQL	已核实
Durable Objects	请求 100,000/天、时长 13,000 GB-s/天	有状态协作、WebSocket	已核实
Workflows	步骤 3,000/天、存储 1 GB-month	多步骤任务编排	已核实

三个容易踩的坑：

D1 的「读 500 万行」是按扫描行数算，不是返回行数。一条没有索引的 SELECT * FROM t 在 5 万行的表上跑一次就是 5 万行读取，跑 100 次当天额度就没了。索引不是优化项，是配额保护。
R2 的 10 GB 免费额度只适用于标准存储。低频访问存储不享受免费额度（官方明确写了 free tier only applies to Standard storage）。
Queues 的免费额度实际比看上去小。一条消息完整走完要 3 次操作（写、读、删），1 万次/天大约只够 3000 条消息。

安全与身份层：Access + Tunnel + Turnstile

服务	免费额度	替代了什么
Cloudflare Tunnel	免费，隧道与路由不限量	ngrok、frp、DDNS + 端口转发
Zero Trust Access	50 用户上限，永久免费	VPN、跳板机、内网鉴权
Gateway	DNS / HTTP 过滤，免费	企业 DNS 过滤
Turnstile	免费，20 个 widget，验证次数不限	reCAPTCHA、hCaptcha
WARP 客户端	个人版免费	加密 DNS + 私网接入

Tunnel + Access 是免费层里最被低估的组合：它一次性干掉了动态 DNS、端口转发、Nginx 反代配置、certbot 证书续期这四件麻烦事，而且路由器上不需要开任何入站端口。

观测与效率层

服务	免费额度
Web Analytics	免费，无 Cookie、无指纹追踪
Email Routing	免费，域名邮箱转发
Workers AI	10,000 Neurons/天
AI Gateway	核心功能免费
Registrar	按成本价注册，无加价
Vectorize	口径存疑：文档中同时存在「需 Workers Paid」与部分 Free 行，不要作为稳定免费依赖
Browser Rendering	免费额度很小且口径不一，上线前需核对官方文档

Cloudflare的使用场景

场景一：把域名接入 Cloudflare（DNS + TLS + CDN）

这是所有后续操作的前提。根域名要挂 Pages、要开 Tunnel，都必须先让域名成为 Cloudflare 的一个 zone。

前置条件

一个已注册的域名，能修改 nameserver
一个 Cloudflare 账号（免费，不需要信用卡）

步骤

登录cloudflare.com，选择 Add a site，输入根域名。
选择 Free 计划。
Cloudflare 会自动扫描现有 DNS 记录。这里要做的第一件事是核对扫描结果——自动扫描经常漏掉 MX、TXT、CNAME 记录。改 nameserver 之前，先把原 DNS 服务商的所有记录导出或截图留档。Cloudflare 自动扫描不是 100% 完整，漏一条 MX 记录就意味着域名邮箱立刻失效。
去域名注册商处，把 nameserver 改成 Cloudflare 分配的两个地址。
等待生效，通常几分钟到 24 小时。
进入 SSL/TLS，把加密模式设为 Full (strict)。如果源站没有有效证书，先用 Full，但不要用 Flexible。
进入 Speed → Optimization，开启 Brotli 与 Early Hints；Auto Minify 已被弃用，不需要设。
验证：

# 确认 nameserver 已切换
dig NS example.com +short

# 确认解析走的是 Cloudflare
dig A example.com +short

# 确认证书与 HTTP 版本
curl -sI https://example.com | head -n 5

三个高频坑

现象	原因	处理
522 连接超时	源站没有放行 Cloudflare 回源 IP，或回源端口不通	放行官方 IP 段，确认 443 可达
无限重定向	SSL 模式用 Flexible，源站又强制 HTTPS	改为 Full (strict)
邮件收不到	自动扫描漏了 MX 记录	手动补 MX，且必须保持 DNS only（灰云）

橙色云（代理）与灰色云（仅 DNS）的区别要记住：邮件相关记录必须是灰云，否则收不到信。

场景二：静态站部署到 Pages

Pages 是免费层里最慷慨的产品：无限站点、无限席位、无限静态请求、无限带宽，只有 500 次/月的构建次数是硬限制。

三种部署方式对比

方式	适用场景	限制
Git 集成	长期维护的项目	一次提交触发一次构建，消耗构建配额
Wrangler CLI	本地已有构建流程	需要 Node 环境，最灵活
拖拽上传	一次性静态页	最多 1000 个文件，不支持 functions/ 目录编译

方式一：Git 集成

进入 Workers & Pages → Create → Pages → Connect to Git。
授权 GitHub / GitLab，选择仓库。
配置构建参数：

字段	说明
Project name	决定 <name>.pages.dev 子域名
Production branch	一般为 main
Framework preset	按框架选择，纯静态 HTML 选 None
Build command	例如 npm run build
Build output directory	例如 dist / out / public
Root directory	monorepo 必填
Environment variables	敏感配置与 NODE_VERSION

保存并部署。之后每次 push 会自动构建，每个 PR 会生成独立的预览链接。

方式二：Wrangler CLI

npm install -g wrangler
wrangler login
npm run build
wrangler pages project create my-site
wrangler pages deploy dist

注意 wrangler pages deploy 消耗的是构建配额之外的直接上传通道，但仍受每站点 20,000 文件上限约束。

三个构建期陷阱

报错	根因	修复
npm ci 直接失败	lockfile 与 package.json 不同步	本地重跑 npm install 提交新 lockfile
Failed to load SWC binary for linux/x64	macOS 生成的 lockfile 只含 darwin 平台可选依赖	在 Linux 环境重新生成 lockfile，或显式加 @next/swc-linux-x64-gnu 到 optionalDependencies
修完依赖仍报同样错	构建缓存复用了旧的 node_modules	加 postinstall 兜底，或关闭构建缓存

这三条都是同一个根源：构建发生在 Cloudflare 的 Linux 容器里，而你的 lockfile 是本地平台生成的。

不要用 <project>.pages.dev 裸域名面向国内用户。该域名段长期存在 DNS 污染与针对性阻断的社区实测反馈，属于不稳定而非完全不可用。绑自定义域名能明显改善，最稳的做法是前置一家国内可用的 CDN。

场景三：Tunnel + Access 暴露内网服务

替代方案是 DDNS + 端口转发 + Nginx 反代 + certbot 四件套。用 Cloudflare 只需要一条出站连接。

架构

本地服务 → cloudflared 出站连接 → Cloudflare 边缘 → 用户路由器上不需要任何入站端口。

步骤

安装 cloudflared（Windows 用 winget 或直接下载 exe）。
登录并授权：cloudflared tunnel login
创建隧道：cloudflared tunnel create homelab
配置 DNS 路由：cloudflared tunnel route dns homelab nas.example.com
写配置文件yml：

tunnel: homelab
credentials-file: C:/Users/you/.cloudflared/<tunnel-id>.json
ingress:
  - hostname: nas.example.com
    service: http://localhost:5000
  - hostname: grafana.example.com
    service: http://localhost:3000
  - service: http_status:404

前台验证：cloudflared tunnel run homelab
确认可访问后，注册为系统服务：cloudflared service install

加上 Access 鉴权

隧道本身只是把服务接上公网，任何知道域名的人都能访问，所以鉴权这一步不能省。

进入 Zero Trust → Access → Applications → Add an application → Self-hosted。
填入受保护的域名。
创建策略：Action 选 Allow，Include 选 Emails 或 GitHub 组织，填入允许的账号。
保存。免费层支持 50 个用户，个人和家庭场景完全够用。

验证方式：用未授权的浏览器或无痕窗口访问，应该被拦截到登录页。

注意点

yml 里最后一条 service: http_status:404 是兜底规则，不能省，否则未匹配的 hostname 会报配置错误。
隧道服务运行在后台时，日志不会自动输出，排查问题先用前台模式跑。
Access 的免费层日志保留期只有 24 小时。

场景四：免费域名邮箱（Email Routing）

免费层能把 hello@yourdomain.com 转发到你的常用邮箱，但它不是邮箱托管——只能收，不能发。

步骤

进入 Email → Email Routing，点击启用。
Cloudflare 会自动添加所需 MX 与 TXT（SPF）记录，确认添加即可。
添加目标邮箱，去该邮箱点击验证链接。
创建自定义地址：hello@yourdomain.com → 转发到目标邮箱。
可选：启用 Catch-all 规则，把所有未匹配地址统一转发。

限制

项目	说明
发信	不支持，需要 SMTP 服务商
邮件内容	Cloudflare 声明不存储、不访问邮件正文
已有 MX 记录	会冲突，启用前需确认没有现存的邮箱服务

如果需要在域名邮箱里回复，方案是转发到 Gmail 后在 Gmail 里添加「以别名发送」，需要该 SMTP 服务商（如 Zoho Mail 免费版）配合。

场景五：纯免费的全栈小应用

把 Workers + D1 + R2 组合起来，可以搭一个没有固定成本的小后端。

初始化

npm create cloudflare@latest my-api
cd my-api
wrangler d1 create my-db

绑定配置 wrangler.jsonc

{
  "name": "my-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "d1_databases": [
    { "binding": "DB", "database_name": "my-db", "database_id": "<上一步返回的 id>" }
  ],
  "r2_buckets": [
    { "binding": "BUCKET", "bucket_name": "my-files" }
  ]
}

示例代码 src/index.ts

export interface Env {
  DB: D1Database;
  BUCKET: R2Bucket;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);

    if (url.pathname === "/items" && request.method === "GET") {
      const { results } = await env.DB
        .prepare("SELECT id, name FROM items WHERE id = ?1")
        .bind(Number(url.searchParams.get("id")))
        .all();
      return Response.json(results);
    }

    if (url.pathname === "/upload" && request.method === "PUT") {
      const key = crypto.randomUUID();
      await env.BUCKET.put(key, request.body);
      return Response.json({ key });
    }

    return new Response("Not Found", { status: 404 });
  },
};

建表与部署

注意示例里 WHERE id = ?1 命中了主键，只读 1 行。如果换成无索引列的条件查询，读取行数会按扫描量暴涨，直接吃掉 D1 的每日配额。这是免费层里最容易被忽略的隐形消耗。

wrangler d1 execute my-db --remote --command \
  "CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT NOT NULL);"

wrangler d1 execute my-db --remote --command \
  "CREATE INDEX idx_items_id ON items(id);"

wrangler deploy

组件	免费额度	这个应用的实际消耗
Workers 请求	10 万/天	按访问量计
D1 读取	500 万行/天	命中索引时每查询 1 行
D1 写入	10 万行/天	每次新增 1 行
R2 存储	10 GB	按文件大小计
R2 出口	免费	下载不产生费用

只要按索引查询、上传文件控制在 10 GB 内、日请求低于 10 万次，这个应用的月成本是 0。

免费额度总表

类别	服务	免费额度	核实状态
域名	DNS / TLS / DDoS	无实质限制	已核实
域名	Registrar	成本价注册，无加价	已核实
托管	Pages	无限带宽、无限请求、500 构建/月、100 域名/项目	已核实
托管	Workers	10 万请求/天、10ms CPU、100 脚本	已核实
数据	KV	读 10 万/天、写 1000/天、1 GB	已核实
数据	D1	读 500 万行/天、写 10 万行/天、5 GB	已核实
数据	R2	10 GB-month、A 类 100 万/月、B 类 1000 万/月、出口免费	已核实
数据	Queues	10,000 操作/天、保留 24h	已核实
数据	Hyperdrive	10 万查询/天	已核实
数据	Durable Objects	10 万请求/天、13,000 GB-s/天	已核实
数据	Workflows	3,000 步骤/天、1 GB-month	已核实
安全	WAF	自定义规则 + 免费托管规则集	已核实
安全	速率限制	1 条规则	已核实
安全	Turnstile	20 widget，验证次数不限	已核实
安全	Zero Trust Access	50 用户	已核实
安全	Tunnel	隧道与路由不限量	已核实
观测	Web Analytics	免费	已核实
邮件	Email Routing	免费转发	已核实
AI	Workers AI	10,000 Neurons/天	已核实
AI	Vectorize	口径存在冲突，勿依赖	口径存疑
AI	Browser Rendering	免费额度小且口径不一	未核实
媒体	Images / Stream	不属于免费核心能力	已核实

风险与坑

免费层没有 SLA

免费计划不提供服务等级承诺，也没有工单支持通道。把关键业务押在免费层上，等于接受「可能突然不可用且无人负责」。

免费额度是硬中断

错误码	含义	表现
1015	触发突发速率限制	1000 请求/分钟以上，被拦截
1027	Worker 因超日限额被暂停	路由默认 fail open（绕过 Worker），可改为 fail closed
1016	源站 DNS 解析错误	回源域名解析失败
522	回源连接超时	源站未放行或端口不通

fail open 与 fail closed 的选择很关键：安全类 Worker（鉴权、校验）应该设成 fail closed，否则额度耗尽时请求会直接穿透到源站，等于安全策略失效。

CDN 代理非 HTML 内容有条款限制

Cloudflare 服务条款第 2.8 节限制用 CDN 代理大比例的流媒体与部分非 HTML 内容。个人博客、文档站、图片站没有风险，但把它当免费视频 CDN 用会违反条款。视频走 R2 或 Stream 是合规路径。

构建环境与本地环境不一致

前面提到的 lockfile 平台差异问题，本质是所有云端构建的通病。对策是锁定 NODE_VERSION、显式声明平台相关可选依赖、必要时关闭构建缓存。

新账号的隐性限制

新注册账号在最初一段时间创建项目可能受限（防滥用机制）。如果第一天就报错，通常不是配置问题，等一等即可。

国内访问不稳定

pages.dev 与 workers.dev 裸域名长期存在解析异常反馈。生产域名必须绑自定义域名，主要面向国内用户时建议前置国内可用的 CDN。

容易误判的免费项

以下几项常被当成免费能力，实际不是或口径不明：Images、Stream、Argo Smart Routing、Load Balancing、高级 Bot Management、Containers、Vectorize。规划架构时不要把它们算进免费方案。

什么时候该付那 5 美元

Workers Paid 是每月 5 美元，包含 1000 万请求、3000 万 CPU 毫秒、1000 万 KV 读取。判断标准很清晰：

信号	说明
日请求逼近 10 万	免费层没有弹性，超了直接 1027
单次任务 CPU 超 10ms	免费层的 CPU 上限锁死了计算类任务
需要 Durable Objects 完整能力	WebSocket 与有状态场景
需要有意义的技术支持	免费层只有社区论坛
业务不能接受无 SLA	这是最实际的付费理由

反过来说，如果只是博客、文档站、家庭内网、小工具 API，免费层可以长期稳定运行，没有必须付费的理由。

参考资料

Cloudflare 开发者平台定价：https://www.cloudflare.com/plans/developer-platform
Workers 定价与限制：https://developers.cloudflare.com/workers/platform/pricing
Workers 限制文档：https://developers.cloudflare.com/workers/platform/limits
Pages 定价：https://pages.cloudflare.com
R2 定价：https://developers.cloudflare.com/r2/pricing
D1 产品页：https://www.cloudflare.com/developer-platform/products/d1
Zero Trust 定价： https://www.cloudflare.com/plans/zero-trust-services

相关文章:

基于 AI 生成 HTML 动态页面，然后录视频，是否是制作短视频的一个可行方案

Sun, 13 Sep 2026 10:30:03 CST

AI Agent + HTML转视频框架（全自动）

这是当前更前沿的“Vibe Motion”趋势，将录屏步骤也自动化了。代表性开源框架包括：

HyperFrames：由 HeyGen 开源，专为 AI Agent 设计。你只需用自然语言描述需求，Agent 就会编写 HTML+CSS+GSAP 动画代码，然后框架通过无头浏览器逐帧捕获，用 FFmpeg 直接渲染成 MP4。
html-video：Open Design 团队出品，基于 HyperFrames 构建。它提供21套预设模板（如数据可视化、电影感标题），支持粘贴文章链接自动生成视频，进一步降低了使用门槛。

HyperFrames

https://github.com/heygen-com/hyperframes

HyperFrames 是一个开源框架，可将 HTML、CSS、媒体内容以及可播放的动画转换为格式固定的 MP4 视频。它可以通过命令行工具在本地使用，也可以与具备相应功能的 AI 编程工具配合使用。此外，它还可以作为托管式内容创作流程中的渲染核心组件来使用。

html-video

https://github.com/nexu-io/html-video

HTML 内容可以直接转换成视频——而且是在你的笔记本电脑上完成。你可以使用各种编程工具来辅助这个过程：Open Design、Windsurf CLI、Trae CLI、Claude Code、Cursor、Codex、Gemini、Grok、Qwen、OpenCode、Copilot、Aider、Hermes，或者 Anthropic API。你只需描述一下想要制作的视频内容，或者粘贴相关文章的链接或 GitHub 代码库的地址，这些工具就会把内容转换成多帧动画视频。最后，这些视频会被直接保存为 MP4 格式，保存在你的电脑上。整个过程非常简单：只需使用相应的工具，无需额外付费，也不会受到任何软件或服务的限制。Apache-2.0 许可证，完全免费使用，无任何附加条件。

选哪个方案

我看了一下这俩个 github 项目，HyperFrames 无论是 star 数量，还是更新频率，及 commit 更新数量，都远远优于 html-video。所以，我还是优先尝试 HyperFrames 吧。

编程 Agent 连接本机大模型的注意点

Fri, 11 Sep 2026 15:01:51 CST

如果你曾经考虑过把编程 Harness 发出的 API 调用替换成本地模型，那么结果很可能令人失望。你可能快速跑了一下 `llama-bench`，以为自己会得到一个“每秒 X token”的结果。但这个基准测试无法告诉你实际使用这些 Harness 时的体验。

不同 Harness 的开发体验差异非常大。你可能会坐在那里等几分钟才看到模型开始响应；或者刚开始运行得不错，中途却突然卡住。

“是谁把 Prefill 的时间全吃光了？”

这并不是你的错： 大多数编程 Harness 从设计之初就没有考虑本地模型。

这并不是要批评其他团队的优秀工作。我只是想可靠地测量： 当你把数据中心换成本地主机（localhost）之后，实际会发生什么。

需要说明的是，我一直在折腾 chad，这是一个专门针对 Apple Silicon 上 Qwen 3.8 27B 优化的 coding harness。

Laptop Physics：笔记本的物理限制

大多数 Harness 会从三个方面与本地模型“作对”。

1. 巨大的 System Prompt 和 Tool Schema

假设你的笔记本读取速度是 90 tokens/s，生成速度大约 10 tokens/s。

这分别对应编程 Harness 每一轮中的 Prefill 和 Generation。

按照这个速度：

每增加 1,000 个 Prompt Token，就意味着模型开始输出前，你要盯着光标等待约 11 秒。

而在模型真正开始干活之前，它必须先读取：

整个 System Prompt
所有加载的 Tool Schema

例如：

Harness	Prompt Token
pi	2,008
OpenCode	18,046

在数据中心 GPU 上，Prefill 可能达到 10k+ tokens/s，因此：

pi：约 0.2 秒
OpenCode：约 1.8 秒

几乎感觉不到区别。

但在你的笔记本上：

pi：约 22 秒
OpenCode：约 226 秒

也就是 将近 4 分钟。

这已经完全无法接受了。

2. 更小的有效 Context Window

LLM 处理完 System Prompt 后，真正能够用于工作的 Context Window 已经减少了。

你的上下文窗口其实比你想象得小。

具体剩余多少，取决于：

你的内存大小
模型权重占用
KV Cache
其他运行时开销

对于一台配置合理的笔记本，可以粗略认为还有 32,000 tokens 可用。

那么：

pi：

System Prompt 只占 2,008 tokens。

大约还有 94% 的 Context 可以真正用于工作。

OpenCode：

一开始就消耗了 18,046 tokens。

真正用于工作的 Context 只剩下约 44%。

3. 大量 Side Request

传统的：

本地客户端 → 远程服务器

架构下，Harness 可以随意向数据中心发起各种额外请求。

但本地模型不同：

你的笔记本既是 Client，又是 Server。

最好的情况是这些 Side Request 排队等待。

最糟糕的情况是：

它们不断触发重复 Prefill。

在测试的 24 个任务中：

OpenCode：33 次 Side Request
Crush：51 次
dsh：24 次

而且几乎都与 Agent Turn 重叠。

结果就是：

OpenCode：GPU 忙碌时间达到实际时间的 125%
Crush： 114%

也就是说：

一块 GPU 上同时跑了两个请求。

Harness 测试结果

作者使用 9 个 Coding Harness，测试了 8 个 Exercism 编程任务。

每个任务都使用：

相同的一句话 Prompt
Auto-approve 模式
同一台 M4 MacBook Pro
24GB 内存
macOS 26.6.2
Qwen 3.8 27B
3-bit 量化
llama.cpp build 10470

所有 Harness 共用同一个 llama-server。

采样参数统一为：

temperature = 1.0
top_k = 20
top_p = 0.95
min_p = 0.05

Context Cache 统一：

32,768 tokens / 4 slots

其中：

wait before 1st token：第一次生成 Token 前的等待时间，也就是 System Prompt + Tool Schema + First Request 的 Prefill 时间
wait / later turn：之后每一轮的等待时间
cache reuse：后续 Turn 有多少比例来自 Prefix Cache
experienced tokens/s：真正用户体验到的速度，包括 Prefill、Tool 等全部时间
pass：Exercism 任务是否通过，作者特别强调不要把它当成模型能力排名

Harness	Tools	首轮 Prompt	首 Token 等待	后续 Turn	Cache	实际 tok/s	通过
mini-swe-agent	1	1,171	12.2s	3.6s	96%	8.0	11/24
pi	4	2,008	21.6s	1.3s	99%	8.1	19/24
cline	26	5,876	64.1s	9.9s	94%	7.3	17/24
codex	10	7,804	87.8s	9.6s	94%	6.9	19/24
dsh	25	8,052	94.4s	2.2s	99%	7.2	18/24
goose	18	9,617	110.3s	1.0s	100%	8.0	22/24
crush	26	16,263	199.8s	1.8s	100%	5.8	18/24
opencode	10	18,046	225.7s	4.6s	99%	5.7	15/24
chad（llama.cpp）	5	2,563	25.6s	0.8s	99%	7.9	24/24
chad（MLX serial）	5	2,566	4.7s	1.0s	99%	12.4	21/24
chad（MLX dflash2）	5	2,562	4.6s	0.9s	99%	17.4	22/24

作者把这些 Harness 分成三类

① Lean and Stable：轻量、稳定

pi、mini-swe-agent、chad

特点：

精简 System Prompt
96–99% Cache Reuse
本地模型和云端模型都能比较好地工作

其中 mini-swe-agent 的问题是：

24 个任务只通过 11 个，并且 Timeout 最多。

② Heavy but Disciplined：比较重，但设计合理

dsh、cline、codex、goose

它们的问题主要来自：

较长的 System Prompt
大量 Tool Schema

但有一个很重要的优点：

Prefix 是稳定的。

所以一旦 Prefill 完成，后面还是比较能够接受的。

作者特别提到 Goose：

1.50.0 版本已经解决了一个问题。

早期版本每一轮都会把一个精确到分钟的 Timestamp 重新写进第一条 User Message，导致 Cache Reuse 从接近 100% 降到了 78%。

③ Heavy to Start：启动非常重

Crush、OpenCode

你会先等：

3～4 分钟

才能看到模型开始工作。

为什么作者认为 chad 特别适合本地模型？

作者认为这些 Harness 并不是设计得不好。

例如：

OpenCode 使用 18K Token 的 System Prompt

这对于：

数据中心 + Frontier Model + 10k+ tokens/s Prefill

完全合理。

同样：

Crush 使用 26 个 Tool Schema

当你拥有：

200K Context
几乎免费的高速 Prefill

这也完全没问题。

问题在于：

这些设计都是建立在“Prefill 几乎免费”的数据中心环境上的。

一旦换成：

本地模型 + 笔记本 + 低 Prefill 速度

原来的设计就会彻底暴露问题。

原文：https://nasutton.notion.site/Nine-coding-harnesses-vs-your-laptop-3d139990182b80d59fa3cf500f0450ba

科学家建议冲马桶合盖以减少气凝胶

Tue, 08 Sep 2026 23:16:05 CST

Flinders 大学的研究人员发现，冲马桶会向周围空气释放气溶胶和生物气溶胶，气溶胶颗粒甚至会进入到成年人的呼吸区，而冲水后气溶胶会在空气中悬浮至少 20 秒。这些发现是基于对 22 项马桶气溶胶研究的分析。结果表明，保持良好的厕所卫生，包括定期清洁马桶及其周围表面，以及使用后洗手，有助于最大限度减少微生物污染和潜在的微生物疾病风险。使用马桶的低冲水模式也有助于最大限度减少气溶胶的产生。充足的通风有助于扩散和清除悬浮的空气颗粒，关闭马桶盖会改变气溶胶的扩散方向，气溶胶会从马桶盖和马桶座之间的缝隙逸出，而不是向上扩散。研究人员建议保持卫生间通风良好，在冲水前盖上马桶盖。

人工智能的效率提升可能会让我们失去下一代专家（如何保护人类技能）

Fri, 04 Sep 2026 09:00:53 CST

十多年前，我曾主导设计美国一座核电站的首套全数字控制系统。从设计图纸上看，这套系统堪称完美——它被设计成像现代客机一样自主运行，操作员只需偶尔监控一下，几乎不需要他们干预。然而，我们却做出了一个在注重效率的观察者看来有些倒退的决定：我们故意在系统能够自主执行的程序中保留了一些手动步骤。

我们当时在解决一个具体问题。一个只负责监督自动化系统的操作员，会逐渐失去操作能力。他的手会变得冰冷，对工厂实际运行情况的认知也会变得模糊。然后，自动化系统就会把控制权交还给他。这总是最糟糕的一天，因为自动化系统只有在出现故障或出错时才会停止工作。但到那时，坐在操作台上的人已经好几年没真正操作过这套系统了。手动操作步骤的存在是为了保持操作员的技能水平。这种设计本身就效率低下，而且是故意为之。

那个核电站最终并没有建成。由于美国核电行业复杂的政治和经济因素，这个项目被搁置了，而这些因素与工程设计本身无关。但是，设计理念却超越了项目本身，而且我逐渐意识到，对于如今席卷所有董事会的争论——“当人工智能取代人类的专业知识来构建它们时，人类的专业知识将何去何从？”——这或许是我能提出的最有价值的观点。

人工智能正在颠覆工程职业发展阶梯

这些数据已不容忽视。哈佛大学一份涵盖超过28万家美国公司约6500万名员工的工作报告发现，在公司采用生成式人工智能后，初级员工的就业率在六个季度内比未采用人工智能的公司下降了约9%，而高级员工的就业率则持续增长。斯坦福大学对ADP工资记录的分析也指向了同样的结果：在人工智能应用最广泛的职业领域，最年轻的员工在2022年底之后就业率下降，而他们经验更丰富的同事则保持了就业水平。斯坦福大学的研究人员发现，就业率下降主要集中在人工智能实现工作自动化的领域；而在人工智能仅仅是辅助工作的领域，初级员工的就业率则保持稳定或有所上升。

因果关系仍存在争议，坦诚相告至关重要。纽约联邦储备银行的研究人员认为，应届毕业生失业率上升的主要原因并非人工智能，而是远程办公。他们认为，企业不愿雇用缺乏经验、无法进行远程培训和指导的人员。但请注意这些解释的共同之处。无论是人工智能吸收了早期培训，还是远程办公切断了指导关系，两者都描述了同一个失效的机制：学徒制渠道——即专业知识从资深员工传授给初级员工的途径——已经失效。无论如何，“入门级”悄然变成了“需要三年工作经验”。

抛开一切杂音，你会发现一个看似简单却又至关重要的问题：你不可能不先当过初级工程师就成为高级工程师。专业知识并非唾手可得，而是需要通过失败的构建、毫无进展的调试以及那些“这到底是怎么回事”的困惑时刻来积累的。而如今，人工智能会很乐意让新手免于经历这些。如果让新手免于经历足够多的此类困惑，你就会培养出一批能够纸上操作模型，却始终无法培养出那种能够准确判断模型何时出现灾难性错误的直觉的人才。

大多数评论止步于诊断，或者试图提出将初级岗位流失视为经济问题的政策解决方案。然而，这同时也是一个工程问题，而安全攸关领域已经花费数十年时间研究如何解决这个问题。

航空业关于自动化悖论的教训

我的职业生涯始于自动化领域的尖端。毕业后的第一份工作是验证和确认数字喷气发动机控制器中的软件，该控制器能够比任何飞行员更快地决定战斗机发动机的响应。即使在20世纪80年代末，这种核心矛盾也显而易见：在常规情况下，机器的性能优于人类；但在机器无法预料的情况下，人类却是飞机免于灾难的唯一保障。这种矛盾被称为“ 自动化悖论”，即随着自动化能力的不断提升，操作人员的实践机会越来越少，而留给他们的却只有最棘手的难题。

航空业曾多次付出惨痛的代价，才明白当人为技能在自动化系统和人工操作之间的鸿沟中退化时，会发生什么。最典型的例子就是2009年坠入大西洋的法航447航班。事故的直接原因很普通：结冰的空速传感器向自动驾驶仪提供了错误数据，自动驾驶仪按照其设计程序断开连接，将飞机控制权交还给机组人员。接下来发生的并非硬件故障，而是飞行员能力的缺失。原本可以挽回的局面变成了无法挽回的悲剧，因为飞行员们在数千小时的自动驾驶操作下，无法识别高空气动失速并手动驾驶飞机脱困。飞机本身没有问题，但被自动化系统悄然削弱的飞行员训练却失效了。

业界的应对措施颇具启发性，与我们在核电站控制室采取的措施如出一辙。他们并没有拆除自动驾驶系统，而是重新引入了刻意的手动飞行练习。2017年，美国联邦航空管理局（FAA）发布了第17007号运营商安全警示——《手动飞行操作熟练度》，其中明确指出“手动飞行是其他飞行技术的基础”。该警示正式承认技能衰退本身就是一种危险。一些航空公司修改了操作规程，鼓励在天气状况良好的情况下进行初始爬升和初始下降阶段的手动飞行，他们明知会牺牲少量燃油效率，却依然努力保持机组人员的飞行技能。这种权衡取舍至关重要。一个看似完美却培养出不称职操作员的系统，根本算不上完美。它只是把故障模式转移到了电子表格无法识别的地方。

手动门禁系统或可保护工程技术

将航空业的经验教训和核武器的本能放在一起比较，它们都指向了我们在人工智能增强型工作中需要的一种设计模式：刻意的“手动关卡”。

手动操作环节是指工作流程中由人接管控制权的某个点，这并非因为这是完成任务最快的方式，也不仅仅是为了安全联锁，而是为了锻炼和保持一项否则会退化的技能。其显著特点在于，它是人为选择的。在设计过程中，你需要决定你的组织必须保留哪些员工的技能，因为在关键时刻，这些技能至关重要。然后，你需要精心设计必要的机制来保持这些技能的熟练度。

想象一下，在一个主要依赖人工智能编写代码的软件团队中，这种机制会如何运作。团队会为他们最不能失去的技能—— 调试——设置一道人工屏障。当关键模块中出现缺陷时，指定的工程师（通常是初级工程师）必须首先重现故障，追溯根本原因，并编写一个能够捕获该缺陷的自动化测试，所有这些操作都必须在人工智能助手关闭的情况下进行。只有在工程师确定诊断结果后，模型才会重新启动，提出修复方案，生成替代方案，并在代码库中搜索类似的缺陷。然后，工程师会将自己的诊断结果与模型的分析结果进行比较。如果两者不一致，那就说明这种设计是有效的，它能够在问题发生之前就发现分歧，而不是在问题发生时才发现。

这种方法彻底改变了初级工程师的角色。如今人们的本能是让人工智能来完成入门级工作，因为它速度更快、成本更低。但有些工作并非可以随意削减的额外开销。它们是培养未来高级员工的基石，你应该像保护其他关键基础设施一样保护它们。或许它在本季度效率不高，但悄悄地拆除它，就等于把未来十年的能力抵押出去。

为什么企业必须持续培养初级工程师

这一切都不是免费的，假装免费是对那些必须签署预算的人的侮辱。人为设置的人工关卡，从本质上来说，短期内效率低于完全自动化。让初级员工从事基础工作并执行手动流程，现在付出一些成本，是为了将来能够获得更好的结果。

在如今这个以季度业绩评判大多数领导者的市场中，这种做法很难奏效。如果一位新聘高管手下有“不必要”的员工，而这些员工本可以被人工智能取代，那么在获得回报之前，董事会就会对此提出批评。只有那些能够免受这种压力影响的人才能从中获益：例如拥有控制权的创始人、私营公司、真正具有长远眼光的机构，或者像飞行员那样，愿意要求员工定期展示技能的监管机构。这意味着，最有可能保留自身专业技能的组织，是那些在结构上能够将短期利润投入到长期能力建设中的组织；其他所有组织都需要外部推动。

所以，论点可以用一句话概括：刻意降低效率并非浪费。在安全至关重要的工程领域，我们一直将其视为一种保障，而且我们是有意为之。随着人工智能接管那些需要专业知识才能完成的工作，明智的做法不是抵制自动化，而是从设计之初就将控制权牢牢掌握在手中——这样，即使自动化最终总会失效，也仍然有人能够胜任。

Chronos-2 Small (112M)一个时间序列预测的强大模型

Tue, 01 Sep 2026 10:30:03 CST

Chronos-2 是一个用于时间序列预测的基础模型，基于 Chronos 和 Chronos-Bolt 构建。它提供了显著的能力改进，可以处理早期模型不支持的多种预测场景。它提供了显著的能力改进，可以处理早期模型不支持的多种预测场景。支持的场景包括（1）单变量时间序列预测：经典的时间序列预测任务；（2）跨项目学习：利用多个相关时间序列的信息进行预；（3）多变量预测：同时预测多个相关目标变量（3）带协变量的预测：仅过去协变量：在预测时已知的历史协变量（如过去的天气数据） + 已知未来协变量：预测期间已知的协变量（如节假日、计划事件）

功能对比

功能	Chronos	Chronos-Bolt	Chronos-2
单变量预测	✅	✅	✅
跨项目学习	❌	❌	✅
多变量预测	❌	❌	✅
仅过去协变量（实数/分类）	❌	❌	✅
已知未来协变量（实数/分类）	🧩	🧩	✅
微调支持	✅	✅	✅
最大上下文长度	512	2048	8192

🧩 Chronos/Chronos-Bolt 不原生支持未来协变量，但可以与外部协变量回归器结合使用（参见 AutoGluon 教程）。这仅对每个时间步的效果进行建模，而不是跨时间的效果。相比之下，Chronos-2 原生支持所有协变量类型。

更多关于 Chronos-2 的详细信息，请参阅技术报告。

安装

pip install 'chronos-forecasting[extras]>=2.2' 'matplotlib'

快速开始

加载模型

import os

# 使用仅 1 个 GPU（如果可用）
os.environ["CUDA_VISIBLE_DEVICES"] = "0"

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
from chronos import BaseChronosPipeline, Chronos2Pipeline

# 加载 Chronos-2 管道
# 推荐使用 GPU 加速推理，CPU 也支持（使用 device_map="cpu"）
pipeline: Chronos2Pipeline = BaseChronosPipeline.from_pretrained(
    "amazon/chronos-2", 
    device_map="cuda"
)

单变量预测

# 加载数据（长格式 pandas DataFrame）
context_df = pd.read_csv("https://autogluon.s3.amazonaws.com/datasets/timeseries/m4_hourly/train.csv")
print("输入数据框形状:", context_df.shape)
display(context_df.head())

# 执行预测
pred_df = pipeline.predict_df(
    context_df, 
    prediction_length=24, 
    quantile_levels=[0.1, 0.5, 0.9]
)

print("输出数据框形状:", pred_df.shape)
display(pred_df.head())

predict_df 参数说明

参数	说明	默认值
`df`	长格式 DataFrame，包含 id、timestamp 和目标列	-
`future_df`	可选的未来协变量 DataFrame（同时存在于 df 和 future_df 中的列被视为已知未来协变量）	None
`id_column`	时间序列标识符列	"item_id"
`timestamp_column`	时间戳列	"timestamp"
`target`	要预测的目标列名	"target"
`prediction_length`	预测步数	-
`quantile_levels`	要计算的分位数	[0.1, 0.2, ..., 0.9]

返回包含预测值（包括点预测和分位数）的 DataFrame。

带协变量的预测

Chronos-2 可以利用协变量来提高预测准确性。以下是一个实际的能源价格预测示例：

# 能源价格预测配置
target = "target"  # 包含要预测的值的列名（能源价格）
prediction_length = 24  # 要预测的小时数
id_column = "id"  # 标识不同时间序列的列（国家/地区）
timestamp_column = "timestamp"  # 包含日期时间信息的列
timeseries_id = "DE"  # 要可视化的特定时间序列（德国）

# 加载历史能源价格和协变量的过去值
energy_context_df = pd.read_parquet(
    "https://autogluon.s3.amazonaws.com/datasets/timeseries/electricity_price/train.parquet"
)
energy_context_df[timestamp_column] = pd.to_datetime(energy_context_df[timestamp_column])

# 加载协变量的未来值
energy_test_df = pd.read_parquet(
    "https://autogluon.s3.amazonaws.com/datasets/timeseries/electricity_price/test.parquet"
)
energy_test_df[timestamp_column] = pd.to_datetime(energy_test_df[timestamp_column])
energy_future_df = energy_test_df.drop(columns=target)

# 使用协变量进行预测
pred_df = pipeline.predict_df(
    df=energy_context_df,
    future_df=energy_future_df,
    id_column=id_column,
    timestamp_column=timestamp_column,
    target=target,
    prediction_length=prediction_length,
    quantile_levels=[0.1, 0.5, 0.9],
)

可视化预测结果

def plot_forecast(
    context_df,
    test_df,
    pred_df,
    timeseries_id,
    target,
    timestamp_column="timestamp",
    id_column="item_id",
):
    fig, ax = plt.subplots(figsize=(12, 3))
    
    # 筛选特定时间序列的数据
    ts_context = context_df[context_df[id_column] == timeseries_id].set_index(timestamp_column)[target]
    ts_ground_truth = test_df[test_df[id_column] == timeseries_id].set_index(timestamp_column)[target]
    ts_pred = pred_df[pred_df[id_column] == timeseries_id].set_index(timestamp_column)
    
    # 绘制历史数据、真实值和预测值
    ts_context.plot(ax=ax, label=f"历史 {target}", color="xkcd:azure")
    ts_ground_truth.plot(ax=ax, label=f"未来 {target} (真实值)", color="xkcd:grass green")
    ts_pred["predictions"].plot(ax=ax, label="预测", color="xkcd:violet")
    
    # 绘制预测区间
    ax.fill_between(
        ts_pred.index,
        ts_pred["0.1"],
        ts_pred["0.9"],
        alpha=0.7,
        label="预测区间",
        color="xkcd:light lavender",
    )
    
    ax.axvline(x=ts_context.index[-1], color="black", linestyle="--", alpha=0.5)
    ax.legend(loc="upper left")
    ax.set_title(f"{target} 预测 - {timeseries_id}")
    fig.show()

支持的场景

单变量时间序列预测：经典的时间序列预测任务
跨项目学习：利用多个相关时间序列的信息进行预测
多变量预测：同时预测多个相关目标变量
带协变量的预测：
- 仅过去协变量：在预测时已知的历史协变量（如过去的天气数据）
- 已知未来协变量：预测期间已知的协变量（如节假日、计划事件）

硬件要求

GPU（推荐）：支持 CUDA 的 NVIDIA GPU，可显著加速推理
CPU（支持）：可在 CPU 上运行，但推理速度较慢

IT社区推荐资讯 - ITIndex.net

全球最富有 0.1% 人口产生的碳污染超过全球最贫困 35 亿人口的总和

PHP 嚴重的 RCE 漏洞「PHP2Shell」解法

PHP 嚴重的 RCE 漏洞「PHP2Shell」解法

相關網頁

REA 逆向神器，AI 时代不再有闭源软件

逆向是什么

热度背后的需求

REA 与当前的工具如何协作

跨层分析难点

能力各有边界

证据决定结论

运行才有观察

如何使用 REA

效率必须实测

闭源边界变化

CPU、DRAM和SSD如今占了一台主流级别笔记本电脑制造成本的68%

Qwen-Image-2.1 Pro 和 Turbo API 上线千问 AI 平台

小米AI Cube 原型机-本地AI模型部署选择

小米刚刚展示了其 AI Cube 原型机，这可能成为来自中国的严肃 GB10 竞争对手 👀 - 3 款定制芯片：Xring O3、O100、D100

- 200 TOPS NPU

- 1.22 TB/s AI 内存带宽

- 最高 160GB 统一内存

- 150W 持续功率

- 120B 模型本地运行

Xring O100：1.22TB/s + 330 t/s 在 150w AI 盒子上真是 🔥 一旦它上市，绝对会像热饼一样热卖。

文本分类语言模型-Language Models for Text Classification: From Bag-of-Words to Jev

词袋模型、循环神经网络、卷积神经网络、Transformer 模型、Jev 类 API 和校准的可视化指南

A Visual Guide to Bag-of-Words, RNNs, CNNs, Transformers, Jev-like APIs, and Calibration

1. Language modeling and classification in the pre-transformer era

1.1 Bag-of-words: naive Bayes, logistic regression, and XGBoost

1.2 Deep neural networks for text classification

1.2.1 Word embeddings

1.2.2 Recurrent neural networks (RNNs)

1.2.3 Convolutional neural networks (CNNs)

2. Transformers

The Big LLM Architecture Comparison

A Visual Guide to Attention Variants in Modern LLMs

2.1 Encoder-style language models

2.2 Decoder-style LLMs

Building an AI Text Detector From Scratch

2.3 Encoder-decoder style architectures

3. Jev overview

3.1 Jev vs existing text-to-text classification

3.2 The Jev API

3.3 Jev classifying IMDb

4. BERT- and GPT-style models with Jev API

5. Jev architecture and training algorithm

5.1 On calibration

5.2 Reinforcement learning with calibration rewards (RLCR)

5.3 Side note: Is calibration necessary?

6. Who is Jev for?

6.1 Jev use cases

6.2 About Jev clones and local Jevs

Conclusion

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR

别吹 Demo 了：读完 Pi 的 Harness v2 和 PR #8172，聊聊写 Agent 的那些烂坑

1. Pi 是谁？

2. 竞品锐评：市面上的 Harness 错在哪？

锐评 LangChain / LangGraph：自找麻烦的“图状态机”

锐评 DeepSeek Harness (dsh)：粗暴丢数据的截断器

锐评 AutoGPT / CrewAI：没有容灾的纸糊玩具

3. Agent 开发者天天踩的五个坑，Pi 怎么解？

坑 1：中途插消息，KV Cache 当场报废

坑 2：进程挂了，留下半截死状态

坑 3：超大输出撑爆上下文，盲目截断导致模型幻觉

坑 4：多任务并发，状态文件被写烂

坑 5：异步 Check-Then-Act 竞态

4. 确定性测试：线上代码怎么写，测试就怎么跑

5. 总结

微软官方开源：一键把全新 Windows 11 变成干净、清爽的开发机

标准安装

删除/关闭

安装/配置

完整安装

关闭/调整

安装

WSL Comfort：顺手配置 WSL

只装需要的开发环境

获取