요약 (TL;DR): 대중에게 공개된 역대 최대 규모의 AI 모델이 1,500줄에 달하는 설명서와 함께 출시되었습니다. 그 핵심적인 내용 중 대부분은 모델의 크기에 관한 것이 아닙니다. 여기 수식은 빼고 비유를 넣어 정리한 설명서가 있습니다.

12일 전, 저는 Kimi K3가 발표된 당일에 이에 대해 글을 썼고, 질문을 던지며 포스팅을 마쳤습니다. Moonshot은 7월 27일에 기술 보고서(technical report)와 함께 가중치(weights)를 공개하겠다고 약속했습니다. 과연 그들이 약속을 지킬지, 그리고 보고서에는 어떤 내용이 담겨 있을지 말입니다.

그들은 약속을 지켰습니다. 가중치는 27일에 Hugging Face에 올라왔으며, 30분 만에 해당 사이트에서 가장 인기 있는 항목이 되었습니다. 보고서도 함께 공개되었습니다.

저는 이제 그 내용을 모두 읽었습니다. 저는 모델을 직접 실행해 보지는 않았고, 앞으로도 할 계획은 없습니다. 모델을 돌리려면 작은 서버실 하나가 필요하기 때문입니다. 하지만 어쨌든 보고서 자체가 훨씬 더 흥미로운 결과물임이 드러났습니다.

여기 제가 예상하지 못했던 부분이 있습니다. 보고서에서 가장 훌륭한 섹션은 Moonshot이 프로젝트 첫 달에 스스로 만들어냈고, 모델이 실제 서비스(production) 단계에 들어서기 전까지는 발견하지 못했던 문제에 대해 설명하고 있습니다. 그 부분은 나중에 다루겠지만, 우선 배경 설명이 몇 단계 필요합니다.

아래에는 수식이 없습니다. 식당 주방에 관한 이야기를 따라갈 수 있다면, 이 내용도 이해할 수 있습니다.

2.8조 개의 파라미터 (parameters)가 실제로 의미하는 것

파라미터 (Parameters)는 모델의 조정 가능한 설정값입니다. 이 값이 많을수록 패턴을 저장할 수 있는 공간이 더 넓어집니다. Kimi K3는 2.8조 개의 파라미터를 가지고 있는데, 이는 누군가가 공개적으로 발표한 수치 중 가장 큰 숫자입니다.

하지만 모델이 이 파라미터를 한꺼번에 모두 사용하지는 않으며, 바로 이 차이점이 핵심입니다.

896명의 전문의가 근무하는 병원을 상상해 보세요. 환자가 들어옵니다. 환자가 896명 전원을 만나는 것은 아닙니다. 분류 간호사(triage nurse)가 차트를 읽고 환자를 16명의 의사에게 보냅니다. 병원은 거대하지만, 개별 진료에는 소규모 팀만 참여합니다.

이것이 전문가 혼합 (Mixture of Experts, MoE) 방식이며, Kimi K3는 이 방식을 사용합니다. 896개의 전문가 서브 네트워크 (sub-networks)가 있으며, 각 단어를 처리할 때마다 그중 16개가 작동합니다. 모델은 디스크 용량은 매우 크지만, 어느 순간에도 모델의 98%가 유휴 상태(idle)로 있기 때문에 실행 비용은 상대적으로 저렴합니다.

이전 버전인 Kimi K2는 384명의 전문가(specialists)를 보유하고 있었으며 8명을 사용했습니다. 따라서 K3는 직원 수를 두 배 이상 늘렸고, 각 환자를 진찰하는 팀의 규모도 두 배로 키웠습니다.

이는 직관적으로 더 좋아 보이지만, 바로 여기서부터 문제가 시작됩니다.

Diagram of the Kimi K3 architecture, showing text and images feeding a shared embedding, a repeating block of three Kimi Delta Attention layers and one Gated MLA layer each paired with a Stable LatentMoE layer, and Attention Residuals reaching back across the network's depth

Kimi K3가 한 번에 백만 단어를 읽는 방법

Kimi K3는 약 700,000단어에 해당하는 백만 토큰(tokens)의 입력을 처리할 수 있습니다. 거대한 코드베이스 전체나 여러 권의 소설 분량입니다.

그만큼 많은 텍스트를 집어넣는 것은 결코 어려운 부분이 아니었습니다. 진짜 어려운 부분은 모델이 읽는 표준 방식이 이차적(quadratic)이라는 점입니다. 즉, 새로운 단어를 하나 쓸 때마다 그 이전에 나온 모든 내용을 다시 읽어야 합니다. 이메일에 답장을 하기 위해 당신이 지금까지 받은 모든 이메일을 처음부터 다시 읽어야 한다고 상상해 보세요. 20통 정도라면 괜찮겠지만, 백만 통이라면 파멸적일 것입니다.

대안은 대신 계속해서 요약본을 유지하는 것입니다. 각 이메일을 읽은 후, 노트를 업데이트하고 이메일은 버리는 방식입니다. 노트의 크기는 얼마나 많은 이메일이 들어오든 상관없이 영원히 동일한 크기를 유지합니다. 저렴하죠. 하지만 예전 이메일을 정확하게 찾아 인용할 수 있는 능력은 상실하게 됩니다.

Kimi K3는 이 두 가지 방식을 일정 비율로 혼합하여 수행합니다. 93개의 레이어(layers) 깊이에서 요약을 유지하는 레이어 3개를 거친 후, 전체를 다시 읽는 레이어 1개를 배치하는 과정을 반복합니다. 요약 레이어들이 저렴한 비용으로 대부분의 작업을 수행하고, 매 네 번째 레이어가 원본 자료를 제대로 살펴봅니다.

이 요약 유지 메커니즘을 Moonshot은 Kimi Delta Attention이라고 부르며, 여기에는 작아 보이지만 결코 작지 않은 보너스가 포함되어 있습니다.

대부분의 모델은 각 단어가 시퀀스(sequence) 내의 어디에 위치하는지 명시적으로 알려주어야 합니다. 3번째 단어, 40,000번째 단어, 900,000번째 단어와 같이 말이죠. 모델의 범위를 128,000단어에서 백만 단어로 확장한다는 것은 그 자(ruler)를 다시 교정해야 함을 의미하며, 이는 까다롭고 정보 손실(lossy)이 발생하는 작업입니다.

Kimi K3에는 자(ruler)가 없습니다. 실행 중인 요약(running summary)이 오래된 정보를 자연스럽게 흐릿하게 만듦으로써, 최신성(recency)이 별도로 덧씌워지는 것이 아니라 메커니즘 자체에 내장됩니다. 재교정할 것이 아무것도 없습니다. 모델이 백만 토큰까지 확장될 수 있는 이유는 파손될 측정 장치가 없기 때문입니다.

왜 896명의 전문가 중 16명만이 일을 하는가

다시 병원으로 돌아가 봅시다. 여기에는 배달(courier) 문제가 있습니다.

보통 상담하는 모든 전문의는 환자의 전체 파일을 받습니다. 8명에게 보내면 건물 안에서 8개의 복사본이 돌아다니게 됩니다. 16명에게 보내면 배달 트래픽, 인쇄량, 지연 시간이 두 배로 늘어납니다. 이것이 모델이 단순히 활성 전문가(active experts)의 수를 무작정 늘리지 않는 이유입니다. 대역폭(bandwidth) 비용이 뒤따르기 때문입니다.

Kimi K3는 대신 요약본을 보냅니다. 전문가들은 절반 너비의 압축된 버전을 받습니다. 모든 환자를 예외 없이 보는 단 두 명의 일반의(general practitioners)만이 전체 파일을 받습니다. 따라서 배달 트래픽의 증가 없이도 라우팅(routing)을 훨씬 더 관대하게 수행할 수 있습니다.

이제 더 미묘한 문제입니다. 어떤 16명을 선택할지는 누가 결정할까요?

라우터(router)가 모든 단어에 대해 각 전문가의 점수를 매기고 상위 전문가들을 선택합니다. 그대로 두면 다음과 같은 예측 가능한 실패가 발생합니다. 몇몇 인기 있는 전문가에게 업무가 몰리고, 대부분은 유휴 상태가 되며, 일부는 환자를 전혀 보지 못해 아무것도 배우지 못하게 됩니다. 더 나쁜 것은, 전문가들이 서로 다른 머신(machine)에 상주할 때, 과부하가 걸린 머신 하나가 다른 모든 머신을 기다리게 만든다는 점입니다.

과거의 해결책은 '넛지(nudge, 살짝 밀기)'였습니다. 매 라운드마다 사용되지 않는 전문가의 점수는 높여주고, 과도하게 사용되는 전문가의 점수는 일정량 삭감하는 방식입니다. 이는 온도 조절기(thermostat)와 같으며, 온도 조절기에는 알려진 실패 모드가 있습니다. 너무 부드럽게 밀면 방이 결코 따뜻해지지 않습니다. 너무 세게 밀면 목표치를 초과(overshoot)하고, 다시 반대로 초과하는 과정이 영원히 반복됩니다. 896개의 방이 있다면, 단 하나의 설정으로 모든 방을 맞출 수는 없습니다.

Moonshot은 온도 조절기를 버렸습니다. 그들의 대체제는 드레스 코드를 추측하는 것을 그만둔 보안 요원(bouncer)입니다. 점수에 따라 모두를 정렬하고, 장소가 수용할 수 있는 정확한 인원수만큼 거꾸로 세어 내려간 뒤, 딱 그 지점에 바(bar)를 설치합니다. 단 한 번의 통과(pass)로 추측 없이 매번 목표 부하(target load)를 달성합니다.

Diagram of Stable LatentMoE showing a token splitting into a full-width shared expert path and a compressed routed path through a router that picks 16 of 896 experts, plus a comparison of the old step-based load balancing with the new quantile method

여기 아주 멋진 실용적인 요령(wrinkle)이 있습니다. 모든 것을 정렬하려면 모든 점수(score)를 한곳에 모아야 하는데, 훈련 규모(training scale)에서는 수백 대의 머신에 흩어져 있는 수백만 개의 숫자입니다. 이를 모으는 것은 비용 효율적이지 않습니다.

그래서 그들은 그것들을 모으지 않습니다. 대신 각 머신은 이름 목록을 제출하는 대신 인구 조사에서 "170cm에서 175cm 사이의 사람이 4,200명"이라고 보고하는 것처럼, 자신의 점수 중 각 구간(band)에 속하는 개수가 몇 개인지 보고합니다. 이 구간(bands)들을 모두 더하면 국가적인 전체 그림을 얻을 수 있습니다. 인구를 어떻게 나누든 카운트(counts)는 깔끔하게 합산되므로, 데이터가 어떻게 분포되어 있든 상관없이 정답은 정확합니다.

만약 샤드(shards) 전체에 걸친 전역 통계(global statistic)가 필요하지만 원시 데이터(raw data)를 수집할 여력이 없다면, 이 요령을 기억해 둘 가치가 있습니다.

숫자를 수용 가능한 크기로 작게 유지하기

이 보고서에서 세 번이나 별도로 나타나는 패턴이 있는데, 한 번 눈치채고 나면 멈출 수 없습니다.

컴퓨터는 제한된 정밀도(precision)로 숫자를 저장하며, AI 하드웨어는 더 빠르기 때문에 의도적으로 매우 거친 정밀도(coarse precision)를 사용합니다. 따라서 엄청나게 큰 숫자를 생성하는 계산은 단순히 느려지는 것에 그치지 않습니다. 시스템이 망가집니다(breaks).

Kimi K3의 요약 메커니즘(summary mechanism)에는 정확히 이러한 위험 요소가 있습니다. 매 단계마다 오래된 정보는 조금씩 흐릿해지며(fades), 수학적으로 이를 올바르게 처리한다는 것은 때때로 그 흐릿해짐을 되돌리는 것을 의미하며, 이는 곧 그것으로 나누는 것을 의미합니다. 무언가를 거의 아무것도 없는 상태로 흐릿하게 만들고 나면, 당신은 거의 아무것도 없는 값으로 나누게 되는 것입니다. 이는 속삭임을 1조 배 증폭하여 재구성하려는 오디오 작업과 같습니다. 증폭기(amplifier)가 감당하지 못하는 것이죠.

이전 버전은 위험한 사례를 감지하여 느리지만 신중한 특수 목적 경로(special-purpose path)로 보내는 방식으로 이를 처리했습니다.

Kimi K3는 대신 설정 하나를 변경했습니다. 그 어떤 것도 원래 강도의 약 0.7% 미만으로 떨어지는 것이 결코 허용되지 않습니다. 이 하한선(floor)은 언두(undo) 숫자가 하드웨어가 수용할 수 있는 범위 내에 머물도록 유지하며, 위험 요소(hazard)가 사라짐에 따라 최적화되지 않았던 느린 경로(slow path)는 삭제되었습니다.

동일한 직관이 활성화 함수(activation function)에서도 나타납니다. 이 함수는 각각 제한 없이 커질 수 있는 두 부분으로 구성되어 있었습니다. 두 개의 무제한적인 요소를 곱하면 결국 두 요소가 함께 급증하여 스피커를 터뜨리게 됩니다. Kimi K3는 두 부분 모두에 리미터(limiter)를 설치하여, 일반적인 볼륨에서는 동일하게 작동하면서 단순히 천장(ceiling)을 넘어서는 것만 거부하도록 설계했습니다. 그리고 훈련 방식에서도 마찬가지였습니다. 대부분의 모델은 전체 정밀도(full precision)로 훈련된 후 나중에 압축되어 약간의 품질 저하를 겪습니다. Kimi K3는 처음부터 압축된 형식으로 훈련되었기 때문에, 예상치 못한 '이발(haircut, 정밀도 손실)'에 적응할 필요가 없었습니다.

세 개의 하위 시스템, 하나의 아이디어. 이 정도 규모에서는 곡선의 형태 자체가 인프라 결정 사항입니다.

세 가지 병목 현상을 제거한 증명

이것은 보고서에서 제가 가장 좋아하는 부분이며, 주방에 관한 이야기입니다.

메뉴에 896개의 요리가 있고, 주방이 여러 스테이션(stations)으로 나뉘어 있다고 상상해 보세요. 주문은 불균등하게 들어오기 때문에 어떤 스테이션은 정신없이 몰아치고 다른 곳은 한가합니다. 일반적인 해결책은 압박이 있는 곳 어디든 보낼 수 있는 유동적인 요리사(floating cooks)를 두는 것입니다. 하지만 교대 근무에 유동적인 인력을 얼마나 유지해야 할까요?

너무 적게 예측하면 어느 날 밤 주방이 마비되고, 업무를 재분배할 합법적인 방법이 없어 서비스가 중단됩니다. 이것은 비유가 아닙니다. 기존 시스템에서는 훈련이 실제로 중단되며, 누군가가 수동으로 숫자를 다시 조정해야 합니다.

Moonshot은 주문 분포가 어떠하든 수학적으로 실패할 수 없는 유동 인력(floater)의 수를 증명했습니다. 또한 그보다 더 잘할 수는 없다는 것도 증명했습니다. 따라서 그들은 정확히 그만큼의 인력을 배치하며, 병목 현상(jam)은 불가능해집니다.

이제 보증(guarantee)이 무엇을 가져다주는지 지켜보십시오. 이것이 제가 계속 생각하게 되는 부분입니다.

부하(load)가 항상 완벽하게 균등하기 때문에, 모든 스테이션(station)은 동일한 양의 작업을 수행합니다. 작업량이 동일하기 때문에, 교대 근무가 시작되기 전에 모든 작업의 크기를 미리 알 수 있습니다. 크기를 사전에 알고 있기 때문에, 다음 배치(batch)를 보내기 전에 아무도 멈춰 서서 각 스테이션에 "지금 주문이 몇 건인가요?"라고 물어볼 필요가 없습니다.

그 질문 자체가 주요한 지연(delay) 요인이었습니다. 모델의 모든 레이어(layer) 사이에서, 단계(step)당 수백 번씩 발생했으며, 그때마다 전체 파이프라인(pipeline)은 답변을 기다리며 멈춰 섰습니다.

한 가지 증거를 보십시오. 세 가지의 별도 속도 저하가 사라졌으며, 그중 두 가지는 증명하려는 대상과는 전혀 상관없는 것들이었습니다.

8개월 늦게 나타난 문제

좋습니다. 약속했던 섹션입니다.

Kimi K3는 두 종류의 레이어(layer)를 혼합하며, 각 레이어는 대화를 다르게 기억합니다.

비디오 게임을 저장하는 두 가지 방식이라고 생각해보십시오. 전체 재독해 레이어(full re-reading layers)는 모든 프레임(frame)을 기록하므로, 사용자가 어느 순간으로든 되감기(scrub)할 수 있습니다. 요약 레이어(summary layers)는 플레이함에 따라 덮어쓰여지는 하나의 커다란 저장 파일(save file)을 유지하며, 이를 기록하는 것은 느리고 비용이 많이 듭니다.

이제 챗봇(chatbot)에 후속 메시지를 보낼 때, 챗봇은 전체 대화를 다시 처리하지 않습니다. 저장된 지점부터 다시 시작합니다. 이것이 채팅의 두 번째 메시지가 첫 번째보다 훨씬 빠른 이유이며, 이러한 모델들을 실행하는 비용을 감당할 수 있게 만드는 큰 이유 중 하나입니다.

Kimi K3의 경우, 중간부터 다시 시작하려면 프레임(frames)과 저장 파일(save file)이라는 두 기록이 동시에 복구되어야 합니다.

하지만 저장 파일은 기록하는 데 비용이 많이 들기 때문에 가끔씩만 기록됩니다. 그리고 시스템은 프레임 기록 일정(frame-recording schedule)이 저장 파일 일정(save-file schedule)에 고정되도록 설계되어 있었습니다. 이는 결과적으로 게임이 매 6,000단어마다 자동 저장(autosave)되는 것과 마찬가지였습니다.

그 과정을 따라가 보면 상황은 상당히 심각합니다. 6,000단어보다 짧은 대화는 저장 지점(save point)에 도달하지 못하기 때문에, 결코, 절대로 다시 재개될 수 없었습니다. 스트리밍되는 긴 문서들은 경계선을 넘기 전까지는 재사용 가능한 결과물을 전혀 만들어내지 못했습니다. 일반적인 코딩 요청이 400,000 토큰의 히스토리를 포함하고 4,000개의 새로운 토큰을 추가하는 100만 토큰 규모의 상황에서, 저장 지점을 놓친다는 것은 400,000 토큰 전체를 다시 처리해야 함을 의미합니다. 저장 지점을 맞추느냐 놓치느냐의 차이는 고작 몇 퍼센트의 차이가 아닙니다. 그것은 비용 측면에서 수십 배(orders of magnitude)의 차이를 만듭니다.