當(dāng)ChatGPT被黑客“入侵”時，OpenAI會如何應(yīng)對？

掐斷API，不讓他們用？不不不。

這幫極客們采取的做法可謂是劍走偏鋒——反手一記《無間道》。

故事是這樣的。

OpenAI雖然在發(fā)布ChatGPT之前做了大量的安全性檢測，但當(dāng)開放API之后，還是防不住一些居心叵測的黑客們拿它搞事情。

然后有一天，團隊中的一個工程師突然發(fā)現(xiàn)ChatGPT端點上的流量有些不太正常；在經(jīng)過一番調(diào)查之后，確定了大概率是有人在反向工程API（盜版API）。

不過OpenAI并沒有選擇立即阻止這些黑客，因為如果團隊這樣做了，黑客們就會馬上發(fā)現(xiàn)異樣，然后改變策略繼續(xù)攻擊。

這時，團隊里一個“大聰明”就支了個妙招：

我們搞成“catGPT”，每個token都是“meow”……

“陷阱”布置成功后，黑客大兄弟再向ChatGPT提問時，畫風(fēng)就是這樣嬸兒的了：

沒錯，不管問啥，回答都是“喵言喵語”：

喵，我不知道。我是只貓，不是只鳥！

這位黑客大兄弟起初還不知道自己早已落入“陷阱”，還發(fā)帖描述了自己神奇的經(jīng)歷。

不過黑客團伙中很快有人察覺到了異樣：

兩個代理都出現(xiàn)了同樣的情況；我覺得我們完了（暴露了）。

團伙中還有人在Discord社區(qū)中這樣討論：

兄弟，你覺得OpenAI是發(fā)現(xiàn)了我們在（拿盜版API）用模型，然后開始拿“貓語promt”來回答我們嗎？

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

OpenAI潛入黑客群聊！盜用ChatGPT被換成“喵喵GPT”，網(wǎng)友：絕對的傳奇??由 商業(yè)新知 提供

殊不知，OpenAI的成員們早就潛入了Discord社區(qū)，觀望著黑客們的對話……

黑客們最終還是發(fā)現(xiàn)了真相，后知后覺的他們，最終在Discord中給OpenAI的團隊發(fā)話了：

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

你們有千載難逢的機會給我們來個“Rick Astley”（發(fā)現(xiàn)被整蠱時用的橋段），你們竟然就搞個貓。

對此，OpenAI的成員表示：“收到，下次我們會的”。

上面這個有趣的故事，其實是一位OpenAI工程師Evan Morikawa在一場技術(shù)分享活動中自曝的。

不少網(wǎng)友在看完這個故事之后，紛紛感慨道：

絕對的傳奇！

雖然故事很精彩、很有趣，不過言歸正傳，這也從側(cè)面反映出了目前大模型時代下所存在的安全隱患。

正如Evan在活動中所說：

隨著模型變得越來越強大，它們在壞人手中可能造成的傷害變得更大，我們在這里的警惕性確實需要成倍增加。

除此之外，Evan在活動中還分享了兩個與OpenAI、ChatGPT相關(guān)的“隱秘的故事”。

我們繼續(xù)往下看。

OpenAI：GPU夠的話，發(fā)布早就提前了

Evan先是回顧了ChatGPT最初爆火的盛況：

從內(nèi)部決定發(fā)布，到后來意外走紅，就連馬斯克都發(fā)推討論等等。

隨之而來的便是大量用戶的涌入，當(dāng)時他們自己也很擔(dān)心，因為以他們GPU的能力，完全hold不住那么大的負(fù)載。

然后Evan在現(xiàn)場展示了他們?yōu)镃hatGPT提供動力的計算機，里面有8個英偉達A100 GPU：

OpenAI潛入黑客群聊！盜用ChatGPT被換成“喵喵GPT”，網(wǎng)友：絕對的傳奇??由 商業(yè)新知 提供

每個GPU上還都附加了特殊的HPM高帶寬內(nèi)存；至關(guān)重要的是，他們還需要所有GPU相互通信：

Evan表示，里面的每個環(huán)節(jié)的性能都會影響ChatGPT最終的體驗感。

接下來，Evan站在現(xiàn)在這個時間節(jié)點，回顧并總結(jié)了OpenAI最初在GPU上所遇到的瓶頸。

1、GPU內(nèi)存不足

由于ChatGPT的模型非常大,需要占用大量GPU內(nèi)存來存儲模型權(quán)重。而GPU上的高帶寬內(nèi)存非常昂貴和有限,不夠用來同時服務(wù)大量用戶請求。這成為第一個瓶頸。

2、計算效率低下

初期通過簡單的GPU利用率指標(biāo)監(jiān)控存在問題,沒有充分考慮到tensor運算的內(nèi)存訪問模式。導(dǎo)致GPU算力沒有被充分利用,浪費了寶貴的計算資源。

3、難以擴容

ChatGPT流量暴增,但受限于整個GPU供應(yīng)鏈,短時間內(nèi)無法擴充GPU服務(wù)器數(shù)量,不得不限制用戶訪問。無法自動擴容成為重大挑戰(zhàn)。

4、多樣化負(fù)載特征

隨著用戶使用模式的變化,不同模型和請求類型對GPU的計算方式和內(nèi)存訪問模式需要不斷調(diào)整,優(yōu)化難度大。

5、分布式訓(xùn)練困難

GPU之間的通信和數(shù)據(jù)交換成為訓(xùn)練架構(gòu)中新的瓶頸。

可以看出，OpenAI開始將GPU用于部署大模型服務(wù)時，確實因為經(jīng)驗不足而遇到一些系統(tǒng)級別的困難。但通過不斷調(diào)整策略和深入優(yōu)化，才使ChatGPT得以穩(wěn)定運行。

而且Evan還爆料說：

如果不是因為GPU短缺，去年產(chǎn)品和功能的發(fā)布速度會更快。

我們已經(jīng)準(zhǔn)備好了東西了，但我們也知道無法處理負(fù)載。

基于上述的挑戰(zhàn)，Evan分享了OpenAI總結(jié)出的經(jīng)驗教訓(xùn)：

• 把問題視為系統(tǒng)工程挑戰(zhàn)，而不僅僅是研究項目；需要優(yōu)化各個系統(tǒng)組件的協(xié)同工作，如緩存、網(wǎng)絡(luò)、批處理大小等。

• 要深入了解硬件的底層細(xì)節(jié)及其對系統(tǒng)的影響，如GPU內(nèi)存帶寬、ops/bytes等對性能的影響；不能停留在表面指標(biāo)。

• 不斷根據(jù)模型和場景變化對系統(tǒng)進行調(diào)優(yōu)；不同的模型結(jié)構(gòu)和使用場景會對系統(tǒng)提出不同要求。

• 要考慮到硬件的各種限制，如內(nèi)存和算力均衡、擴容限制等，這會影響產(chǎn)品路線圖；不能簡單地套用傳統(tǒng)的云擴展經(jīng)驗。

把ChatGPT看成初創(chuàng)公司

至于團隊方面，Evan也有所介紹。

ChatGPT啟動時，應(yīng)用工程團隊只有30人左右，發(fā)布10個月后才擴充到近100人。

OpenAI一直在員工數(shù)量增長與保持高人才密度之間尋找平衡，他們最初希望團隊盡可能小，這樣可以保持高效的迭代文化。

不過后來隨著產(chǎn)品規(guī)模增長，很多職能只有幾個人在支撐，這樣就會存在一定風(fēng)險，因此才決定進行一定擴張。

Evan對于團隊建設(shè)方面的分享，有一個觀點是值得劃重點的。

那就是他認(rèn)為：

不要把ChatGPT看成是OpenAI的一個部門。

他們在三年前就嘗試過用API做類似ChatGPT的事情，因此在Evan看來——

ChatGPT更像是個10月大的初創(chuàng)公司嵌套到了3年前的初創(chuàng)公司；而這個三年前的初創(chuàng)公司，又嵌套在一個8年前的初創(chuàng)公司（即OpenAI）。

接下來，如果公司還會出現(xiàn)新的產(chǎn)品，Evan希望還是能夠保持沿用這種模式。