| {{{#!wiki style="margin:-0px -10px -5px" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin:-5px -1px -11px; word-break:keep-all" | OpenAI | GPT (1 · 2 · 3 · 4.x · 5.x · 6개발 중) GPT-OSS (20B · 120B) OpenAI (o1 · o3 · o4) |
| 구글 | Gemini (1 · 1.5 · 2 · 2.5 · 3 · 3.1 · 3.5) Gemma · LaMDA · PaLM 2 | |
| Anthropic | Claude (Fable · Opus · Sonnet · Haiku) | |
| xAI | Grok | |
| 메타 | LLaMA · Muse Spark | |
| 기타 | }}}}}}}}} |
| OpenELM Open Efficient Language Models | |
| <colbgcolor=#101719,#101719><colcolor=#b7d8cc,#b7d8cc> 개발 | Apple |
| 기능 | 언어 모델 |
| 공개 | 2024년 4월 |
| 라이선스 | 오픈 소스 소프트웨어[1] |
| 링크 | |
1. 개요
Apple의 머신러닝 연구팀이 개발하여 2024년 4월 22일 공개한 오픈 소스 소형 언어 모델. OpenELM은 Open Efficient Language Models의 약자다.OpenELM 연구는 모델의 크기를 줄이는 것뿐만 아니라, 공개된 데이터와 학습 설정을 이용해 연구 결과를 재현할 수 있도록 하는 것을 주요 목적으로 삼았다. Apple은 모델 가중치와 추론 코드 외에도 데이터 준비, 사전 학습, 명령어 미세 조정, 평가에 사용된 CoreNet 기반 코드와 학습 설정, 중간 체크포인트, 학습 로그 및 MLX 변환 코드를 함께 공개했다.[2]
관련 논문인 《OpenELM: An Efficient Language Model Family with Open Training and Inference Framework》는 ICML 2024의 Efficient Systems for Foundation Models 워크숍에 채택됐다.
2. 종류
OpenELM은 실제 파라미터 수에 따라 270M, 450M, 1.1B, 3B의 네 가지 규모로 구성된다. 각 규모마다 사전 학습만 수행한 기본 모델과 사용자의 지시를 따르도록 추가 조정한 Instruct 모델이 제공되므로, 공개된 모델은 모두 8종이다.[3]모델 이름의 M과 B는 각각 백만과 십억을 의미한다. 다만 이름은 파라미터 수를 반올림한 값이므로 OpenELM-1_1B의 실제 파라미터 수는 약 10억 8천만 개, OpenELM-3B는 약 30억 4천만 개다. 1_1B는 저장소와 파일 이름에서 소수점 대신 밑줄을 사용한 표기다.
2.1. 공통 구조
네 가지 OpenELM 모델은 모두 다음 토큰을 예측하는 자기회귀형 decoder-only Transformer다. 입력 토큰은 32,000개 어휘를 가진 LLaMA 계열 토크나이저로 변환되며, 각 Transformer 블록은 인과적 자기어텐션과 피드 포워드 네트워크로 구성된다.| <rowcolor=#f5f5f7> 계열 | 실제 파라미터 | 레이어 수 | [math(d_{\text{model}})] | head 차원 | Query head | Key·Value head |
| 270M | 약 2억 7천만 | 16 | 1,280 | 64 | 12 → 20 | 3 → 5 |
| 450M | 약 4억 5천만 | 20 | 1,536 | 64 | 12 → 24 | 3 → 6 |
| 1.1B | 약 10억 8천만 | 28 | 2,048 | 64 | 16 → 32 | 4 → 8 |
| 3B | 약 30억 4천만 | 36 | 3,072 | 128 | 12 → 24 | 3 → 6 |
위 표의 Query head와 Key·Value head 범위는 첫 번째 레이어에서 마지막 레이어까지 증가하는 실제 설정을 나타낸다.[4]
OpenELM의 핵심은 모든 레이어에 동일한 수의 파라미터를 배치하지 않는 layer-wise scaling이다. 이 발상은 Apple 연구진이 앞서 발표한 DeLighT의 block-wise scaling에서 영향을 받았다. DeLighT는 입력에 가까운 블록을 상대적으로 얕고 좁게, 출력에 가까운 블록을 더 깊고 넓게 구성해 파라미터를 비균일하게 배분했다.[5]
전체 레이어 수를 [math(N)], 현재 레이어의 인덱스를 [math(i)]라 하면 OpenELM은 레이어별 어텐션 스케일 [math(\alpha_i)]와 피드 포워드 스케일 [math(\beta_i)]를 다음과 같이 선형적으로 변화시킨다.
[math(\displaystyle \alpha_i=\alpha_{\min}+\frac{i}{N-1}(\alpha_{\max}-\alpha_{\min}))]
[math(\displaystyle \beta_i=\beta_{\min}+\frac{i}{N-1}(\beta_{\max}-\beta_{\min}))]
논문에서 어텐션 스케일은 [math(\alpha_{\min}=0.5)]에서 [math(\alpha_{\max}=1.0)]까지, 피드 포워드 스케일은 [math(\beta_{\min}=0.5)]에서 [math(\beta_{\max}=4.0)]까지 증가한다. 레이어 [math(i)]의 Query head 수와 피드 포워드 중간 차원은 개념적으로 다음과 같이 결정된다.
[math(\displaystyle n_h^{(i)}=\frac{\alpha_i d_{\text{model}}}{d_h})]
[math(\displaystyle d_{\text{FFN}}^{(i)}=\beta_i d_{\text{model}})]
여기서 [math(d_h)]는 어텐션 head 하나의 차원이다. 실제 구현에서는 Grouped Query Attention의 그룹 수와 하드웨어 정렬 조건에 맞도록 head 수와 피드 포워드 차원이 이산적인 값으로 조정된다.
주의할 점은 각 모델 내부의 [math(d_{\text{model}})]은 모든 레이어에서 일정하다는 것이다. 레이어가 깊어질수록 토큰 표현 자체의 잔차 스트림 차원이 1,280에서 더 큰 값으로 계속 변하는 것이 아니라, 고정된 잔차 스트림에서 어텐션 투영이 사용하는 Query head 수와 SwiGLU 피드 포워드 네트워크의 중간 차원이 증가한다. 어텐션과 피드 포워드의 출력은 다시 고정된 [math(d_{\text{model}})] 차원으로 투영돼 다음 레이어로 전달된다.
OpenELM은 이와 함께 다음 구조를 사용한다.
- Pre-norm RMSNorm: 어텐션과 피드 포워드 연산 전에 입력을 정규화한다. RMSNorm은 LayerNorm의 평균 제거 과정을 생략하고 입력의 제곱평균제곱근으로 크기를 정규화한다.[6]
- RoPE: Query와 Key 벡터에 위치에 따른 회전을 적용해 절대 위치와 상대적인 토큰 거리 정보를 어텐션 내적에 반영한다.[7]
- Grouped Query Attention: 여러 Query head가 하나의 Key head와 Value head를 공유한다. OpenELM에서는 Query head 네 개당 Key·Value head 한 쌍을 사용한다. 따라서 같은 수의 Query head를 모두 독립적인 Key·Value head와 연결하는 Multi-Head Attention보다 KV cache에 저장해야 할 head 수가 감소한다.[8]
- SwiGLU: 피드 포워드 네트워크에서 Swish 계열 활성화 함수와 게이트를 결합한다. 일반적인 ReLU 또는 GELU 피드 포워드층과 달리 두 선형 투영의 성분별 곱으로 활성화할 정보를 선택한다.[9]
- FlashAttention: 어텐션 행렬 전체를 GPU의 고대역폭 메모리에 반복해서 기록하지 않고 타일 단위로 계산해 메모리 입출력을 줄이는 정확한 어텐션 알고리즘이다.[10]
- 가중치 공유: 입력 토큰 임베딩과 출력 언어 모델 head가 같은 가중치를 공유한다. 이를 weight tying이라고 하며, 어휘 임베딩에 필요한 파라미터의 중복을 줄인다.
- 선형층 bias 제거: 주요 선형 투영에서 학습 가능한 편향 파라미터를 사용하지 않는다.
- Q·K 투영 정규화: 공식 모델 설정에는 Query와 Key 투영을 정규화하는 옵션이 활성화돼 있다.
- 최대 문맥 길이 2,048토큰: 사전 학습 설정의 최대 시퀀스 길이는 네 모델 모두 2,048토큰이다. 이는 모델이 기술적으로 절대 2,048토큰을 넘겨 실행될 수 없다는 뜻보다, 공식 사전 학습과 평가가 해당 문맥 길이를 기준으로 이루어졌다는 의미에 가깝다.
2.2. 사전 학습 모델과 Instruct 모델
각 규모에는 이름 끝에 -Instruct가 없는 사전 학습 모델과 -Instruct가 붙은 명령어 조정 모델이 존재한다.2.2.1. 사전 학습 모델
사전 학습 모델은 이전 토큰들이 주어졌을 때 다음 토큰의 확률분포를 예측하도록 학습된 기본 언어 모델이다. 예를 들어 “대한민국의 수도는”이라는 입력을 받으면 뒤에 등장할 가능성이 높은 토큰을 이어서 생성하지만, 질문에 정확하고 친절하게 답하거나 사용자가 요구한 출력 형식을 준수하도록 별도로 정렬된 것은 아니다.사전 학습에는 RefinedWeb, 중복 제거 PILE, RedPajama와 Dolma의 일부를 결합한 공개 데이터 풀이 사용됐다. 전체 데이터 풀은 약 1조 8천억 토큰이며, 각 모델은 약 400만 토큰 규모의 배치로 35만 스텝을 학습해 약 1조 5천억 토큰을 처리했다.[11]
최적화에는 AdamW와 cosine learning-rate schedule이 사용됐으며, 초기 5,000스텝은 학습률을 점진적으로 높이는 warm-up 구간으로 설정됐다. Weight decay는 0.1, gradient clipping 기준은 1.0이었다. 네 모델 모두 128개의 GPU로 학습됐으며 270M과 450M에는 NVIDIA A100, 1.1B와 3B에는 NVIDIA H100이 사용됐다.
2.2.2. Instruct 모델
Instruct 모델은 같은 규모의 사전 학습 모델을 출발점으로 삼아, 사용자의 명령과 선호되는 응답 사이의 관계를 추가로 학습한 모델이다. 따라서 파라미터 규모와 기본 Transformer 구조는 동일하지만 가중치의 값이 달라진다.OpenELM의 명령어 조정에는 정제된 UltraFeedback 데이터셋의 약 6만 개 프롬프트가 사용됐다. UltraFeedback은 여러 언어 모델이 생성한 응답을 GPT-4가 유용성·정확성·정직성 등의 기준으로 평가해 선호 정보를 구성한 데이터셋이다.[12]
OpenELM 연구진은 Alignment Handbook의 학습 절차를 바탕으로 통계적 거부 샘플링 최적화와 Direct Preference Optimization, DPO계열 설정을 탐색했다. DPO는 선호 응답과 비선호 응답의 확률 차이를 직접 최적화함으로써 별도의 보상 모델과 온라인 강화학습 단계를 생략하는 방법이다.[13][14]
명령어 조정 단계의 최대 시퀀스 길이는 1,024토큰, 프롬프트 최대 길이는 512토큰이었다. 연구진은 규모별로 학습률, epoch 수와 DPO loss 형태를 탐색한 뒤 평가 평균이 가장 높은 설정을 최종 Instruct 모델로 선택했다. 따라서 OpenELM의 Instruct 모델은 단순히 질문·답변 예시를 지도 학습한 모델이라기보다, 선호 데이터로 응답 성향을 조정한 모델에 가깝다.
2.3. OpenELM-270M 계열
- OpenELM-270M
- OpenELM-270M-Instruct
약 2억 7천만 개의 파라미터를 가진 OpenELM 제품군의 최소 모델이다. 16개의 Transformer 레이어와 1,280차원의 잔차 스트림으로 구성되며, 어텐션 head 하나의 차원은 64다.
초기 레이어는 Query head 12개와 Key·Value head 3개를 사용하고, 뒤쪽 레이어로 갈수록 각각 20개와 5개까지 증가한다. Query head 네 개가 Key·Value head 하나를 공유하는 4:1 GQA 비율은 모든 레이어에서 유지된다. 피드 포워드 확장 계수는 초기의 0.5에서 마지막의 4.0까지 증가한다.
| <rowcolor=#f5f5f7> 평가 | 270M | 270M-Instruct | 차이 |
| 7개 과제 평균 | 54.37 | 55.11 | +0.74%p |
| ARC-Challenge | 26.45 | 30.55 | +4.10%p |
| HellaSwag | 46.71 | 52.07 | +5.36%p |
| BoolQ | 53.98 | 48.56 | -5.42%p |
| WinoGrande | 53.91 | 52.72 | -1.19%p |
Instruct 모델은 ARC-Challenge와 HellaSwag에서는 기본 모델보다 높은 점수를 기록했지만, BoolQ와 WinoGrande에서는 낮아졌다. 전체 평균 상승 폭도 0.74%p에 그쳤다. 이는 2억 7천만 파라미터라는 제한된 모델 용량에서 선호도 조정이 일부 행동을 강화하는 대신 다른 능력을 약화시킬 수 있음을 보여주는 결과다. 다만 개별 벤치마크 점수만으로 실제 대화 품질이나 특정 응용 분야의 성능을 단정할 수는 없다.
네 종류 가운데 가중치와 KV cache가 가장 작아 구조 분석, 양자화, 미세 조정 방법의 실험에 필요한 자원이 상대적으로 적다. 반면 복잡한 지시의 장기적 유지, 다단계 추론과 희소한 지식의 재현에서는 더 큰 OpenELM 모델보다 제약이 크다. 이는 Apple이 공식 사용 목적을 지정한 것이 아니라 모델 규모와 공개 평가 결과를 바탕으로 한 상대적인 해석이다.
2.4. OpenELM-450M 계열
- OpenELM-450M
- OpenELM-450M-Instruct
약 4억 5천만 개의 파라미터를 가진 모델로, 20개의 Transformer 레이어와 1,536차원의 잔차 스트림을 사용한다. 어텐션 head 차원은 64이며 Query head는 12개에서 24개, Key·Value head는 3개에서 6개로 증가한다.
270M과 비교하면 파라미터 수가 약 67% 증가하지만, 레이어 수뿐 아니라 고정 잔차 차원과 후반부 어텐션 폭도 함께 증가한다. 따라서 두 모델의 차이는 단순히 동일한 블록을 몇 개 더 쌓은 것에 그치지 않는다.
| <rowcolor=#f5f5f7> 평가 | 450M | 450M-Instruct | 차이 |
| 7개 과제 평균 | 57.56 | 59.95 | +2.39%p |
| ARC-Challenge | 27.56 | 30.38 | +2.82%p |
| HellaSwag | 53.97 | 59.34 | +5.37%p |
| BoolQ | 55.78 | 60.37 | +4.59%p |
| SciQ | 87.20 | 88.00 | +0.80%p |
450M-Instruct는 네 규모 가운데 7개 과제 평균의 명령어 조정 전후 상승 폭이 가장 컸다. 특히 HellaSwag와 BoolQ에서 비교적 큰 개선이 나타났다. 다만 이러한 결과가 450M이 항상 가장 효율적인 Instruct 모델이라는 뜻은 아니다. 모델 규모별로 선택된 학습률과 epoch 수, loss 설정이 서로 달랐으며, 단일 평가 평균은 생성 품질·안전성·사실성·긴 문맥 처리 능력을 모두 반영하지 않는다.
450M은 10억 개 미만 파라미터 영역에 속하면서도 270M보다 넓은 어텐션과 피드 포워드 표현을 사용한다. 소규모 모델에서 파라미터 수만 늘리는 것보다 깊이, 폭, 임베딩 공유와 GQA 같은 구조 선택이 중요하다는 점은 MobileLLM 등 다른 온디바이스 언어 모델 연구에서도 보고됐다.[15]
2.5. OpenELM-1.1B 계열
- OpenELM-1_1B
- OpenELM-1_1B-Instruct
실제 파라미터 수는 약 10억 8천만 개다. 28개의 Transformer 레이어와 2,048차원의 잔차 스트림을 사용하며, head 차원은 64다. Query head 수는 16개에서 32개, Key·Value head는 4개에서 8개로 증가한다.
450M보다 파라미터 수가 약 2.4배 많고 레이어도 8개 더 깊다. 마지막 레이어의 Query 투영 폭은 [math(32\times64=2,048)]차원으로 잔차 스트림 전체 차원과 같아지는 반면, 초기 레이어에서는 [math(16\times64=1,024)]차원만 사용한다. 이것이 OpenELM의 어텐션 layer-wise scaling을 가장 직관적으로 보여주는 사례다.
| <rowcolor=#f5f5f7> 평가 | 1.1B | 1.1B-Instruct | 차이 |
| 7개 과제 평균 | 63.44 | 65.50 | +2.06%p |
| ARC-Challenge | 32.34 | 37.97 | +5.63%p |
| HellaSwag | 64.81 | 71.20 | +6.39%p |
| BoolQ | 63.58 | 70.00 | +6.42%p |
| SciQ | 90.60 | 89.30 | -1.30%p |
1.1B는 OpenELM 논문에서 layer-wise scaling의 효율성을 설명할 때 대표적으로 비교된 규모다. OpenLLM Leaderboard 방식의 다섯 개 과제 평균에서 OpenELM-1.1B는 45.93점, 약 11억 8천만 파라미터의 OLMo는 43.57점을 기록했다. 차이는 2.36%가 아니라 2.36%p다.[16][17]
OpenELM의 사전 학습량은 약 1조 5천억 토큰, 해당 OLMo 모델은 약 3조 토큰이었다. 따라서 논문은 OpenELM이 절반 수준의 사전 학습 토큰으로 더 높은 평균을 기록했다고 설명한다.
그러나 이 비교만으로 2.36%p의 차이가 모두 layer-wise scaling에서 발생했다고 결론 내릴 수는 없다. 두 모델은 어텐션 구조, 정규화, 피드 포워드 활성화, 토크나이저, 데이터 혼합 비율과 최적화 설정이 서로 다르며, OpenELM 논문은 동일 조건에서 layer-wise scaling만 켜고 끈 대규모 통제 실험을 제시하지 않았다. 따라서 OLMo 비교는 전체 OpenELM 학습 체계의 결과이지, 개별 구조 요소의 순수한 인과 효과를 측정한 ablation은 아니다.
2.6. OpenELM-3B 계열
- OpenELM-3B
- OpenELM-3B-Instruct
OpenELM 제품군에서 가장 큰 모델이다. 실제 파라미터 수는 약 30억 4천만 개이며, 36개의 Transformer 레이어와 3,072차원의 잔차 스트림을 사용한다.
다른 세 모델의 head 차원이 64인 것과 달리 3B는 128이다. 이에 따라 Query head 수는 12개에서 24개로 증가하지만, 마지막 레이어의 전체 Query 투영 폭은 [math(24\times128=3,072)]로 잔차 스트림 차원과 일치한다. Key·Value head는 3개에서 6개로 증가하며 4:1 GQA 비율은 유지된다.
| <rowcolor=#f5f5f7> 평가 | 3B | 3B-Instruct | 차이 |
| 7개 과제 평균 | 67.39 | 69.15 | +1.76%p |
| ARC-Challenge | 35.58 | 39.42 | +3.84%p |
| HellaSwag | 72.44 | 76.36 | +3.92%p |
| PIQA | 78.24 | 79.00 | +0.76%p |
| SciQ | 92.70 | 92.50 | -0.20%p |
기본 모델과 Instruct 모델 모두 각 유형에서 네 규모 중 가장 높은 7개 과제 평균을 기록했다. 그러나 규모가 가장 크다는 이유만으로 모든 평가에서 항상 가장 좋은 것은 아니다. OpenLLM Leaderboard 평가에서 3B 모델의 MMLU 점수는 명령어 조정 전 26.76점에서 조정 후 24.80점으로 낮아졌다. 이는 선호도 조정이 대화 지시 준수와 일부 상식 추론을 향상시키더라도 사전 학습에서 형성된 모든 지식 능력을 보존한다고 보장할 수 없음을 보여준다.
3B 모델은 더 많은 레이어와 넓은 잔차 스트림을 사용하므로 가중치 저장 공간, 메모리 대역폭과 연산량도 가장 크다. 4비트 양자화를 적용하면 가중치가 차지하는 공간을 크게 줄일 수 있지만, 실제 메모리 사용량에는 양자화 메타데이터, 활성값, KV cache와 실행 프레임워크의 버퍼가 추가되므로 파라미터 수에 0.5바이트를 곱한 값만으로 전체 메모리 요구량을 계산할 수는 없다.
2.7. 규모별 성능 비교
OpenELM 논문은 ARC-Challenge, ARC-Easy, BoolQ, HellaSwag, PIQA, SciQ, WinoGrande의 7개 과제를 공통 평가로 사용했다.| <rowcolor=#f5f5f7> 계열 | 기본 모델 평균 | Instruct 평균 | 조정 후 변화 |
| 270M | 54.37 | 55.11 | +0.74%p |
| 450M | 57.56 | 59.95 | +2.39%p |
| 1.1B | 63.44 | 65.50 | +2.06%p |
| 3B | 67.39 | 69.15 | +1.76%p |
규모가 커질수록 평균 점수도 증가했지만 증가 폭은 일정하지 않다. 기본 모델에서는 270M에서 450M으로 확대할 때 3.19%p, 450M에서 1.1B로 확대할 때 5.88%p, 1.1B에서 3B로 확대할 때 3.95%p 상승했다. 이는 벤치마크 점수가 파라미터 수에 단순 비례하지 않으며, 특정 규모 구간과 과제에서 확장 효과가 다르게 나타남을 보여준다.
명령어 조정 역시 네 모델 모두 평균을 높였지만, 개별 과제에서는 점수가 하락한 사례가 있다.
2.8. MLX 실행 성능
Apple은 모델을 MLX 형식으로 변환해 M2 Max와 64 GB 통합 메모리를 탑재한 MacBook Pro에서 실행 속도를 측정했다. 운영체제는 macOS 14.4.1, MLX 버전은 0.10.0이었으며, KV cache를 사용해 1,024토큰을 생성했다.| <rowcolor=#f5f5f7> 모델 | BF16 생성 속도 | 4비트 생성 속도 |
| OpenELM-270M | 초당 212.40토큰 | 초당 256.35토큰 |
| OpenELM-450M | 초당 147.26토큰 | 초당 197.81토큰 |
| OpenELM-1.1B | 초당 78.72토큰 | 초당 117.90토큰 |
| OpenELM-3B | 초당 33.96토큰 | 초당 60.33토큰 |
양자화 모델은 네 가지 규모에서 모두 BF16 모델보다 높은 생성 처리량을 보였다. 토큰을 한 개씩 생성하는 디코딩 단계에서는 연산량뿐 아니라, 매번 가중치를 메모리에서 불러오는 데 필요한 대역폭도 속도에 큰 영향을 준다. 양자화를 적용하면 가중치의 크기가 줄어드는 만큼 메모리 전송량도 감소하므로, 사용한 하드웨어와 구현에 따라 BF16 모델보다 빠른 생성 속도가 나올 수 있다.
다만 파라미터를 효율적으로 배분한 구조가 실제 추론에서도 항상 빠른 것은 아니다. OpenELM 논문의 NVIDIA GPU 실험에서는 RMSNorm 구현이 많은 수의 작은 GPU 커널을 반복해서 호출하면서 병목이 발생했다. 연구진의 분석에 따르면 OpenELM-1.1B는 토큰 하나를 생성하는 동안 RMSNorm 연산이 113회 호출됐지만, 비교 대상인 OLMo에서는 정규화 레이어 호출이 33회였다. 이 때문에 비슷한 파라미터 규모임에도 OpenELM의 생성 속도가 더 느리게 측정됐다.
기본 RMSNorm을 NVIDIA Apex의 최적화된 구현으로 교체하자 처리량은 상당히 개선됐다. 다만 OLMo와의 속도 차이가 완전히 없어지지는 않았는데, 정규화 커널 외에도 레이어 구성과 연산 배치 등 모델 구조상의 차이가 남아 있었기 때문이다.
결국 OpenELM에서 말하는 효율성은 한 가지 수치로만 판단하기 어렵다. 같은 정확도에 도달하는 데 필요한 학습 토큰 수, 모델 가중치와 KV cache가 차지하는 메모리, 실제 장치에서 측정되는 초당 생성 토큰 수는 각각 다른 조건의 영향을 받는다. 따라서 layer-wise scaling으로 파라미터 활용도가 높아졌다는 결과가 곧바로 더 빠른 추론 속도를 뜻하는 것은 아니다.
2.9. layer-wise scaling의 해석
OpenELM 논문은 제한된 파라미터를 모든 레이어에 똑같이 나누는 대신, 모델의 깊이에 따라 어텐션 헤드 수와 피드 포워드층의 크기를 다르게 배분하는 layer-wise scaling을 제안했다. 일반적으로 앞쪽 레이어에서는 비교적 국소적인 특징이 형성되고, 뒤쪽으로 갈수록 문맥을 종합한 표현이 만들어진다는 관찰을 바탕으로 후반부 레이어에 더 많은 파라미터를 배치한 것이다.다만 Transformer의 각 레이어가 맡는 역할은 학습 과정과 데이터, 모델 구조에 따라 달라질 수 있다. 초기 레이어는 단순한 정보만 처리하고 후반 레이어는 항상 더 복잡한 추론을 담당한다고 고정적으로 설명하기는 어렵다. OpenELM이 OLMo나 Pythia보다 높은 데이터 효율성을 보인 것 역시 layer-wise scaling만의 효과라고 단정할 수 없다. 학습 데이터와 모델 구성 등 여러 조건이 함께 달랐고, 해당 요소를 하나씩 통제한 대규모 ablation 결과가 제시된 것은 아니기 때문이다.
2025년에 공개된 후속 사전 연구 《Crown, Frame, Reverse: Layer-Wise Scaling Variants for LLM Pre-Training》에서는 약 1억 8천만 파라미터 규모의 모델을 50억 토큰으로 학습시키면서 OpenELM 방식과 여러 layer-wise scaling 변형을 비교했다. 실험에 사용된 layer-wise 모델들은 같은 연산량을 사용한 균일 구조 모델보다 대체로 낮은 검증 perplexity를 기록했다. 반면 OpenELM 논문에서 언급된 약 2배의 데이터 효율성까지 재현되지는 않아, 그 차이를 layer-wise scaling 하나만의 효과로 보기는 어렵다는 결과가 나왔다.[18]
이 연구 역시 실험 범위가 넓지는 않다. 하나의 파라미터 규모와 학습 토큰 수만을 사용했고, 각 모델의 학습도 한 차례씩 진행했으며 평가는 주로 perplexity에 집중됐다. 그러므로 OpenELM의 결과를 완전히 반박했다기보다는, layer-wise scaling 자체가 어느 정도 이점을 줄 가능성은 있지만 그 효과의 크기를 확인하려면 더 큰 모델과 반복 실험이 필요하다는 정도로 보는 편이 타당하다.
3. 특징
OpenELM은 약 2억 7천만 개에서 30억 4천만 개의 파라미터를 가진 소형 언어 모델 제품군이다. 일반적으로 파라미터가 적은 모델은 실행에 필요한 메모리와 연산량이 줄어들기 때문에 개인용 컴퓨터와 같은 로컬 환경에서 운용하기가 상대적으로 쉽다.다만 모델이 작다는 이유만으로 다른 언어 모델보다 성능이 낮다고 단정할 수는 없다. Apple의 실험에서 10억 8천만 파라미터 OpenELM은 약 11억 8천만 파라미터의 OLMo보다 일부 평가 묶음에서 높은 평균 정확도를 기록했다. 이는 특정 벤치마크와 평가 설정에서 얻은 결과이므로 모든 언어 처리 과제에서 OpenELM이 더 우수하다는 의미는 아니다.
트랜스포머의 각 레이어에 서로 다른 수의 파라미터를 배분하는 layer-wise scaling 전략을 채용했다.
기존 언어 모델에서는 각 Transformer 레이어에 동일한 수의 어텐션 헤드와 동일한 크기의 피드 포워드 네트워크를 사용하는 경우가 많다. 이에 비해 OpenELM은 입력에 가까운 레이어에서는 어텐션 헤드 수와 피드 포워드 네트워크의 확장 비율을 작게 설정하고, 출력에 가까워질수록 점차 확대한다.
이를 통해 제한된 전체 파라미터 예산 안에서 모든 레이어에 같은 수의 파라미터를 배분하는 대신, 뒤쪽 레이어에 더 많은 파라미터를 배치할 수 있다. 논문에서는 이러한 비균일 구조가 동일한 규모의 균일한 Transformer보다 파라미터를 효과적으로 활용하도록 한다고 설명한다.[19]
아키텍처는 텍스트를 왼쪽에서 오른쪽으로 생성하는 디코더 전용 Transformer 구조다. 완전 연결층의 학습 가능한 편향 파라미터를 제거했으며, 사전 정규화 방식의 RMSNorm, Rotary Positional Embedding, Grouped Query Attention, SwiGLU 피드 포워드 네트워크와 FlashAttention을 사용한다. 토크나이저는 LLaMA와 동일한 계열의 토크나이저를 사용한다.
4. 학습
OpenELM의 학습에는 Apple이 공개한 CoreNet이 사용됐다. PyTorch를 기반으로 하는 연구용 프레임워크로, 언어 모델뿐 아니라 이미지 분류·객체 탐지·의미론적 분할 등 여러 종류의 모델을 학습할 수 있다.학습 데이터는 RefinedWeb, 중복을 제거한 PILE, RedPajama와 Dolma v1.6의 일부를 조합해 구성했다. 여기에는 일반 웹 문서 외에도 GitHub 코드, 서적, arXiv 논문, Wikipedia, Stack Exchange, C4, The Stack, Reddit, Project Gutenberg 등의 자료가 포함된다. Apple이 공개한 데이터 풀의 전체 규모는 약 1조 8천억 토큰이다.[20]
다만 1조 8천억 토큰을 전부 한 차례씩 학습한 것은 아니다. 각 모델이 실제로 처리한 양은 약 1조 5천억 토큰으로, 네 가지 규모 모두 35만 스텝 동안 학습됐다. 한 스텝의 배치에는 약 400만 토큰이 들어갔으며, 모델 규모에 따라 128개의 NVIDIA A100 또는 NVIDIA H100 GPU가 사용됐다.[21]
데이터 전처리 방식도 일반적인 정적 토큰화 파이프라인과 다소 달랐다. 전체 데이터를 미리 토큰으로 변환해 저장하는 대신, 학습 중에 데이터를 불러와 필터링하고 토큰화했다. 원문 길이가 200자보다 짧거나 토큰화한 뒤 256토큰에 미치지 못하는 데이터는 제외했다. 덕분에 토크나이저나 필터링 기준을 바꿀 때 데이터셋 전체를 다시 전처리하지 않고도 실험 설정을 조정할 수 있었다.
5. 성능
Apple은 ARC-Challenge, ARC-Easy, BoolQ, HellaSwag, PIQA, SciQ, WinoGrande 등 7개 상식 추론 과제에서 모델을 평가했다.| <rowcolor=#f5f5f7> 모델 규모 | 사전 학습 모델 평균 | Instruct 모델 평균 |
| 270M | 54.37 | 55.11 |
| 450M | 57.56 | 59.95 |
| 1.08B | 63.44 | 65.50 |
| 3.04B | 67.39 | 69.15 |
Instruct 모델은 네 가지 규모에서 모두 전체 평균이 상승했지만, BoolQ·SciQ·MMLU 등 일부 개별 과제에서는 사전 학습 모델보다 낮은 점수를 기록하기도 했다.
OpenLLM Leaderboard 방식의 평가에서 10억 8천만 파라미터 OpenELM은 평균 45.93점을, 11억 8천만 파라미터 OLMo는 평균 43.57점을 기록해 2.36%p의 차이를 보였다. OpenELM의 사전 학습량은 약 1조 5천억 토큰으로, 약 3조 토큰을 사용한 OLMo의 절반 수준이었다.[22]
6. 온디바이스 실행
Apple은 OpenELM 코드와 가중치를 MLX로 변환해 M2 Max와 64 GB 통합 메모리를 탑재한 MacBook Pro에서 실행 성능을 측정했다. 이 실험에서는 macOS 14.4.1과 MLX 0.10.0이 사용됐다.[23]| <rowcolor=#f5f5f7> 모델 | BF16 생성 속도 | 4비트 양자화 생성 속도 |
| OpenELM-270M | 초당 212.40토큰 | 초당 256.35토큰 |
| OpenELM-450M | 초당 147.26토큰 | 초당 197.81토큰 |
| OpenELM-1.08B | 초당 78.72토큰 | 초당 117.90토큰 |
| OpenELM-3.04B | 초당 33.96토큰 | 초당 60.33토큰 |
7. 한계
OpenELM은 이름과 달리 추론 속도 자체만을 최우선으로 설계한 모델은 아니다. 논문의 벤치마크에서는 비슷한 규모의 OLMo보다 높은 평가 정확도를 보였지만, 일부 CUDA 추론 실험에서는 OLMo보다 느렸다.연구진은 OpenELM에서 사용한 최적화되지 않은 RMSNorm 구현이 다수의 작은 GPU 커널 호출을 발생시킨 것을 주요 병목으로 분석했다. 논문에서는 연구의 주된 목적이 최고의 추론 속도보다 모델 학습 과정의 투명성과 재현성을 제공하는 데 있다고 설명했다.
또한 Apple은 모델에 별도의 안전성을 보장하지 않는다. 학습 데이터에 포함된 편향이나 오류로 인해 부정확하거나 유해하거나 편향된 결과를 생성할 수 있으며, 실제 서비스에 적용할 때에는 목적에 맞는 안전성 평가와 출력 필터링이 필요하다고 명시했다.[24]
8. 둘러보기
[[Apple|]]
#!wiki
[[파일:Apple 로고 화이트.svg|height=40]]
Apple
- [ 펼치기 · 접기 ]
- ||<-4><tablewidth=100%><tablebgcolor=transparent><bgcolor=#333>하드웨어 제품
#!wiki class="element" [[Mac(컴퓨터)|[[파일:Mac 심볼.svg|width=80&theme=light]][[파일:Mac 심볼 다크.svg|width=80&theme=dark]][br]{{{#333,#ddd Mac}}}]]#!wiki class="element" [[iPhone|[[파일:iPhone 15 Pro 심볼.svg|width=25&theme=light]][[파일:iPhone 15 Pro 심볼 화이트.svg|width=25&theme=dark]][br]{{{#333,#ddd iPhone}}}]]#!wiki class="element" [[iPad|[[파일:iPad Pro 아이콘 라이트.svg|width=40&theme=light]][[파일:iPad Pro 아이콘 다크.svg|width=40&theme=dark]][br]{{{#333,#ddd iPad}}}]]#!wiki class="element" [[틀:Apple 디스플레이 라인업|[[파일:Pro Display XDR 심볼(1).svg|width=55&theme=light]][[파일:Pro Display XDR 심볼 화이트.svg|width=55&theme=dark]][br]{{{#333,#ddd Display}}}]]#!wiki class="element" [[Apple Watch|[[파일:Apple Watch 심볼.svg|width=22&theme=light]][[파일:Apple Watch 심볼 다크.svg|width=22&theme=dark]][br]{{{#333,#ddd Watch}}}]]#!wiki class="element" [[AirPods|[[파일:AirPods Pro 심볼.svg|width=45&theme=light]][[파일:AirPods Pro 심볼 화이트.svg|width=45&theme=dark]][br]{{{#333,#ddd AirPods}}}]]#!wiki class="element" [[Apple TV|[[파일:Apple TV 4K 3rd 심볼.svg|width=42&theme=light]][[파일:Apple TV 심볼 다크.svg|width=42&theme=dark]][br]{{{#333,#ddd TV}}}]]#!wiki class="element" [[HomePod|[[파일:HomePod 2세대 심볼.svg|width=60&theme=light]][[파일:HomePod 2세대 심볼 화이트.svg|width=60&theme=dark]][br]{{{#333,#ddd HomePod}}}]]#!wiki class="element" [[Apple Vision|[[파일:Vision 심볼.svg|width=60&theme=light]][[파일:Vision 심볼 화이트.svg|width=60&theme=dark]] [br]{{{#333,#ddd Vision}}}]]#!wiki class="element" [[AirTag|[[파일:AirTag 심볼.svg|width=50&theme=light]][[파일:AirTag 심볼 다크.svg|width=50&theme=dark]][br]{{{#333,#ddd AirTag}}}]]#!wiki class="element" [[Apple/액세서리|[[파일:Magic Keyboard 심볼.svg|width=63&theme=light]][[파일:Magic Keyboard 심볼 화이트.svg|width=63&theme=dark]][br]{{{#333,#ddd 액세서리}}}]]#!wiki class="element" [[Apple Silicon|[[파일:Apple Silicon 심볼.svg|width=35&theme=light]][[파일:Apple Silicon 심볼 화이트.svg|width=35&theme=dark]][br]{{{#333,#ddd Silicon}}}]]기타 단종 제품군|Apple Car|스티커| 소프트웨어 <colbgcolor=#333><colcolor=#fff>OS iOS | iPadOS | watchOS | macOS | tvOS(audioOS) | visionOS App iOS 앱 | Watch 페이스 AI MLX | Apple Intelligence | Apple Foundation Models | OpenELM 디자인 시스템 Aqua | Liquid Glass 서비스 프로그램 Apple Trade In | AppleCare+ | Apple 베타 소프트웨어 프로그램 이벤트 Apple 이벤트 | WWDC Apple Store 한국 | 미국 | 일본 | 영국 | 싱가포르 | 태국 | 인도 | 대만 결제 및 구독 Apple One | Apple Pay | Apple Gift Card 캠퍼스 쿠퍼티노 Campus | Apple Park 오스틴 Riata Vista Circle | Austin Campus 관계사 자회사 Beats | Shazam 인물 창업주 CEO 이사회 의장 경영진 이사진 기타
#!style
.element {
display: flex;
width: min(calc(100% / 4), 100px);
height: 95px;
padding-bottom: 5px;
border-radius: min(10px, 1.5vw);
background: #f5f5f7;
flex-grow: 1;
justify-content: center;
align-items: flex-end;
}
@theseed-dark-mode {
.element {
background: #272829;
}
}
[1] 정확히는 Apple Sample Code License를 사용한다.[2] Apple Machine Learning Research - OpenELM[3] Sachin Mehta et al., 《OpenELM: An Efficient Language Model Family with Open Training and Inference Framework》, 2024. arXiv:2404.14619.[4] Apple, OpenELM 공식 설정 파일: 270M, 450M, 1.1B, 3B.[5] Sachin Mehta et al., 《DeLighT: Deep and Light-weight Transformer》, 2020. arXiv:2008.00623.[6] Biao Zhang and Rico Sennrich, 《Root Mean Square Layer Normalization》, NeurIPS 2019. arXiv:1910.07467.[7] Jianlin Su et al., 《RoFormer: Enhanced Transformer with Rotary Position Embedding》, 2021. arXiv:2104.09864.[8] Joshua Ainslie et al., 《GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints》, EMNLP 2023. arXiv:2305.13245.[9] Noam Shazeer, 《GLU Variants Improve Transformer》, 2020. arXiv:2002.05202.[10] Tri Dao et al., 《FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness》, NeurIPS 2022. arXiv:2205.14135.[11] OpenELM 논문 Appendix A, Table 6. arXiv:2404.14619.[12] Ganqu Cui et al., 《UltraFeedback: Boosting Language Models with Scaled AI Feedback》, 2023. arXiv:2310.01377.[13] Rafael Rafailov et al., 《Direct Preference Optimization: Your Language Model is Secretly a Reward Model》, NeurIPS 2023. arXiv:2305.18290.[14] Tianqi Liu et al., 《Statistical Rejection Sampling Improves Preference Optimization》, 2023. arXiv:2309.06657.[15] Zhe Chen et al., 《MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases》, 2024. arXiv:2402.14905. 단, MobileLLM과 OpenELM은 서로 다른 모델과 학습 설정을 사용하므로 해당 연구 결과를 OpenELM의 직접적인 성능 근거로 볼 수는 없다.[16] Dirk Groeneveld et al., 《OLMo: Accelerating the Science of Language Models》, 2024. arXiv:2402.00838.[17] OpenELM 논문 Table 2 및 Table 4. arXiv:2404.14619.[18] Andrei Baroian and Kasper Notebomer, 《Crown, Frame, Reverse: Layer-Wise Scaling Variants for LLM Pre-Training》, 2025. arXiv:2509.06518.[19] OpenELM 논문 2.1 OpenELM architecture[20] Apple OpenELM 모델 카드[21] OpenELM 논문 Appendix A[22] OpenELM 논문 Experimental Results[23] OpenELM 논문 Benchmarking[24] OpenELM 모델 카드 - Bias, Risks, and Limitations