AI观察：GPT-5延期？Cloudflare与苹果PCC

一、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.通过大模型的个性化广告无法实现。

文章来源于“共识粉碎机”，作者“Andy Liu”