为什么 OpenAI 的 GPT-2 权重总比我的好？第五章：数据质量

深度摘要

Giles Thomas 从零复刻 GPT-2 系列的第五章：只换训练数据，重训 4 个 163M 模型，验证"数据质量"是不是 OpenAI 权重更强的秘密。FineWeb-Edu 模型在指令微调评测上距离 GPT-2 small 仅 0.63 分，是全系列最接近的一次；但他诚实地指出，同等质量数据的不同随机采样本身就有 3 分以上的噪声，所以结论远非定论。附带一个重要自我纠错：之前所有对比里，OpenAI 权重在微调时都是 163M 参数的"解绑"版本，而非原始的 124M——天平可能从一开始就是歪的。

关键要点

• 4 个 163M 模型、仅数据不同：FineWeb-Edu 在指令微调评分上最接近 GPT-2 small（差 0.63 分）
• 测试损失与训练集里 FineWeb 占比严格相关——OpenAI 模型在该测试集上表现好反而更显神秘
• "精选"高知识密度数据集在事实问答上惨败：小模型可能消化不了高密度知识
• 作者预注册了全部预测，并量化了数据采样噪声范围（3.05 分）
• 下一杠杆：weight tying——评测用的 OpenAI 权重在微调时其实是 163M 解绑版，对比可能一直不公平

关键事实

作者用 JAX 从零训练了 4 个 163M 参数的 GPT-2 级模型，各 3.2B token（Chinchilla 最优量），仅训练数据不同：FineWeb-Edu、50:50 FineWeb/FineWeb-Edu、"精选"混合（45% FineWeb + 45% FineWeb-Edu + 10% 简明英文维基）、OpenWebText。评测分两项：FineWeb 测试集上的交叉熵损失，以及 Alpaca 子集指令微调后由 GPT 5.5 打分的 IFT 评分（跑 5 次取平均）。结果：测试损失与训练集中 FineWeb 占比完美相关（意料之中）；IFT 上 FineWeb-Edu 模型最接近 OpenAI GPT-2 small（差距 0.63 分），"精选"数据集出人意料地差，OpenWebText 模型测试损失最差（4.05）。

作者观点

作者主张：FineWeb-Edu 这类"教育性更强"的数据确实有助于指令微调（IFT）表现，但证据远非确凿——50:50 混合与"精选"数据集（45% FineWeb + 45% FineWeb-Edu + 10% 简明维基）表现平平，且同等质量数据的不同随机采样本身就能带来 ±3 分的噪声；"精选"数据集在事实问答上惨败（把《傲慢与偏见》作者答成 Priscilla Finch、氯的化学符号答成 H），说明 163M 参数的小模型可能根本消化不了高密度知识数据，就像让六岁小孩先背书再理解。

为什么重要

这是公开领域少有的"控制变量做到极致"的个人 LLM 训练实验：同一代码、同一超参、只换数据。它给出的不是鸡汤式的"数据质量很重要"，而是带噪声范围的量化答案——对今天人人都在调数据配比的训练实践有直接参考价值，也提醒所有做模型对比的人：先检查你的评测天平本身是不是歪的。

编辑点评

这篇的真正价值不在结论而在方法：预注册预测、五次 LLM 裁判取平均、主动报告"裁判心情"带来的系统性漂移、把噪声范围（3.05 分）摆在台面上——个人实验者能做到这个严谨度很少见。结论上，FineWeb-Edu 只比 GPT-2 small 低 0.63 分，考虑到噪声范围，数据质量很可能就是作者与 OpenAI 之间差距的主要来源之一。作者下一杠杆是 weight tying：他意识到自己评测用的 OpenAI 权重在微调时其实是 163M 参数的"解绑版"，而非原始 124M——这个自我纠错很关键，说明之前的对比可能一直不公平。

深度摘要

Brian Potter 写给非 ML 读者的 VLA（视觉-语言-动作模型）长篇详解：从矩阵乘法、MLP、注意力一路讲到 Physical Intelligence 开源的 π0.5——SigLIP 看图、Gemma 理解语言、FAST 把动作变成 token、一个 3 亿参数的动作 transformer 做 10 轮去噪，一次输出 50 个动作。核心洞察：机器人 AI 与聊天机器人用的几乎是同一套 transformer 构件，VLA 字面意义上就是"把 LLM 当主干、把动作当语言"。

关键要点

• VLA = 文本+图像+机器人状态进，动作序列出；π0.5 用 PaliGemma（SigLIP+Gemma）做视觉语言主干
• 动作经 FAST 编码为 token，300M 参数的动作 transformer 做 10 轮迭代去噪，一次输出 50 个动作（action chunking）
• 18+18 个 transformer 块，视觉语言侧用 multi-query attention
• 机器人 AI 与 LLM 共享同一套构件：VLA 字面意义上复用了文本训练的 LLM
• 作者判断：这不保证机器人能力会复刻 LLM 的加速曲线，但让这种可能性变得可信

关键事实

π0.5 的视觉语言主干基于 PaliGemma：400M 参数的 SigLIP（2023）处理图像 patch，20 亿参数的 Gemma（3 万亿 token 文本训练）处理语言，两者在 2024 年合并并在 10 亿+图文样本上训练。动作侧：FAST 系统把机器人动作编码为 token，3 亿参数的动作 transformer 与视觉语言模型并行运行 18 个块，在每个注意力步骤中同时参考动作向量与对应块的图文状态向量，经过 10 次迭代把 50 个随机动作去噪为可用动作序列，再交由传统控制器转为电机力矩。

作者观点

作者主张：机器人进展的大头来自机器人 AI 而非硬件；VLA 与 LLM 的重叠程度超出他预期——VLA 直接把文本训练的 LLM 当主要构件用；这不必然意味着机器人能力会像 LLM 一样快速起飞，但确实让他觉得这种加速"有可能"发生。机器人及其 AI 是他计划长期深挖的主题。

为什么重要

人形机器人正处在资本狂热期（Figure、NEURA、Unitree 等动辄数亿美元融资），但公开讨论里能把 VLA 讲到"每个矩阵在干什么"这个颗粒度的内容极少。这篇是给技术决策者的极佳底座：读完它，再看任何机器人 demo 都能分辨哪些是工程、哪些是魔法。

编辑点评

Potter 的写作策略值得注意：他不假设读者懂 ML，从点积一路铺到 action chunking，28k 字符全是干货没有水分。这种"第一性原理解释器"正是 Karpathy 圈子稀缺的内容类型。配合本期 Clef 与 Pi 1.0 一起看：机器人走 VLA（大模型主干），软件智能体走决策小模型+极简脚手架——具身与非具身智能在架构上正在分岔，这个分岔本身比任何单一模型发布都值得记住。

深度摘要

Cloudflare 发布开源决策模型 Clef / Clef-flash（Apache 2.0）与 RL 微调平台。决策模型是 Typesafe Jev 带火的新品类：不做开放式生成，只对"是否紧急、归哪个团队、严重程度几级"这类问题输出带概率的类型化答案，便宜、快速、确定。Clef 在 Jev 决策指数上领先，带视觉编码器（Jev 纯文本）、64k 上下文（Jev 32k），API 兼容 Jev 可直接替换。训练上冻结 Qwen 主干、非自回归并行打分，中位延迟 209ms（Jev 524ms），flash 版 38.8ms。

关键要点

• 开源 Clef / Clef-flash，Apache 2.0，Jev API 兼容可直接替换
• 决策模型定位：智能体工作流中的高频有界决策，不做开放式生成
• 架构：冻结 Qwen 主干 + 双阶段注意力路由，非自回归并行打分 schema 选项
• 训练：rank-256 LoRA、标签平滑 CE + Brier 损失校准概率，自研 RLCD（面向校准决策的 RL）
• 配套 RL 微调平台：AI Gateway 采集数据 → Workers AI 生成 rollouts → Containers 沙箱打分 → Trainer 更新权重
• 内部已用：威胁情报团队用 Clef+Browser Run 做域名分类，2.2s vs gpt-oss-120b 的 4.7s

关键事实

Clef 在 Jev Decision Index 的 10 项评测中多数领先：BFCL 98.47、API-Bank 准确率 91.93、BANKING77 macro-F1 94.20、CLINC150+OOS 97.43；中位延迟 209.3ms、p95 238.6ms，Clef-flash 中位 38.8ms、p95 122.4ms，均显著快于 Jev（524.1ms）。训练细节：Clef 冻结 Qwen3.8-27B、Clef-flash 冻结 Qwen3.5-9B，联合优化路由头与 rank-256 LoRA；用内部合成数据（打乱字段顺序、prompt 与 schema 结构）；RLCD 对相邻有序选项给部分 credit、防分布漂移。模型已开源至 Hugging Face，同步上线 Workers AI 托管。

作者观点

Cloudflare 主张：决策模型是智能体走向生产的关键缺失构件——LLM 太贵太慢太不确定，高频决策应该由小而专的模型承担；Jev 验证了需求，Clef 在质量、延迟、视觉输入三项上超越它；RL 微调平台（先 FDE 人工服务、再自助平台）是把客户自有标注数据变成专用决策模型的路径。

为什么重要

"决策模型"是 2026 下半年智能体架构最重要的分化：把"判断"从"生成"里拆出来。这直接对应成本结构——客服分拣、风控、安全运营这类每秒成千上万次的调用，用 LLM 是烧钱，用决策模型是可行的。Cloudflare 把模型、托管、RL 微调做成一条龙，等于在定义这个品类的商业形态。

编辑点评

注意 Cloudflare 的训练路线：冻结大主干、只训路由头+LoRA、非自回归打分——这是"把大模型当特征提取器、小头做决策"的务实派做法，与全参数微调派形成对照。Brier loss + RLCD 的组合也值得玩味：决策模型的胜负手不在绝对准确率，而在概率校准——一个知道自己"有多确定"的模型，才能让智能体决定何时转人工。这正是 Pi 1.0 那种极简脚手架缺的一块：Pi 管"怎么执行"，Clef 管"该不该做、找谁做"。

深度摘要

Earendil 发布 Pi 1.0：极简、可扩展的智能体脚手架正式版。每周有数十万人使用。1.0 新增：Codemode（原生 MCP 支持、Jev 等非 LLM 模型与图像模型）、虚拟模型扩展、延迟工具加载、Anthropic 模型缓存预热、会话中系统消息（transcript 感知的 prompt/工具变更）、默认全屏。同时发布实验性的 Pi Durable——把 Pi 的极简主义延伸到长运行、多界面的智能体应用。两者均为 MIT 协议。

关键要点

• Pi 1.0：硬化、极简、可扩展的 agent harness；每周数十万用户
• 新增 Codemode（原生 MCP、Jev 等非 LLM 模型）、虚拟模型扩展、延迟工具加载
• Anthropic 缓存预热、会话中系统消息、全屏默认
• 同步发布 Pi Durable：面向长运行智能体应用的实验性基座
• 设计哲学：等一个功能被验证后再收敛，"扔上墙没粘住的清单要长得多"
• MIT 协议，文档 pi.dev，代码 github.com/earendil-works/pi

关键事实

Pi 1.0 运行所有主流厂商的最新模型，已成为许多人的日常编码智能体。1.0 功能清单：Codemode（MCP 原生支持、Jev 与图像模型等非 LLM 模型）、虚拟模型扩展支持、延迟工具加载、Anthropic 模型缓存预热、会话中系统消息、全屏模式默认开启。Pi Durable 通过 npm 分发（@earendil-works/pi-durable 等三个包），定位是长运行、可从多界面触达的智能体应用基座。安装：curl pi.dev/install.sh。

作者观点

Earendil 主张：智能体工具每周都在变，但大多活不下来；Pi 的策略是等一个东西被证明有价值再收敛，权衡真实功能与引入的复杂度。1.0 是数月社区反馈打磨出的"可依赖"版本；Pi Durable 则是把极简主义带出终端、带进长运行任务的新实验——不稀释 Pi 本体的极简定位，另起一个包承载。

为什么重要

智能体脚手架正在经历"框架大爆炸"，Pi 是其中罕见的反共识样本：不做大而全的平台，做薄而硬的 harness，且真的有数十万周活。它的 1.0 功能取舍（收敛了什么、拒绝了什么）是观察智能体工程化的一手风向标。Jev 出现在 Codemode 支持列表里，也与本期 Clef 形成互文：决策小模型正在成为 agent harness 的一等公民。

编辑点评

最值得玩味的是 Pi 的"慢哲学"：在一个人人每周发版的赛道里，它把"拒绝"当作核心功能。这与 turbopuffer 杀死向量主索引、Clef 把决策拆出大模型是同一个动作——为生产环境做减法。Pi Durable 另起一包而不是膨胀本体，也说明团队对定位漂移有清醒的恐惧。HN 545 分说明社区吃这套：开发者已经被臃肿的 agent 框架折磨够了。

深度摘要

turbopuffer 宣布 v3 架构：亲手杀死让自己成名的"向量主索引"，把 ANN 降格为普通二级索引。原因有三：存储放大（多向量文档要为每个向量复制全文）、写入放大（SPFresh 重平衡会级联搬动整个文档及其倒排索引）、向量化受限（所有查询计划被锁死在 100–200 文档的 ANN 簇块大小）。v3 不再按 ANN 地址组织文档，CI 已 100% 通过，接下来公开做性能打磨直到追平再上线生产。

关键要点

• v1：文档=ID+向量，SPANN→SPFresh 分层聚类索引，对象存储为源、NVMe/内存分层缓存
• v2：属性过滤与 BM25 全文检索都是倒排索引指向 ANN 地址，存储布局未变
• 向量主索引的三宗罪：存储放大、写入放大（调优已收益递减）、块大小被锁死
• 实证：FTS v2 把 posting 切成 256 固定块后索引小 10 倍、查询快 20 倍
• v3：文档不再按 ANN 地址组织；CI 全过，公开做性能追平后再上线
• 规模：1T+ 文档、1000 万+ 写入/秒、2.5 万+ 查询/秒；单索引 100B+ 向量、200ms p99

关键事实

turbopuffer v1 以对象存储为源头、SPANN（后迁至 SPFresh 支持增量索引）做分层聚类；v2 加入属性倒排与 BM25 全文检索，但都 keyed 在 ANN 地址（ClusterId+LocalId）上。v3 改动：文档主键不再是 ANN 地址。量化证据：FTS v1 的 posting 按 ANN 簇切分、中位块仅 1.5 条 posting，v2 改为 256 固定块后索引缩小 10 倍、查询快 20 倍。当前规模：托管 1 万亿+文档、每秒 1000 万+写入、2.5 万+查询；向量检索单索引 100B+向量、1k+QPS 下 200ms p99。v3 里程碑：本月早些时候 CI 100% 通过，下一步公开做性能打磨。

作者观点

turbopuffer 主张：向量主索引对纯 ANN 检索极好（100B 向量、200ms p99），但已成为全文、聚合、正则等多查询形态的天花板；正确的做法是让 ANN 退为二级索引，用通用存储布局服务所有查询计划；与其藏着做，不如开门让用户从 day zero 跟着看性能打磨。

为什么重要

这是向量数据库品类的一次公开自我否定：连头部玩家都承认"为向量而生的存储"走到了头。信号很明确——RAG 之后，真实工作负载是混合查询（向量+过滤+全文+聚合），赢家是通用检索引擎，不是向量专库。对正在选型的人：别再为"向量原生"付架构税。

编辑点评

这篇最漂亮的是它的诚实：把三宗罪量化（存储/写入/向量化），把 FTS v2 的 10 倍/20 倍改进当证据，最后承认"改动不小、有回归风险"。与本期 Pi、Clef、Chacon 放在一起看，2026 年的基础设施叙事正在从"专用化"摆回"通用化+可组合"：专用索引退为二级、专用决策模型从 LLM 里拆出来——拆与合的钟摆，这次摆向了"薄的专用层 + 厚的通用底座"。

深度摘要

GitHub 联创 Scott Chacon 开炮：Git 3.0 把默认哈希从 SHA-1 换成 SHA-256，将是一场"代价高昂、几乎零价值、可避免的全球噩梦"。SHA-1 的"被破解"只意味着碰撞攻击在理论上可能（需攻击者预先构造双文件）， second-preimage 在宇宙热寂前都不现实；而真实世界的代码投毒靠的是社工拿维护权，不是租 GPU 碰撞哈希。迁移代价：仓库格式二分、所有含 SHA-1 的 URL 失效、签名全断、40 字符假设的工具链全崩。他的替代方案：签名时附带独立的树哈希头（如 git-evtag），不迁库也能解决信任问题。

关键要点

• SHA-1 的"破解"=碰撞攻击理论上可能；second-preimage 即使用 MD5 也要约 160 亿年
• 真实攻击向量：社工拿 npm 包维护权，比 GPU 碰撞便宜"十亿倍"
• "哈希不是信任机制"——Linus 2005 年原话：真正的信任在于你从哪里 pull
• 迁移代价：新仓库默认 SHA-256、与旧库不互通、push 会报 receiving end 不支持
• 子模块、40 字符哈希假设的工具链、所有历史链接全部受影响
• 替代方案：签名时注入独立树哈希头（SHA-256/BLAKE3），Chromium 2.1M 文件全量校验仅 5 秒
• NIST 2030 大限针对的是"用 SHA-1 做密码学保护"，独立签名头同样合规

关键事实

SHA-1 碰撞攻击已有 SHAttered（2017）与"SHA-1 is a Shambles"（2020）论文，成本约数万美元 GPU 算力；但 second-preimage 即使对 MD5，按"全球 30 亿 GPU 全换成 RTX 5090 全力跑"的估算仍需约 160 亿年。Git 3.0 现状：git init 默认 SHA-256（可用 --object-format=sha256 提前体验），新仓库无法 push 到尚未声明支持的托管端（"the receiving end does not support this repository's hash algorithm"），子模块要求两端同格式，转换需重写全部对象并导致所有签名失效。作者的概念验证：在 Chromium 35GB/210 万文件（含子模块）上生成独立树校验和耗时 5 秒（M5 Mac 多线程），Linux 树 257ms，Git 自身 17ms。git-evtag 自 2015 年起已实现类似方案。

作者观点

Chacon 主张：把哈希当信任根是概念混淆——信任来自源的可信度，而非哈希强度；SHA-1 作为内容寻址键完全够用（历史上从未发生意外碰撞），真正的威胁模型下碰撞攻击是"最蠢的攻击方式"；与其让全行业为理论威胁付迁移税，不如在签名里加独立树哈希头，花 5 秒解决 Chromium 级仓库的信任问题，且未来算法再被破解时只需加新头、不迁库。

为什么重要

Git 3.0 是未来几年开发者工具链最大的 breaking change 之一，而 Chacon 是极少数敢在发车前喊停的圈内人。无论你站哪边，这篇都是理解"为什么迁移这么痛"最完整的清单：格式二分、签名失效、链接腐烂、工具链 40 字符假设——每一项都是真实会落到每个团队头上的成本。

编辑点评

这篇的论证结构值得拆解：先区分 collision vs second-preimage（大多数人混为一谈），再用"攻击经济学"（社工 $40k vs GPU 碰撞）把威胁模型拉回地面，最后给出一个 5 秒验证的替代方案——完整的"问题-代价-出路"三段论。唯一的保留：NIST 合规与 FIPS 语境下，"SHA-1 只是键"的说法在审计面前未必过关，作者自己也承认这是 1% 不信任源场景的方案。把它和本期 turbopuffer 一起读：两篇都在问同一个问题——为理论上的最坏情况重构整个系统，到底值不值？

深度摘要

Nicholas Nethercote 的 Rust 编译器性能月报：7 月 29 日至 9 月 28 日，629 项基准平均墙钟时间下降 4.57%，555 项改善、74 项回退，"一片绿油油"。亮点：Clippy 开 PGO（最好 18%）、LLVM 23 升级（平均 1.2%）、Polonius Alpha 新借用检查器与新 trait 求解器登陆 Nightly（附带可测量的回退，正在修）、xmakro 的一系列分配优化、CFG 遍历算法改动让 cranelift 某巨型函数快 30%、增大默认栈大小从而删掉 ensure_sufficient_stack。作者下月将全职加入 Hexcat 做编译器性能优化。

关键要点

• 两个月平均墙钟 -4.57%，629 项基准中 555 项改善
• Clippy 开 PGO 最好 -18%；LLVM 23 升级平均 -1.2%
• Polonius Alpha（新借用检查器）与新 trait 求解器已进 Nightly，伴随小幅回退、持续修复中
• xmakro：specialization 图、增量编译数据加载、obligation 热路径去分配
• CFG 遍历算法改动：cranelift 18000+ 基本块函数的 fixpoint 迭代从 150 万次降到 9 万次，-30%
• 删掉 ensure_sufficient_stack：增大默认栈大小替代手工栈扩展
• 性能 PR 多到要打包含并：10 个性能 PR 的 rollup 首次出现

关键事实

统计窗口 2026-07-29 至 2026-09-28，629 个基准测量平均墙钟降低 4.57%。具体 PR：#159642（Clippy PGO，最好 -18%）、#158734（LLVM 23，平均 -1.2%）、#161938/#163027（Polonius liveness 惰性化，serde 指令数 -3~5%）、#157281（specialization 图，平均 cycle -1.58%）、#160193（CFG 遍历，cranelift 巨型函数 -30%）、#160033（EverInitializedPlaces，match-stress -17%）、#160535（增大默认栈，删 ensure_sufficient_stack，最好 -3%）。作者披露在部分 PR 中用了 LLM 做分析辅助，但代码与文字均为手写（项目政策要求）。

作者观点

作者视角：这是典型的"积少成多"——没有银弹，十几个 1~3% 的改进叠出 4.57%；新借用检查器与 trait 求解器的回退被整体改进淹没（"sea of green"吞掉了回退）；性能 PR 多到需要打包合并是"甜蜜的烦恼"；下月全职投入 Hexcat 的编译器性能项目。

为什么重要

Rust 编译慢是生态多年的痛点，这份月报展示的是系统性、可持续的解法：benchmark 驱动、每个 PR 单独可测量、回退可追踪。对任何维护大型系统性能的人，这套工作方法比数字本身更值得借鉴。

编辑点评

把这篇和 Chacon 的 Git 长文对照看很有意思：两边都在谈"渐进改进 vs 推倒重来"。Rust 选择用上百个微小 PR 把编译器磨快 4.57%，Chacon 则警告 Git 正在用一次豪赌式的迁移解决理论问题。工程文化的两种气质，同一天摆在你面前。另注意作者对 LLM 辅助的披露方式——"分析用了 LLM，代码文字全手写，政策要求"——这种披露范式可能会成为技术写作的新常态。