Control Room
隨著模型能力日益強大，相關的安全與資安風險也隨之增加。因此，能夠偵測潛在問題，並在必要時迅速阻止模型繼續運作，變得愈來愈重要。為了因應這項需求，我們打造了 Control Room。
Control Room 是一套集中式系統，可追蹤整個研究基礎架構中的模型工作負載，並在出現安全或資安疑慮時迅速停止這些工作負載。它串接了所有研究推論工作負載，包括用於模型訓練與評估的智慧體採樣、資料處理等。這套系統與我們的未對齊行為監控系統協同運作，從決定介入停止或暫停作業起，能在 35 秒內停止模型輸出。它的設計能在其他系統故障時繼續運作，而若 Control Room 本身中斷，也會停止模型輸出。
Control Room 已部署於我們的整個研究基礎架構，這也是最需要它的地方。我們對外提供模型服務的技術堆疊，本身就採用更集中的架構，也已具備成熟的維運能力，可在必要時迅速下線已部署的模型。
Control Room 透過整合幾個系統來運作：工作負載、推論引擎，以及集中式的 Control Room 服務。
工作負載是正在執行的作業，例如強化學習實驗、評估、大量採樣或資料處理作業。我們要求每個執行智慧體推論的研究工作負載，都必須關聯至一份經核准的安全論證。
推論引擎，或簡稱引擎，就是模型本身。你可以將引擎想成模型的大腦，直接在 GPU 上執行。一個工作負載通常會使用一或多個模型，而這些模型可能在一或多個不同的推論引擎上執行。同一個推論引擎也可能供多個不同的工作負載使用。
Control Room 服務會追蹤作業，並控管是否允許它們繼續產生模型輸出。引擎在處理請求前，會先向 Control Room 服務確認。如果作業已停止，服務就會拒絕請求，防止產生後續輸出。
Control Room 的整合方式如下：
啟動新作業時，工作負載程式碼會向 Control Room 請求新的 job_id。
每當工作負載需要從模型採樣 token，就會向執行該模型的推論引擎發出請求，並傳入 job_id。引擎會向 Control Room 請求處理該請求的許可，同時將 job_id 傳給 Control Room。
Control Room 會檢查該作業是否已終止；如果是，就會拒絕推論請求。引擎會針對工作負載的推論請求回傳拒絕訊息，不再為該作業產生模型輸出。
Control Room 的運作方式
研究作業
推論引擎
在 GPU 上執行模型
Control Room
- job_039，執行中
- job_040，執行中
- job_041，執行中
我們所有前沿模型的強化學習作業，都會搭配監控模型執行。監控模型是另一個模型，會檢查受訓模型的所有行為，並在偵測到問題時發出警示。例如，我們近期的 DNS 相關事件(在新視窗中開啟)，就是由監控模型發現的。
Control Room 與我們的監控系統整合方式如下：
如果監控系統偵測到潛在問題，可能會視具體情況與嚴重程度，決定停止作業。
此時，監控系統會傳送訊息給 Control Room，要求停止作業，並傳入 job_id。Control Room 會記錄該作業已終止。
下次具有該 job_id 的作業發出推論請求，想從任何引擎上執行的任何模型採樣更多 token 時，請求都會遭到拒絕，從而停止後續的模型輸出。
從 Control Room 收到停止作業的指令，到作業無法再繼續推進，最長需要 35 秒。這 35 秒的延遲來自推論授權的快取層，其用途是支援所需的流量。我們正努力將這段延遲縮短至零，以便即時終止作業。
實驗、評估作業等工作負載，通常由研究人員或研究團隊負責管理與執行。因此，工作負載的程式碼經常變動，並不適合用來實作承擔關鍵防護責任的安全機制。基於這點，我們的設計能在工作負載程式碼有錯誤或無法正常運作時，仍然發揮作用。
我們透過在推論層實作終止機制來達成這一點。工作負載程式碼的形式多樣，管理也相當分散。相較之下，OpenAI 所有研究使用的推論程式碼路徑僅有極少數，其部署方式也更集中且一致。這意味著推論層可以作為必經的管制關卡，讓我們能夠確保研究中執行的所有模型推論，每次提出推論請求時都會接受 Control Room 的授權檢查。此外，我們也持續透過智慧體與程式進行全面檢查，確認使用者沒有意外或惡意啟動未實作或已停用 Control Room 的引擎版本，讓它們脫離管控。
最後，我們的系統採取「故障時拒絕存取」的設計。也就是說，引擎中的 Control Room 整合機制已設定為：如果 Control Room 服務因系統錯誤而中斷，或因其他任何原因停用，包括遭惡意行為者竄改，所有推論請求都會遭到拒絕，直到 Control Room 恢復正常運作為止。這項故障時拒絕存取的機制，目前已部署至所有前沿模型研究工作負載，並將在未來幾天內完成其餘所有研究工作負載的部署。
