一、GPT-5 延期？

OpenAI 的名义 CTO Mira 在最新的访谈中提到：

GPT-3 是 Toddler-level 的智力水平，GPT-4 更像是聪明的高中生智力水平。

在一年半后，我们会有一个能在 Specific Tasks 上达到 PhD-level 智力水平的大模型。

视频最早在周四发出来，周五的时候 Twitter 和中文自媒体开始讨论，并且理解为 "GPT-5 将在一年半后发布 "。大家可以查阅原视频，Mira 在整个讨论中都没有提过 GPT-5，也只是提到一年半后会有一个 PhD-level 的模型。

OpenAI 在流程上实际的 CTO 是 Greg，但 Greg 更喜欢编程而不是管理，所以有了 Mira 任职目前的 CTO 管理方面的工作。但 Mira 本身的职能主要在负责 Enterprise 大客户，不负责目前的模型训练，这也造成了 Mira 在很多外部沟通中都出现了模棱两可的回答，包括上次提到 "OpenAI 实验室内的模型没有比外部更加先进 "，再往前回溯还有类似的回答。

目前我们了解到的情况是，下一代模型的参数量和训练数据量都在 GPT-4 级别的 5-10 倍，同时会加强多模态和复杂任务的推理。传统训练模型，是在小模型上做足够的 ablation 实验，然后再到大模型上尝试的方法。在这么强大的下一代模型面前，有一定的失效，因此很多实验需要在大模型上直接跑，需要的算力资源是巨大的。同时，这么强大和复杂的模型，如何做 post-train 和 alignment 也非常复杂，需要大量的算力资源。

OpenAI 的超大集群互联可能还是有一定挑战，当下仍然是 2-3 个集群进行互联，而不是一个 10 万 + 的大集群。这样在实验和训练的效率上都会受到影响，跨集群训练的问题在于，集群间的传输速度和集群内的传输速度不一样（集群间一般只有集群内的 1/3 或者更低的传输速度）。导致集群间的传输调度策略要保证各种协同、一致变得非常复杂，而参数量大的模型，训练本身数据传输就非常多，协同要求也非常高。

比如，有的实验或者 pretrain，如果只跑了一半或者 1/3，可能并不能看出来最后的结果如何。因此，OpenAI 也需要更多的时间和计算资源，来调配出（炼丹）最优的 pretrain 和 posttrain 的 recipe。

这也是为什么 Elon Musk 会很激进地提到 xAI 今年就要做出来 10 万卡的集群，未来想要 30 万卡 + 的 B 卡集群。因为下一代 B 卡的互联性能有很大的提升，能够极大地帮助后进者来提升实验的效率和速度，追赶 OpenAI。

尽管目前仍然存在工程问题，但随着更大互联集群的迅速落地，大部分问题都会很快解决。

二、苹果 PCC 对 Cloudflare 的带动

苹果在 Apple Intelligence 上的安全方案 PCC 中披露，网络层会使用一家第三方服务商来确保客户隐私数据传输的安全性。

这里提到的第三方 OHTTP 服务商大概率是说的 Cloudflare。因为苹果从 2022 年开始和 Cloudflare 合作，搞 iCloud Private Relay。主要目的是 iCloud 通过 Cloudflare 的出栈代理系统，进行 IP、位置信息及其他可能涉及隐私数据的隐藏和加密，确保处理用户数据的任何一方都无法获得有关用户身份以及他们尝试访问的内容的完整信息。

这种合作大概率延伸到 PCC 上，解决 PCC 对外的网络传输层对于外部服务器的访问问题。主要的底层技术方案是 OHTTP。该项技术最主要是实现了端到端加密。

趋势：Cloudflare 于 2022 年推出这个方案，是行业中推出比较早的商业化方案的公司，主要合作伙伴是苹果。Fastly 于 2023 年推出，主要合作伙伴是谷歌，主要应用场景是设备通过 Chrome 浏览器对外部的访问。

后续影响：

1. 对 Cloudflare 的收入影响：如果 Apple Intelligence 的推广较为顺利的话，通过 PCC 的 request 会带来一些增量。

因为不确定 Cloudflare 在这个方案中的位置：request per day（手机每天每用户 request 大约在 1000 量级）X Total number of users（200M，假设 Apple Intelligence 能占 Apple 用户的 ~20%）X OHTTP 单价（$0.01/10K requests，OHTTP 会比一般的 HTTP 访问 $0.0075/10K 贵一些，假设贵 30%）X discount（70%，Apple 作为大客户）X 天数（365 天）=$50M/year 的增量，占 Cloudflare 年收入（23 年，$1.3B）的 4%。

2. 对广告行业的影响：通过这套方案，外部基本上获得不了用户具体的信息，通过外部大模型进行用户 specific 广告的路径基本上无法实现。

OHTTP 介绍（选自 Cloudflare 官方网站）：

端到端加密的请求和响应通过中继在客户端和服务器之间转发，将谁与发送的内容分离。这是一种常见的模式，Oblivious DoH 和 Apple Private Relay 等部署的技术证明了这一点

应用程序使用 OHTTP 来确保请求不会链接到以下任一项（Stronger than a promise:proving Oblivious HTTP privacy properties ( cloudflare.com ) ）：

1. 客户端标识信息，包括 IP 地址、TLS（Transport Layer Security，TLS），TLS 的主要用例是对 web 应用程序和服务器之间的通信（例如，web 浏览器加载网站）进行加密）指纹等。作为代理协议，这是一项基本要求。

2. 来自同一客户端的未来请求。这对于不跨请求携带状态的应用程序是必需的。

这两个属性使 OHTTP 非常适合在不影响基本功能的情况下，为用户提供隐私的应用程序。

值得注意的是，这两个属性都可以通过面向连接的协议来实现，但代价是客户端希望传输的每条消息都有一个新的端到端 TLS 连接。对于参与该协议的所有实体来说，这可能非常昂贵（2022 年的时候）。

技术架构：客户端 ->Server

从请求封装开始，混合公钥加密。客户端首先将其 HTTP 请求转换为二进制格式，称为二进制 HTTP，由 RFC9292 指定。此表示形式允许客户端将 HTTP 请求编码为二进制编码值，并允许网关反转此过程，从二进制编码值中恢复 HTTP 请求。二进制编码是必需的，因为公钥加密层需要二进制编码的输入。

一旦 HTTP 请求被编码为二进制格式，它就会被馈送到 HPKE 中以生成加密消息，然后客户端将其发送到中继以转发到网关。网关解密此消息，将二进制编码的请求转换回其等效的 HTTP 请求，然后将其转发到目标服务器进行处理。

Server-> 客户端：加密

来自网关的响应以非常相似的方式封装回客户端。网关首先将响应编码为等效的二进制 HTTP 消息，使用只有客户端和网关知道的对称密钥对其进行加密，然后将其返回到中继以转发到客户端。客户端解密并转换此消息以恢复结果。

可能的影响：

1. 苹果的 request 和 traffic 很大的话对 Cloudflare 是个利好，但单独来看，苹果的 request 和 traffic 没那么大。

2. 如果苹果之外，还有其他手机厂商采用类似 PCC 的方法呢？

3. 通过大模型的个性化广告无法实现。