Diary - 2024 OpenAI dev day 참가 후기

26 Nov 2024

2023년 OpenAI dev day. 회사에서 참가시켜준다고 했지만 OpenAI 측에서 사람이 너무 많이 지원했다며 짤랐다. 올해에는 SF 이외에도 런던과 싱가폴에서도 개최되었고, 싱가폴에 포닥가있는 친구도 만날 겸 2024 OpenAI dev day 에 참석했다. 내돈내산으로 갔다와서 그런지 더 뜻깊은 경험이었던 것 같기도 해서 후기를 남겨본다.

Intro

2024 OpenAI dev day 는 Pan pacific hotel 에서 열렸다. 이렇게 생긴 곳이었는데, 싱가폴에는 특이하게 구멍을 뻥뻥 뚫어놓고 식물을 잔뜩 심어놓은 호텔이 많다.

11시에 호텔에 도착했는데 로비에서부터 OpenAI 직원분들이 반갑게 맞아주었다. 싱가폴에서 열린 dev day 는 OpenAI 싱가폴 유닛의 오픈 행사를 겸한다고 한다. We are hiring!! 이라고 했지만… 소문에 의하면 24시간 전화받는 박사출신만 데려간다고…

19층인가에서 행사가 열렸고, 들어가자마자 질문있으면 적어서 넣으라고 통이 준비되어 있었다. 질문은 따로 안적었지만 종이는 하나 챙겼다.

Demo booths

행사는 12시반에 시작되고, 11시~12시반까지는 데모 부스를 구경하거나 networking zone 에서 간단한 점심을 먹으면서 기다리는 시간이 있었다. 데모는 총 6가지로 비디오 생성 모델인 Sora, 이미지 생성 모델인 Dall-e, audio 모드의 gpt-4o 그리고 chatGPT API 관련 distillation, evaluation, reasoning and coding ability 그리고 realtime api 를 시연했다. chatGPT 관련된 부분들은 이후 speech 에서도 발표되는 내용들이었고, 궁금한 점들을 이것저것 물어봤다.

Sora

Sora 는 비디오 생성 모델로 https://openai.com/index/sora/ 에 가면 자세히 나와 있다. 실제 홈페이지에 올라온 영상들을 그냥 틀어주는 데모였다. 가서 이거 대체 모델 사이즈가 어떻게 되냐고 물어봤는데,

여기에 있는 영상마다 모델이 다 다르다. 사람 한명 나오는 간단한 영상들은 작은 모델을 쓴거고 군중들이 모여있는 도로 영상 이런 건 큰 모델을 쓴 거다.

라고 대답해줬다. 암튼 sora 는 API 로 풀리지도 않았고, 아주 자세히 들여다보면 디테일이 조금 무너지는 부분들이 있다. 아마도 체리픽 해서 홈페이지에 올려놓은 거 같고, API 공개 시점까지 더 발전시킬 계획이 아닐까 싶다.

Dall-e 와 audio 모드

이건 뭐…이제는 평범한 기술이 되어버린 것 같다. 그냥 간단한 이미지 생성과, gpt-4o 로 농담이랑 하이쿠 생성하는 데모였는데, 재밌는건 힘을 빡 줬다.

이렇게까지 만들 일인가?? ㅋㅋㅋ Joke 라는 버튼을 누르면 농담을 생성한다. 굳이…??

distillation and evaluation

Distillation 과 Evaluation 은 이번에 출시된 기능들이다. Distillation 의 경우 큰 모델을 이용해 작은 모델을 학습하는 기능으로 prompt 로만 구성된 데이터로 학습이 가능하다는 장점이 있다. Evaluation 의 경우 fine-tune 된 모델의 성능 파악을 위한 데이터셋을 업로드하고 metric 을 선택하거나 직접 작성하면, 평가까지 해주는 기능이다.
사실 이거 LLM 지식이 좀 있으면 굳이 없어도 되는 기능이다. fine-tune API 만 있어도 충분하니까. 다만 진짜로 노코드로 학습 및 평가까지 가능하게 만들어 준 것이다. 특히나 Evaluation 쪽은 UX 가 상당히 좋다. 사내 LLM 평가 페이지 업데이트 할 때 많이 참고해야겠다는 생각이 든다.
Distillation 의 경우에도 직접 할 수 있지만, gpt-4o 로 답변 다 생성하고 다시 데이터셋 만들어서 fine-tune API 에 넣는 수고로움을 줄여준다. 그리고 제일 좋은 기능이라고 생각된 건, API 호출 history 데이터를 사용해서 distillaiton 을 수행할 수 있다! 내가 만약 openAI API 를 활용한 application 을 만들었다면, 로그데이터를 따로 모으고 하는 작업 없이도, openAI 서버에 호출 기록을 저장하고 바로 fine-tuning 까지 클릭 몇 번으로 가능하게 해줬다.

real-time API

gpt-4o 는 audio token 베이스로 input, output 을 처리한다고 한다 (추측은 하고 있었지만 사실로 확인함!!) 데모는 https://github.com/openai/openai-realtime-console 요 녀석을 그대로 사용했다.
Audio token 을 사용한다고 했을 때 제일 의아한 점이 output 에 글이 같이 나온다는 건데, real-time API 에는 audio only 모드와 audio-text output 모드가 따로 있다. audio 토큰 1개가 약 500 ms 정도 된다고 하고, 초당 토큰 생성 속도가 그거보다 훨씬 빠르다보니까 buffer 에 audio 토큰이 계속 쌓인다. 그러니까 text 토큰과 번갈아가며 생성하는 것도 가능하지 않을까 싶었다.

실제로 데모를 보면, 소리 생성보다 text 로 출력되는게 더 먼저 나온다. audio 토큰들이 버퍼에 쌓여있는 동안 text 는 그냥 streaming 되어 버려서 그런 것이다. 중간에 interupt 할 수 있는게 되게 신기했었는데, 이부분은 그냥 threshold 처리를 통해서 하는거였다. input 쪽에서도 buffer 에 audio 를 쌓다가 threshold 넘으면 출력을 중단하고 buffer 에 있는 데이터를 밀어넣는 방식이다.

Reasoning

o1-preview 부터 엄청나게 개선된 reasoning 능력은 coding 에서 상당한 두각을 나타낸다. 데모도 간단한 snake 게임을 prompting 만으로 만들어내는 거였는데, 사실 재미없어보이는 게임이어서 약간 아쉬웠다.
o1-preview 와 CoT 의 차이가 뭐라고 생각하냐고 질문했는데, consistency 에 있다고 답변한게 흥미로웠다. CoT 의 경우 step by step 으로 이유와 최종 답변을 생성하는데 consistency 를 유지한다. 하지만 o1-preview 는 답변을 한 번 낸 이후에도 그게 틀렸었다는걸 인정하고 수정한다고 한다. 쉬운 문제는 한번에 답변을 알아낼 수 있지만 어려운 건 계속 틀리고 수정하면서 나아가는게 인간이 문제를 푸는 방법이지 않나? Consistency 라는 한 단어로 차이를 설명하다니, 좋은 인사이트를 얻었다.

Speech sessions

12시 반부터 kick-off 와 함께 본행사가 시작되었다. 킥오프 이후에 총 3가지 기능에 대해서 30분씩 소개하는 세션이 진행되었다.

Kick-off

간단한 인사말과 함께 데모로 시작했는데, 데모가 미쳤다… 키보드로 드론을 날릴 수 있는 코드를 짜달라고 프롬프팅했고, 진짜 세션장에서 날렸다!!

임팩트를 주는 방법을 잘 안다는 생각이 들었다. 물론 DJI 드론 날려본사람은 알겠지만 드라이버가 상당히 잘되어 있어서 코드가 어렵지는 않다. 그래도 그 함성을 이끌어내기엔 충분했다.

그리고 gpt-4o 의 버전 업데이트 (gpt-4o-1120) 도 알렸다. 거의 3개월 단위로 업데이트가 되는데, 3개월 주기의 의미가 무엇일까 궁금하다. 아무튼 chat arena 에서 다시 1위를 차지했다고 한다.

Structured output

https://platform.openai.com/docs/guides/structured-outputs
Agent 개발이 중요해지면서 LLM 으로 자연어 output 보다는 API 실행이 가능한 json 타입의 output 을 받아야하는 일이 많아지고 있다. openai API 는 json mode 라는것을 지원하는데, 답변을 무조건 json 형태로 강제한다.
이 경우 hallucination 이 발생하면 문제가 되는데, 예를 들어 num 필드에 숫자만 들어가야 하는데, 문자열이 들어간 채로 output 을 뱉는다던가 하면 해당 API 를 활용하는 application 단에서 예외처리를 다 해줘야 한다. 이를 해결하기 위해 structed output strict mode 를 소개했다.

아래와 같은 tool 을 사용해 gpt API 를 호출한다고 하자.

{
    "name": "get_weather",
    "description": "Fetches the weather in the given location",
    "strict": true,
    "parameters": {
        "type": "object",
        "properties": {
            "location": {
                "type": "string",
                "description": "The location to get the weather for"
            },
            "unit": {
                "type": "string",
                "description": "The unit to return the temperature in",
                "enum": ["F", "C"]
            }
        },
        "additionalProperties": false,
        "required": ["location", "unit"]
    }
}

이 때 strict = true 를 넣어주면 location 은 string 으로, unit 은 “F” 나 “C” 중 하나로 채워진다.

대체 이게 어떻게 가능하냐 하면 mask decoding 전략을 쓰기 때문이라고 한다. 예를 들자면 "unit": 이라는 토큰 뒤에 나올 토큰은 반드시 F 혹은 C 여야 하니까, 두 토큰 중에서만 다음 토큰을 sampling 하겠다는 것이다.
마찬가지로 F 혹은 C 이후의 토큰은 },}\t,}\n 등이 될 수 있다. 자세한 건 설명해 주지 않았지만, 여기까지 들었을 때에는 상당히 hueristic 하게 접근했을 것이라는 생각이 든다. 지원하는 포맷 타입은 String, Number, Boolean, Integer, Object, Array, Enum, anyOf 만 가능하다.

이 기능을 개발하면서 리서치적으로 문제가 하나 발생했었는데, mask decoding 을 할 때 \t,\n 과 같은 토큰들은 항상 포함되다 보니까, 얘네가 무한히 나오는 현상이 있었다고 한다. LLM 필드에서도 반복 현상은 자주 발생하는데, 보통 이런 문제는 underfitting 이 문제라서 epoch 을 늘리거나 데이터를 늘려주면 자연스레 해결된다. 혹은 모델이 너무 작을 때도 발생하는데, gpt는 그럴일은 없겠지…

Distillation

아쉽게도 distillation 방법론에 대한 리서치적인 이야기는 나오지 않았다. OpenAI 내에서 distillation 방식으로 alignment tuning 이 이뤄지는지가 궁금한데…아쉽아쉽…
Distillation 쪽은 요새 speculative decoding 같이 inference 최적화에도 많이 사용되고, 상용 서비스에 작은 모델을 내보내기 위해서 많이 사용된다.

이 distillation API를 활용한 application 에 적용하면 좋은 상황들에 대한 언급이 있었다.

결국 knowledge 나 reasoning 능력은 distillation 했을 때 크게 감소될 수 밖에 없으나, 감정 분석이나 키워드 추출 등의 간단하면서도 제한적인 상황에 대해서는 비용절감에 큰 역할을 할 수 있다는 것이다. (당연한 얘기긴 함) 또 재미있는 이야기는 1K 정도 데이터에서 distillation 성능이 가장 높았고, 오히려 1M 데이터를 넣었을 때에는 성능이 떨어질 가능성도 높다는 언급이었다. 이 발언에서 미루어봤을 떄 특정 도메인의 데이터를 너무 많이 넣으면 전반적인 성능이 떨어질 수 있는 forgetting 이 많이 발생한다는 것이고, gpt-4o-mini 의 모델 사이즈가 8B ~ 60B 사이로 추정되고 있는 만큼, 해당 사이즈의 모델 SFT 단계에서 추가적인 학습이 가능한 room 은 1K 정도 데이터라고 짐작할 수 있겠다. 결국 distillation 기능의 시사점은 application 개발자들이 클릭 몇 번 만으로 gpt-4o 에 육박하면서 비용은 gpt-4o-mini 인 모델을 만들어 낼 수 있다는 점에 있다. 가격이 무려 1/16이니까. 하지만 어떤 방식으로 distillation 이 일어나는지 알 수가 없기 때문에, 다양한 기법을 적용해보는데에는 무리가 있다.

Realtime API

Realtime API 은 기존 STT -> LLM -> TTS 의 audio input/audio output 파이프라인을 처리하기 위해서 audio input / audio output 이 가능한 LLM (gpt-4o) 을 만들면서 나온 기능이다. 기존 방법론의 가장 큰 문제는 LLM 은 STT 가 끝날 때 까지 기다려야 하는 것, TTS 는 LLM 의 output 이 나올 때까지 기다려야 하는 것에 있었다. 여기서 latency 가 적어도 1초 이상 발생했고, 음성 대화형 챗봇 등에서 사용자 경험을 악화시켰다. 인공지능 스피커에게 뭔가 업무를 지시할 수는 있어도 자연스러운 대화는 불가능했던 이유다.

그러나 gpt-4o 에서 audio token 이 사용가능해지면서 latency 가 거의 0으로 수렴했다. gpt-4o 의 throughput 은 약 109 tokens/second 로 하나의 첫 번째 audio token 이 나올 때 까지 빠르면 10ms 정도가 소요된다는 것이다. 우리가 보통 100ms 이내로 들어오면 realtime 이라고 부르고 사람이 latency 를 크게 느끼지 못한다고 보니까, 진짜 realtime 음성 대화가 가능한 API 가 된 것이다.

Dev day 에서는 이 API 를 활용해서 망고타르트를 직접 주문하는 데모를 선보였다. API 에게 타르트집에 전화를 걸어서 여기로 몇시 몇분까지 배달시켜 달라고 prompt 를 입력했다. 이 때 타르트집에 전화를 거는 tool 도 함께 입력해준다 (아래처럼 작성했는데, 정확히 저런형태는 아니었고, 기억으로 복기한 것)

"tools": [
    {
        "name": "call",
        "description": "Make a call",
        "parameters": {
        "type": "object",
        "properties": {
            "number": {
            "type": "string",
            "description": "Number of target phone",
            }
        },
        "required": ["number"]
        }
    }
]

그러니까 바로 전화를 걸었고, 무대에 나와있는 타르트집 주인아저씨 휴대폰으로 전화가 왔다. 그리고 실시간 대화를 하기 시작했는데, prompt 에 적혀있는 배달 위치, 시간, 개수, 예산 한도 기반으로 타르트집 주인아저씨와 약 10턴의 대화를 거쳐서 결국 주문을 완료했다.

이걸 보면서 첫번째로 들었던 생각은 음성사서함 대신에 realtime API 를 활용해서 나 대신 전화받는 봇을 만들 수 있겠구나. 두 번째 생각은 보이스피싱의 자동화가 가능하겠구나…(최악인데) 아무튼 이 API 는 가능성이 꽤 무궁무진해 보였다. 그리고 단순 챗봇이 아닌 reasoning 기능이 강화된 gpt-4o-realtime-preview API 도 제공된다. (어디에 쓰일지는 고민해봐야겠지만)

가격이 좀 문제인데, output token 은 거의 분당 24센트 정도라고 한다. input token 과 합치면 분당 거의 40센트, 즉 500원 정도라는 것이다. 대규모 유저 서비스로 내보내기에는 꽤나 가격이 있다고 생각이 든다. 텍스트랑 다르게 음성은 그냥 계속 대화가 이어질수도 있으니까? 제한적으로 잘 사용해야겠다.

Firechat

OpenAI 의 SVP 인 Mark Chen 의 대담 세션이 있었다. 작년 SF 는 샘알트만이어서 기대했는데 아쉽아쉽. 20분 정도 사회자와 질의 응답이 있었고, 라이브 질문은 따로 받지 않았다. 인상깊었던 질문과 답변들을 정리해봤다.

Q1. AGI 가 언제쯤 어떤 형태로 나올 거라고 생각하는가?

A1. 처음 OpenAI 가 chatGPT 를 내놨을 때 수학문제를 풀면 AGI 가 될거라고 사람들은 말했다. gpt-4 가 수학문제를 풀기 시작하자 phD 급의 문제를 풀면 AGI 라고 말했다. o1-priview 가 phD 급의 문제를 풀기 시작하자 o1-preview 가 풀지 못하는 도메인들을 가져오면서 이걸 풀면 AGI 라고 말한다. 모델이 발전하고 시대가 바뀌면서 AGI 에 대한 정의와 기준은 계속 바뀐다. 우리는 이 iterative 한 과정들을 계속 반복할 것이고, 모든 benchmark 를 차례로 정복하다보면 언젠간 AGI 시대가 올 수 있다고 생각한다.

Q2. o1 의 아이디어를 어떻게 떠올리게 되었는가?

A2. 2년전에 agi 로써 부족한게 뭘까 생각을 했다. (2년이나 전에…?? 놀랍네요) 사람이 gpt-4 와 같은 방식으로 생각하나 고민했을 때 아니라고 생각했다. 결국 생각하고 틀리고 바로잡고 다시 정답을 내놓는 과정들을 반복해야 할거라 생각했고, 해당 데이터를 수집하고 학습하는 과정을 거쳐 결과물을 내놓을 수 있었다.

Q3. OpenAI 에서 리서치를 할 때 가장 중요한 점이 무엇인가?

A3. 사실 moon shot 과 같이 세상에 없었던 것을 새롭게 만들어내는 프로젝트를 할때 리서처들을 지켜주는게 중요하다. 적어도 3~4개월간 프로젝트를 진행하면서 무의미하다고 느껴지는 결과물들이 계속 나올 것이고, 어떠한 발전도 없는 채로 자금이 계속 쓰일 것이다. 그럼에도 불구하고 프로젝트에 대한 사람들의 excitement level 을 조직 내에서 계속 유지하는 것이다. 그러다 보면 갑자기 누군가 엄청난 breakthrough 를 찾아낸다. 계속 믿고 기다리는 환경을 만들어 주어야만 한다.

Q4. o1 의 등장으로 사람의 코딩 능력이 크게 중요하지 않을텐데 어떻게 생각하나?

A4. 코딩이 중요하지않다? 잘 모르겠다. 당연한 이야기겠지만 더 깊이 이해한 사람이 더 잘쓴다. 물론 o1의 등장으로 코딩의 난이도가 많이 내려갈 것이고, 생산성은 더욱 올라갈 것이다. 이러한 툴들을 이용해서 생산성을 더욱 끌어올리는 방향으로 코딩 공부를 해야하지 않을까.

Q5. OpenAI 의 가장 큰 장점이 뭐라고 생각하는가?

A5. 많은 사람들이 OpenAI는 기술 중심적이라고 생각할텐데, 사실은 굉장히 인간적인 곳이라고 생각한다. OpenAI는 excitement 로 굴러간다. 모두가 deeply excited되어있기 때문에 어떤 breakthrough를 만들어낼 수 있는 것이라 생각한다. 모든 사람들이 너무나 열정적이고 신나있다는 것이 가장 큰 장점이다.

Reception

모든 행사가 마무리되고 다함께 reception 장으로 이동했다. 위치는 마리나베이 전망대에 위치한 LAVO!! 역시 OpenAI 부자회사라는 생각이 들었다. 뷔페 형식의 음식과 무제한 주류를 제공해서 주변 사람들과 함께 네트워킹하는 시간을 가졌다.

약간 아쉬웠던 점은 OpenAI 관계자들과 이야기 나누기가 조금 어려웠던 점? 뭔가 OpenAI 사람들끼리 뭉쳐서 이야기를 하고 있는 바람에 더 많은 이야기를 나누기는 어려웠다. (사실 그래도 가서 얘기할 수 있긴 했겠지만)
운 좋게도 중간에 Distillation 세션 연사였던 Jillian Khoo 와 잠시 만나서 이런저런 이야기도 하고 앞으로 미래가 어떻게 될지에 대해서도 떠들어보긴 했다. LLM의 기술적인 내용에 대해서 딥하게 물어볼 수는 없었지만 (distillation API 쪽 application 담당하시는 분이었다) 앞으로 agent와 관련된 기능들을 눈여겨보고 있다는 것, OpenAI 싱가폴 유닛이 오늘 오픈했고 채용중이라는 사실 등이 기억이 난다.

Conclusion

되게 재밌는 경험이었고 견문을 넓힐 수 있었던 기회였다. 물론 AI researcher 보다는 OpenAI 의 API 나 제품들을 활용해 application 화 하는 사람들을 위한 행사였지만, LLM 필드의 선두주자가 어떤 생각을 하고 있는지 간접적으로 알아볼 수 있는 자리였던 것 같다. 언젠가는 OpenAI 를 따라잡을 수 있도록! 열심히 노력해보자.

Jae-Kyung Cho LLM Developers who was a Robotics engineer