OpenAI 潜入黑客群聊！将盗版 ChatGPT 换成“喵喵 GPT”，网友：绝对的传奇

感谢IT之家网友 Coje_He、西窗旧事、Alejandro86、咩咩洋 的线索投递！

当 ChatGPT 被黑客“入侵”时，OpenAI 会如何应对？

掐断 API，不让他们用？不不不。

这帮极客们采取的做法可谓是剑走偏锋 —— 反手一记《无间道》。

故事是这样的。

OpenAI 虽然在发布 ChatGPT 之前做了大量的安全性检测，但当开放 API 之后，还是防不住一些居心叵测的黑客们拿它搞事情。

然后有一天，团队中的一个工程师突然发现 ChatGPT 端点上的流量有些不太正常；在经过一番调查之后，确定了大概率是有人在反向工程 API（盗版 API）。

不过 OpenAI 并没有选择立即阻止这些黑客，因为如果团队这样做了，黑客们就会马上发现异样，然后改变策略继续攻击。

这时，团队里一个“大聪明”就支了个妙招：

我们搞成“catGPT”，每个 token 都是“meow”……

“陷阱”布置成功后，黑客大兄弟再向 ChatGPT 提问时，画风就是这样婶儿的了：

没错，不管问啥，回答都是“喵言喵语”：

喵，我不知道。我是只猫，不是只鸟！

这位黑客大兄弟起初还不知道自己早已落入“陷阱”，还发帖描述了自己神奇的经历。

不过黑客团伙中很快有人察觉到了异样：

两个代理都出现了同样的情况；我觉得我们完了（暴露了）。

团伙中还有人在 Discord 社区中这样讨论：

兄弟，你觉得 OpenAI 是发现了我们在（拿盗版 API）用模型，然后开始拿“猫语 promt”来回答我们吗？

若真如此，那也太搞笑了吧！

殊不知，OpenAI 的成员们早就潜入了 Discord 社区，观望着黑客们的对话……

黑客们最终还是发现了真相，后知后觉的他们，最终在 Discord 中给 OpenAI 的团队发话了：

我很失望。我知道 OpenAI 的某人正在读这段文字。

你们有千载难逢的机会给我们来个“Rick Astley”（发现被整蛊时用的桥段），你们竟然就搞个猫。

对此，OpenAI 的成员表示：“收到，下次我们会的”。

上面这个有趣的故事，其实是一位 OpenAI 工程师 Evan Morikawa 在一场技术分享活动中自曝的。

不少网友在看完这个故事之后，纷纷感慨道：

绝对的传奇！

虽然故事很精彩、很有趣，不过言归正传，这也从侧面反映出了目前大模型时代下所存在的安全隐患。

正如 Evan 在活动中所说：

随着模型变得越来越强大，它们在坏人手中可能造成的伤害变得更大，我们在这里的警惕性确实需要成倍增加。

除此之外，Evan 在活动中还分享了两个与 OpenAI、ChatGPT 相关的“隐秘的故事”。

我们继续往下看。

OpenAI：GPU 够的话，发布早就提前了

Evan 先是回顾了 ChatGPT 最初爆火的盛况：

从内部决定发布，到后来意外走红，就连马斯克都发推讨论等等。

随之而来的便是大量用户的涌入，当时他们自己也很担心，因为以他们 GPU 的能力，完全 hold 不住那么大的负载。

然后 Evan 在现场展示了他们为 ChatGPT 提供动力的计算机，里面有 8 个英伟达 A100 GPU：

每个 GPU 上还都附加了特殊的 HPM 高带宽内存；至关重要的是，他们还需要所有 GPU 相互通信：

Evan 表示，里面的每个环节的性能都会影响 ChatGPT 最终的体验感。

接下来，Evan 站在现在这个时间节点，回顾并总结了 OpenAI 最初在 GPU 上所遇到的瓶颈。

1、GPU 内存不足

由于 ChatGPT 的模型非常大，需要占用大量 GPU 内存来存储模型权重。而 GPU 上的高带宽内存非常昂贵和有限，不够用来同时服务大量用户请求。这成为第一个瓶颈。

2、计算效率低下

初期通过简单的 GPU 利用率指标监控存在问题，没有充分考虑到 tensor 运算的内存访问模式。导致 GPU 算力没有被充分利用，浪费了宝贵的计算资源。

3、难以扩容

ChatGPT 流量暴增，但受限于整个 GPU 供应链，短时间内无法扩充 GPU 服务器数量，不得不限制用户访问。无法自动扩容成为重大挑战。

4、多样化负载特征

随着用户使用模式的变化，不同模型和请求类型对 GPU 的计算方式和内存访问模式需要不断调整，优化难度大。

5、分布式训练困难

GPU 之间的通信和数据交换成为训练架构中新的瓶颈。

可以看出，OpenAI 开始将 GPU 用于部署大模型服务时，确实因为经验不足而遇到一些系统级别的困难。但通过不断调整策略和深入优化，才使 ChatGPT 得以稳定运行。

而且 Evan 还爆料说：

如果不是因为 GPU 短缺，去年产品和功能的发布速度会更快。

我们已经准备好了东西了，但我们也知道无法处理负载。

基于上述的挑战，Evan 分享了 OpenAI 总结出的经验教训：

把问题视为系统工程挑战，而不仅仅是研究项目；需要优化各个系统组件的协同工作，如缓存、网络、批处理大小等。

要深入了解硬件的底层细节及其对系统的影响，如 GPU 内存带宽、ops / bytes 等对性能的影响；不能停留在表面指标。

不断根据模型和场景变化对系统进行调优；不同的模型结构和使用场景会对系统提出不同要求。

要考虑到硬件的各种限制，如内存和算力均衡、扩容限制等，这会影响产品路线图；不能简单地套用传统的云扩展经验。

把 ChatGPT 看成初创公司

至于团队方面，Evan 也有所介绍。

ChatGPT 启动时，应用工程团队只有 30 人左右，发布 10 个月后才扩充到近 100 人。

OpenAI 一直在员工数量增长与保持高人才密度之间寻找平衡，他们最初希望团队尽可能小，这样可以保持高效的迭代文化。

不过后来随着产品规模增长，很多职能只有几个人在支撑，这样就会存在一定风险，因此才决定进行一定扩张。

Evan 对于团队建设方面的分享，有一个观点是值得划重点的。

那就是他认为：

不要把 ChatGPT 看成是 OpenAI 的一个部门。

他们在三年前就尝试过用 API 做类似 ChatGPT 的事情，因此在 Evan 看来 ——

ChatGPT 更像是个 10 月大的初创公司嵌套到了 3 年前的初创公司；而这个三年前的初创公司，又嵌套在一个 8 年前的初创公司（即 OpenAI）。

接下来，如果公司还会出现新的产品，Evan 希望还是能够保持沿用这种模式。

参考链接：

[1]https://www.youtube.com/watch?v=PeKMEXUrlq4

[2]https://twitter.com/random_walker/status/1719342958137233605?s=20

[3]https://twitter.com/nearcyan/status/1719225443788935372?s=20

广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。