메모리와 양자화

컴퓨터는 실수를 무한히 정확하게 저장할 수 없으므로 제한된 bit에 부호, 값의 크기를 정하는 exponent(지수), 유효 숫자를 정하는 significand 또는 mantissa(가수)를 나누어 담습니다. IEEE 계열 Floating Point 32(FP32, 32bit 부동소수점)는 1bit 부호·8bit 지수·23bit 가수를 사용합니다. Floating Point 16(FP16)은 1·5·10bit, Brain Floating Point 16(BF16)은 1·8·7bit를 사용합니다. 같은 16bit인 FP16과 BF16도 지수와 가수에 주는 자리가 다르므로 범위와 촘촘함이 다릅니다. 범위와 정밀도는 같은 말이 아닙니다.

NVIDIA TensorRT의 2026년 정확도 문서는 FP16의 최대 유한값을 65,504로 설명합니다. 계산 중 표현 범위를 넘는 overflow가 발생하면 infinity(Inf, 무한대 표기)가 생길 수 있고, 뒤 연산에서 Not a Number(NaN, 유효한 수가 아님)로 번질 수 있습니다. BF16은 8bit 지수 덕분에 훨씬 넓은 크기를 다루지만 가수가 7bit라 같은 크기 부근의 두 표현값 사이 간격은 FP16보다 클 수 있습니다. 따라서 학습 loss가 갑자기 NaN이 되는 사례에서는 “16bit라서 빠르다”보다 최초 overflow 위치와 누적 type을 먼저 확인합니다.

반대로 값이 표현 범위 안에 있다는 사실만으로 충분히 정확하다는 뜻도 아닙니다. Unit in the Last Place(ULP, 마지막 자리 한 단위)는 현재 크기에서 표현 가능한 이웃 값 사이 간격입니다. 값의 크기가 커질수록 간격도 커질 수 있어 작은 차이가 반올림되어 사라집니다. 확률을 만드는 softmax처럼 작은 logit 차이를 지수 함수로 키우는 계산, 많은 값을 더하는 reduction, normalization 전후는 정밀도 변화에 민감할 수 있습니다. 정상 입력 하나가 맞았다는 사실보다 큰 값·작은 차이·긴 누적을 포함한 경계 입력이 필요합니다.

Mixed precision(혼합 정밀도)은 모델 전체를 한 type으로 칠하는 방식이 아닙니다. Weight 저장, activation, matrix multiply 입력, accumulator와 출력이 서로 다른 type을 사용할 수 있고 민감한 연산만 FP32로 올릴 수 있습니다. 같은 FP16 checkpoint라도 runtime과 GPU kernel이 어떤 계산을 더 넓게 누적하는지에 따라 결과와 속도가 달라집니다. 파일명만으로 전체 계산 정밀도를 단정할 수 없습니다. Profiler와 runtime의 precision 보고서, 실패 layer의 중간값을 함께 봐야 합니다.

왜 이런가

정해진 bit를 범위와 간격에 나누어 쓰므로 같은 저장 크기라도 overflow 위험과 반올림 특성이 달라집니다.

언제 문제가 되는가

학습 loss가 Inf·NaN이 되거나 일부 큰 입력에서만 추론 결과가 반복·붕괴할 때 reduced precision의 최초 비정상 연산을 찾아야 합니다.

초보자가 자주 하는 오해

BF16은 FP16보다 언제나 정확한 상위 형식이 아닙니다. 지수 범위는 넓지만 가수 정밀도는 더 낮습니다.

직접 확인하는 방법

같은 정상·큰 값·작은 차이 입력을 FP32 기준선과 후보 precision으로 실행하고 layer별 Inf·NaN, 출력 차이와 kernel type을 기록하십시오.

가중치 이론 용량은 parameter count×bits per parameter÷8로 계산합니다. 8 billion parameter를 모두 16bit로 저장한다고 단순화하면 8,000,000,000×16÷8=16,000,000,000byte입니다. 4bit라면 4,000,000,000byte입니다. 이 식에서 parameter와 bit를 곱한 값은 bit 총량이므로 byte로 바꾸려면 8로 나누어야 합니다. “8B FP16은 약 16GB, 8B Q4는 약 4GB”라는 빠른 계산은 후보를 거르는 데 유용하지만 이론값은 구매 보증값이 아닙니다.

단위도 숫자와 함께 적습니다. Decimal Gigabyte(GB, 10억 byte)와 Binary Gibibyte(GiB, 2의 30승 byte)는 같은 단위가 아닙니다. 16,000,000,000byte는 16GB지만 약 14.90GiB입니다. 파일 탐색기, `ls`, GPU 도구가 서로 다른 단위를 표시하면 같은 artifact가 다른 크기처럼 보일 수 있습니다. 8GB VRAM과 7.45GiB 표시를 혼동해 남는 공간을 과대평가하지 않도록 원시 byte와 단위 이름을 함께 기록합니다.

실제 quantized file에는 block 또는 group마다 scale, 경우에 따라 zero point·minimum 같은 보조값이 들어갑니다. Embedding, output projection, normalization이나 품질에 민감한 tensor를 더 높은 type으로 남길 수도 있고 metadata, tensor 정렬 padding과 shard 구조도 공간을 씁니다. 따라서 이름이 Q4여도 평균 bits per weight는 정확히 4.000이 아닐 수 있습니다. 실제 file byte에서 parameter count를 나눈 평균과 tensor type 분포를 확인해야 명목 bit와 실효 저장 비용의 차이를 설명할 수 있습니다.

구체적인 개인 PC 사례를 보겠습니다. 8B Q4 파일이 4.8GiB이고 VRAM이 6GiB라면 “1.2GiB가 남는다”로 끝내면 안 됩니다. GPU에 올린 weight 외에 dequantization 작업 공간, KV cache, graph와 allocator 예약, display가 쓰는 VRAM이 더해집니다. 짧은 질문은 실행돼도 8K 문맥에서 Out of Memory(OOM, 메모리 부족)가 날 수 있습니다. 실제 artifact byte, 시작 직후 memory와 최장 입력 peak를 차례로 측정해야 합니다.

왜 이런가

간단한 식은 모든 parameter가 같은 bit라는 가정만 계산하며 scale·혼합 tensor·runtime 상태를 포함하지 않기 때문입니다.

언제 문제가 되는가

파일은 저장되지만 load 중 메모리가 부족하거나 짧은 입력만 통과하고 긴 문맥에서 중단될 때 이론값을 실행 요구량으로 오해한 것입니다.

초보자가 자주 하는 오해

Q4 파일은 반드시 parameter당 정확히 4bit이고 8B 모델이면 정확히 4GB라는 뜻이 아닙니다.

직접 확인하는 방법

Parameter·명목 bit·이론 byte·실제 file byte·평균 bits per weight·load 직후와 최대 문맥 peak를 같은 표에 적으십시오.

대칭 uniform integer quantization을 단순화하면 실수 weight를 scale로 나누고 허용 정수 범위에 맞춘 뒤 가장 가까운 code로 반올림합니다. 다시 계산할 때는 code에 scale을 곱해 근사값을 얻습니다. 예를 들어 scale이 0.1이면 0.24는 code 2로 저장되어 0.2로 돌아올 수 있고, 0.26은 code 3으로 저장되어 0.3이 될 수 있습니다. 서로 다른 원래 값이 같은 code로 모일 수 있으므로 양자화는 무손실 압축이 아닙니다.

Rounding error(반올림 오차)는 원래 값이 두 표현값 사이에 있어 가까운 한쪽으로 이동할 때 생깁니다. Clipping 또는 clamping error(범위 잘림 오차)는 원래 값이 code 범위를 넘어 가장 큰 값이나 가장 작은 값으로 잘릴 때 생깁니다. NVIDIA의 현재 TensorRT 문서도 scale이 넓어져 clipping을 줄이면 표현 간격이 커져 rounding이 증가할 수 있는 trade-off를 설명합니다. Scale을 넓히는 것에도 대가가 있습니다.

작은 숫자 대부분과 매우 큰 outlier 하나가 같은 block에 있다고 가정해 보겠습니다. Outlier를 보존하려고 범위를 넓히면 작은 값 여러 개가 같은 code로 뭉개질 수 있습니다. 반대로 작은 값에 맞춘 좁은 범위는 outlier를 경계에 잘라 버립니다. 이 변화는 모든 질문에 같은 정도로 나타나지 않습니다. 숫자 비교의 경계, 수학 계산, 드문 한국어 고유명사, code 문법과 JSON 닫힘처럼 작은 logit 차이가 선택을 바꾸는 입력에서 먼저 드러날 수 있습니다.

직접 확인할 때는 전체 평균 정확도 하나로 끝내지 않습니다. FP16 기준선의 tensor 또는 logit과 candidate의 차이를 보고, 업무 평가를 정상·경계·실패 하위 집합으로 나눕니다. 예를 들어 상담 분류 평균이 95%로 같아도 환불 거부와 승인 경계에서만 오류가 두 배가 되면 운영 후보로 승인할 수 없습니다. Quantization error를 숫자 손실과 실제 의사결정 손실의 두 층으로 측정해야 합니다.

왜 이런가

사용할 수 있는 code 수가 제한되어 여러 원래 값을 같은 근사값으로 보내거나 범위 밖 값을 경계에 잘라야 하기 때문입니다.

언제 문제가 되는가

평균 점수는 유지되지만 숫자·코드·희귀 표현·분류 경계에서만 오답과 형식 오류가 늘 수 있습니다.

초보자가 자주 하는 오해

압축을 풀듯 dequantize하면 원래 FP16 weight를 완전히 복원할 수 있다는 생각은 틀립니다.

직접 확인하는 방법

같은 block의 원래 값·scale·code·복원값·오차를 표로 만들고, 오차가 큰 입력을 업무 회귀 세트에 추가하십시오.

Granularity(세분성)는 하나의 scale을 얼마나 많은 값이 공유하는지를 뜻합니다. Per-tensor는 tensor 전체에 하나, per-channel은 출력 channel마다 하나, per-group 또는 per-block은 일정한 weight 묶음마다 scale을 둡니다. 공유 범위가 작으면 서로 다른 분포와 outlier에 더 잘 맞출 수 있지만 scale 수와 metadata가 늘고, weight packing과 kernel이 그 배치를 지원해야 합니다. 세밀한 granularity가 언제나 공짜로 더 좋은 것은 아닙니다.

Post-Training Quantization(PTQ, 학습이 끝난 모델을 변환하는 양자화)은 calibration sample이나 weight 통계를 이용해 scale과 보호 대상을 정할 수 있습니다. GPTQ 원 논문은 approximate second-order information을 사용하는 one-shot weight quantization을 제안했고, AWQ는 activation 분포를 이용해 중요한 weight channel을 식별하고 scaling으로 보호하는 weight-only 경로를 제안합니다. 이 이름은 모두 “4bit”로 보일 수 있지만 오차를 줄이는 기준과 필요한 runtime kernel이 다릅니다.

Calibration은 실제 업무 분포를 대표해야 하지만 정답 평가 세트와 같은 자료를 그대로 재사용해서는 안 됩니다. 한국어 고객 문의를 운영하면서 영어 일반 문장만으로 중요도를 정하면 한국어 고유명사나 숫자 형식에 민감한 channel을 놓칠 수 있습니다. 반대로 최종 시험 문장을 calibration에 포함하면 candidate가 평가 자료에 맞춰진 결과를 일반화 성능처럼 오해할 수 있습니다. 정상·경계·실패가 섞인 calibration 자료와 독립 evaluation 자료를 버전으로 나눕니다.

운영 장애 사례로 quantizer를 업데이트한 뒤 평균 perplexity는 좋아졌지만 tool call의 JSON key가 자주 틀리는 상황을 생각할 수 있습니다. 복구는 이전 artifact로 rollback한 뒤 quantizer revision, group size, calibration set, 중요도 matrix와 runtime kernel 중 한 항목만 바꿔 비교하는 순서입니다. “같은 Q4”라는 이름만 남기면 원인을 분리할 수 없습니다. Quantization recipe 자체를 model artifact의 일부로 보관해야 합니다.

왜 이런가

Weight와 activation의 분포가 tensor 안에서도 고르지 않아 하나의 scale이 모든 영역을 같은 품질로 표현하지 못할 수 있습니다.

언제 문제가 되는가

새 group size나 calibration 자료를 적용한 뒤 특정 언어·숫자·JSON 형식에서만 회귀가 생기면 recipe 차이를 확인해야 합니다.

초보자가 자주 하는 오해

Group size가 작을수록 file·속도 비용 없이 항상 품질이 좋아진다는 보장은 없습니다.

직접 확인하는 방법

Quantizer revision, scheme, group size, calibration digest, importance matrix, 평균 bits per weight와 하위 평가 결과를 후보마다 고정하십시오.

Weight-only quantization은 주로 model weight를 낮은 bit로 저장하고 계산할 때 activation을 FP16·BF16 같은 더 넓은 type으로 유지합니다. Weight-and-activation quantization은 activation도 INT8·FP8 등으로 줄이며 scale을 삽입하는 위치와 calibration이 더 중요합니다. Accumulator는 여러 곱을 더하는 중간 합이므로 입력과 같은 type이라고 단정할 수 없습니다. “INT4 모델”이라는 이름만으로 어느 tensor와 연산이 어떤 type인지 알 수 없습니다.

Hugging Face의 현재 bitsandbytes 문서도 이 구분을 구체적으로 보여 줍니다. Linear8bitLt와 Linear4bit 계층은 기존 linear layer를 quantized 대안으로 바꾸지만, 기본적으로 LayerNorm 같은 다른 module은 별도 dtype을 사용할 수 있고 CPU로 offload된 weight는 FP32로 유지될 수 있습니다. NF4 저장을 선택해도 compute dtype을 따로 정하는 옵션이 있으므로, library 이름이나 load_in_4bit 표시만 보지 말고 quantization config·device map·module별 dtype을 함께 남겨야 합니다.

속도는 file 크기만으로 결정되지 않습니다. Packed 4bit weight를 GPU가 읽어 지원 kernel에서 효율적으로 dequantize하며 곱할 수 있으면 memory bandwidth 부담이 줄어 빨라질 수 있습니다. 반대로 runtime이 해당 architecture·group size·tensor type을 지원하지 않으면 CPU fallback, 실행 전 변환, 작은 batch의 kernel overhead 때문에 Q4가 Q8이나 FP16보다 느릴 수도 있습니다. 낮은 bit file이 항상 더 빠른 것은 아닙니다.

예를 들어 노트북 내장 GPU에서 7B Q4가 memory에는 들어가지만 지원되지 않는 operator가 CPU로 이동해 첫 token까지 수십 초가 걸릴 수 있습니다. 데스크톱 GPU에서는 같은 file이 전용 kernel로 빠르게 실행될 수 있습니다. 이 차이는 model 지능이 아니라 hardware instruction, driver, backend build와 offload 비율의 차이입니다. 파일명과 GPU 제품명만 비교하지 말고 runtime log에서 실제 backend와 layer 배치를 확인합니다.

공정한 benchmark는 같은 model revision, prompt, context, 출력 token, batch·동시성, sampling과 warm-up 조건을 고정합니다. Peak memory, Time to First Token(TTFT, 첫 token이 나오기까지 걸린 시간), prompt 처리 token/s, 생성 token/s와 전력·온도를 분리해 기록합니다. 한 번의 짧은 생성이나 제조사의 peak TOPS를 실제 대화 속도로 바꾸어 읽지 않습니다. 품질을 통과한 후보 안에서만 성능과 비용을 비교합니다.

왜 이런가

저장 type을 계산하려면 unpack·dequantize와 누적이 필요하고 이 경로를 효율적으로 수행하는 kernel 지원이 장치마다 다르기 때문입니다.

언제 문제가 되는가

낮은 bit 후보가 오히려 느리거나 CPU 사용률이 치솟고 GPU 사용률이 낮으면 fallback과 변환 경로를 확인해야 합니다.

초보자가 자주 하는 오해

4bit weight를 사용하면 activation·KV cache·accumulator까지 모두 자동으로 4bit가 된다고 생각하면 안 됩니다.

직접 확인하는 방법

Runtime log와 profiler에서 weight·activation·cache·accumulator type, offload layer, fallback operator와 실제 token/s를 기록하십시오.

GGUF는 ggml 생태계의 binary model format입니다. 현재 공식 명세는 header의 magic과 version, key-value metadata, 각 tensor의 이름·dimension·type·offset, 정렬 padding과 실제 tensor data를 정의합니다. Architecture, tokenizer, quantization version과 license 같은 metadata를 담을 수 있지만 모든 선택 항목이 반드시 채워지는 것은 아닙니다. GGUF 확장자는 4bit나 특정 품질 등급을 뜻하지 않습니다.

Q4_K_M은 llama.cpp의 K-quant 계열 혼합 구성을 나타내는 이름입니다. 공식 quantize 도구는 `--pure`로 혼합을 끄거나 output·token embedding과 특정 tensor에 별도 quant type을 정하는 옵션을 제공합니다. 따라서 M이 붙은 file은 모든 tensor가 같은 4bit code라는 뜻이 아닙니다. `general.file_type` 같은 다수 type 표기와 각 tensor의 실제 type을 확인해야 “Q4인데 왜 예상보다 큰가”를 설명할 수 있습니다.

변환 기록에는 원본 model ID와 revision·hash, converter와 quantizer commit, 입력 dtype, 목표 quant type, group·importance matrix 설정, output hash를 남깁니다. llama.cpp의 현재 문서는 고정밀 GGUF를 만든 뒤 quantize하는 두 단계를 안내합니다. 이미 낮은 bit인 file을 다시 바꾸는 `--allow-requantize`는 16bit·32bit에서 직접 변환할 때보다 품질을 심하게 낮출 수 있다고 명시합니다. 재양자화는 원본에서 직접 변환하는 것과 다릅니다.

Runtime이 새 architecture나 tensor type을 모르면 unknown architecture, unsupported type, load failure로 즉시 드러날 수 있습니다. 더 위험한 경우는 file은 열리지만 chat template 또는 tokenizer metadata가 맞지 않아 답이 반복되고 종료 token이 동작하지 않는 상황입니다. 복구할 때 임의 metadata override로 덮기 전에 검증한 runtime build와 원본 artifact 묶음으로 돌아갑니다. Loader log, GGUF metadata dump와 동일 회귀 prompt를 함께 비교합니다.

왜 이런가

Format은 여러 architecture·metadata·tensor type을 담는 그릇이고 quantization은 그 안의 숫자 표현 recipe이므로 서로 다른 층입니다.

언제 문제가 되는가

Unsupported tensor 오류, CPU fallback, 반복 출력이나 예상 밖 file 크기가 나타나면 runtime·metadata·tensor type과 변환 기록을 대조해야 합니다.

초보자가 자주 하는 오해

확장자가 `.gguf`이거나 이름에 Q4_K_M이 있으면 출처·호환성·품질이 자동 검증되었다는 뜻이 아닙니다.

직접 확인하는 방법

원본 revision·converter/quantizer commit·명령·metadata dump·tensor type 분포·hash·runtime build를 한 manifest에 저장하십시오.

Model을 실행할 때는 GPU에 offload된 weight 외에 이미 읽은 token의 Key와 Value를 저장하는 KV cache, attention과 matrix kernel의 workspace, graph와 allocator가 예약한 영역, multimodal projector와 다른 process가 쓰는 memory가 필요합니다. CPU offload를 사용하면 system RAM과 GPU VRAM의 두 예산, 두 장치 사이 전송 지연을 함께 봐야 합니다. Disk file 크기와 실행 peak를 같은 값으로 놓지 않습니다.

Context와 동시 sequence는 KV cache를 키웁니다. 같은 model과 weight quantization에서도 2K 질문 하나와 32K 문서 두 개를 동시에 처리하는 구성은 요구량이 크게 다릅니다. Cache dtype도 weight dtype과 독립적일 수 있습니다. Q4 weight를 선택했다고 KV cache가 자동으로 4bit가 되지 않습니다. 최대 context라는 제품 표의 수치를 보려면 해당 context에서 필요한 cache와 prompt 처리 시간을 실제 장비에 넣어야 합니다.

Out of Memory가 발생하면 오류 직전의 model·quant·runtime·driver, context·최대 출력·동시 요청, GPU allocated·reserved와 system RAM을 먼저 저장합니다. 동시 요청을 1개로 만들고 context와 출력 예약을 줄여 작은 기준선을 만든 뒤 한 번에 변수 하나만 바꿉니다. 그래도 실패하면 offload, 더 작은 model 또는 낮은 bit를 검토합니다. 실행된다는 이유로 즉시 원래 부하를 복원하지 않고 peak와 지연을 비교합니다.

작은 팀의 장애 복구 사례를 생각해 보겠습니다. 12GB GPU에서 8B Q5를 운영하다 runtime 업데이트 뒤 OOM이 시작됐다면 곧바로 Q3로 바꾸지 않습니다. 이전 runtime과 같은 입력을 재실행하고 allocator·workspace 변화인지 확인합니다. Context를 낮춰 복구한 뒤 update와 quant 중 하나만 바꿔 원인을 분리합니다. VRAM 100%는 안정적인 운영 목표가 아닙니다. 예상 입력 변화와 monitoring 도구가 사용할 여유를 남깁니다.

왜 이런가

생성은 가중치를 읽는 일 외에도 과거 token 상태와 계산 중간값을 보관하므로 입력 길이와 동시성에 따라 memory가 변합니다.

언제 문제가 되는가

짧은 질문은 되지만 긴 문서·동시 요청·runtime 업데이트에서 OOM이 나는 증상은 weight 외 예산을 측정해야 합니다.

초보자가 자주 하는 오해

파일이 VRAM보다 작으면 모든 context와 동시 요청에서 안정적으로 실행된다는 결론은 성립하지 않습니다.

직접 확인하는 방법

최소·대표·최장 입력과 동시성 1·목표값에서 load 직후·prefill peak·generation peak·system RAM을 반복 측정하십시오.

먼저 높은 정밀도 baseline의 정확한 model revision, tokenizer, chat template, runtime과 prompt를 고정합니다. Candidate에서는 quantization만 바꾸고 같은 정상·경계·실패 입력, sampling seed와 출력 한도를 사용합니다. 업무 정답이 하나가 아니라면 두 명 이상이 rubric으로 blind review하고 model 이름을 가립니다. Quantized 후보가 더 짧게 답해 우연히 점수가 높아지는 일을 막으려면 근거·누락·형식·안전 항목을 따로 채점합니다.

승인 기준은 결과를 보기 전에 정합니다. 예를 들어 정확도 하락 1 percentage point 이하, JSON 형식 준수 99.5% 이상, 위험 답변 증가 0건, peak memory 25% 이상 감소, p95 첫 token 지연 2초 이하처럼 품질과 자원을 함께 적습니다. Candidate가 memory만 통과하고 형식 준수에 실패하면 보류입니다. 결과를 본 뒤 허용치를 낮추면 gate가 아니라 선택한 결론을 꾸미는 숫자가 됩니다.

평균 하나가 하위 집합의 실패를 숨기게 두지 않습니다. 전체 500건 정확도는 같아도 긴 숫자, 코드, 희귀한 한국어 이름, 긴 context, tool schema 50건에서 오류가 크게 늘 수 있습니다. 각 하위 집합에 최소 통과선을 두고 실패 문장을 regression corpus에 추가합니다. 평가 자료 자체의 오답과 중복도 검토해야 quantization 손실과 잘못된 정답표를 혼동하지 않습니다.

마지막으로 rollback을 실제로 시험합니다. 후보 artifact를 중단하고 이전 hash·runtime·template 묶음을 다시 올려 같은 실패 입력이 회복되는지 확인합니다. 승인 기록에는 source revision, quant recipe, file hash, 평가 결과, peak memory, 측정 장비, known limitation과 책임자를 남깁니다. 실습에서 baseline과 candidate 수치를 입력해 실패→기준 충족 복구를 수행하지만, 그 브라우저 결과는 실제 model 시험 증빙을 대신하지 않습니다.

왜 이런가

양자화 이익과 손실은 model·업무·runtime마다 달라 file 크기나 공개 평균만으로 내 배포 결과를 예측할 수 없기 때문입니다.

언제 문제가 되는가

평균은 같지만 중요한 경계 입력과 JSON 형식에서 회귀하거나 rollback artifact가 재현되지 않으면 승격할 수 없습니다.

초보자가 자주 하는 오해

Perplexity 변화가 작거나 model이 정상 load되면 실제 업무 품질도 자동으로 같다는 뜻이 아닙니다.

직접 확인하는 방법

사전 합의한 하위 집합별 품질·형식·안전·메모리·지연 gate를 같은 평가 묶음으로 실행하고 이전 artifact 복구까지 기록하십시오.

개인 PC를 고를 때는 “몇 B까지 돌아가는가”보다 실제로 할 일을 먼저 씁니다. 하루에 짧은 질문 몇 번을 하는지, 50쪽 문서를 한 번에 읽힐지, code completion처럼 지연이 짧아야 하는지, 음성과 이미지가 필요한지를 구분합니다. 그다음 model revision과 quant 후보, context, 동시 sequence 1에서 필요한 memory를 계산합니다. 실행 가능과 일상적으로 사용 가능은 다릅니다. Fan 소음, 전력, 발열과 첫 token 지연이 생활 조건을 넘으면 memory에 들어가도 적합한 구성이 아닙니다.

예를 들어 8GB VRAM 노트북에서 7B Q4와 Q5를 비교한다면 Q5가 품질에서 조금 낫다는 공개 평균만 보고 선택하지 않습니다. 동일한 한국어 문서와 출력 길이로 Q4·Q5의 peak, 첫 token 지연, 지속 생성 속도와 온도를 반복 측정합니다. Q5가 열 때문에 몇 분 뒤 느려지거나 목표 context에서 여유가 없다면 Q4가 더 안정적일 수 있습니다. 반대로 Q4에서 제품 코드와 숫자 오류가 허용선을 넘으면 작은 model의 더 높은 precision도 비교해야 합니다.

작은 팀의 API 서버에서는 평균 한 요청이 아니라 동시에 들어오는 요청과 가장 긴 입력을 봅니다. 한 사용자 시험에서 20% 여유가 있어도 네 요청의 KV cache와 scheduler workspace가 겹치면 OOM이 날 수 있습니다. 새 quant를 올릴 때는 일부 traffic만 candidate에 보내고 오류율, queue, p95 지연, peak memory와 하위 집합 품질을 관찰합니다. 장애가 늘면 자동으로 더 낮은 bit로 바꾸는 대신 이전 검증 artifact로 되돌린 뒤 부하와 품질 원인을 분리합니다.

구매와 배포 기록은 같은 표를 사용할 수 있습니다. 요구 업무와 실패 비용, model·tokenizer·template revision, quant scheme과 group, 실제 file byte, runtime·driver·장비, context·동시성, 품질과 형식 gate, peak·지연, 전력·온도, license와 rollback 위치를 적습니다. 빈칸이 많으면 더 큰 GPU나 더 작은 file을 결정할 단계가 아닙니다. 장비 가격만 있는 비교표와 model benchmark만 있는 표를 합쳐야 전체 비용과 위험을 볼 수 있습니다.

Quantization 변경도 운영 배포 변경입니다. 변환 도구가 새 버전이 되거나 calibration 자료, importance matrix, group size, cache dtype과 kernel이 달라지면 같은 Q4 이름이라도 새 후보로 취급합니다. 이전과 동일한 평가와 부하 시험을 다시 실행하고 known limitation을 갱신합니다. 이 계약을 지키면 “더 작으니 더 좋다”와 “높은 precision이니 안전하다”라는 두 극단을 피하고, 품질 기준을 만족하는 가장 단순하고 복구 가능한 조합을 선택할 수 있습니다.

운영 보고에서는 성공한 숫자만 남기지 않습니다. 어떤 입력에서 기준을 넘지 못했는지, memory 절감과 함께 어떤 품질 비용이 생겼는지, 보류한 후보와 되돌린 이유를 기록합니다. 다음 담당자는 이 기록으로 낮은 bit를 다시 시험할 가치가 있는지, 장비를 늘려 높은 정밀도를 유지할지, context나 동시성 요구를 바꿀지 판단할 수 있습니다. 실패 결과를 지우면 같은 quant를 다른 이름으로 반복 시험하고, 사용자에게서 같은 오류를 다시 발견하게 됩니다. 승인하지 않은 후보도 재현 조건과 폐기 이유를 남기는 것이 교육 실습과 실제 변경 관리의 마지막 단계입니다. 다시 시험할 날짜와 필요한 추가 증거도 함께 정합니다.

왜 이런가

실용 결과는 model weight뿐 아니라 context·동시성·runtime·장비의 지속 성능과 업무 허용 오차가 함께 결정하기 때문입니다.

언제 문제가 되는가

한 번은 실행되지만 장시간 사용에서 느려지거나, 여러 사용자에서 OOM이 나고, 도구 업데이트 뒤 같은 Q4가 다른 품질을 보일 수 있습니다.

초보자가 자주 하는 오해

가장 낮은 bit가 항상 효율적이거나 가장 높은 precision이 항상 최선이라는 단일 순위는 없습니다.

직접 확인하는 방법

개인 장비는 지속 부하·소음·온도를, 팀 서버는 목표 동시성·queue·p95·rollback을 같은 품질 평가와 함께 반복 측정하십시오.

Context window(문맥 창)는 모델이 한 번의 요청에서 함께 참고할 수 있는 token의 최대 범위입니다. 사용자가 입력창에 쓴 질문만 세는 값이 아닙니다. 애플리케이션이 앞에 붙이는 system 지침, 역할을 표시하는 control token, 이전 대화, Retrieval-Augmented Generation(RAG, 검색 증강 생성)이 가져온 문서, tool schema와 결과, 현재 질문과 새로 생성할 답이 모두 같은 예산을 사용합니다. 대화가 끝난 뒤 이 묶음을 다시 보내지 않으면 모델은 앞 요청을 자동으로 기억하지 못합니다. 채팅 앱이 history를 저장해 다음 요청에 붙이기 때문에 영구 기억처럼 보이는 것입니다.

예를 들어 8,192 token 한도에서 system·template 600, 대화 기록 2,400, 검색 문서 3,800, 질문 400, 출력 예약 1,600을 잡으면 합계는 8,800으로 이미 608 token 초과합니다. 사용자가 화면에서 보는 질문은 400 token뿐이므로 “짧게 썼는데 왜 거절됐지?”라고 느낍니다. 검사 지점은 입력창이 아니라 chat template이 완성된 뒤 model 호출 직전입니다. 구성 요소별 token을 실제 tokenizer로 측정하고 출력 공간을 먼저 예약해야 답이 중간에 잘리지 않습니다.

최대 context라는 model card의 숫자도 권장 사용량이나 내 업무 품질을 보증하지 않습니다. Meta의 Llama 3.1 공식 model card는 128K context를 명시하지만, 그 숫자가 개인 GPU에서 128K를 빠르고 안정적으로 처리한다거나 한국어 장문에서 중요한 조건을 놓치지 않는다는 뜻은 아닙니다. 입력이 길면 prefill 계산 시간과 KV cache가 늘고, 관련 없는 문장이 중요한 근거를 밀어낼 수 있습니다. 공식 상한, runtime이 허용하는 상한, 내 장비의 메모리 상한과 업무 합격선을 서로 다른 값으로 기록합니다.

개인 문서 요약에서는 파일 전체를 무조건 넣기보다 제목과 절 구조를 보존해 필요한 부분을 찾고, 작은 팀의 상담 앱에서는 오래된 대화를 요약하되 현재 질문과 안전 지침은 보존합니다. 초과할 때 system 규칙부터 지우거나 질문을 임의로 잘라 맞추면 실행은 되어도 다른 업무가 됩니다. 줄일 우선순위를 미리 정하고 같은 질문·정답 기준으로 품질을 다시 확인해야 context 절약이 단순한 정보 손실로 바뀌지 않습니다.

왜 이런가

애플리케이션이 화면 밖 입력을 합치고 생성 결과도 같은 sequence 뒤에 이어지므로 사용자가 본 문자 수와 model이 처리하는 token 수가 다르기 때문입니다.

언제 문제가 되는가

짧은 질문인데 context 초과가 나거나 답이 중간에 잘리고, 대화가 길어질수록 갑자기 요청이 거절될 때 최종 prompt 구성과 출력 예약을 확인해야 합니다.

초보자가 자주 하는 오해

Context가 길수록 모델이 더 똑똑하거나 이전 대화를 영구히 기억한다는 뜻은 아닙니다.

직접 확인하는 방법

System·template·history·검색 문서·tool·질문·출력 예약을 실제 tokenizer로 각각 재고 합계와 제거 우선순위를 기록하십시오.

Autoregressive generation(자기회귀 생성)은 답을 한 token씩 이어 만듭니다. Prompt 전체를 처음 처리하는 prefill 단계에서는 각 위치의 hidden state로 Query, Key와 Value를 계산하고 attention을 수행합니다. 그다음 decode 단계에서 새 token 하나를 만들 때는 새 위치의 Query가 과거 모든 위치의 Key·Value를 참고합니다. 과거 Key·Value를 매번 처음부터 계산하면 같은 행렬 연산을 반복하므로 응답이 길어질수록 낭비가 커집니다. Key-Value cache(KV cache, 이전 token의 attention 중간 상태 저장소)는 이 과거 값을 보관해 재사용합니다.

비유하면 긴 회의록에서 새 문장을 쓸 때마다 처음부터 모든 참석자의 발언을 다시 요약하는 대신, 각 발언의 찾아보기 표를 옆에 계속 쌓아 두는 방식입니다. 새 문장이 생기면 그 문장의 표만 추가하고 이전 표를 참조합니다. 계산은 줄지만 찾아보기 표 자체가 자리를 차지합니다. 대화가 길거나 여러 사용자의 회의록을 동시에 유지하면 표가 커지는 것처럼 token과 sequence 수가 늘면 cache memory도 늘어납니다.

KV cache는 model weight와 다른 생명주기를 가집니다. 같은 Q4 weight file을 계속 사용해도 prompt가 2K에서 32K로 늘면 cache는 커질 수 있고, weight가 4bit라고 cache가 자동으로 4bit가 되지도 않습니다. Cache dtype은 runtime과 설정에 따라 FP16·BF16 또는 quantized type일 수 있습니다. 그래서 다운로드한 file 크기와 긴 대화 중 GPU memory 증가가 다른 숫자로 보입니다. Disk file이 변하지 않았다는 사실은 memory leak이 없다는 증거도, cache가 작다는 증거도 아닙니다.

Cache를 끄면 memory가 줄 수 있지만 매 decode 단계에서 과거 Key·Value를 다시 계산해야 해 속도가 크게 떨어질 수 있습니다. Hugging Face 공식 문서도 cache를 반복 계산을 줄여 생성 응답을 개선하는 장치로 설명합니다. 장애 대응에서 무조건 cache를 비활성화하는 것은 작은 재현 시험에는 쓸 수 있어도 일반 운영의 첫 해법은 아닙니다. Cache가 예상대로 해제되는지, 요청 종료 뒤 memory allocator가 재사용 영역을 보유하는지와 실제 지연을 함께 측정해야 합니다.

왜 이런가

다음 token은 앞선 모든 token의 attention 상태를 참고하므로 과거 Key·Value를 저장하면 같은 투영 계산을 다시 하지 않아도 됩니다.

언제 문제가 되는가

긴 생성에서 memory가 계속 늘거나 cache를 끈 뒤 token 생성이 급격히 느려지면 저장과 반복 계산의 trade-off를 보고 있는 것입니다.

초보자가 자주 하는 오해

KV cache는 모델의 영구 지식이나 대화 데이터베이스가 아니며 요청의 attention 상태를 잠시 보관하는 실행 memory입니다.

직접 확인하는 방법

같은 prompt와 출력 길이에서 cache 사용 전후의 peak memory, prefill 시간, decode token/s와 요청 종료 뒤 memory 변화를 기록하십시오.

표준적인 decoder-only attention을 단순화한 KV cache byte 식은 `2 × layer 수 × KV head 수 × head dimension × 저장 token 수 × 원소당 byte × 동시 sequence 수`입니다. 앞의 2는 Key와 Value 두 묶음을 뜻합니다. 32 layer, 8 KV head, head dimension 128, 8,192 token, FP16 2byte와 sequence 1을 넣으면 2×32×8×128×8,192×2=1,073,741,824byte, 즉 1GiB입니다. 같은 조건에서 4개 sequence를 동시에 유지하면 단순 cache 항목은 4GiB가 됩니다.

이 계산에서 가장 자주 틀리는 값은 KV head입니다. Config의 `num_attention_heads`는 Query head 수일 수 있고 Grouped-Query Attention(GQA, 여러 Query head가 더 적은 Key·Value head를 공유하는 방식)에서는 `num_key_value_heads`가 따로 있습니다. Hidden size를 Query head 수로 나눈 값이 흔한 head dimension이지만 일부 architecture는 `head_dim`을 명시하거나 다른 latent 구조를 씁니다. 모델 이름이나 B 숫자로 추측하지 말고 정확한 revision의 config와 구현을 확인합니다.

Token 수도 “사용자가 입력한 최대 길이” 하나가 아닙니다. Prefill 입력과 생성된 token이 cache에 함께 쌓이고, batch 안의 sequence가 padding 또는 별도 page로 관리될 수 있습니다. Beam search나 여러 후보 생성은 일반적인 단일 sequence와 다른 cache 배수를 만들 수 있습니다. Sliding-window attention은 window에 도달한 layer의 cache 증가가 멈출 수 있고 chunked attention, encoder-decoder, Multi-head Latent Attention(MLA, Key·Value를 더 작은 잠재 표현으로 다루는 구조)은 단순 식과 다릅니다.

따라서 계산기는 첫 예산과 원인 설명에 쓰고 구매 보증으로 사용하지 않습니다. 식의 각 숫자 옆에 출처를 적고 byte 결과를 GiB로 변환한 뒤 runtime의 실제 cache allocation과 비교합니다. 차이가 나면 식을 억지로 맞추지 말고 alignment, page block, static preallocation, sliding layer, cache dtype, graph workspace와 allocator 예약을 찾아냅니다. 계산값·관찰값·차이 원인을 한 표에 남기면 runtime update 뒤 변화를 재현할 수 있습니다.

왜 이런가

각 layer가 모든 저장 token과 sequence에 대해 Key와 Value head vector를 보관하므로 여섯 차원의 곱으로 크기가 늘어납니다.

언제 문제가 되는가

Query head를 넣어 과대 계산하거나 weight bit를 cache byte로 넣어 과소 계산하면 장비 예산과 동시성 한도가 크게 빗나갑니다.

초보자가 자주 하는 오해

모든 모델의 KV cache가 이 식과 정확히 같거나 Q4 model이면 원소당 0.5byte라고 가정하면 안 됩니다.

직접 확인하는 방법

Config의 layer·num_key_value_heads·head_dim, runtime cache dtype, 실제 token과 sequence를 넣고 peak cache 지표와 차이를 설명하십시오.

Multi-Head Attention(MHA, 다중 머리 attention)은 일반적으로 Query head마다 대응하는 Key·Value head를 둡니다. Multi-Query Attention(MQA, 다중 질의 공유 attention)은 여러 Query head가 하나의 KV head 집합을 공유합니다. Grouped-Query Attention(GQA, 그룹 질의 attention)은 그 사이에서 여러 Query head 묶음이 몇 개의 KV head를 공유합니다. GQA 원 논문은 KV head 수가 하나보다 많고 Query head 수보다 적은 중간 구성을 설명합니다. 이 차이는 생성 중 읽고 저장할 KV vector 수에 직접 영향을 줍니다.

32 Query head와 8 KV head인 GQA를 같은 layer·head dimension·token·byte 조건의 32 KV head MHA와 비교하면 단순 KV 항목은 8/32, 즉 25%입니다. 네 Query head가 한 KV head 묶음을 공유한다고 볼 수 있습니다. 하지만 model 전체 VRAM도 25%가 되는 것은 아닙니다. Embedding, feed-forward network, Query와 output projection, quantized weight, graph와 workspace는 그대로 남습니다. GQA의 이득을 전체 model 압축률로 바꾸어 말하면 장비를 과소 산정합니다.

실제 제품 사례로 Meta Llama 3.1 model card는 8B·70B·405B가 모두 GQA를 사용하고 128K context를 지원한다고 명시합니다. 이것은 model family의 구조와 공식 context 사실을 확인하는 근거입니다. 그러나 각 크기의 실제 KV head 수, cache dtype, consumer GPU에서 128K의 peak와 속도는 config와 runtime으로 다시 확인해야 합니다. Model card의 “GQA Yes” 한 칸만으로 cache byte를 계산할 수 없습니다.

변환한 checkpoint의 config에서 `num_key_value_heads`를 잘못 적으면 tensor shape가 맞지 않아 load가 실패하거나 runtime이 지원하지 않는 배치를 해석하지 못할 수 있습니다. 반대로 계산기만 잘못된 경우 model은 정상 실행되지만 운영자가 동시 사용자를 너무 많이 허용해 OOM을 만듭니다. 원본 config, weight tensor shape, runtime load log와 계산 manifest를 함께 대조해야 구조 오류와 예산 오류를 분리할 수 있습니다.

왜 이런가

생성 단계의 memory bandwidth와 cache는 과거 Key·Value를 읽는 비용이 크므로 여러 Query가 더 적은 KV head를 공유하면 이 부분을 줄일 수 있습니다.

언제 문제가 되는가

GQA 모델의 Query head 수를 cache 식에 넣거나 GQA 비율을 model 전체 memory에 적용하면 context와 동시성 예산이 틀립니다.

초보자가 자주 하는 오해

GQA가 attention 계산이나 model 가중치 전체를 같은 비율로 줄이는 기능이라고 해석하지 않습니다.

직접 확인하는 방법

Model card의 구조 설명과 정확한 config의 Query·KV head를 대조하고 MHA 대비 KV 항목 비율과 전체 peak 변화를 따로 측정하십시오.

Hugging Face Transformers의 현재 공식 문서에서 DynamicCache는 생성이 진행되며 Key·Value 저장 공간이 동적으로 자라는 기본 전략입니다. 실제 token만큼 늘어나는 점은 이해하기 쉽지만 shape가 변하므로 일부 Just-In-Time(JIT, 실행 직전 최적화) 경로와 맞지 않을 수 있습니다. StaticCache는 정한 최대 길이의 공간을 미리 할당해 compile 가능한 고정 shape를 만들 수 있습니다. 대신 짧은 요청에도 큰 최대 공간을 잡고 사용하지 않는 token 위치가 attention 계산에서 mask되는 낭비가 생길 수 있습니다.

같은 32K 최대치라도 요청 대부분이 28~32K라면 static preallocation과 compile의 지연 이익이 도움이 될 수 있습니다. 반대로 한 달에 한 번 32K 문서가 있고 나머지가 1K 대화라면 모든 요청이 큰 static cache를 쓰는 구성이 비효율적일 수 있습니다. “Static이 빠르다”나 “Dynamic이 memory를 적게 쓴다”라는 한 줄 대신 실제 길이 분포, cold·warm latency, peak와 동시에 유지할 sequence 수를 측정합니다.

Sliding-window attention은 각 위치가 최근 일정 window만 참고하도록 설계되어 해당 layer의 cache가 window 크기에 도달하면 더 자라지 않을 수 있습니다. Chunked attention도 layer별 상한을 만들 수 있습니다. 그러나 model이 이런 구조를 쓰지 않는데 runtime 옵션만으로 과거 정보를 잘라 같은 품질을 기대하면 안 됩니다. 어떤 layer가 full attention이고 어떤 layer가 local인지, 공식 config와 implementation이 cache를 어떻게 제한하는지 확인해야 합니다.

Cache 전략 변경 뒤 결과가 달라지면 memory 숫자만 보지 않습니다. Static maximum이 실제 입력보다 작은지, attention mask와 position이 올바른지, sliding 범위 밖의 근거가 필요한 평가에서 품질이 떨어지는지, compile 재사용이 되는지 확인합니다. 긴 계약서의 첫 장 조건과 마지막 장 결론을 연결해야 하는 업무는 최근 window만 보는 구성에서 실패할 수 있습니다. 대표·경계·최장 입력을 같은 정답 기준으로 비교합니다.

왜 이런가

동적 증가는 실제 길이에 맞지만 shape가 변하고, 정적 할당은 compile하기 쉽지만 짧은 요청에도 최대 공간과 mask 계산을 사용할 수 있기 때문입니다.

언제 문제가 되는가

짧은 요청 위주인데 static maximum 때문에 peak가 커지거나 sliding window 밖의 중요한 근거를 놓치면 전략과 업무가 맞지 않습니다.

초보자가 자주 하는 오해

특정 cache class가 모든 모델과 모든 입력 길이에서 항상 가장 빠르고 memory가 적다는 순위는 없습니다.

직접 확인하는 방법

요청 길이 백분위, dynamic·static의 cold/warm 지연과 peak, sliding layer의 실제 cache 상한과 장문 품질을 같은 runtime version에서 측정하십시오.

Offloaded cache는 여러 layer의 KV 상태를 Central Processing Unit(CPU, 중앙 처리 장치) memory로 옮겨 GPU Video Random Access Memory(VRAM, GPU 전용 메모리) 부담을 줄이는 전략입니다. GPU에서 완전히 사라지는 것이 아니라 현재 계산에 필요한 layer 상태를 장치 사이에 가져와야 하므로 Peripheral Component Interconnect Express(PCIe, CPU와 장치를 연결하는 고속 통로) 전송과 system RAM이 필요합니다. VRAM 절감은 GPU 밖 memory와 전송 지연으로 비용을 옮긴 것입니다.

Quantized cache는 Key·Value 원소를 INT4·INT8 같은 낮은 정밀도로 저장해 cache byte를 줄일 수 있습니다. Weight quantization과 별도 설정이고 runtime이 지원하는 backend·axis·residual 구성이 필요합니다. Hugging Face 공식 문서는 QuantizedCache가 memory를 줄이는 반면, context가 짧고 GPU memory가 충분한 경우 양자화·복원 과정 때문에 latency가 나빠질 수 있다고 경고합니다. Cache를 낮은 bit로 바꿨다는 사실만으로 무조건 더 빠르다고 보고하지 않습니다.

개인 PC 사례로 12GB GPU에서 8B Q4 weight는 들어가지만 32K cache 때문에 OOM이 난다면 먼저 context와 출력 예약을 줄여 기준선을 만듭니다. 그다음 offloaded cache와 quantized cache를 각각 같은 prompt로 비교합니다. Offload가 2GiB VRAM을 줄였지만 첫 token 지연이 두 배가 될 수 있고, cache quantization이 숫자·code 하위 평가를 나쁘게 만들 수 있습니다. 두 기능을 동시에 켜면 원인을 분리하기 어려우므로 한 번에 하나만 바꿉니다.

복구 계획도 설정과 함께 만듭니다. 새 cache backend가 unsupported type, 느린 fallback 또는 품질 회귀를 만들면 이전 dynamic FP16 cache 설정으로 즉시 되돌릴 수 있어야 합니다. Candidate의 runtime build, cache implementation·dtype, axis와 residual length, system RAM, PCIe 전송, peak VRAM, TTFT와 하위 평가 결과를 manifest에 남깁니다. Memory를 확보했어도 목표 latency와 품질을 넘지 못하면 운영 후보가 아닙니다.

왜 이런가

Offload는 저장 위치를 GPU 밖으로 옮기고 quantization은 원소당 byte를 줄이지만 각각 전송과 수치 변환이라는 새 작업을 만들기 때문입니다.

언제 문제가 되는가

VRAM은 줄었는데 TTFT가 급증하거나 CPU memory·전송이 병목이 되고, 특정 경계 입력 품질이 떨어질 수 있습니다.

초보자가 자주 하는 오해

Cache offload와 quantization은 공짜 memory이거나 weight quantization을 선택하면 자동 적용되는 기능이 아닙니다.

직접 확인하는 방법

동일 prompt·출력·동시성에서 기본·offloaded·quantized 후보의 VRAM, system RAM, 전송, TTFT, token/s와 하위 품질을 한 항목씩 비교하십시오.

Batch는 여러 입력을 묶어 한 번에 계산 장치로 보내는 단위이고 concurrency(동시성)는 서비스가 동시에 진행하는 요청 수입니다. Runtime은 여러 sequence의 prefill이나 decode token을 연속 batching으로 묶을 수 있습니다. GPU 행렬 연산을 더 채워 전체 throughput을 높일 수 있지만 각 sequence의 KV cache와 scheduler metadata가 필요하고, 긴 요청 하나가 짧은 요청의 대기와 memory에 영향을 줄 수 있습니다. 한 사용자 token/s가 좋다는 사실은 여러 사용자의 p95 latency가 좋다는 뜻이 아닙니다.

32 layer·8 KV head 조건에서 8K cache가 sequence당 단순 1GiB라면 네 요청은 cache만 4GiB입니다. 실제 서비스에서는 요청마다 길이가 다르고 prefill workspace, page block의 빈칸, weight와 다른 process도 공간을 씁니다. 24GB GPU에 Q4 weight 10GiB가 있어 14GiB가 남는다고 해서 14명의 1GiB 요청을 허용할 수 없습니다. Traffic burst, 출력 증가와 allocator 변동을 견딜 여유를 남겨야 합니다.

작은 팀의 문서 상담 API라면 동시 사용자 1·2·4·8을 차례로 늘리며 queue length, Time to First Token(TTFT, 첫 token까지 걸린 시간), generation token/s, peak VRAM과 오류율을 기록합니다. 긴 문서와 짧은 질문을 섞고 취소된 요청의 cache가 실제로 해제되는지도 봅니다. 처리량만 높이려고 batch를 키웠다가 한 사용자의 대기 시간이 업무 목표를 넘으면 scheduler와 상한을 다시 조정합니다.

운영 한도는 물리 최대치보다 낮게 둡니다. 사용자별 input·output token, 동시 요청, queue와 timeout을 제한하고 초과 요청에는 명확한 재시도 안내를 제공합니다. OOM이 난 뒤 자동으로 더 많은 요청을 재시도하면 장애가 증폭됩니다. Admission control(수용 제어, 처리 가능한 요청만 받는 장치)이 현재 cache와 queue 상태를 보고 새 요청을 보류하고, 필요하면 작은 model 또는 짧은 context 경로로 안전하게 낮추도록 설계합니다.

왜 이런가

각 진행 중 sequence가 자기 문맥의 KV 상태를 보유하고 runtime이 여러 sequence를 묶고 대기시키므로 memory와 지연이 함께 변합니다.

언제 문제가 되는가

단일 사용자 시험은 통과하지만 네 명부터 OOM·queue 급증·취소 지연이 생기면 동시성 예산과 admission control이 부족합니다.

초보자가 자주 하는 오해

Batch를 늘리면 모든 사용자의 응답이 같은 비율로 빨라지거나 남은 VRAM을 cache 단위로 나누면 안전한 사용자 수가 나온다고 생각하면 안 됩니다.

직접 확인하는 방법

실제 길이 분포를 섞어 동시성 단계별 cache·workspace·queue·TTFT·token/s·오류와 취소 뒤 회복을 측정하십시오.

Out of Memory(OOM, 메모리 부족)는 GPU나 system memory에 weight, KV cache, runtime workspace, graph, allocator 예약과 다른 process 사용량을 모두 담지 못한 상태입니다. 첫 대응은 값을 마구 낮추는 것이 아니라 오류 직전의 model·tokenizer·runtime·driver, cache implementation·dtype, input·output token, 동시 sequence, GPU allocated·reserved, system RAM과 log를 보존하는 일입니다. 이 증거가 없으면 weight 문제인지 cache 증가인지 runtime update의 workspace 변화인지 분리할 수 없습니다.

복구는 동시 요청을 1개로 만들고 context와 최대 출력을 줄인 작은 기준선에서 시작합니다. 이 상태도 실패하면 실제 weight와 다른 process, runtime load를 확인합니다. 기준선이 성공하면 context, 출력, 동시성을 한 번에 하나씩 원래 목표로 늘립니다. Cache quantization, offload와 더 작은 model을 동시에 켜지 않습니다. 어느 변화가 memory를 줄였고 지연·품질에 어떤 비용을 만들었는지 관찰할 수 있어야 합니다.

운영 장애 사례로 12GB GPU의 8B Q4 서비스가 runtime update 뒤 16K 두 요청에서만 OOM이 났다고 하겠습니다. 즉시 Q3 model로 바꾸기 전에 이전 runtime·동일 artifact·동일 입력으로 회귀 여부를 확인합니다. 새 version의 static preallocation이나 workspace가 원인이라면 context를 8K로 낮춘 임시 한도로 복구하고 이전 build로 rollback할 수 있습니다. Q3로 바꾸면 cache 문제가 가려지고 업무 품질이라는 새 변수가 생깁니다.

종료 조건은 “한 번 실행됨”이 아닙니다. 최소·대표·최장 입력, 동시성 1과 목표값에서 여러 번 실행해 peak와 p95 지연이 한도 안에 있고, 정답·근거·형식 품질이 유지되며, 취소와 rollback 뒤 같은 실패 입력이 회복돼야 합니다. Runbook에는 증상, 먼저 볼 지표, 안전한 임시 한도, 변경 순서, 이전 artifact·runtime 위치와 동일 조건 재검증을 적습니다. 다음 담당자가 같은 숫자로 복구할 수 있어야 장애가 끝난 것입니다.

왜 이런가

OOM은 여러 memory 층의 합과 입력·동시성에 따라 생기므로 증거를 보존하고 작은 성공 상태에서 변수 하나씩 확대해야 원인을 찾을 수 있습니다.

언제 문제가 되는가

여러 설정을 동시에 낮춰 잠시 실행되지만 품질·속도 저하의 원인을 모르고 traffic이 돌아오면 다시 OOM이 날 수 있습니다.

초보자가 자주 하는 오해

더 낮은 weight bit나 프로그램 재시작만으로 cache·workspace·동시성 원인이 해결되었다고 결론 내리지 않습니다.

직접 확인하는 방법

오류 조건을 고정하고 기준선→context→출력→동시성 순서의 표를 만든 뒤 같은 최장 입력과 rollback으로 peak·지연·품질 회복을 확인하십시오.

여러 요청이 동일한 system prompt, 도구 설명 또는 문서 앞부분으로 시작하면 runtime은 공통 prefix에서 계산한 Key·Value를 보관했다가 다음 요청의 prefill에 재사용할 수 있습니다. 예를 들어 6,000 token짜리 사내 규정 앞부분이 매 질문마다 완전히 같다면 그 구간을 매번 다시 계산하지 않아 Time to First Token(TTFT)을 줄일 여지가 있습니다. 그러나 “문장이 비슷하다”는 조건으로 재사용하는 것이 아닙니다. Tokenizer를 거친 token id 배열과 위치, model·adapter·cache dtype, attention 구현이 호환되는 prefix만 같은 계산 상태로 취급할 수 있습니다.

Chat template의 공백이나 role marker 하나, system prompt의 날짜 한 글자, tokenizer revision, LoRA adapter 또는 model weight가 바뀌어도 뒤의 Key·Value는 같은 상태가 아닙니다. Cache key에는 model artifact와 tokenizer·template revision, 실행 설정, prefix token hash를 포함하고 그중 하나가 바뀌면 이전 항목을 무효화해야 합니다. 문자열 hash만 같고 template version이 다른 cache를 돌려쓰면 오류가 즉시 나지 않으면서 답변 품질과 권한 문맥만 어긋나는 어려운 장애가 생길 수 있습니다.

재사용 범위는 성능보다 보안 경계를 먼저 따릅니다. 공개 system prompt처럼 모든 사용자에게 동일한 내용은 공유 후보가 될 수 있지만, 사용자 이름·권한·검색 결과·비공개 문서나 secret이 들어간 prefix를 다른 tenant가 참조해서는 안 됩니다. 조직과 사용자 권한, data classification을 cache namespace에 반영하고 로그에도 원문 대신 안전한 식별자만 남깁니다. 삭제 요청이나 권한 회수 뒤에는 해당 prefix와 파생 entry가 수명 만료를 기다리지 않고 제거되는지도 검증합니다.

운영에서는 cache hit 비율만 높이지 않습니다. Hit·miss와 무효화 이유, entry byte와 수명, eviction, tenant별 점유, 재사용 뒤 정답·권한 검사를 함께 봅니다. 대표 입력에서 cache를 끈 기준선과 켠 후보의 TTFT·peak memory·답변을 비교하고, prompt revision 직후 첫 요청이 miss로 새 상태를 만드는지 확인합니다. 성능 이익이 작거나 격리 검증을 통과하지 못하면 공유 범위를 줄이거나 요청 내부 cache만 쓰는 것이 올바른 결론입니다.

왜 이런가

동일한 token prefix의 attention 상태는 다시 계산하지 않을 수 있지만 그 상태에는 model·template·권한 문맥이 함께 반영되기 때문입니다.

언제 문제가 되는가

Template이나 권한이 바뀌었는데 이전 cache가 hit하면 오래된 지시나 다른 tenant의 비공개 문맥이 응답에 영향을 줄 수 있습니다.

초보자가 자주 하는 오해

문자열이 얼핏 같거나 같은 system prompt 이름을 썼다는 사실만으로 안전하게 공유할 수 있는 것은 아닙니다.

직접 확인하는 방법

Cache key 구성, tenant namespace, revision 변경과 삭제 시 무효화, hit·miss의 TTFT 및 cache를 끈 기준선과의 답변 일치를 시험하십시오.

KV cache 공식은 실제 tensor 원소의 byte를 설명하지만 runtime이 장치 memory를 관리하는 방식까지 포함하지는 않습니다. Serving engine은 token을 일정한 block이나 page로 나누고 kernel 정렬을 맞추며, StaticCache는 최대 길이를 미리 잡고 graph와 workspace도 별도로 예약할 수 있습니다. 마지막 page의 일부만 써도 page 전체가 할당되고 길이가 다른 sequence가 섞이면 빈 공간이 생깁니다. 따라서 계산기가 8GiB를 가리킨다고 GPU 측정치도 정확히 8GiB 늘어야 하는 것은 아닙니다.

요청이 끝나 논리 block이 반환되어도 framework allocator가 다음 요청에 재사용하려고 장치 memory를 process에 reserved 상태로 둘 수 있습니다. 이때 active allocation은 줄고 reserved는 유지될 수 있으므로 숫자가 즉시 내려가지 않는다는 이유만으로 memory leak이라고 결론 내리면 안 됩니다. 반대로 같은 부하를 반복할 때 active sequence와 cached token은 제자리인데 allocated·reserved가 계속 증가하고 결국 OOM이 난다면 참조 해제, 취소 경로와 runtime issue를 조사해야 합니다. Allocated, reserved와 system-level used를 같은 시간축으로 구분해 기록합니다.

Capacity dashboard에는 진행 중 sequence, prefill·decode queue, cached token, 사용·여유 block, eviction과 prefix hit, GPU allocated·reserved·utilization, system RAM, TTFT·inter-token latency와 오류를 함께 둡니다. Cache 사용률 90%라는 단일 수치만 보면 queue가 이미 쌓이는지, 큰 static pool이 비어 있는지, 다른 process가 memory를 가져갔는지 알 수 없습니다. 취소·timeout 뒤 block이 회수되는 시간과 새 요청이 정상 수용되는지도 운영 지표와 반복 시험으로 확인합니다.

안전 한도는 평균 요청 하나가 아니라 실제 길이 분포와 동시성 조합에서 정합니다. Input과 output token의 p50·p95·최장, 동시 sequence 1·2·4·목표값, 짧은 요청과 긴 요청이 섞인 burst를 표로 만들고 peak memory와 p95 TTFT를 측정합니다. 목표 부하를 여러 번 통과하고도 model load·workspace·allocator 변동과 일시 burst를 위한 여유가 남는 지점을 admission limit으로 채택합니다. Runtime이나 block 설정을 바꾼 release는 같은 표를 다시 실행하고 이전 artifact와 한도로 되돌리는 rollback 조건을 기록합니다.

왜 이런가

Runtime은 순수 tensor 외에 page의 빈칸, 정렬, graph·workspace와 재사용할 예약 pool을 가지므로 실측 peak가 단순식보다 커질 수 있습니다.

언제 문제가 되는가

평균 길이와 theoretical byte만으로 동시성을 허용하면 긴 요청 burst에서 block이 고갈되고 queue·TTFT가 급증하거나 OOM이 납니다.

초보자가 자주 하는 오해

Reserved memory가 남으면 모두 leak이거나 반대로 cache 계산식만 맞으면 allocator 여유를 고려하지 않아도 된다고 생각하지 않습니다.

직접 확인하는 방법

길이 백분위와 동시성별로 cached token·block·allocated·reserved·queue·p95 지연을 기록하고 취소 회수와 rollback까지 반복하십시오.

Transformer layer를 attention과 Feed-Forward Network(FFN, token마다 적용되는 비선형 변환)로 단순화해 보겠습니다. Dense model에서는 layer에 들어온 모든 token이 같은 FFN parameter 묶음을 통과합니다. “환불”과 “배송”의 activation 값은 서로 달라도 어느 FFN weight를 읽는지는 같습니다. Total parameter와 token당 사용 parameter가 완전히 같다는 수학적 선언은 아니지만 sparse expert 구조와 비교할 때 두 값의 차이가 상대적으로 작습니다.

Sparse Mixture of Experts(MoE, 전문가 혼합)는 보통 Dense FFN 하나를 여러 expert FFN으로 바꾸고 router가 token 표현으로 각 expert의 점수를 냅니다. Top-k가 2라면 점수가 높은 두 expert 결과를 가중합해 다음 layer로 보냅니다. Expert는 학습으로 만들어진 수치 함수이므로 “E1은 한국어, E2는 수학”처럼 사람이 정한 부서라고 단정할 수 없습니다. 같은 단어도 앞뒤 context와 layer에 따라 다른 route를 탈 수 있습니다.

MoE에서도 embedding, attention, normalization, router와 output layer 같은 shared 부분이 남고 model에 따라 shared expert도 있을 수 있습니다. 따라서 expert 128개 중 8개를 선택한다는 사실을 model 전체 parameter의 8/128만 계산한다는 말로 바꾸면 안 됩니다. 어느 layer가 MoE인지, expert FFN의 크기, shared expert와 공통 parameter가 무엇인지 exact config와 technical report에서 확인해야 합니다.

입문자는 먼저 도해에서 세 색을 구분합니다. 모든 token이 지나는 shared 계산, token마다 선택되는 expert 계산, 이번 token이 선택하지 않았지만 artifact에는 존재하는 expert weight입니다. 이 구분을 할 수 있으면 “sparse=작은 파일”, “expert 수=업무 종류”, “active 숫자=전체 FLOPs”라는 세 오해를 피할 수 있습니다. 실제 비교표도 세 층을 따로 적어야 합니다.

왜 이런가

MoE는 model 전체를 희소하게 지우는 것이 아니라 주로 FFN의 여러 후보 중 token별 일부 경로를 선택하기 때문입니다.

언제 문제가 되는가

Active parameter만 보고 artifact와 memory를 정하거나 shared 계산을 빼면 load 실패와 속도 과장이 생깁니다.

초보자가 자주 하는 오해

Expert가 사람이 이해하는 업무 전문 분야로 자동 분리되거나 선택되지 않은 expert가 file에서 사라지는 것은 아닙니다.

직접 확인하는 방법

Config와 weight 이름에서 MoE layer, expert 수·크기, top-k와 shared expert를 찾고 도해의 세 층에 배치하십시오.

한 MoE layer에 token vector가 들어오면 router projection이 expert 수만큼 logit 또는 score를 만듭니다. Softmax나 model이 정의한 normalization을 거친 뒤 높은 expert를 top-k로 고르고 token을 해당 expert FFN에 보냅니다. Expert 출력은 router weight로 합쳐져 residual 경로에 돌아옵니다. Top-1은 한 expert, top-2는 두 expert를 선택하지만 model에 shared expert가 있으면 그 계산이 추가될 수 있습니다.

Expert가 128개이고 top-k가 8이면 token 하나가 128개 expert 모두를 계산한다는 뜻도, model 전체에서 정확히 8개만 사용된다는 뜻도 아닙니다. 각 MoE layer가 자기 router와 expert를 가지면 같은 token은 layer마다 다른 여덟 개를 고를 수 있습니다. Batch의 token도 제각기 다른 route를 선택하므로 한 step에서 실제로 활성화된 unique expert 수는 token 하나의 top-k보다 클 수 있습니다.

Router probability가 비슷한 경계에서는 precision, kernel과 입력의 작은 변화가 선택 순서를 바꿀 수 있습니다. 이것이 곧 답변 오류라는 뜻은 아니지만 quantization이나 runtime 변경 뒤 특정 언어·형식에서 route 분포와 품질이 함께 달라질 수 있는 이유입니다. Router log를 공개하거나 저장할 때는 prompt 원문과 민감한 token을 그대로 남기지 말고 집계 지표와 안전한 sample을 사용합니다.

직접 점검할 때는 model config의 `num_experts`, `num_experts_per_tok` 또는 family별 동등 필드, router dtype과 shared expert를 기록합니다. 작은 고정 batch를 같은 seed·prompt로 실행하고 layer별 expert token 수, top-k 분포와 출력 품질을 비교합니다. Runtime이 이 지표를 제공하지 않으면 profiler나 공식 trace 기능을 찾고, 추정값을 실제 route처럼 보고하지 않습니다.

왜 이런가

Token 표현과 router parameter가 layer별 expert 점수를 만들므로 경로가 입력과 layer에 따라 달라집니다.

언제 문제가 되는가

Config의 expert 총수와 top-k를 뒤섞거나 한 token의 선택 수를 batch 전체 unique expert 수로 쓰면 계산·통신 예산이 틀립니다.

초보자가 자주 하는 오해

한 번 E3으로 간 token이 모든 layer에서 E3을 쓰거나 expert label만 보면 그 의미를 알 수 있다고 생각하지 않습니다.

직접 확인하는 방법

공식 config 필드와 runtime의 layer별 expert token histogram을 대조하고 같은 입력의 route·출력 변화를 기록하십시오.

Batch token 수를 T, token당 선택 expert를 k라고 하면 route assignment는 단순히 T×k입니다. Expert가 N개라면 완전히 균형일 때 평균은 T×k÷N입니다. 예를 들어 16 token, top-2, 8 expert면 총 32 route와 평균 4 route입니다. 하지만 첫 expert가 16 route를 받고 나머지가 2~3개를 받는다면 평균은 그대로여도 첫 expert의 buffer와 장치가 병목이 됩니다.

Switch Transformer 원 논문은 한 token을 최고 router probability expert로 보내고 expert별 fixed batch size를 token 수÷expert 수×capacity factor로 정하는 구성을 설명합니다. 이 정의는 해당 top-1 architecture의 훈련 설계입니다. 다른 MoE가 같은 capacity 식, drop 정책이나 padding을 쓴다고 일반화하면 안 됩니다. Model·framework·serving runtime의 overflow 동작을 별도로 확인해야 합니다.

Capacity가 작으면 초과 token이 drop되거나 fallback을 거쳐 품질 손실이 생길 수 있고, capacity factor를 크게 잡으면 사용하지 않는 slot과 communication buffer가 늘 수 있습니다. Load-balancing auxiliary loss는 학습 중 사용 분포를 개선하려 하지만 production의 특정 언어·업무 batch에서 완전한 균형을 보장하지 않습니다. 평균 loss나 전체 token/s만으로 hot expert와 경계 입력 실패를 가리지 않습니다.

실습에서는 한 expert에 50% route가 몰린 실패를 먼저 만듭니다. Hot 비율을 15%로 바꾸어 숫자를 통과시키는 과정은 관찰법을 익히기 위한 모형일 뿐 실제 router를 slider로 고친 것이 아닙니다. 운영에서는 expert별 route·capacity·overflow, 장치별 queue, p95 latency와 실패 token의 정답을 함께 보고 model·batch·runtime 변경을 한 항목씩 검증합니다.

왜 이런가

Router가 token 내용에 따라 선택하므로 균등 분배가 보장되지 않고 가장 바쁜 expert가 batch 완료를 지연시킬 수 있습니다.

언제 문제가 되는가

평균 utilization은 낮은데 p95가 튀거나 특정 token이 drop되면 expert별 최대와 overflow를 확인해야 합니다.

초보자가 자주 하는 오해

Expert 수를 늘리면 route가 자동으로 고르게 나뉘거나 capacity factor를 키우면 비용 없이 품질이 해결되는 것은 아닙니다.

직접 확인하는 방법

대표·경계 batch에서 expert별 route histogram, 최대/평균, overflow·drop과 같은 token의 품질·지연을 기록하십시오.

Parameter 수는 먼저 전체 weight 장부에 씁니다. 단순 weight byte는 total parameter×bit÷8로 계산할 수 있습니다. 30.5B Q4라면 약 15.25GB지만 실제 artifact에는 scale, metadata, mixed high-precision tensor, alignment가 있고 실행에는 KV cache, graph·workspace와 allocator 여유가 더해집니다. GB와 GiB 단위도 다르므로 계산식은 구매 보증이 아니라 첫 하한입니다.

Non-embedding parameter는 embedding과 output weight 처리 방식에 따라 total과 다를 수 있습니다. Tied embedding 여부, multimodal encoder와 projector, shared parameter를 model card와 config로 확인합니다. 두 model의 “30B”가 같은 tensor 구성과 실제 byte를 뜻한다고 가정하지 않습니다. Shard file의 합, index와 tensor dtype 분포를 직접 확인해야 저장·download·load 예산이 재현됩니다.

Activated parameter는 token 하나가 지나가는 selected expert와 shared 부분을 제작자가 정의한 방식으로 센 값입니다. 이것을 total과 비교하면 sparse 계산의 방향을 이해할 수 있지만 곧바로 FLOPs, bandwidth, latency나 energy 비율이 되지는 않습니다. Attention·router·dispatch·gather, padding과 통신이 있고 batch마다 unique expert와 load balance가 달라지기 때문입니다.

두 번째 실습은 total 30.5B, active 3.3B와 Q4를 넣어 total weight 하한과 active-weight 상당값을 나란히 보여 줍니다. 16GiB available에서는 교육용 실행 예산이 실패하고 21GiB로 바꾸면 기준선을 통과합니다. 실제 승인에서는 공식 file byte와 load·prefill·decode peak, context·동시성, quality를 측정하고 단순 10% overhead 가정을 교체해야 합니다.

왜 이런가

저장하려면 전체 tensor가 필요하지만 token 계산에서는 router가 일부 expert를 선택할 수 있어 두 parameter 장부가 생깁니다.

언제 문제가 되는가

Active 3B를 file 3B로 읽으면 다운로드는 되어도 load 단계에서 memory 부족이 나거나 CPU offload로 급격히 느려집니다.

초보자가 자주 하는 오해

Total/active 비율이 실제 속도·전력·memory 절감 비율과 정확히 같다는 보장은 없습니다.

직접 확인하는 방법

Model card·config·artifact index에서 total·non-embedding·active 정의와 byte를 찾고 runtime 단계별 peak와 비교하십시오.

Qwen 공식 Qwen3-30B-A3B model card는 causal language model, total parameter 30.5B, activated 3.3B, non-embedding 29.9B, 48 layer를 명시합니다. 또한 128 experts와 token당 8 activated experts, GQA의 Query 32·KV 4를 함께 제시합니다. 따라서 이 정확한 family와 revision에서는 30B-A3B를 total과 activated의 두 수치로 풀 수 있습니다.

이 숫자만 보고 3.3B Dense와 같다고 말할 수는 없습니다. Qwen3 technical report가 dense와 MoE 모델을 함께 다루더라도 각 model의 shared layer, attention과 expert 구성이 다릅니다. 같은 Qwen 이름 아래에서도 base·instruct·thinking, 후속 revision과 multimodal variant가 존재할 수 있으므로 정확한 repo와 commit, config를 고정해야 합니다.

공식 model card의 native context와 확장 context, recommended Transformers version 같은 조건도 이름 바깥에 있습니다. A3B가 맞더라도 runtime이 해당 `qwen3_moe` architecture와 quantized expert kernel을 지원하지 않으면 load error나 느린 fallback이 생길 수 있습니다. Community GGUF 이름은 원본 revision, conversion recipe와 mixed tensor를 추가로 검증해야 합니다.

안전한 읽기 결과는 한 문장보다 manifest입니다. Source organization과 exact model ID, revision·license, total·non-embedding·activated, layer·expert·top-k, attention config, context, tokenizer·template, artifact dtype·hash와 runtime 지원을 적습니다. 그다음 내 장비에서 실제 file byte, peak와 token/s를 채워 이름 해석을 실행 증거로 바꿉니다.

왜 이런가

Qwen 제작자가 해당 model card에서 A3B를 activated 3.3B 구조 사실과 expert config로 구체화하기 때문입니다.

언제 문제가 되는가

Qwen이라는 family 이름과 30B-A3B만 복사하고 revision·runtime을 고정하지 않으면 다른 variant나 변환물을 같은 후보로 오인합니다.

초보자가 자주 하는 오해

A3B가 모든 회사에서 같은 계산식을 쓰는 표준 suffix이거나 3.3GB file을 뜻하지 않습니다.

직접 확인하는 방법

공식 model card 수치와 exact config·artifact index·runtime load log를 한 manifest에서 대조하십시오.

Google의 Gemma 3n 공식 안내는 E2B와 E4B의 E가 reduced set of Effective parameters로 동작할 수 있음을 뜻한다고 설명합니다. Model 안의 total parameter는 이름 수치보다 크며 text, vision, audio와 Per-Layer Embedding(PLE) parameter 그룹으로 나뉩니다. 이 family의 이름 규칙은 먼저 resource-constrained device에서의 flexible execution과 연결됩니다.

공식 문서는 E2B 표준 실행에서 5B가 넘는 parameter가 load되지만 PLE caching과 parameter skipping을 쓰면 약 1.91B effective memory load로 운용할 수 있다고 설명합니다. 이는 “total 5B 중 router가 2B expert만 top-k로 선택한다”라는 Qwen A 표기의 문장이 아닙니다. 어떤 parameter를 cache·skip하고 modality를 load하는지가 memory 결과의 조건입니다.

Gemma 3n E4B는 E2B의 parameter를 포함하는 nested MatFormer 구조이며 intermediate sub-model 구성도 가능하다고 공식 안내는 설명합니다. Vision·audio parameter를 조건부 load할 수 있으므로 text-only와 multimodal 실행의 memory가 다를 수 있습니다. E4B 하나의 이름으로 모든 modality, runtime과 operating memory가 같다고 고정하면 안 됩니다.

비교표에서 A와 E를 같은 열에 숫자만 넣지 않습니다. `suffix`, `제작자 정의`, `total`, `standard loaded`, `effective·activated 조건`, `modality`, `runtime`, `실측 peak`를 별도 열로 둡니다. 공식 정의가 없는 community suffix는 추정하지 않고 미확인으로 남깁니다. 이름이 짧을수록 조건을 더 많이 찾아야 합니다.

왜 이런가

Gemma 3n은 PLE caching, parameter skipping과 nested sub-model 같은 family 고유 기술로 effective 실행 규모를 정의하기 때문입니다.

언제 문제가 되는가

E2B를 2B total 또는 expert top-k로 읽으면 file·load·modality memory와 runtime 선택이 모두 어긋납니다.

초보자가 자주 하는 오해

A와 E는 parameter가 적다는 같은 뜻의 국제 표준 약어가 아닙니다.

직접 확인하는 방법

Gemma 3n 공식 overview·model card에서 standard load, effective 조건과 modality를 확인하고 실제 실행 mode별 peak를 측정하십시오.

MoE training에서는 task loss뿐 아니라 expert 사용을 고르게 유도하는 auxiliary load-balancing objective, router 안정화와 capacity가 함께 사용될 수 있습니다. 어느 방식이 적용됐는지는 model technical report를 확인해야 합니다. Expert가 많다는 이유만으로 서로 다른 능력이 자동 형성되거나 모든 expert가 같은 빈도로 사용되는 것은 아닙니다. 학습 data 분포와 router objective가 실제 route를 만듭니다.

Fine-tuning에서 LoRA adapter를 attention에만 붙이는지, expert FFN과 router까지 붙이는지에 따라 학습 parameter와 결과가 달라집니다. 모든 expert에 adapter를 두면 adapter 총량과 optimizer memory가 커질 수 있고 일부 expert만 바꾸면 route가 드문 업무에서 효과가 제한될 수 있습니다. Library의 target module 이름과 shared·expert tensor를 확인하고 trainable parameter report를 저장합니다.

Quantization도 expert weight만 낮출지 router·shared layer를 더 높은 precision으로 유지할지 recipe마다 다를 수 있습니다. Router 경계 score의 작은 수치 변화가 top-k 순서를 바꿀 가능성이 있으므로 file이 load되고 평균 score가 유지된다는 사실만으로 끝내지 않습니다. 높은 정밀도 baseline과 같은 정상·경계·실패 입력에서 route histogram, 하위 품질, 형식과 latency를 비교합니다.

변경은 하나씩 적용합니다. Base→expert quant, quant→adapter, adapter→runtime update처럼 artifact와 실행 변수를 분리하고 source revision, trainable target, quant scheme·excluded tensor, calibration·evaluation digest와 output hash를 남깁니다. Route나 품질이 나빠지면 이전 artifact로 rollback해 같은 실패 입력이 회복되는지 확인해야 MoE 변경의 원인을 설명할 수 있습니다.

왜 이런가

Router와 expert weight가 학습·양자화·adapter 대상이 될 수 있고 top-k 선택은 그 수치 결과에 의존하기 때문입니다.

언제 문제가 되는가

새 adapter·quant 뒤 일부 expert만 과부하되거나 경계 과업 형식이 무너지면 target tensor와 route 변화를 분리해야 합니다.

초보자가 자주 하는 오해

Dense model과 같은 LoRA target 이름·quant recipe를 복사하면 모든 expert와 router가 의도대로 처리된다고 보장할 수 없습니다.

직접 확인하는 방법

Trainable·quantized tensor 목록, router dtype, artifact hash와 동일 평가의 expert 분포·하위 품질을 baseline과 대조하십시오.

단일 GPU에서 total weight와 cache·workspace가 모두 들어가고 runtime이 optimized expert kernel을 제공하면 active path의 계산 절감이 이점이 될 수 있습니다. 그러나 total Q4 artifact가 VRAM에 간신히 맞으면 context와 batch가 늘 때 OOM이 날 수 있습니다. File load 성공, prefill peak와 decode peak를 따로 측정하고 display나 다른 process가 사용할 여유를 남깁니다.

일부 expert를 CPU memory에 두는 offload는 GPU VRAM을 줄이지만 선택된 expert가 CPU에 있을 때마다 weight 또는 activation 전송이 필요할 수 있습니다. Token이 어떤 expert를 고를지 입력마다 달라 연속적인 layer offload보다 access pattern이 불규칙할 수 있습니다. System RAM 용량만 맞추지 말고 PCIe traffic, page fault, CPU bandwidth와 TTFT·decode 지연을 측정합니다.

여러 GPU의 expert parallelism은 expert weight를 장치에 나누고 router가 선택한 token을 해당 장치로 dispatch한 뒤 결과를 gather합니다. All-to-all 통신과 가장 늦은 expert가 step 완료를 지연시킬 수 있습니다. Expert별 route와 장치별 token이 불균형하면 GPU 평균 utilization은 높아 보여도 한 장치의 straggler와 network가 p95를 지배합니다.

Runtime 선택 전 공식 지원 matrix에서 model architecture, quant type, expert parallel, tensor parallel과 hardware topology를 확인합니다. Unsupported expert operator가 Dense fallback이나 CPU 경로로 바뀌는지 load log와 profiler를 봅니다. 같은 model·artifact를 single GPU, offload, multi-GPU 후보에서 비교할 때 prompt·context·batch·sampling을 고정해야 병목 원인을 설명할 수 있습니다.

왜 이런가

전체 expert weight 배치와 token별 선택 경로가 장치 memory·interconnect를 동시에 사용하기 때문입니다.

언제 문제가 되는가

VRAM 합은 충분하지만 CPU fallback, PCIe 또는 all-to-all이 병목이면 active parameter 기대와 달리 latency가 커집니다.

초보자가 자주 하는 오해

GPU 여러 장의 VRAM을 단순히 더하거나 active weight만 GPU에 두면 통신 없이 실행된다고 가정할 수 없습니다.

직접 확인하는 방법

Profiler에서 expert kernel, device placement, dispatch·gather, interconnect byte, 장치별 route와 p50·p95를 같은 부하로 기록하십시오.

Dense와 MoE 비교는 parameter 수 하나를 맞추는 문제가 아닙니다. 같은 업무에서 허용할 file·memory와 latency를 먼저 정하고 그 범위의 후보를 고릅니다. Model·tokenizer·template, quantization, prompt·context, sampling, output, batch와 장비를 기록합니다. 후보마다 architecture가 다르므로 total과 active를 각각 공개하되 실제 결과는 같은 업무 입력으로 측정합니다.

품질 세트에는 정상·경계·실패 입력과 한국어 고유명사, 숫자·JSON·긴 context를 포함합니다. 전체 평균이 같아도 router 쏠림이 큰 특정 하위 집합에서 형식 오류가 늘 수 있습니다. Route 지표가 달라졌다는 이유만으로 품질 원인이라고 단정하지 않되, 품질 실패 token과 expert load가 같은 조건에서 재현되는지 조사할 근거로 사용합니다.

성능은 Time to First Token(TTFT), prompt token/s, decode token/s, 요청 전체 latency, peak GPU·RAM, energy와 목표 동시성 처리량을 분리합니다. MoE의 batch throughput이 좋아도 한 사용자 latency가 나쁘거나 queue가 길면 interactive 서비스에는 맞지 않을 수 있습니다. Dense가 느리지만 단순하고 안정적인 rollback을 제공하면 작은 팀의 낮은 traffic에는 더 나은 선택일 수 있습니다.

승인 기준은 결과를 보기 전에 정합니다. 예를 들어 핵심 하위 집합 정확도 하락 1%p 이하, JSON 99%, p95 TTFT 2초, peak 20GiB, overflow 0과 rollback 재현처럼 적습니다. Architecture 이름이나 공개 benchmark가 좋아도 하나의 필수 gate를 넘지 못하면 보류합니다. 후보의 장점뿐 아니라 실패 조건과 다음 검토 시점도 남깁니다.

왜 이런가

Dense와 MoE의 이익·비용은 model, runtime, batch와 업무 분포에 따라 달라 parameter 이름만으로 최종 결과를 예측할 수 없기 때문입니다.

언제 문제가 되는가

공개 평균은 좋지만 내 한국어 경계·JSON·동시성에서 회귀하면 architecture보다 업무 gate를 우선해야 합니다.

초보자가 자주 하는 오해

MoE가 항상 더 빠르고 효율적이거나 Dense가 항상 더 안정적이라는 단일 순위는 없습니다.

직접 확인하는 방법

두 후보의 exact manifest를 고정하고 같은 평가·부하에서 하위 품질, latency, memory, energy와 rollback을 반복하십시오.

Router를 관측한다고 해서 사용자의 질문과 token 문자열을 그대로 log에 남겨야 하는 것은 아닙니다. 운영에 먼저 필요한 값은 layer·expert별 route 수, 최대/평균 비율, 분포의 상위 백분위, overflow·drop 수, dispatch와 gather 시간입니다. 여기에 model·artifact·runtime revision, batch token 수와 익명화한 업무 분류를 붙이면 어느 release와 어떤 부하에서 쏠림이 시작됐는지 비교할 수 있습니다. 원문은 별도 권한·보존 기간·삭제 절차가 승인된 진단 표본에만 제한합니다.

정상 기준선은 traffic이 한산한 한 번의 평균이 아니라 대표 분포로 만듭니다. 한국어 짧은 문의, 긴 검색 문서, JSON 응답, 반복 입력과 목표 동시성을 나누고 expert별 route histogram, 최대/평균, overflow, queue와 p50·p95를 같은 요청 묶음에서 기록합니다. 이후 수치가 달라져도 곧바로 이상으로 단정하지 않고 입력 구성, scheduler와 batch 크기가 같은지 확인합니다. 조건이 다른 두 histogram을 비교하면 자연스러운 traffic 변화가 model 회귀처럼 보일 수 있습니다.

경보는 expert 하나의 route가 많다는 사실보다 사용자 증상과 함께 설계합니다. 최대/평균 비율이 기준선을 계속 넘고 동시에 p95 TTFT나 queue가 증가하거나 overflow와 필수 품질 실패가 나타날 때 조사하도록 합니다. 반대로 route가 고르더라도 CPU fallback, interconnect 병목이나 잘못된 template 때문에 응답이 느리고 틀릴 수 있습니다. Router metric은 원인 후보를 좁히는 신호이지 정답률·보안·형식 준수를 대신하는 합격 점수가 아닙니다.

새 runtime이나 quant artifact를 canary에 넣을 때는 기존 version과 동일한 익명 평가 batch를 번갈아 보내 route 분포, kernel 경로와 출력 rubric을 대조합니다. 차이가 생기면 model, runtime, batch policy와 quant 중 한 요소만 되돌려 재시험하고 결과 표에 조건을 남깁니다. 관측 도구가 route를 제공하지 않는 경우에는 그 사실을 “균형”으로 기록하지 말고 미관측으로 표시하며, 장치별 utilization·queue·latency와 실제 업무 실패를 이용한 제한된 진단임을 명시합니다.

왜 이런가

MoE의 병목은 expert별 분포에서 드러날 수 있지만 token 원문은 개인정보·기밀을 포함할 수 있어 필요한 집계와 민감한 내용을 분리해야 합니다.

언제 문제가 되는가

평균 token/s만 남기면 hot expert를 놓치고 원문을 무제한 보관하면 교육용 관측이 새로운 정보 노출 사고가 됩니다.

초보자가 자주 하는 오해

Route histogram만 있으면 답변 품질과 장애 원인이 자동으로 증명되거나 prompt 전체를 저장해야만 routing을 분석할 수 있는 것은 아닙니다.

직접 확인하는 방법

Revision과 업무 하위 집합별 집계 route·overflow·queue·p95를 남기고 원문 수집 권한·보존 기간·삭제 여부와 미관측 항목을 점검하십시오.

모델 이름을 본 첫 단계는 검색이 아니라 식별입니다. 제작자 organization, exact repository와 model ID, base·instruct·thinking 같은 variant, revision 또는 commit, 공개 날짜와 license를 적습니다. 비슷한 이름의 community 변환은 원본과 같은 항목으로 합치지 않고 변환자, 원본 revision, conversion·quantization recipe와 license 조건을 별도로 기록합니다. “30B-A3B 최신판”처럼 움직이는 문구는 다음 점검에서 다른 artifact를 가리킬 수 있어 재현 가능한 구매나 장애 분석의 식별자가 되지 못합니다.

두 번째 단계는 숫자의 정의를 원문 필드에 연결하는 일입니다. Total·non-embedding·activated·effective parameter, expert 수와 top-k, shared expert, layer, modality와 context를 각각 어느 공식 card·report·config에서 읽었는지 남깁니다. 값이 없으면 family 이름의 관습으로 채우지 않고 미확인으로 둡니다. 특히 A와 E 같은 suffix는 회사와 architecture를 넘어 환산하지 않으며, 같은 글자가 후속 family에서도 같은 조건을 뜻하는지는 새 공식 문서로 다시 확인합니다.

세 번째 단계에서는 내려받을 artifact와 실행 환경을 고정합니다. Shard 목록과 전체 byte, checksum 또는 digest, tensor format·dtype·quant 방식, tokenizer와 chat template, runtime·driver·kernel 지원, 운영체제와 장치 topology를 manifest에 넣습니다. Model card의 parameter 계산이 맞아도 실제 file이 손상됐거나 runtime이 expert operator를 CPU로 fallback하면 기대한 memory와 latency가 나오지 않습니다. Load log와 profiler가 manifest의 지원 주장을 확인하는 실행 증거가 됩니다.

마지막 단계는 승인과 폐기의 조건입니다. 같은 정상·경계·실패 입력에서 필수 품질, p95, peak memory, concurrency와 route·overflow를 측정하고 합격하지 못한 수치도 보존합니다. License 변경, 보안 권고, runtime 지원 중단이나 업무 회귀가 생겼을 때 어느 artifact로 돌아갈지, 누가 중단을 승인할지, cache와 변환물을 어디까지 제거할지도 적습니다. 이 절차를 거치면 모델 이름은 홍보 문구가 아니라 출처·호환성·품질·복구를 반복 검증할 수 있는 운영 계약이 됩니다.

왜 이런가

같은 표시 이름 아래에 variant·revision·quant·template가 여러 개 존재하고 suffix만으로 license와 runtime 지원을 알 수 없기 때문입니다.

언제 문제가 되는가

Repository와 digest를 고정하지 않으면 재배포 때 다른 weight를 받고 장애 후에도 이전 artifact와 조건을 재현하지 못합니다.

초보자가 자주 하는 오해

공식 organization의 이름이나 parameter suffix를 확인했으면 license·artifact 무결성·runtime compatibility와 업무 평가는 생략해도 된다고 생각하지 않습니다.

직접 확인하는 방법

Source·revision·license·수치 정의·artifact digest·runtime·장비·평가·rollback 열을 채우고 빈칸을 추정 대신 보류로 처리하십시오.

처음 보는 이름을 받으면 ①제작자와 exact ID, ②model family·세대, ③base·instruct 등 variant, ④suffix의 제작자 정의, ⑤total·activated·effective 수치, ⑥modality와 context, ⑦license, ⑧artifact byte·dtype·digest, ⑨runtime·hardware compatibility, ⑩같은 업무 평가와 rollback을 차례로 채웁니다. 앞 네 칸만 채워도 이름의 뜻은 말할 수 있지만 장비 구매나 production 승인을 하려면 열 칸이 모두 필요합니다. 공식 정보가 없는 칸에는 추정치 대신 출처 없음과 확인 책임자를 적습니다.

예를 들어 Qwen3-30B-A3B를 받으면 A를 임의로 “압축”이라고 풀지 않고 공식 카드에서 30.5B total, 3.3B activated, expert 128개와 token당 8개를 찾습니다. 이어 실제 artifact와 quant, tokenizer·template, runtime의 architecture 지원을 고정합니다. 이름 판독은 여기서 끝나지 않습니다. 목표 context와 동시성에서 load·prefill·decode peak, expert 분포와 한국어 업무 품질을 측정해야 16GiB 또는 24GiB 장비에 맞는지 답할 수 있습니다.

Gemma 3n E2B에는 같은 A 공식이나 expert 수 열을 억지로 적용하지 않습니다. 공식 overview와 card가 말하는 standard load, PLE caching·parameter skipping, modality와 effective 조건을 해당 칸에 적습니다. Text-only 조건의 작은 memory 결과를 vision·audio가 포함된 실행으로 복사하지 않고 runtime이 그 조건부 경로를 실제 지원하는지 확인합니다. 두 이름의 작은 숫자를 한 열에 놓고 “2B가 3B보다 가볍다”고 순위를 매기면 family 정의와 실행 mode가 달라 비교가 성립하지 않습니다.

판독표의 실패 시험도 필요합니다. Community file에 원본 revision과 recipe가 없거나 suffix 공식 정의가 서로 충돌하면 download 전에 보류합니다. File은 정상이어도 runtime log에서 unsupported expert kernel과 CPU fallback이 보이면 성능 후보에서 보류합니다. 마지막으로 필수 한국어·JSON·안전 사례나 rollback이 실패하면 architecture 설명이 정확해도 배포를 승인하지 않습니다. 검증자는 각 보류 사유에 필요한 공식 문서, 측정 명령, 책임자와 재검토 조건을 함께 적어 다음 사람이 같은 결론을 다시 확인할 수 있게 합니다. 이 열 단계는 새로운 이름을 외우는 암기법이 아니라 모르는 부분을 드러내고 다음 검증을 지정하는 반복 가능한 절차입니다.

왜 이런가

모델 이름은 구조 일부만 압축해 표시하며 license·artifact·runtime·업무 결과처럼 배포에 필요한 조건은 대부분 이름 밖에 있기 때문입니다.

언제 문제가 되는가

Suffix 번역만 맞고 artifact·runtime이나 업무 gate가 틀리면 load 실패, 과도한 구매, 형식 회귀와 되돌릴 수 없는 배포가 생깁니다.

초보자가 자주 하는 오해

열 칸을 모두 암기하거나 빈칸을 업계 관습으로 채우는 것이 아니라 공식 근거와 실측이 없는 결론을 보류하는 절차입니다.

직접 확인하는 방법

처음 보는 exact ID 하나로 열 칸을 작성하고 각 수치 옆에 공식 URL·revision 또는 실측 log를 연결한 뒤 동료가 같은 artifact를 찾는지 확인하십시오.

장애 증상은 다양합니다. 특정 한국어 batch에서만 latency가 튀고, runtime update 뒤 GPU 한 장만 바쁘거나, 같은 total model이 새 quant에서 load되지만 출력 형식이 무너질 수 있습니다. 재시작 전에 exact model·artifact hash, tokenizer·template, runtime·driver, expert·parallel config, input token·batch·route histogram, 장치별 memory·communication과 품질 결과를 보존합니다.

복구는 동시성 1, 짧고 검증된 입력과 이전 runtime의 작은 성공 기준선에서 시작합니다. 이 상태에서도 실패하면 artifact·kernel 지원과 device placement를 먼저 봅니다. 기준선이 성공하면 context, batch, concurrency를 하나씩 원래 조건으로 늘립니다. Quant, expert parallel, router 설정과 model을 동시에 바꾸면 어떤 변화가 memory·지연·품질을 바꿨는지 알 수 없습니다.

예를 들어 update 뒤 30B-A3B Q4가 네 사용자에서만 p95를 넘고 GPU 2번 expert route가 몰렸다면 더 낮은 Q3로 즉시 바꾸지 않습니다. 이전 runtime·동일 artifact·동일 실패 batch로 회귀를 확인하고, single GPU 또는 동시성 1에서 expert kernel과 route를 대조합니다. 새 scheduler나 collective가 원인이면 임시 동시성 한도로 복구하고 이전 build rollback을 실행합니다.

종료 조건은 한 번 응답한 것이 아닙니다. 최소·대표·실패 batch와 목표 동시성을 반복해 필수 품질, expert overflow, p95·throughput, peak와 communication이 gate 안에 있고 이전 artifact 복구가 재현되어야 합니다. Runbook에는 이름을 해석한 공식 근거, 먼저 볼 expert·장치 지표, 안전 한도, 변경 순서와 rollback 위치를 적습니다.

왜 이런가

MoE 장애에는 model route, runtime kernel, device placement·통신과 traffic 분포가 함께 관여하므로 작은 성공 상태에서 분리해야 합니다.

언제 문제가 되는가

여러 설정을 동시에 낮춰 잠시 성공해도 원인을 모르고 traffic이 돌아오면 같은 hot expert·queue·품질 장애가 반복됩니다.

초보자가 자주 하는 오해

Active parameter가 작으므로 OOM·통신 병목이 없거나 재시작만 하면 router 불균형이 해결된다고 볼 수 없습니다.

직접 확인하는 방법

같은 실패 batch로 이전·현재 runtime을 비교하고 기준선→context→batch→동시성 순서와 rollback을 표로 재실행하십시오.