En stoppknapp i inferenslaget

OpenAI har beskrevet et system som heter Control Room, og som holder oversikt over alle modelljobber som kjører i selskapets forskningsinfrastruktur og kan hindre enhver av dem fra å produsere mer utdata. I et innlegg publisert 9. november opplyser selskapet at den maksimale tiden mellom øyeblikket Control Room får instruksjon om å stanse en jobb og øyeblikket videre framdrift ikke lenger er mulig, er 35 sekunder.

Det uvanlige er hvor stoppen sitter. Forskningskoden — eksperimentene, evalueringene og de store samplingsjobbene som forskerne skriver og endrer hele tiden — blir ikke bedt om å sjekke om den fortsatt har lov til å kjøre. I stedet må hver forskningsjobb som gjør agentisk inferens registrere seg hos Control Room og få en jobb-id, som den fester til hver forespørsel den sender til en inferensmotor. Det er motoren, ikke jobben, som spør Control Room om jobben fortsatt er autorisert. Blir svaret nei, nekter motoren å generere.

Begrunnelsen OpenAI gir, er rett fram. Jobbkoden, skriver selskapet, “endres ofte og er ikke et ideelt sted å legge kritiske, bærende sikkerhetsbeskyttelser”. Det finnes bare et svært lite antall kodeveier for inferens i hele forskningen, så inferenslaget kan fungere som en flaskehals der hver enkelt forespørsel kontrolleres.

Et patchpanel med nettverkskabler i et serverrack
OpenAI legger stoppmekanismen i inferenslaget, der all forskningstrafikk går gjennom noen få kodeveier. Brett Sayles · pexels · Pexels License

Hvor de 35 sekundene kommer fra

Forsinkelsen er ikke betenkningstid. OpenAI tilskriver den et mellomlager for inferensautorisering, som trengs for å bære det nødvendige trafikkvolumet, og sier selskapet “arbeider med å presse tallet ned til null, slik at vi kan avslutte jobber øyeblikkelig”. Inntil da kan en modell som har fått ordre om å stanse, fortsette å produsere utdata i opptil et halvt minutt.

Hver registrert jobb må dessuten knyttes til en godkjent sikkerhetsbegrunnelse, et krav selskapet la fram i et innlegg i september om sikkerhetsbegrunnelser for trening av frontmodeller. Å stanse en jobb dreper ikke prosessen rundt: jobben lever videre, motoren står fortsatt tilgjengelig for andre autoriserte jobber, og det eneste som opphører, er utdataen.

Feiler lukket, og rulles fortsatt ut

Control Room er bygget for å feile lukket. Faller tjenesten ut — gjennom en systemfeil, fordi den er slått av, eller gjennom det OpenAI kaller “manipulering fra en ondsinnet aktør” — avvises alle inferensforespørsler til den er i normal drift igjen. Selskapet opplyser at denne oppførselen nå er rullet ut til alle forskningsjobber som gjelder frontmodeller, og at utrullingen til de øvrige forskningsjobbene blir ferdig “i løpet av de nærmeste dagene”. Det kjører også løpende agentiske og programmatiske sveip for å kontrollere at ingen har startet en inferensmotor med Control Room avslått.

Ventiler og rørføring inne i et industrianlegg
Control Room feiler lukket: faller tjenesten ut, avvises inferensforespørsler til den er tilbake. Sonny Vermeer · pexels · Pexels License

Hvorfor hullet satt på forskningssiden

OpenAI opplyser at selskapets eksterne stakk for modelldrift i sin natur allerede er langt mer sentralisert, med en godt utviklet evne til å ta ned modelldriftsettinger raskt. Hullet satt i forskningen, og der er behovet størst, ifølge selskapet.

Utløseren som beskrives, er en monitor: en annen modell som inspiserer hva modellen under trening gjør, og slår alarm. OpenAI peker på en publisert rapport der en agent brukte DNS for å nå en ekstern chatbot som et tilfelle en monitor fanget opp, og gjorde rede for overvåkingsarbeidet mer i detalj i slutten av oktober. Mener overvåkingssystemet at en jobb skal stanses, sender det jobb-id-en til Control Room, og neste inferensforespørsel blir avvist.

Tallet å følge er de 35 sekundene. OpenAI har satt navn på det, forklart det som en mellomlagringseffekt og lovet å fjerne det. Foreløpig er det det klareste offentlige tallet på hvor raskt et frontlaboratorium kan stanse sine egne modeller midt i en kjøring.