GPT-2에서 gpt-oss까지: 아키텍처 발전 분석

ko생성일: 2025. 8. 11.갱신일: 2025. 8. 19.

OpenAI의 새로운 오픈 웨이트 LLM gpt-oss-20b와 gpt-oss-120b를 GPT-2 및 Qwen3와 비교하며, SwiGLU·MoE·GQA·슬라이딩 윈도우 어텐션·RMSNorm·MXFP4 등 핵심 설계 선택과 추론 특성, 성능 벤치마크를 정리합니다.

OpenAI가 이번 주에 새로운 오픈 웨이트 LLM을 공개했습니다. gpt-oss-120b와 gpt-oss-20b로, 2019년 GPT-2 이후 처음 공개된 오픈 웨이트 모델입니다. 그리고 몇 가지 영리한 최적화 덕분에 로컬에서도 실행이 가능합니다(이에 대해서는 뒤에서 더 자세히 다룹니다).

GPT-2 이후로 OpenAI가 대형의 완전한 오픈 웨이트 모델을 공유한 것은 이번이 처음입니다. 초기 GPT 계열은 트랜스포머 아키텍처가 스케일링된다는 점을 보여줬고, 2022년 ChatGPT는 글쓰기와 지식(나중에는 코딩) 작업에 즉각적인 유용성을 입증하며 이러한 모델을 대중화했습니다. 이제 오랜 기다림 끝에 웨이트 모델이 공개되었고, 아키텍처에는 흥미로운 요소들이 보입니다.

지난 며칠간 코드를 읽고 기술 보고서를 살펴보며 가장 흥미로운 세부 사항을 정리했습니다. (며칠 뒤 OpenAI는 GPT-5도 발표했는데, 이 글의 마지막 부분에서 gpt-oss와의 비교 맥락에서 간단히 언급합니다.)

아래는 글에서 다루는 내용을 간단히 미리 본 것입니다. 글 페이지 왼쪽의 목차를 이용하면 탐색이 더 쉬울 것입니다.

  • GPT-2와의 모델 아키텍처 비교
  • 단일 GPU에 gpt-oss 모델을 올리기 위한 MXFP4 최적화
  • 폭(width) 대 깊이(depth) 트레이드오프(gpt-oss vs Qwen3)
  • 어텐션 바이어스와 싱크(sinks)
  • 벤치마크와 GPT-5 비교

유익하게 읽으시길 바랍니다!

아키텍처를 자세히 논의하기 전에, 먼저 두 모델 gpt-oss-20b와 gpt-oss-120b를 그림 1로 개괄해 보겠습니다.

Image 1

그림 1: 두 가지 gpt-oss 모델을 나란히 비교.

최근 LLM 아키텍처 도식이나 이전의 제 글 Big Architecture Comparison을 보신 분이라면, 언뜻 보기에는 새로운 것이 없다고 느낄 수도 있습니다.

이것은 놀랍지 않습니다. 선도적인 LLM 개발자들은 대체로 동일한 기본 아키텍처를 사용하고, 그 위에 작은 개선을 더하는 경향이 있기 때문입니다. 어디까지나 제 추측이지만, 그 이유는 아마 다음과 같을 것입니다.

  • 연구소 간 인력 이동이 활발합니다.
  • 아직 트랜스포머를 능가하는 대안이 없습니다. 상태공간 모델이나 텍스트 확산 모델이 존재하긴 하지만, 제가 알기로는 이 스케일에서 트랜스포머만큼 잘 작동한다는 결과가 없습니다. (대부분의 비교는 벤치마크 점수에 초점을 둡니다. 실제 다중 턴 글쓰기나 코딩 작업을 얼마나 잘 처리하는지는 여전히 불분명합니다. 작성 시점 기준 LM Arena에서 순수 트랜스포머가 아닌 모델 중 가장 높은 순위는 트랜스포머–상태공간 하이브리드인 Jamba로 96위입니다. EDIT: 친절한 제보에 따르면 더 높은 순위의 하이브리드 모델 Hunyuan-TurboS가 22위에 있습니다.)
  • 대부분의 개선은 큰 아키텍처 변화보다는 데이터와 알고리즘의 미세 조정에서 나오는 듯합니다.

그럼에도 불구하고, 설계 선택에는 여전히 흥미로운 부분이 많습니다. 일부는 위 그림에 나타나 있고(나타나지 않은 부분은 뒤에서 논의), 나머지 글에서는 이러한 특징들을 하나씩 짚어 보며 다른 아키텍처와 비교하겠습니다.

또한 저는 OpenAI와 아무런 관련이 없습니다. 본문 정보는 공개된 모델 코드와 기술 보고서에서 얻었습니다. 로컬에서 이 모델들을 사용하는 방법을 배우고 싶다면, OpenAI의 공식 모델 허브 페이지부터 시작하시기 바랍니다.

20B 모델은 최대 16GB RAM의 소비자용 GPU에서 실행할 수 있습니다. 120B 모델은 80GB RAM의 H100 한 장 또는 그 이상의 하드웨어에서 단일 GPU로 실행할 수 있습니다. 몇 가지 중요한 주의점이 있으므로 뒤에서 다시 다루겠습니다.

이제 gpt-oss를 최신 아키텍처와 비교하기 전에, 시간 여행을 해보듯 GPT-2(그림 2)를 나란히 놓고 얼마나 멀리 왔는지 살펴봅시다.

Image 2

그림 2: gpt-oss-20b와 GPT-2 XL 1.5B의 나란한 비교.

gpt-oss와 GPT-2 모두 Attention Is All You Need (2017) 논문에서 소개된 트랜스포머 아키텍처를 기반으로 한 디코더 전용 LLM입니다. 수년 사이 많은 디테일이 발전했습니다.

다만, 이러한 변화는 gpt-oss만의 고유한 것은 아닙니다. 뒤에서 보겠지만, 많은 다른 LLM에서도 동일하게 나타납니다. 이전 글 Big Architecture Comparison에서 여러 측면을 다루었기 때문에, 여기서는 각 소절을 간결하게 정리합니다.

Dropout (2012)은 학습 중 층의 활성값이나 어텐션 점수의 일부를 무작위로 “드롭”(0으로 설정)하여 과적합을 방지하는 전통적인 기법입니다(그림 3). 하지만 현대 LLM에서는 드롭아웃을 거의 사용하지 않으며, GPT-2 이후 대부분의 모델이 드롭아웃을 제거했습니다(의도한 말장난 아님).

Image 3

그림 3: 어텐션 점수 행렬에 드롭아웃을 적용한 예시.

GPT-2에서 드롭아웃이 사용된 것은 원래 트랜스포머 아키텍처에서 가져왔기 때문이라고 추정합니다. 연구자들은 곧 LLM 성능 향상에는 크게 도움이 되지 않는다는 점을 관찰했을 가능성이 큽니다(소규모 GPT-2 재현 실험에서도 동일하게 관찰했습니다). 이는 LLM이 보통 방대한 데이터셋을 단 1에폭만 학습하기 때문일 것입니다. 드롭아웃이 처음 도입되었던 수백 에폭 학습 체제와 대조적입니다. 즉, LLM은 학습 중 각 토큰을 한 번만 보기 때문에 과적합 위험이 낮습니다.

흥미롭게도, LLM 아키텍처 설계에서 드롭아웃은 오랫동안 사실상 무시되어 왔는데, 최근 2025년 연구가 소규모 LLM(Pythia 1.4B) 실험을 통해 단일 에폭 체제에서는 드롭아웃이 다운스트림 성능을 오히려 떨어뜨린다는 점을 확인했습니다.

트랜스포머 기반 LLM에서는 어텐션 메커니즘 특성상 위치 인코딩이 필요합니다. 기본적으로 어텐션은 입력 토큰에 순서가 없다고 가정합니다. 원래 GPT 아키텍처에서는 절대적 위치 임베딩을 사용해 시퀀스의 각 위치마다 학습된 임베딩 벡터를 생성하고(그림 4), 이를 토큰 임베딩에 더해 위치 정보를 부여했습니다.

Image 4

그림 4: 절대적 위치 임베딩 개념도.

RoPE(Rotary Position Embedding)는 다른 접근을 제안했습니다. 위치 정보를 별도 임베딩으로 더하는 대신, 각 토큰의 위치에 따라 쿼리와 키 벡터를 회전시키며 위치를 인코딩합니다. (RoPE는 우아한 아이디어이지만 설명은 다소 까다롭습니다. 언젠가 별도로 자세히 다룰 계획입니다.)

RoPE는 2021년에 처음 소개되었지만, 2023년 Llama 공개와 함께 널리 채택되었고 현재는 현대 LLM의 표준이 되었습니다.

초기 GPT 아키텍처는 GELU를 사용했습니다. 지금은 왜 GELU 대신 Swish를 사용할까요? Swish가 계산적으로 약간 더 저렴하기 때문이고, 제 생각에는 그게 전부입니다. 논문에 따라 어느 쪽이 모델링 성능이 약간 더 낫다고 하기도 합니다. 하지만 이런 차이는 표준 오차 범위 내인 경우가 많고, 하이퍼파라미터 민감도에 따라 결과가 달라질 것입니다.

활성화 함수는 10여 년 전 딥러닝 커뮤니티가 ReLU에 대체로 합의하기 전까지는 뜨거운 논쟁거리였습니다. 이후 연구자들은 더 매끈한 곡선을 가진 다양한 ReLU 변형을 제안했고, 그 중 GELU와 Swish(그림 5)가 자리를 잡았습니다.

Image 5

그림 5: Swish와 GELU 활성화 비교. 둘 다 ReLU의 더 매끈한 변형.

초기 GPT 아키텍처에서 사용된 GELU는 0.5x * [1 + erf(x / sqrt(2))]로 정의됩니다. 여기서 erf(오차 함수)는 가우시안 적분의 근사 다항식으로 계산되며, Swish에서 사용하는 시그모이드 같은 단순 함수보다 계산 비용이 큽니다. Swish는 단순히 x * sigmoid(x)입니다.

실무적으로 Swish는 GELU보다 계산이 약간 더 저렴하며, 이것이 대부분의 최신 모델에서 GELU를 대체한 주된 이유일 것입니다. 논문에 따라 어느 쪽이 모델링 성능이 다소 우위라고도 하지만, 대개 표준 오차 범위 내이고 하이퍼파라미터 튜닝에 크게 좌우됩니다.

오늘날 대부분의 아키텍처는 Swish를 사용합니다. 다만 GELU가 완전히 잊힌 것은 아니고, 예를 들어 Google의 Gemma 모델은 여전히 GELU를 씁니다.

더 주목할 점은, 피드포워드 모듈(작은 다층 퍼셉트론)이 게이트드 "GLU"(gated linear unit) 변형으로 대체되었다는 것입니다. GLU는 2020년 논문에서 제안되었고, 구체적으로 2개의 완전연결 층을 3개의 완전연결 층으로 바꾸어 그림 6과 같이 사용합니다.

Image 6

그림 6: Swish와 GELU 및 그 게이트드 변형인 SwiGLU와 GEGLU 비교.

언뜻 보면 GEGLU/SwiGLU가 층이 하나 더 있어 파라미터 수가 늘어나므로 일반 피드포워드보다 더 좋을 것처럼 보입니다. 하지만 실제로는 SwiGLU/GEGLU의 WV 가중치 층을 전통적 피드포워드의 W_1 절반 크기로 두는 경우가 일반적이어서 그렇지 않습니다.

이를 더 잘 보여주기 위해, 일반형과 GLU 변형의 코드 구현을 비교해 보겠습니다.

Image 7

그림 7: 일반 피드포워드 모듈(위)과 SwiGLU 변형(아래)의 나란한 비교.

예를 들어 임베딩 차원이 1024라고 합시다. 일반 피드포워드의 경우:

  • fc1: 1024 × 4096 = 4,194,304
  • fc2: 1024 × 4096 = 4,194,304

즉, fc1 + fc2 = 8,388,608 파라미터입니다.

GLU 변형의 경우:

  • fc1: 1024 × 1024 = 1,048,576
  • fc2: 1024 × 1024 = 1,048,576
  • fc3: 1024 × 1024 = 1,048,576

즉, 3 × 1,048,576 = 3,145,728 가중치 파라미터입니다.

종합하면 GLU 변형을 사용하면 파라미터 수가 더 적으면서 성능은 더 좋습니다. 성능이 더 좋아지는 이유는 GLU 변형이 추가적인 곱셈적 상호작용을 제공하여 표현력이 증가하기 때문입니다(적절히 학습된다는 전제 하에 얕고 넓은 네트보다 깊고 슬림한 네트가 더 잘하는 것과 같은 이유).

앞 절에서 SwiGLU로 피드포워드를 업그레이드한다고 했는데, gpt-oss는 여기서 한 걸음 더 나아가 단일 피드포워드 모듈을 여러 개의 피드포워드 모듈로 대체하고, 각 토큰 생성 단계에서 그중 일부만 사용합니다. 이를 Mixture-of-Experts(MoE)라고 하며 그림 8과 같습니다.

Image 8

그림 8: 피드포워드 모듈을 전문가 혼합(MoE) 모듈로 교체.

즉, 단일 피드포워드 모듈을 여러 개로 바꾸면(=MoE 설정) 모델의 총 파라미터 수가 크게 증가합니다. 하지만 핵심은 모든 토큰에서 모든 전문가를 사용(“활성화”)하지 않는다는 점입니다. 대신 라우터가 토큰마다 소수의 전문가만 선택합니다.

일반적으로 MoE 모듈은 한 번에 일부 전문가만 활성화되므로 “스파스”라고 부르며, 항상 모든 파라미터를 사용하는 “덴스” 모듈과 대비됩니다. 다만 MoE를 통해 전체 파라미터 수를 크게 늘리면 LLM의 수용 용량(capacity)이 커져 학습 중 더 많은 지식을 담을 수 있습니다. 동시에 스파시티 덕분에 추론 시에는 모든 파라미터를 동시에 쓰지 않으므로 효율성을 유지합니다.

(재미있는 사실: 대부분의 MoE 모델에서 전문가 가중치가 전체 파라미터의 90% 이상을 차지합니다.)

앞선 글들에서 언급했듯, Grouped Query Attention(GQA)은 최근 MHA(멀티헤드 어텐션)에 비해 연산 및 파라미터 효율이 더 좋은 대안으로 자리 잡았습니다.

MHA에서는 각 헤드가 자체 키와 값 세트를 가집니다. GQA는 여러 헤드를 묶어 동일한 키/값 투영을 공유하게 해서 메모리 사용량을 줄입니다.

예컨대 그림 9처럼 키–값 그룹이 2개이고 어텐션 헤드가 4개라면, 헤드 1과 2는 하나의 키/값 세트를 공유하고, 헤드 3과 4는 다른 키/값 세트를 공유합니다. 이렇게 그룹화하면 키/값 계산의 총량이 줄어 메모리 사용량이 줄고 효율이 개선되며, 어블레이션 연구에 따르면 모델링 성능에는 눈에 띄는 영향이 없습니다.

Image 9

그림 9: MHA와 GQA 비교. 여기서는 그룹 크기가 2로, 키/값 한 쌍을 2개의 쿼리가 공유합니다.

GQA의 핵심 아이디어는 여러 쿼리 헤드가 키/값 헤드를 공유하게 해서 키/값 헤드 수를 줄이는 것입니다. 이는 (1) 모델 파라미터 수를 줄이고 (2) 추론 시 KV 캐시에 저장·조회해야 할 키/값 텐서의 메모리 대역폭 사용을 줄여 효율을 높입니다.

(GQA가 코드에서 어떻게 보이는지 궁금하다면, KV 캐시 없는 버전은 GPT-2 to Llama 3 conversion guide, KV 캐시 버전은 여기를 참고하세요.)

GQA는 주로 MHA의 계산 효율 우회책이지만, 원저 논문Llama 2 논문 등의 어블레이션에 따르면 LLM 모델링 성능은 표준 MHA와 유사합니다.

슬라이딩 윈도우 어텐션(그림 10)은 LongFormer(2020)에서 처음 제안되었고 이후 Mistral이 대중화했습니다. 흥미롭게도 gpt-oss는 격층(매 두 번째 층)마다 적용합니다. 멀티헤드 어텐션(혹은 여기서는 GQA)의 변형으로 볼 수 있으며, 주의를 둘 수 있는 컨텍스트를 작은 윈도우로 제한해 메모리와 연산 비용을 줄입니다.

Image 10

그림 10: 일반 어텐션(왼쪽)과 슬라이딩 윈도우 어텐션(오른쪽) 비교.

구체적으로 gpt-oss는 전체 컨텍스트에 주의하는 GQA 층과 128 토큰으로 제한된 슬라이딩 윈도우 GQA 층을 번갈아 사용합니다.

이전 글에서 언급했듯, Gemma 2 (2024)는 비슷한 1:1 비율을 사용했습니다. 올해 초 공개된 Gemma 3는 더 나아가 5:1 비율로 바꾸어, 로컬(윈도우) 어텐션 5층마다 전체 어텐션 1층만 두었습니다.

Gemma 어블레이션에 따르면, 슬라이딩 윈도우 어텐션은 모델링 성능에 미치는 영향이 미미합니다. Gemma 2의 윈도우 크기는 4096 토큰이었고, Gemma 3은 이를 1024로 줄였습니다. 이에 비해 gpt-oss의 윈도우는 단 128 토큰으로 상당히 작습니다.

그리고 재미있는 사실 하나, 공식 발표 글에 따르면 슬라이딩 윈도우 어텐션은 GPT-3에서도 이미 사용되었다고 합니다.

이 모델은 GPT-3와 유사하게, 조밀(dense) 어텐션과 국소(banded) 스파스 어텐션 패턴을 교대로 사용합니다.

실제로 GPT-3 원문을 다시 확인해 보면 다음과 같이 언급되어 있습니다.

우리는 GPT-2(RWC+19)와 동일한 모델과 아키텍처를 사용하되, 그 안의 수정된 초기화, 사전 정규화, 가역 토크나이제이션을 포함하고, 층마다 Sparse Transformer(CGRS19)와 유사하게 조밀 어텐션과 국소 밴드 스파스 어텐션을 교대로 사용합니다.

마지막으로 GPT-2에서 내려온 작은 트윅 하나는 LayerNorm (2016)RMSNorm (2019)으로 교체한 것입니다. 이는 최근의 일반적 추세입니다.

GELU를 Swish와 SwiGLU로 바꾼 것과 비슷하게, RMSNorm도 작지만 합리적인 효율 개선입니다. RMSNorm은 그림 11에서 보듯, 층 활성값을 정규화한다는 목적은 LayerNorm과 유사합니다.

얼마 전까지만 해도 이 목적에는 BatchNorm이 기본 선택이었지만, 배치 평균/분산 통계 때문에 병렬화가 어렵고 작은 배치에서 성능이 떨어져 선호되지 않게 되었습니다.

Image 11

그림 11: 작은 선형층에서의 LayerNorm(왼쪽)과 RMSNorm(오른쪽) 비교.

그림 11에서 보듯 두 방법 모두 층 출력을 적당한 범위로 스케일합니다.

LayerNorm은 평균을 빼고 표준편차로 나눠 층 출력의 평균을 0, 분산을 1(표준편차 1)로 맞춥니다.

RMSNorm은 제곱평균제곱근(root-mean-square)으로 입력을 나눕니다. 평균 0, 분산 1을 강제하진 않지만 평균과 분산을 적정 범위에 둡니다. 이 예에서는 평균이 0.77, 분산이 0.41입니다.

둘 다 활성 스케일을 안정화하고 최적화를 돕지만, RMSNorm은 계산이 더 저렴해 대규모 LLM에서 선호됩니다. LayerNorm과 달리 바이어스(시프트) 항이 없고, 평균과 분산을 각각 계산하는 대신 RMS 한 번만 계산하면 됩니다. 이는 피처 간 리덕션 수를 둘에서 하나로 줄여 GPU 통신 오버헤드를 낮추고 학습 효율을 높입니다.

그림 12는 코드에서의 차이를 보여줍니다.

Image 12

그림 12: LayerNorm과 RMSNorm의 코드 구현 비교. RMSNorm이 계산적으로 더 단순함을 볼 수 있습니다.

여전히 GPT-2는 LLM을 배울 때 훌륭한 입문 아키텍처라고 생각합니다. 최적화 트릭의 층층이 속에서 길을 잃지 않을 만큼 충분히 단순하면서도 현대 트랜스포머 모델의 작동 원리를 익히기에 충분히 복잡합니다.

GPT-2부터 시작하면 어텐션, 위치 임베딩, 정규화, 전체 학습 파이프라인 같은 기본에 집중할 수 있고, 최신 아키텍처의 추가 기능과 트윅에 압도되지 않습니다.

사실 최신 변화를 얹기 전에 GPT-2를 먼저 학습하고 구현해 보는 것이 시간을 들일 가치가 있다고 생각합니다. 그러면 최신 변화들을 더 쉽게 이해할 뿐 아니라, 그 변화들이 어떤 한계를 해결하려는지 더 잘 체감하게 될 것입니다.

예컨대 제 GPT-2 코드를 바탕으로 최근 Qwen3 아키텍처를 처음부터 구현했는데, gpt-oss와 매우 유사합니다. 이제 다음 주제로 넘어가 gpt-oss를 보다 최근 아키텍처와 비교해 보겠습니다.

GPT-2에서 GPT-OSS까지의 변화를 훑어봤으니, 이제 한 걸음 더 나아가 2025년 5월에 공개된 최신 아키텍처인 Qwen3와 gpt-oss를 비교해 보겠습니다.

Qwen3를 고른 이유는 작성 시점 기준 최상위 오픈 웨이트 모델 중 하나이기 때문입니다. 또한 Qwen3의 MoE 모델 중 하나는 학습 가능한 파라미터 수가 비교적 비슷하여 GPT OSS와 직접 비교가 가능합니다.

그림 13은 gpt-oss-20b와 크기가 비슷한 Qwen3 모델을 비교합니다.

Image 13

그림 13: 크기가 비슷한 gpt-oss와 Qwen3 모델의 나란한 비교.

보시다시피 gpt-oss 20B와 Qwen3 30B-A3B는 아키텍처 구성요소가 매우 유사합니다. 차이는 차원 설정 이외에는, 앞서 1.6절에서 말한 슬라이딩 윈도우 어텐션을 gpt-oss가 쓰고(그림에는 표시되지 않음) Qwen3는 쓰지 않는다는 점입니다.

다음 소절에서 주목할 만한 디테일을 하나씩 살펴보겠습니다.

두 모델을 자세히 보면, Qwen3는 트랜스포머 블록이 24개인 gpt-oss와 달리 48개로 훨씬 더 깊습니다(그림 14).

Image 14

그림 14: Qwen3는 gpt-oss-20b보다 트랜스포머 블록 수가 두 배.

반면 gpt-oss는 훨씬 더 넓은 아키텍처입니다.

  • 임베딩 차원: 2048 대신 2880
  • 전문가(피드포워드) 중간 프로젝션 차원: 768 대신 2880

또한 gpt-oss는 어텐션 헤드 수가 2배이지만, 이는 모델의 “폭”을 직접 늘리지는 않습니다. 폭은 임베딩 차원에 의해 결정됩니다.

고정된 파라미터 수에서 어느 접근이 더 유리할까요? 경험칙으로, 더 깊은 모델은 유연성이 크지만 폭주/소실 그래디언트로 인해 학습이 더 불안정할 수 있습니다(RMSNorm과 잔차(쇼트컷) 연결은 이를 완화하기 위함).

더 넓은 아키텍처는 메모리 비용이 증가하지만 병렬화가 좋아져 추론 시 토큰/초 처리량(throughput)이 더 빠른 장점이 있습니다.

모델링 성능 관점에서는, 파라미터 크기와 데이터셋을 동일하게 맞춘 엄밀한 사과-사과 비교는 제가 아는 한 거의 없습니다. 예외적으로 Gemma 2 논문(Table 9)의 어블레이션에서 9B 파라미터 모델에 대해 “넓은” 구성이 “깊은” 구성보다 소폭 우수했습니다. 4개 벤치마크 평균에서 넓은 모델은 52.0, 깊은 모델은 50.8이었습니다.

그림 14에서 보듯, gpt-oss는 놀랍게도 전문가 수가 128이 아닌 32개로 적고, 토큰당 활성 전문가도 8개가 아니라 4개만 씁니다. 다만 각 전문가는 Qwen3의 전문가보다 훨씬 큽니다.

흥미로운 점은 최근 트렌드는 더 많고 더 작은 전문가가 유리하다는 방향이라는 것입니다. 총 파라미터가 일정하다고 할 때 이러한 변화를 잘 보여주는 예시가 DeepSeekMoE 논문의 그림 15입니다.

Image 15

그림 15: “DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models”의 주석 추가 그림, https://arxiv.org/abs/2401.06066

참고로 DeepSeek의 모델과 달리 gpt-oss와 Qwen3 모두 공유 전문가(shared experts)를 사용하지 않습니다.

공정하게 보자면, gpt-oss의 전문가 수가 적은 것은 20B 모델 크기의 부작용일 수도 있습니다. 아래의 120B 모델을 보면 실제로 트랜스포머 블록 수와 전문가 수만 늘리고 나머지는 고정한 것을 볼 수 있습니다(그림 16).

Image 16

그림 16: 두 gpt-oss 아키텍처의 나란한 비교. 더 큰 120B 모델은 트랜스포머 블록 수와 전문가 수만 스케일링.

20B와 120B가 이렇게 닮은 이유에 대한 가장 단순한 설명은, 120B가 주력 모델이었고 더 작은 모델을 만들 때는 트랜스포머 블록을 줄이고(짧게 만들고) 전문가 수를 줄이는 게 쉬웠기 때문일 것입니다(대부분의 파라미터가 그쪽에 있으므로). 혹은 120B 학습 중 일부 블록과 전문가를 잘라낸 뒤 계속 프리트레이닝했을지도 모른다는 추측도 가능합니다(무작위 초기화로 새로 시작하는 대신).

어쨌든 트랜스포머 블록 수와 전문가 수만 스케일하는 것은 다소 이례적입니다. 예컨대 다양한 크기의 Qwen3 MoE 모델들을 보면(그림 17), 더 많은 측면에서 더 비례적으로 스케일되었습니다.

Image 17

그림 17: 다양한 Qwen3 모델의 아키텍처 차이.

gpt-oss와 Qwen3는 모두 GQA를 사용합니다. 주요한 차이는 gpt-oss가 앞서 언급했듯 매 두 번째 층에서 슬라이딩 윈도우 어텐션으로 컨텍스트를 제한한다는 점입니다.

다만 한 가지 흥미로운 디테일이 눈에 띄었습니다. gpt-oss는 어텐션 가중치에 바이어스 항을 사용하는 것으로 보입니다(아래 그림 참조).

Image 18

그림 18: gpt-oss 모델은 어텐션 층에 바이어스 항을 사용합니다. 코드 예시는 여기 참고.

GPT-2 이후로 바이어스 항은 잘 쓰이지 않았고, 흔히 불필요하다고 여겨집니다. 실제로 최근 논문은 적어도 키 변환(k_proj)에서는 수학적으로 불필요함을 보였고, 실험적으로도 바이어스 유무에 따른 차이가 매우 작음을 보였습니다(그림 19 참조).

또 하나 눈에 띄는 디테일은 그림 18 코드 스크린샷의 sinks 정의입니다. 일반적으로 어텐션 싱크(attention sinks)는 긴 컨텍스트에서 어텐션을 안정화하기 위해 시퀀스 시작부에 배치하는 “항상 주의 받는” 특수 토큰을 의미합니다. 즉, 컨텍스트가 매우 길어져도 시작부의 이 토큰에 대한 주의는 유지되어 전체 시퀀스에 관한 유용한 정보를 저장하도록 학습될 수 있습니다(원래는 Efficient Streaming Language Models with Attention Sinks에서 제안된 것으로 압니다).

하지만 gpt-oss 구현에서 어텐션 싱크는 입력 시퀀스의 실제 토큰이 아닙니다. 대신, 어텐션 점수에 추가되는 헤드별 학습 바이어스 로짓입니다(그림 20). 목적은 앞서 말한 어텐션 싱크와 같지만 토크나이즈된 입력을 바꾸지 않습니다.

Image 19

그림 20: gpt-oss에서의 어텐션 싱크 사용. Hugging Face 코드 기반 here.

마지막으로, Qwen3와 마찬가지로 gpt-oss 모델은 Apache 2.0 오픈소스 라이선스로 배포됩니다. 이는 제 오픈소스 프로젝트에도 선호하는 라이선스이기도 합니다. 즉, 이 모델을 다른 모델로 디스틸하거나 상업 제품에 제한 없이 사용할 수 있습니다.

오픈 웨이트 vs 오픈 소스 LLM. 이 구분은 수년간 논쟁되어 왔지만, 이번 공개와 관련 산출물을 혼동하지 않도록 명확히 하고자 합니다. 일부 개발사는 모델 웨이트와 추론 코드만 공개합니다(예: Llama, Gemma, gpt-oss). 다른 곳(예: OLMo)은 학습 코드, 데이터셋, 웨이트까지 모두 공개해 진정한 오픈소스로 배포합니다.

엄격한 정의에 따르면 gpt-oss는(그리고 Qwen3도) 학습 코드나 데이터셋 없이 웨이트와 추론 코드만 포함했으므로 “오픈 웨이트” 모델입니다. 다만 업계에서는 용어가 일관되게 쓰이지는 않습니다.

“gpt-oss”의 “oss”는 아마 “open source software”를 의미할 것입니다. 그럼에도 OpenAI가 공식 발표 글에서 gpt-oss를 분명히 오픈 웨이트 모델로 설명한 점은 긍정적으로 보입니다.

앞 절에서는 GPT-2 이후의 아키텍처 변화와 Qwen3(및 대부분의 최신 모델)와의 유사점을 다루었습니다. 이제까지 언급하지 않았지만 주목할 몇 가지 추가 사항이 더 있습니다. 앞선 섹션에 딱 맞게 넣기 어려웠지만 언급할 가치가 있는 내용입니다.

안타깝게도 학습 데이터셋 크기와 알고리즘에 관한 정보는 많지 않습니다. 모델 카드 보고서(1)와 발표 글(2)에서 얻은 흥미로운 단서들을 아래에 덧붙입니다.

gpt-oss 모델은 우리의 최신 프리트레이닝 및 포스트트레이닝 기법을 사용해 학습되었습니다 [...] (1)

[...] 완료까지 210만 H100-시간이 필요했으며, gpt-oss-20b는 그보다 약 10배 적게 필요했습니다. (1)

[...] 지도 미세조정 단계와 높은 연산량의 RL 단계 포함 [...] (2)

우리는 주로 영어 텍스트만으로 구성된 데이터셋에서, STEM, 코딩, 일반 지식에 중점을 두고 학습했습니다. (2)

따라서 gpt-oss 모델은 추론(reasoning) 모델임을 알 수 있습니다. 학습 연산량 210만 H100 GPU-시간은, 약 5.6배 더 큰 DeepSeek V3 모델의 278.8만 H800 GPU-시간과 대략 비슷한 수준입니다. 불행히도 Qwen3의 학습 시간 정보는 아직 없습니다.

흥미롭게도 GPT-oss의 시간 추정치는 지도식 지시 따르기 학습과 추론을 위한 강화학습(RL)을 모두 포함합니다. 반면 DeepSeek V3는 별도의 R1을 추가 학습하기 전의 프리트레인 베이스 모델입니다.

앞 절에서 언급했듯, gpt-oss 모델은 추론 모델입니다. 특히 흥미로운 점은 추론 단계에서 사용자가 추론 강도를 쉽게 제어할 수 있도록 학습되었다는 것입니다.

구체적으로 gpt-oss는 시스템 프롬프트에 “Reasoning effort: low/medium/high” 지시를 포함할 수 있고, 이는 응답 길이와 정확도에 직접적인 영향을 줍니다(그림 21).

Image 20

그림 21: 서로 다른 추론 강도에서의 gpt-oss 응답 길이와 품질(주석 추가: 모델 카드 발췌)

이 정도의 조절 가능성은 비용·연산·정확도의 균형을 잡는 데 유용합니다. 예를 들어 단순한 과제(사실 질문에 답하거나 작은 오탈자를 고치는 등)라면 확장된 추론을 건너뛸 수 있습니다. 이는 시간과 자원을 절약하고, 불필요하게 긴 응답과 장황한 추론 흔적을 피할 수 있게 합니다.

OpenAI가 Qwen3나 OLMo처럼 강화학습 기반 추론 학습 이전의 베이스 모델을 공개하지 않았다는 점은 다소 아쉽습니다. 베이스 모델은 추론 기법을 연구하는 연구자들에게 특히 가치 있는 출발점입니다(제가 현재 Qwen3 Base와 작업하기를 좋아하는 이유 중 하나). 아마 OpenAI의 결정은 연구보다는 산업·프로덕션 사용 사례를 더 고려한 결과일 것이라 추측합니다.

참고로 원래 Qwen3 모델도 토크나이저 설정에서 enable_thinking=True/False로 생각(추론) 모드를 켜고 끌 수 있었습니다(단순히 <think></think> 태그를 추가/제거하여 추론 동작을 비활성화). 하지만 Qwen3 팀은 최근 몇 주 사이 하이브리드 모델에서 벗어나 Instruct/Thinking/Coder 전용 변형으로 전환했습니다.

그 이유는 하이브리드 모드가 개별 모델 대비 성능이 낮았기 때문입니다.

커뮤니티와 논의하고 숙고한 끝에, 하이브리드 추론 모드를 포기하기로 했습니다. 이제 최고 품질을 위해 Instruct와 Thinking 모델을 별도로 학습합니다. Source

흥미로운 깜짝 요소 하나는 OpenAI가 gpt-oss 모델을 MoE 전문가에 대해 MXFP4 양자화 스킴으로 공개했다는 점입니다.

양자화 포맷은 한때 모바일·임베디드 AI에 국한된 주제였지만, 더 큰 모델로의 움직임과 함께 중요성이 커졌습니다. 여기서 MXFP4 최적화는 모델을 단일 GPU 장치에서 실행할 수 있게 만듭니다.

실제로는 다음과 같습니다.

  • 대형 모델(120B급)이 80GB H100 또는 그 이상의 단일 GPU에 올라갑니다. 소비자 하드웨어는 아니지만, 다중 H100 머신보다 1장의 H100 머신을 임대하는 것이 훨씬 저렴합니다. 또한 모델을 여러 GPU에 분산하고 통신 오버헤드를 추가할 필요가 없습니다. AMD MI300X 카드가 공개 1일 차부터 지원되는 것도 아주 반갑습니다!
  • 더 작은 20B 모델은 16GB VRAM에도 들어갑니다. 단, MXFP4를 지원하려면 RTX 50 시리즈 이상의 GPU여야 한다는 제약이 있습니다.

MXFP4를 지원하지 않는 구형 하드웨어에서도 모델은 실행되지만 메모리 사용량이 증가합니다. MXFP4 최적화 없이 bfloat16으로는 gpt-oss-20b가 약 48GB, gpt-oss-120b가 약 240GB를 사용합니다.

덧붙여, 저는 Mac Mini에서 ollama로 gpt-oss-20b를 무난히 돌릴 수 있었습니다. 메모리는 약 13.5GB 정도 사용해 꽤 합리적입니다.

모델이 아직 공개된 지 얼마 안 돼 독립 벤치마크는 많지 않습니다. LM Arena 리더보드를 확인해 보면 gpt-oss는 아직 등재되지 않았습니다. 그래서 현재로서는 Qwen3-Instruct가 사용자 평가 기준 최상위 오픈 웨이트 모델로 남아 있습니다(그림 22).

gpt-oss 발표 글의 추론 벤치마크를 보면, gpt-oss 모델은 OpenAI의 독점 모델 및 Qwen3와 동급임을 볼 수 있습니다(그림 23).

다만 gpt-oss-120b는 Qwen3 A235B-A22B-Thinking-2507 모델보다 거의 절반 크기이며 단일 GPU에서 실행된다는 점을 덧붙입니다.

한편 벤치마크 성능이 항상 실제 사용성을 반영하지는 않습니다. 지난 며칠간 제한적으로 사용해 본 결과, gpt-oss는 꽤 유능했습니다. 다만 다른 사람들이 지적했듯, 환각(hallucination) 경향이 비교적 높은 편으로 보입니다(모델 카드에도 언급).

이는 수학, 퍼즐, 코드 같은 추론 중심 작업에 학습 비중을 높인 탓에 “일반 지식의 망각”이 일부 발생했을 가능성이 있습니다. 그래도 gpt-oss는 도구 사용을 염두에 두고 설계되었기 때문에, 이 한계는 시간이 지나며 덜 중요해질 수 있습니다. 오픈소스 LLM의 도구 통합은 아직 초기 단계지만, 성숙해질수록 사실·지식 기반 질의에는 외부 소스(검색 엔진 등)를 참고하도록 모델을 점점 더 활용하게 될 것입니다.

그럴 경우 암기보다 추론 능력의 우선순위를 높이는 것이 합리적일 수 있습니다. 이는 학교(혹은 인생 전반)에서 문제 해결 능력이 단순한 사실 암기보다 중요할 때가 많은 것과 유사합니다.

OpenAI는 gpt-oss 직후 오랫동안 기다려온 GPT-5도 공개했습니다. GPT-5 공개는 흥미로웠습니다. 한 가지 말해야 한다면, 벤치마크 성능 기준으로 그들의 오픈소스(오픈 웨이트) 모델이 최고 성능의 상용 제품과 매우 근접하다는 점에 정말 놀랐습니다(그림 24).

종합하면, 어떤 이들은 이번 공개를 과대평가라고 했지만, 최고 수준의 독점 모델에 크게 뒤지지 않는 강력한 오픈 웨이트 모델 세트를 얻게 되어 기쁩니다. 물론 벤치마크가 실제 사용성을 정확히 반영하지 않는 경우가 많고, 사용해본 시간이 아직 짧아 판단하기 이릅니다. 그래도 오픈 웨이트와 로컬(혹은 프라이빗 호스팅) 모델로 작업하기 좋아하는 분들에게는 좋은 시기라 생각합니다.

이 매거진은 개인적인 열정 프로젝트이며, 여러분의 후원이 큰 힘이 됩니다. 기여를 원하신다면 아래의 방법들이 있습니다.

  • 제 책을 한 권 받아보세요. Build a Large Language Model (From Scratch)는 토크나이저부터 학습까지 LLM을 한 단계씩 구현하는 과정을 안내합니다.
  • 비디오 코스도 확인하세요. 책을 바탕으로 한 17시간 분량의 비디오 코스가 Manning에 있습니다. 책을 섹션별로 밀접하게 따라가며, 단독으로도, 코드-어롱 자료로도 잘 작동합니다. 유튜브와 달리 광고가 없고 더 깔끔하고 구조적인 형식입니다. 또한 Abhinav Kimothi가 제작한 5시간 분량의 사전 요구 사항 비디오도 포함되어 있습니다.
  • 구독하기. 유료 구독은 제 글쓰기를 지속 가능하게 돕고 추가 콘텐츠에 접근할 수 있게 합니다.

읽어주셔서 감사드리며, 독립 연구를 응원해 주셔서 고맙습니다!

Image 21