LLM 원리와 언어

Large Language Model(LLM, 대규모 언어 모델)은 사람이 쓴 지시를 이해하는 하나의 프로그램처럼 보이지만, 실제 서비스는 여러 층으로 이루어집니다. 사용자가 질문을 입력하면 애플리케이션이 보이지 않는 운영 지침인 system prompt, 이전 대화, 검색한 문서와 질문을 정해진 순서로 묶습니다. Tokenizer(토크나이저, 글을 모델용 조각으로 나누는 구성 요소)는 이 글을 token ID라는 숫자 배열로 바꾸고, Ollama·llama.cpp·MLX·vLLM 같은 runtime(실행 프로그램)이 모델 가중치를 이용해 계산합니다. 마지막에는 반대 과정을 거쳐 숫자 조각이 사람이 읽는 문장으로 돌아옵니다. 로컬 LLM을 이해하려면 모델 이름만 보는 것이 아니라 이 전체 흐름을 함께 봐야 합니다.

맨 아래의 모델 가중치는 학습 과정에서 조정된 매우 많은 숫자의 묶음입니다. 이 숫자만 저장된 파일은 스스로 질문을 받거나 화면을 그리거나 인터넷을 검색하지 못합니다. 파일 형식을 읽을 runtime, 계산을 수행할 Central Processing Unit(CPU, 중앙 처리 장치)·Graphics Processing Unit(GPU, 그래픽 처리 장치), 입력 형식을 맞추는 chat template, 결과를 보여 줄 앱이 모두 필요합니다. 같은 모델 파일을 사용해도 runtime의 설정, prompt 형식, context 길이와 양자화 방식이 다르면 속도와 답변이 달라질 수 있는 까닭이 여기에 있습니다.

사용자가 “내 자료를 AI에 넣고 싶다”고 말할 때도 원하는 기능을 먼저 나누어야 합니다. 새로운 사실을 검색해 질문 옆에 붙이는 Retrieval-Augmented Generation(RAG, 검색 증강 생성), 답변 형식과 행동을 조정하는 fine-tuning(미세조정), 이전 대화를 다음 요청에 다시 넣는 history 관리는 서로 다른 기능입니다. PDF를 검색하게 만들었는데 모델이 그 내용을 영구히 학습했다고 생각하거나, 말투를 고치려고 최신 사내 규정을 미세조정 데이터에 넣으면 유지보수가 어려워집니다. 이 구분이 서야 필요한 도구와 장비를 과하게 사지 않고 올바른 해결책을 고를 수 있습니다.

왜 이런가

오류가 났을 때 모델 자체, runtime, prompt, 검색 문서 중 어느 층에서 문제가 생겼는지 나누어야 원인을 찾을 수 있기 때문입니다.

언제 문제가 되는가

“AI가 이상하다”라고만 기록하면 잘못된 chat template이나 오래된 검색 문서를 모델 성능 문제로 오판해 더 비싼 장비를 사게 될 수 있습니다.

초보자가 자주 하는 오해

모델 파일을 내려받는 행위는 AI 전체를 설치하거나 내 자료를 학습시키는 일이 아닙니다. 이미 학습된 숫자를 내 장비에서 실행할 준비를 한 것입니다.

직접 확인하는 방법

사용 중인 앱에서 모델 이름, runtime 버전, context 설정, system prompt, 검색 사용 여부를 각각 적어 보십시오. 적지 못한 항목이 현재 보이지 않는 시스템 층입니다.

사람 눈에는 답변 한 문단이 빠르게 나타나지만 모델 내부에서는 작은 생성 단계가 계속 반복됩니다. 먼저 입력 전체를 읽어 다음 위치에 올 수 있는 수많은 token 후보의 점수인 logit을 계산합니다. 이 점수는 확률 분포로 바뀌고 설정된 선택 규칙에 따라 후보 하나가 선택됩니다. 선택된 token을 기존 문장 뒤에 붙이면 입력이 한 조각 길어지고, 모델은 늘어난 문맥으로 다시 다음 후보를 계산합니다. 종료 token이 선택되거나 최대 출력 길이에 도달할 때까지 같은 계산이 이어집니다.

예를 들어 “퇴근길에 비가 와서” 다음에는 “우산을”, “택시를”, “옷이”처럼 여러 후보가 자연스럽게 이어질 수 있습니다. 모델은 질문의 의미를 사전에서 조회한 뒤 완성 답을 복사하는 것이 아니라, 학습에서 익힌 언어 패턴과 현재 문맥을 이용해 다음 조각의 확률을 만듭니다. Temperature(온도, 후보 선택의 다양성을 조절하는 값)를 낮추면 높은 점수 후보를 더 안정적으로 고르고, 높이면 낮은 순위 후보가 뽑힐 가능성도 커집니다. 같은 질문에 표현이 달라지는 현상은 이 생성 방식에서 자연스럽게 생깁니다.

“다음 token 예측기라면 단순 자동완성과 무엇이 다른가”라는 질문이 생길 수 있습니다. 차이는 학습 규모와 내부 표현의 깊이에 있습니다. 방대한 문장, 코드, 표와 설명에서 다음 token을 맞히려면 문법뿐 아니라 대상 간 관계, 글의 목적, 자주 함께 나타나는 사실과 추론 패턴을 숫자 관계로 압축해야 합니다. 여러 Transformer layer가 이 관계를 조합하면서 번역·요약·질문 답변처럼 보이는 복잡한 능력이 나타납니다. 학습 목표가 단순하다는 말은 모델의 내부 계산과 결과가 단순하다는 뜻이 아닙니다.

왜 이런가

token 단위 반복을 이해하면 답변 속도를 “초당 token 수”로 재고, 출력 길이가 길수록 대기 시간이 늘어나는 이유를 설명할 수 있습니다.

언제 문제가 되는가

답변 전체가 저장돼 있다고 오해하면 temperature, context, 검색 근거가 결과를 왜 바꾸는지 이해할 수 없고 사실 검증도 소홀해집니다.

초보자가 자주 하는 오해

가장 확률이 높은 token을 항상 선택한다고 해서 문장 전체가 가장 사실적인 것은 아닙니다. 각 위치에서 자연스러운 후보를 고르는 것과 외부 사실을 확인하는 일은 다릅니다.

직접 확인하는 방법

교육의 token 생성 단계 실습에서 같은 문장으로 선택 규칙을 바꾸어 보십시오. 앞에서 token 하나가 달라지면 뒤 후보 분포도 연쇄적으로 바뀌는지 확인할 수 있습니다.

Training(학습)은 모델이 예측한 값과 학습 데이터의 정답 사이 오차를 계산하고, 그 오차가 줄어드는 방향으로 가중치를 반복해서 수정하는 과정입니다. 대규모 사전 학습은 수많은 GPU와 긴 시간이 필요하며 데이터 정제, 분산 계산, checkpoint와 평가가 함께 움직입니다. 개인이 수행하는 LoRA(Low-Rank Adaptation, 적은 추가 가중치만 조정하는 미세조정)는 이보다 범위가 작지만 그래도 데이터 준비와 학습·평가 절차가 필요합니다. 단지 채팅창에 문서를 붙이거나 모델 파일을 내려받았다고 가중치가 바뀌지는 않습니다.

Inference(추론)는 이미 학습된 가중치를 메모리에 올려 새 입력의 답을 계산하는 과정입니다. Ollama에서 모델을 실행해 대화하거나 llama.cpp로 GGUF 파일을 여는 것은 추론입니다. 채팅 앱이 이전 대화를 저장했다가 다음 질문 앞에 다시 붙이면 모델이 과거를 기억하는 것처럼 보일 수 있지만, 대화 기록이 모델의 영구 지식이 된 것은 아닙니다. 새 대화에서 기록을 보내지 않으면 그 정보는 사라지며 모델 파일도 원래 상태 그대로입니다.

RAG는 최신 규정이나 개인 문서처럼 자주 바뀌는 사실을 다룰 때 유용합니다. 질문과 가까운 문서 조각을 먼저 찾고, 그 원문을 질문과 함께 모델에 전달해 근거 안에서 답하게 합니다. 반대로 fine-tuning은 일정한 답변 형식, 말투, 분류 방식과 작업 절차를 익히게 하는 데 더 적합합니다. 예를 들어 매달 바뀌는 가격표는 RAG로 관리하고, 고객 문의를 회사의 다섯 분류 중 하나로 일정하게 출력하는 행동은 미세조정 후보가 될 수 있습니다. 해결책을 고르기 전에 “새 사실인가, 행동 방식인가, 잠깐의 대화 기억인가”를 먼저 물어야 합니다.

왜 이런가

세 기능을 구분해야 데이터 갱신 주기, GPU 요구량, 개인정보 노출 지점과 실패 원인을 정확히 설계할 수 있습니다.

언제 문제가 되는가

최신 사실을 미세조정으로 외우게 하면 정보가 바뀔 때마다 다시 학습해야 하고, RAG로 말투를 고치려 하면 매 요청마다 긴 지시를 반복하게 됩니다.

초보자가 자주 하는 오해

“내 데이터로 AI를 학습했다”는 표현이 실제로는 파일 검색 기능을 붙인 경우가 많습니다. 결과가 유용하더라도 기술적으로 같은 일은 아닙니다.

직접 확인하는 방법

모델 파일의 수정 시각과 hash를 대화 전후에 비교하고, 새 대화에서 이전 정보를 다시 묻습니다. 별도 학습 절차가 없었다면 가중치는 같고 기록을 제외한 정보도 남지 않습니다.

모델은 다음 token을 잘 맞히도록 학습했기 때문에 문맥에 자연스러운 설명을 만드는 데 강합니다. 그러나 자연스러움은 사실성 보증서가 아닙니다. 학습 시점 이후의 사건, 정확한 버전 번호, 드문 전문 지식, 존재 여부가 불분명한 논문과 출처를 묻는 순간 모델은 빈칸을 그럴듯한 패턴으로 채울 수 있습니다. 질문에 포함된 틀린 전제를 그대로 받아들일 수도 있고, 서로 비슷한 제품의 사양을 섞을 수도 있습니다. 이것은 말투의 문제가 아니라 생성 목표와 이용 가능한 근거에서 비롯되는 구조적인 한계입니다.

가령 아직 출시되지 않은 가상의 GPU 모델명을 실제 제품처럼 질문하면 모델은 이름의 규칙을 보고 메모리 용량과 출시일을 만들어 낼 수 있습니다. 프로그래밍에서도 존재하지 않는 함수 이름을 그럴듯하게 제시하고, 법령에서는 과거 조항과 현재 조항을 섞을 수 있습니다. 이때 답변이 문법적으로 매끄럽고 표까지 갖추었다는 사실은 정확도의 증거가 아닙니다. 오히려 사람이 표현의 완성도에 안심해 확인을 생략하는 자동화 편향이 더 큰 위험이 됩니다.

실무에서는 “모델이 틀리지 않게 해 달라”는 주문보다 실패가 어디에서 걸러지는지를 설계합니다. 최신 사실에는 원문 검색과 인용을 붙이고, 숫자는 계산기로 다시 계산하며, 구조화된 결과는 JSON schema로 검증하고, 코드는 test를 통과시킵니다. 삭제·결제·외부 발송처럼 되돌리기 어려운 행동에는 사람 승인을 둡니다. RAG도 잘못된 문서를 찾으면 틀릴 수 있으므로 검색 결과의 날짜·버전·권한과 답변이 근거를 충실히 따랐는지를 별도로 평가해야 합니다.

왜 이런가

모델을 사실 데이터베이스가 아니라 확률적 생성기로 다루면 위험도에 맞는 검증 비용을 계획할 수 있습니다.

언제 문제가 되는가

“확실하지 않으면 모른다고 답하라”는 prompt만 믿으면 모델이 자신 있게 틀리는 경계 사례를 운영 단계에서 놓치게 됩니다.

초보자가 자주 하는 오해

RAG를 붙이면 환각이 사라지는 것이 아닙니다. 검색이 빗나가거나 모델이 근거를 무시할 수 있으므로 검색과 생성 두 단계를 각각 검사해야 합니다.

직접 확인하는 방법

답변에서 날짜·숫자·고유명사·인용을 표시한 뒤 원문과 하나씩 대조하십시오. 확인할 원문이 제시되지 않았다면 그 문장을 사실이 아니라 검증 대기 주장으로 분류합니다.

Local LLM(로컬 대규모 언어 모델)은 모델 계산을 개인 PC, 워크스테이션, 사내 서버처럼 사용자가 통제하는 장비에서 수행하는 구성을 말합니다. 인터넷이 끊겨도 사용할 수 있고, 민감한 원문을 외부 모델 API에 보내지 않도록 설계하기 쉬우며, 반복 호출 비용을 장비 비용 안에서 예측할 수 있습니다. 모델과 runtime 버전을 고정해 같은 환경을 재현하기 쉬운 것도 장점입니다. 다만 앱이 update 검사, telemetry, 외부 검색이나 확장 기능을 통해 통신할 수 있으므로 실제 네트워크 흐름까지 확인해야 “외부 전송이 없다”고 말할 수 있습니다.

클라우드 제공자가 맡았던 운영 책임은 사용자에게 돌아옵니다. 모델과 실행 파일의 출처, 라이선스, 악성 파일 여부, GPU driver와 runtime 호환성, 계정과 접근 제어, 대화 로그의 개인정보, backup과 장애 복구를 직접 관리해야 합니다. 가족 한 명이 자신의 PC에서 사용하는 구성과 회사 직원 여러 명이 API로 접속하는 구성은 같은 로컬 서비스가 아닙니다. 후자에는 Transport Layer Security(TLS, 통신 암호화), 인증, 요청 제한, 감사 기록과 자원 격리가 필요합니다.

예를 들어 병원 문서 요약을 사내 GPU에서 수행해도 모든 직원이 원문과 prompt log를 볼 수 있다면 개인정보 보호가 된 것이 아닙니다. 반대로 공개된 블로그 초안을 개인이 다듬는 일은 외부 API를 사용하더라도 데이터 위험이 낮을 수 있습니다. 로컬과 클라우드 중 하나를 선악처럼 고르지 말고 데이터 민감도, 필요한 품질, 응답 속도, 예상 요청량, 장비·전력 비용, 운영할 사람과 장애 허용 시간을 같은 표에서 비교해야 합니다.

왜 이런가

계산 위치와 보안 통제를 분리해 생각해야 실제 데이터 경로와 책임자를 빠뜨리지 않습니다.

언제 문제가 되는가

로컬이라는 이유만으로 인증과 로그 정책을 생략하면 같은 네트워크의 다른 사용자가 민감한 대화나 모델 API를 이용할 수 있습니다.

초보자가 자주 하는 오해

오픈 가중치 모델은 무료·무제한·안전한 모델과 같은 말이 아닙니다. 라이선스와 사용 제한, 배포 파일의 출처를 각각 확인해야 합니다.

직접 확인하는 방법

모델 실행 중 운영체제의 연결 목록과 firewall log를 확인하고, 입력·출력·검색 문서·오류 log가 어느 경로에 얼마나 오래 저장되는지 데이터 흐름도로 적습니다.

소형 모델은 정해진 문서 분류, 요약 초안, 일정한 형식의 문서 작성, 간단한 코드 설명과 unit test 초안, 자막 정리와 내레이션 대본처럼 입력과 기대 출력이 분명한 일에서 유용합니다. 예를 들어 고객 문의를 결제·배송·교환·계정·기타로 분류하면 사람이 결과를 빠르게 확인하고 잘못된 분류만 고칠 수 있습니다. 회의록에서 날짜와 담당자 후보를 추출한 뒤 원문 링크를 붙이는 작업도 결과 검증이 비교적 쉽습니다. 이때 성공 기준은 “똑똑해 보인다”가 아니라 정답률, 누락률, 검토 시간 감소처럼 측정 가능한 값이어야 합니다.

Text-to-Speech(TTS, 글을 음성으로 읽는 기술)용 내레이션을 만들 때도 LLM은 발음 자체를 생성하는 음성 모델이 아니라 대본을 다듬는 역할을 맡을 수 있습니다. Speech-to-Text(STT, 음성을 글로 바꾸는 기술), LLM 요약, TTS를 하나의 AI라고 부르면 어느 단계에서 오류가 생겼는지 알기 어렵습니다. 회의 음성을 잘못 받아 적은 문제와 요약 모델이 사실을 누락한 문제는 해결 방법이 다릅니다. 업무를 여러 단계로 나누는 편이 작은 모델과 전통적인 프로그램을 적절히 조합하고 실패를 되돌리기 쉽습니다.

반면 최신 전문 지식을 근거 없이 묻기, 매우 긴 문서를 한 번에 넣기, 여러 시스템을 오가며 복잡한 결정을 완전히 자동으로 실행하기는 첫 프로젝트로 적합하지 않습니다. 모델이 틀렸을 때 손실이 크거나 정답을 사람이 확인하기 어려운 업무일수록 더 큰 모델, RAG, 전용 검색·계산 도구와 승인 절차가 필요합니다. 작은 모델이 작업 범위 안에서 충분하다면 더 큰 모델을 선택하는 것보다 빠르고 저렴하며 운영도 단순합니다.

왜 이런가

작업 범위를 좁히면 필요한 모델 크기와 데이터, 평가 문항, 실패 처리 방법을 구체적으로 정할 수 있습니다.

언제 문제가 되는가

처음부터 “회사 업무를 모두 처리하는 비서”를 목표로 잡으면 정답 기준도 만들 수 없고 어느 모델이 나아졌는지도 측정할 수 없습니다.

초보자가 자주 하는 오해

소형 모델은 쓸모없다는 결론도, 모든 단순 업무를 안전하게 맡길 수 있다는 결론도 틀립니다. 과업과 검증 가능성이 성패를 결정합니다.

직접 확인하는 방법

후보 업무 20건을 사람이 먼저 처리해 정답과 소요 시간을 기록하고, 모델 결과의 정확도·누락·검토 시간을 같은 기준으로 비교합니다.

모델 이름의 8B는 대략 80억 개의 parameter(파라미터, 학습으로 조정된 숫자)가 있다는 뜻입니다. 가중치를 16bit로 저장하면 단순 이론값은 80억×16bit÷8, 약 16GB입니다. 4bit 양자화를 적용하면 약 4GB로 줄어들지만 실제 파일에는 양자화 scale, metadata와 일부 다른 정밀도의 값이 들어가 이론값보다 커질 수 있습니다. 이 계산은 출발점일 뿐이며 “4GB 파일이니 4GB GPU에서 실행된다”는 결론으로 바로 이어지지 않습니다.

생성 중에는 이전 token의 attention 중간 결과를 다시 계산하지 않도록 Key-Value cache(KV cache, 이전 문맥 계산을 저장하는 공간)를 유지합니다. Context가 길고 동시에 사용하는 사람이 많을수록 cache가 커집니다. Runtime의 계산 buffer, 그래프, driver가 쓰는 메모리와 화면 출력에 쓰이는 Video Random Access Memory(VRAM, GPU 전용 메모리)도 남겨야 합니다. 따라서 12GB GPU에 11.5GB를 쓰는 모델을 올리는 것보다 8~9GB 수준에서 시작해 실제 최장 입력과 동시 요청으로 측정하는 편이 안전합니다.

Out of Memory(OOM, 메모리 부족)는 이 전체 요구량이 사용 가능한 메모리를 넘어 실행이 중단된 상태입니다. 해결할 때는 무작정 프로그램을 다시 켜지 말고 context와 최대 출력 길이, 동시 요청을 줄여 기준선을 만든 다음 모델 크기나 양자화를 조정합니다. 한 번에 여러 값을 바꾸면 어느 항목이 원인이었는지 알 수 없습니다. 메모리를 끝까지 채우는 설정은 안정적인 설정이 아닙니다. 업데이트나 입력 길이의 작은 변화에도 다시 중단될 수 있으므로 반복 측정으로 여유를 정해야 합니다.

왜 이런가

가중치 외 메모리를 알아야 모델은 올라가지만 긴 대화에서만 중단되는 현상을 설명할 수 있습니다.

언제 문제가 되는가

모델 파일 크기만 보고 장비를 사면 짧은 질문은 되지만 긴 문서나 두 번째 사용자부터 OOM이 발생할 수 있습니다.

초보자가 자주 하는 오해

4bit 모델은 모든 계산을 4bit로 수행한다는 뜻이 아닙니다. 저장 정밀도, 계산 정밀도와 KV cache 정밀도는 따로 볼 수 있습니다.

직접 확인하는 방법

runtime 시작 직후, 짧은 prompt, 목표 최대 context, 동시 요청 2개 순서로 메모리와 속도를 기록하십시오. 단계별 증가량이 실제 안전 여유를 보여 줍니다.

첫 번째 질문은 “어떤 모델이 가장 좋은가”가 아니라 “누가 어떤 입력으로 어떤 결과를 만들 것인가”입니다. 입력에 개인정보나 회사 기밀이 있는지, 결과가 초안인지 자동 실행 명령인지, 한 번의 오류가 만드는 손실이 어느 정도인지, 정답을 누가 어떤 원문으로 확인할 수 있는지를 적습니다. 그다음 하루 요청 수, 동시에 사용할 사람, 허용할 응답 시간과 예산을 정합니다. 이 정보가 있어야 로컬 실행의 필요성과 모델 크기, context, runtime, GPU를 합리적으로 고를 수 있습니다.

예를 들어 가족 사진의 파일명을 설명문으로 바꾸는 개인 작업은 외부 전송을 원치 않고 결과를 눈으로 바로 확인할 수 있으므로 작은 vision-language model을 로컬에서 시험하기 좋습니다. 반면 회사 계약서의 법적 위험을 자동 판정해 발송하는 일은 근거·권한·전문가 승인 없이는 시작하면 안 됩니다. 같은 요약 작업도 공개 뉴스 초안과 환자 기록은 데이터 위험과 접근 통제가 다릅니다. 모델 성능표 하나로 이 결정을 대신할 수 없습니다.

실행 순서는 20~50개의 대표 사례를 모아 사람이 기대 결과를 만든 뒤, 가장 작은 후보 모델로 기준선을 측정하는 것입니다. 정상 사례뿐 아니라 빈 문서, 모호한 질문, 오래된 규정, 금지된 요청 같은 실패 사례도 넣습니다. 정확도와 속도뿐 아니라 사람이 수정하는 시간, 근거 누락, 거절해야 할 요청을 처리하는지를 기록합니다. 합격 기준을 만족할 때만 데이터와 사용자 수를 늘립니다. 작게 검증한 뒤 늘리는 순서가 장비와 운영 비용을 줄이고 사고 범위를 제한합니다.

왜 이런가

모델 선택을 업무 요구사항에 연결하면 유행하는 모델 이름이나 최고 benchmark 점수에 끌려가는 결정을 피할 수 있습니다.

언제 문제가 되는가

성공 기준 없이 시연만 보면 몇 개의 인상적인 답변을 전체 품질로 착각하고, 운영 후에야 누락과 비용을 발견합니다.

초보자가 자주 하는 오해

큰 모델을 먼저 설치하고 쓸 일을 찾는 순서는 학습에는 재미있어도 운영 프로젝트의 설계 순서는 아닙니다.

직접 확인하는 방법

입력 예시, 기대 출력, 허용 오류, 금지 행동, 검증자, 처리 시간, 데이터 보관 위치를 표로 채우십시오. 빈 칸은 모델 설치보다 먼저 해결해야 할 요구사항입니다.

문서 편집기에서 “가”는 한 글자로 보입니다. 그러나 컴퓨터는 먼저 문자를 Unicode code point(유니코드 코드 포인트, 문자에 붙인 국제 번호)로 표현하고, 파일이나 네트워크에서는 이를 UTF-8 같은 encoding(인코딩, 번호를 byte로 저장하는 규칙)으로 바꿉니다. 한글 음절 하나가 화면에서는 한 칸이어도 UTF-8에서는 여러 byte를 쓸 수 있습니다. 여기에 tokenizer(토크나이저, 글을 모델이 처리할 조각과 번호로 바꾸는 구성 요소)가 다시 별도의 분할을 수행합니다. 따라서 “한 글자”, “한 byte”, “한 token”은 같은 양을 세는 세 이름이 아니라 처리 단계가 다른 서로 다른 단위입니다.

눈에 같은 글자로 보이는 문자열도 내부 표현이 다를 수 있습니다. 예를 들어 한글 음절은 완성된 음절 code point로 저장할 수도 있고 초성·중성·종성에 해당하는 jamo code point의 조합으로 저장할 수도 있습니다. Unicode Normalization Form(유니코드 정규화 형식)은 뜻이 같은 문자 배열을 일정한 표현으로 맞추는 규칙입니다. Tokenizer가 어떤 정규화를 적용하는지에 따라 분할 결과가 달라질 수 있으므로, 복사해 온 문장 두 개가 화면상 같다는 사실만으로 token ID도 같다고 단정하면 안 됩니다.

이 구분은 단순한 용어 문제가 아닙니다. 파일 업로드 제한은 byte로 정하고, 편집기의 분량 표시는 문자나 단어로 보여 주며, LLM의 context 한도와 사용량은 token으로 계산합니다. 고객이 “문서가 2MB밖에 안 되는데 왜 못 넣느냐”고 묻는다면 이미지·서식이 포함된 파일 크기와 추출된 텍스트의 token 수가 직접 비례하지 않는다고 설명해야 합니다. 반대로 작은 텍스트 파일이라도 반복되는 코드, 긴 숫자열, 깨진 OCR 문자가 잘게 분할되면 예상보다 많은 token을 사용할 수 있습니다.

왜 이런가

각 단계가 다른 단위를 쓰므로 문제를 해결하려면 파일 크기, 문자 표현, token 분할 중 어디에서 양이 늘었는지 구분해야 합니다.

언제 문제가 되는가

문자 수를 token 수로 그대로 간주하면 context 초과, 비용 계산 오류, 출력 공간 부족을 배포 뒤에 발견할 수 있습니다.

초보자가 자주 하는 오해

UTF-8 byte가 많으면 언제나 token도 같은 비율로 많아진다는 생각은 틀립니다. Tokenizer의 vocabulary와 분할 알고리즘이 중간에서 다시 묶고 나눕니다.

직접 확인하는 방법

같은 문장의 문자 수와 UTF-8 byte 수를 먼저 기록하고 실제 모델 tokenizer가 만든 token 문자열과 ID를 나란히 출력해 세 열을 비교하십시오.

첫 단계 normalization(정규화)은 원문을 tokenizer가 기대하는 표기로 맞춥니다. Unicode NFC·NFD 같은 문자 정규화, 대소문자 변환, 공백 처리, accent 제거 중 무엇을 적용하는지는 tokenizer마다 다릅니다. 정규화는 검색과 학습에서 같은 표현을 일관되게 다루는 데 도움을 주지만 정보를 바꿀 수도 있습니다. 제품 코드에서 대소문자가 의미를 가지거나 원문 철자를 보존해야 하는 업무라면, 모델 입력용 정규화 결과와 사용자에게 보여 줄 원문을 따로 보관해야 합니다.

두 번째 pre-tokenization(사전 분할)은 공백, 문장부호, 숫자 같은 경계 후보를 먼저 나눕니다. 세 번째 tokenizer model은 이 조각을 vocabulary(어휘표, token 문자열과 ID의 목록)에 있는 subword(부분 단어)로 더 나누고 각각을 정수 ID에 연결합니다. Byte-Pair Encoding(BPE, 자주 붙는 쌍을 반복해 합치는 방식), WordPiece(학습 기준으로 유용한 부분 단어를 고르는 방식), Unigram(가능한 분할 중 확률이 좋은 조합을 고르는 방식)은 이 단계의 서로 다른 알고리즘입니다. 이름이 달라도 목표는 제한된 어휘표로 흔한 표현은 크게, 드문 표현은 더 작게 표현하는 데 있습니다.

마지막 post-processing(후처리)은 문장의 시작과 끝, 문장 쌍의 경계처럼 모델이 요구하는 특수 token을 더할 수 있습니다. 생성 뒤 decoder(디코더, token ID를 사람이 읽는 문자열로 되돌리는 구성 요소)는 subword 표식과 공백 규칙을 합쳐 문장을 복원합니다. 화면에서 “안녕하세요”가 자연스럽게 보인다고 내부에서도 한 조각이었다고 생각하면 안 됩니다. 정확한 진단에서는 최종 문자열만 보지 말고 정규화 문자열, pre-token, token 문자열, token ID, special token 포함 여부를 각 단계에서 확인해야 합니다.

왜 이런가

Pipeline을 단계로 나누면 같은 문장이 달라진 원인이 Unicode 정규화인지, 경계 규칙인지, vocabulary인지, special token인지 찾을 수 있습니다.

언제 문제가 되는가

Tokenizer 파일 일부만 교체하면 model weight는 같아도 ID 의미가 어긋나 답변 품질이 급격히 떨어지거나 문장이 깨질 수 있습니다.

초보자가 자주 하는 오해

Tokenizer는 단순히 공백에서 문장을 자르는 함수가 아닙니다. 공백이 없는 언어와 드문 문자열도 처리하도록 학습된 subword 규칙과 후처리를 포함합니다.

직접 확인하는 방법

Tokenizer의 encode 결과에서 tokens, ids, offsets와 special token mask를 출력하고 원문의 어느 범위가 어느 ID로 바뀌었는지 한 줄씩 연결하십시오.

모든 단어를 token 하나로 저장하면 새 단어가 생길 때마다 vocabulary가 끝없이 커지고, 글자 하나만 token으로 쓰면 문장이 지나치게 길어집니다. Subword tokenization은 그 중간을 택합니다. 학습 자료에서 자주 함께 나온 “transform”, “ation” 같은 문자열이나 반복되는 한글 조각을 vocabulary에 넣고, 처음 보는 단어는 이미 아는 조각의 조합으로 표현합니다. 그래서 자주 쓰이는 표현은 적은 token으로 처리되고 희귀한 고유명사, 긴 URL과 철자 오류는 더 많은 token으로 갈라질 수 있습니다.

BPE는 작은 단위에서 시작해 학습 자료에서 자주 이웃한 쌍을 합치는 merge 규칙을 배웁니다. WordPiece와 Unigram은 세부 학습 방식이 다르며 동일한 문장에도 다른 경계를 만들 수 있습니다. SentencePiece는 미리 단어로 잘라 놓은 입력을 전제로 하지 않고 raw sentence에서 subword model을 학습할 수 있도록 설계되었습니다. 중요한 결론은 어느 알고리즘이 언제나 우월하다는 것이 아니라, model weight가 학습될 때 사용한 tokenizer와 정확히 같은 어휘표·규칙을 추론에도 사용해야 한다는 것입니다.

예를 들어 사내 제품 코드 “KDX-2026-α”가 학습 자료에 거의 없었다면 하이픈, 숫자, 그리스 문자가 여러 token으로 나뉠 수 있습니다. 이 코드가 문서마다 수백 번 반복되면 context를 빠르게 소비하고 검색 embedding에서도 표기가 조금만 달라져 결과가 갈릴 수 있습니다. 그렇다고 운영 tokenizer에 제품 코드를 임의로 한 token으로 추가하면 끝나는 것도 아닙니다. 새 ID에 대응하는 embedding을 학습하거나 model을 조정하지 않으면 그 번호의 의미가 준비되어 있지 않으므로, 먼저 정규화·별칭 사전·검색 metadata 같은 외부 처리로 해결할 수 있는지 검토해야 합니다.

왜 이런가

Subword는 제한된 어휘표로 새로운 문자열을 표현하면서 흔한 표현의 sequence 길이를 줄이기 위한 절충입니다.

언제 문제가 되는가

희귀 문자열이 반복되는 로그·코드·OCR 문서를 일반 문장과 같은 글자/token 비율로 계산하면 입력 예산이 크게 빗나갑니다.

초보자가 자주 하는 오해

단어 뜻이 하나면 token도 하나라는 생각은 틀립니다. Token 경계는 의미 사전보다 학습된 문자열 빈도와 알고리즘에 좌우됩니다.

직접 확인하는 방법

일반 단어, 사내 고유명사, 오타, URL, UUID를 같은 tokenizer에 넣어 token 수와 경계를 비교하고 반복 횟수에 따른 총 사용량을 계산하십시오.

한국어는 어간 뒤에 조사와 어미가 붙어 문법 역할과 높임, 시제를 표현합니다. “찾다”, “찾았다”, “찾으셨습니까”는 관련된 의미를 가지지만 표면 문자열의 결합이 다양합니다. 어떤 tokenizer는 자주 본 어절 전체를 큰 token으로 가지고 있고, 다른 tokenizer는 어간·어미나 더 작은 문자 조각으로 나눕니다. 영어도 “run”, “running”, “unpredictability”처럼 분할이 달라지므로 영어는 늘 단어 하나가 token 하나인 것도 아닙니다. 차이는 문자 체계의 우열이 아니라 학습 자료와 vocabulary 설계가 만든 압축 효율의 차이입니다.

영어 자료가 압도적으로 많았던 tokenizer에서는 흔한 영어 단어가 긴 token 하나로 등록되고 같은 뜻의 한국어 표현은 여러 조각이 될 가능성이 있습니다. 반대로 다국어·한국어 자료를 충분히 반영한 최신 tokenizer는 한국어 표현을 더 큰 단위로 가질 수 있습니다. 따라서 “한국어는 영어보다 정확히 두 배 비싸다” 같은 비율을 제품 설명에 고정하면 모델을 바꾸는 순간 틀릴 수 있습니다. 번역문 길이, 문체, 숫자와 영문 제품명이 섞인 정도도 달라 단일 예문 결과를 전체 업무로 확대해서는 안 됩니다.

실무 비교는 같은 의미를 가진 대표 문장 묶음으로 수행합니다. 짧은 대화, 공문서, 기술 문서, 표에서 추출한 문장, 띄어쓰기가 불안정한 고객 문의를 한국어와 영어로 준비하고 실제 tokenizer revision별 token 수 분포를 냅니다. 평균뿐 아니라 상위 95% 지점과 가장 많이 늘어난 문장을 살펴야 최대 context와 quota를 안전하게 정할 수 있습니다. 번역해서 token을 줄이는 방법은 원문 의미 손실과 번역 비용이 생기므로, 먼저 불필요한 boilerplate·중복 문서·과거 대화를 제거하는 편이 안전합니다.

왜 이런가

언어별 형태와 tokenizer 학습 분포가 다르므로 동일한 문자 수라도 vocabulary가 재사용할 수 있는 긴 조각의 수가 달라집니다.

언제 문제가 되는가

영어 예시로만 context 예산을 검증하면 한국어 고객 문의나 혼합 기술 문서가 production에서 먼저 잘릴 수 있습니다.

초보자가 자주 하는 오해

한글은 음절 하나가 항상 한 token이거나, 영어는 단어 하나가 항상 한 token이라는 두 주장 모두 모델 독립적인 규칙이 아닙니다.

직접 확인하는 방법

업무에서 익명화한 한국어·영어·혼합 문장 각 50개를 실제 tokenizer로 측정하고 평균, 중앙값, 상위 95%, 최대값을 revision별로 저장하십시오.

“재고 1000개”와 “재고 1,000개”, “2026-08-26”과 “2026년 8월 26일”은 사람이 같은 정보로 읽을 수 있지만 tokenizer에는 쉼표, 하이픈, 공백과 숫자 조합이 다른 문자열입니다. 긴 일련번호, hash, Base64, UUID처럼 규칙은 있지만 반복 빈도가 낮은 문자열은 짧은 자연어보다 훨씬 촘촘하게 나뉠 수 있습니다. 로그를 그대로 prompt에 붙였을 때 몇 줄 안 되는데도 context가 많이 줄어드는 이유가 여기에 있습니다. 중요한 값만 구조화해 전달하고 전체 원문은 필요할 때 조회하는 설계가 낫습니다.

이모지는 화면에서 한 그림처럼 보여도 여러 Unicode code point가 결합될 수 있습니다. 피부색·성별·가족 조합, variation selector와 zero-width joiner가 포함되면 문자 세기 방법과 token 분할 결과가 달라집니다. OCR 오류로 생긴 깨진 문자와 제어 문자는 더 심각합니다. 사용자는 한 칸의 이상한 기호로 보지만 tokenizer는 byte 수준의 여러 조각으로 처리할 수 있고, 검색도 같은 단어를 찾지 못합니다. 입력 정제에서 제거한 문자를 기록하지 않으면 나중에 원문과 답변의 위치를 추적하기 어려워집니다.

코드는 공백과 줄바꿈이 문법 또는 가독성에 중요하므로 자연어처럼 무조건 합치면 안 됩니다. 들여쓰기, 긴 identifier, import 경로와 반복되는 generated code가 token을 소비하지만 임의 압축은 실행 의미를 바꿀 수 있습니다. 먼저 관련 함수와 오류 주변만 선택하고, line number와 파일 경계를 보존하며, build 산출물·lockfile·minified code처럼 질문에 불필요한 파일을 제외합니다. 원문 구조를 보존한 채 범위를 줄이는 것이 문자를 삭제해 token 수만 맞추는 것보다 정확합니다.

왜 이런가

Tokenizer는 사람이 인식하는 의미 단위가 아니라 실제 문자열과 학습된 경계를 처리하므로 표기 차이가 곧 다른 입력 배열이 됩니다.

언제 문제가 되는가

로그·OCR·코드·식별자를 정제 없이 넣으면 자연어 문서보다 context를 빨리 소모하고 검색 결과도 불안정해집니다.

초보자가 자주 하는 오해

공백과 기호는 의미가 없으니 모두 지워도 된다는 생각은 위험합니다. 코드 문법, 표 열, 문서 위치와 고유명사 구분을 잃을 수 있습니다.

직접 확인하는 방법

같은 의미를 숫자·날짜·공백 형식만 바꾼 네 문자열로 만들고 token 경계를 비교한 뒤, 정제 전후에 원문 위치가 추적되는지 확인하십시오.

채팅 UI에는 마지막 질문 한 줄만 보이더라도 application은 system instruction, 안전 규칙, 사용자와 assistant 역할, 이전 대화, 검색한 문서, tool schema와 실행 결과를 하나의 요청으로 조립할 수 있습니다. Chat template은 role과 content를 모델이 학습 때 본 control token 형식으로 바꿉니다. 같은 base model에서 만들어진 chat model도 서로 다른 template을 사용할 수 있으므로, 다른 모델의 template을 복사하면 역할 구분과 종료 동작이 나빠질 수 있습니다. 화면 글자만 세면 이 숨은 입력을 모두 놓칩니다.

Tool calling에서는 함수 이름, 설명, parameter schema가 매 요청에 들어가 수백 또는 수천 token을 쓸 수 있습니다. RAG는 질문보다 검색 문서가 훨씬 길고, 여러 turn의 agent는 매 단계의 관찰과 tool output을 다시 넣습니다. 따라서 사용자의 quota를 “질문 500자”처럼 정하면 실제 GPU 메모리와 처리량을 보호할 수 없습니다. Gateway나 runtime에서 최종 prompt token, 예약 output token, cached token과 실제 생성 token을 구분해 측정해야 합니다.

검사 지점은 UI 입력창이 아니라 실제 전송 직전입니다. Application이 message 배열과 tool을 조립한 뒤 동일한 tokenizer와 chat template을 적용해 token 수를 계산하고, 입력 상한을 넘으면 모델 호출 전에 사용자에게 어떤 요소가 큰지 설명해야 합니다. 오래된 대화 요약, 검색 문서 수 조정, tool 목록 축소 같은 복구를 자동으로 하더라도 원문 손실과 권한 변화를 기록합니다. 단순히 앞부분을 잘라 버리면 system 규칙이나 질문의 전제가 사라질 수 있습니다.

왜 이런가

Chat model은 role dictionary를 직접 읽는 것이 아니라 template이 만든 token sequence를 읽으므로 보이지 않는 control token과 부가 입력도 context를 차지합니다.

언제 문제가 되는가

사용자 질문만 측정하면 짧은 질문인데도 context 초과가 발생하거나 output 공간이 사라지는 현상을 설명하지 못합니다.

초보자가 자주 하는 오해

이전 대화가 화면에서 접혀 있으면 모델 입력에서도 사라졌다고 생각하기 쉽지만, 앱이 다시 보내면 모두 현재 요청에 포함됩니다.

직접 확인하는 방법

API 호출 직전의 message·tool·검색 문서 목록을 익명화해 기록하고 apply_chat_template 뒤 special token 포함 길이와 각 구성 요소의 비중을 출력하십시오.

Context window(문맥 창)는 한 요청에서 모델이 다룰 수 있는 token 범위입니다. 어떤 runtime은 입력과 새 출력의 합을 한도로 보고, 별도의 max input·max output 제한을 둘 수도 있으므로 공식 문서와 실제 오류를 함께 확인해야 합니다. 8,192 token 한도에 입력을 8,000 token 넣고 1,000 token 답을 요청하면 산술적으로 맞지 않습니다. Application이 어디를 자르거나 요청을 거절하는지 명확히 하지 않으면 사용자마다 다른 위치에서 중요한 내용이 사라집니다.

예산을 짤 때는 먼저 업무에 필요한 최대 출력량을 예약합니다. 그다음 고정 system과 template, 현재 질문, 대화 history, RAG 문서 순으로 현재 값을 측정합니다. 예를 들어 8K 한도에서 출력 1,200, system·template 500, 질문 300을 예약하면 history와 검색 문서에 남은 공간은 약 6,000 token입니다. 여기에 안전 여유를 두지 않고 끝까지 사용하면 tokenizer revision, tool schema와 문서 길이의 작은 변화에도 한도를 넘을 수 있습니다.

초과했을 때는 기계적으로 맨 앞 token부터 지우지 않습니다. 먼저 오래된 대화를 사실·결정·미해결 항목으로 요약하고, RAG에서 질문과 관련 없는 chunk를 줄이며, 중복된 system 지침과 tool 설명을 정리합니다. 문서 하나가 커서 조건과 결론이 떨어져 있다면 chunk를 무작정 작게 만들기보다 제목·절 구조를 보존하고 retrieval과 rerank를 개선해야 합니다. 복구 뒤에는 같은 최장 질문으로 답변 누락과 인용 정확도까지 다시 시험해야 합니다.

왜 이런가

생성될 답변도 같은 sequence에 이어지므로 입력만 한도 안에 넣는 것으로는 완성된 요청의 공간이 확보되지 않습니다.

언제 문제가 되는가

출력 예약이 없으면 답변이 중간에서 끊기고 JSON이 닫히지 않거나 인용과 결론이 사라질 수 있습니다.

초보자가 자주 하는 오해

Context 한도를 늘리면 항상 품질도 좋아진다는 생각은 틀립니다. 처리 시간·KV cache가 늘고 중요한 근거가 긴 입력에 묻힐 수 있습니다.

직접 확인하는 방법

실습에서 system·history·문서·질문·출력 예약량을 합산하고, 초과 상태를 history와 문서만 줄여 통과시킨 뒤 실제 최장 입력으로 회귀 시험하십시오.

기획 단계에는 아직 모델이 정해지지 않아 대략적인 범위가 필요할 수 있습니다. 이때 문자 종류별 경험칙으로 최소·최대 범위를 잡는 것은 가능하지만 구매 보증이나 운영 상한으로 사용하면 안 됩니다. 같은 문장이 모델 A에서 30 token, 모델 B에서 46 token이 될 수 있고 chat template까지 더하면 차이는 더 커집니다. 추정 도구는 “어떤 문장이 상대적으로 위험한가”를 발견하는 장치이며 정답 tokenizer를 흉내 내는 장치가 아닙니다.

배포 검증표에는 model ID와 revision, tokenizer 파일의 commit 또는 digest, chat template, special token 포함 여부, truncation·padding 설정과 측정 코드를 함께 남깁니다. 정상 문장만 아니라 빈 입력, 매우 긴 한국어, 영문 약어가 섞인 기술 문서, 숫자열, 이모지, OCR 오류, 코드와 tool schema를 포함합니다. 평균 token 수, 상위 95%, 최대값과 실패한 원문 유형을 기록하면 quota와 chunk 크기를 근거 있게 정할 수 있습니다.

모델이나 tokenizer를 업데이트할 때는 같은 입력 묶음으로 다시 측정합니다. Token 수가 줄어도 품질이 좋아졌다는 뜻은 아니며, 기존 prompt가 다른 경계로 처리되어 답변이 달라질 수 있습니다. Context 초과가 줄었는지뿐 아니라 검색 recall, 형식 준수, 한국어 고유명사와 숫자 보존, 첫 token 지연과 KV cache를 함께 비교합니다. 문제가 생기면 이전 tokenizer·template·model 세트를 한 묶음으로 되돌릴 수 있어야 원인을 분리할 수 있습니다.

왜 이런가

경험칙은 실제 vocabulary와 template을 모르므로 범위만 제시할 수 있고, 운영 결정에는 재현 가능한 실제 ID 배열이 필요합니다.

언제 문제가 되는가

Model weight만 고정하고 tokenizer나 template을 움직이는 버전으로 두면 같은 prompt의 token 수와 의미가 예고 없이 달라질 수 있습니다.

초보자가 자주 하는 오해

Token 수가 적은 tokenizer가 언제나 더 좋은 tokenizer는 아닙니다. 학습 일치, 언어 품질, 특수문자 처리와 model 성능을 함께 봐야 합니다.

직접 확인하는 방법

고정 평가 입력을 JSONL로 보관하고 배포 전후 tokens·ids·총량·출력 품질을 자동 비교해 허용 범위를 넘으면 승격을 보류하십시오.

Tokenizer는 화면 문자열을 model embedding 행의 ID로 연결하는 계약입니다. Vocabulary 순서가 다른 tokenizer를 기존 weight에 연결하면 같은 ID가 다른 조각을 가리켜 무의미한 반복, 특수 token 노출과 종료 실패가 생길 수 있습니다. Vocabulary 크기가 우연히 같아도 ID mapping과 normalization, pre-tokenization 규칙이 다를 수 있습니다. Model repository에서 tokenizer file·config와 special token을 exact revision으로 받아 weight와 한 manifest에 고정합니다.

Chat template도 tokenizer migration의 일부입니다. Beginning of Sequence(BOS, 문장 시작), End of Sequence(EOS, 문장 종료), role과 tool control token의 ID·삽입 위치가 달라지면 token 수뿐 아니라 model이 대화를 해석하는 방식이 바뀝니다. Template를 바꾼 뒤 답이 짧아졌다고 곧 효율 개선으로 보고하지 않습니다. System 준수, multi-turn role, tool schema·종료와 출력 형식을 같은 대화 세트로 다시 시험합니다.

교체 전에는 한국어 띄어쓰기·조사·고유명사, 영문 약어, 숫자·날짜, 이모지, OCR 오류, code와 tool schema를 포함한 고정 corpus를 준비합니다. 이전·후보 tokenizer의 normalized text, token 문자열·ID, special token 포함 총량과 상위 백분위를 diff합니다. ID가 달라지는 것은 정상일 수 있지만 연결된 weight도 같은 후보인지, context quota·chunk 경계와 비용이 허용 범위인지 설명해야 합니다.

승격 뒤 context 초과나 반복 출력이 늘면 새 tokenizer만 다시 수정하지 않고 model·tokenizer·template 묶음을 이전 revision으로 되돌려 같은 실패 입력이 회복되는지 확인합니다. 원인이 분리되면 normalization, template 또는 quota 중 하나만 바꿔 재시험합니다. 변경 보고에는 평균뿐 아니라 한국어·숫자·코드 하위 집합의 최대 증가, context 초과 건수와 출력 품질을 함께 적어 일부 사용자에게만 생긴 비용을 숨기지 않습니다. 특히 고객 이름과 숫자 단위가 여러 조각으로 급증한 사례는 별도 회귀 입력으로 보존하고, 같은 문장을 새 모델에서도 다시 측정합니다. Rollback artifact에는 tokenizer JSON·model·special token 설정과 digest를 함께 보존해 다음 담당자가 같은 ID 배열을 재현할 수 있게 합니다.

왜 이런가

Token ID는 embedding 행을 선택하고 control token은 대화 경계를 만들므로 tokenizer와 model weight·template는 함께 호환돼야 합니다.

언제 문제가 되는가

Tokenizer만 바뀐 뒤 반복·종료 실패, token 급증이나 RAG chunk 변화가 생기면 ID·normalization·template diff를 확인합니다.

초보자가 자주 하는 오해

Vocabulary 크기나 model family 이름이 같으면 아무 tokenizer나 연결해도 같은 입력과 품질이 되는 것은 아닙니다.

직접 확인하는 방법

고정 다국어 corpus의 normalized text·token·ID·총량을 이전·후보에서 비교하고 model·template 묶음 rollback으로 실패 회복을 재시험하십시오.

Parameter(파라미터)는 신경망이 학습할 때 예측 오차를 줄이도록 바뀌는 숫자입니다. 모델 이름의 B는 billion, 즉 10억을 나타내므로 3B는 약 30억, 8B는 약 80억, 70B는 약 700억 개를 뜻합니다. 이 숫자들은 하나의 거대한 표에 나란히 놓이지 않습니다. Token ID를 벡터로 바꾸는 embedding, 문맥 관계를 계산하는 attention, 각 token 표현을 변환하는 Feed-Forward Network(FFN), normalization과 출력 투영 등 여러 tensor에 분산됩니다. Tensor는 같은 종류의 숫자를 여러 차원으로 배열한 자료라고 이해하면 됩니다.

초보자가 가장 먼저 버려야 할 생각은 “파라미터 하나가 지식 하나를 저장한다”는 대응입니다. 서울이 대한민국의 수도라는 관계도 특정 숫자 하나에서 꺼내지지 않고, 수많은 언어 문맥에서 학습된 분산 표현과 여러 layer의 계산이 함께 작동해 답으로 나타납니다. 한 parameter를 지우면 사실 하나만 깔끔히 사라지는 구조도 아닙니다. 반대로 80억 parameter라고 해서 검증된 사실 80억 건을 제공한다는 뜻도 아닙니다. 지식의 정확성, 최신성, 출처 제시는 별도 평가와 검색 시스템이 맡아야 합니다.

Parameter 수는 용량과 계산을 예상하는 데는 유용합니다. 같은 구조와 정밀도에 가까운 두 모델이라면 숫자가 큰 쪽이 가중치 저장 공간과 메모리 대역폭을 더 요구하는 경향이 있습니다. 하지만 실제 파일에는 quantization, 일부 다른 정밀도의 tensor, metadata가 반영되고, 실행에는 KV cache와 작업 공간도 필요합니다. 그래서 B는 “어느 정도 규모의 후보인가”를 알려 주는 첫 단서이지 다운로드 가능 여부, 속도와 업무 합격을 한 번에 결정하는 최종 값은 아닙니다.

왜 이런가

B를 정확히 읽어야 모델 파일 용량을 추정하고, 성능 비교에서는 크기 이외의 조건을 빠뜨리지 않을 수 있습니다.

언제 문제가 되는가

70B를 8B보다 8.75배 정확한 모델로 해석하면 필요 이상의 장비를 구입하거나 실제 업무 평가 없이 큰 모델을 배포하게 됩니다.

초보자가 자주 하는 오해

Parameter는 사람이 읽는 사실 행이나 단어 사전의 개수가 아닙니다. 여러 계산 행렬에 분산된 학습값입니다.

직접 확인하는 방법

후보 model의 config와 weight index에서 embedding·attention·FFN tensor 이름과 shape를 찾아 어느 구성 요소에 숫자가 배치되는지 적어 보십시오.

Parameter가 많으면 더 복잡한 패턴을 표현할 capacity(수용 능력)가 커질 가능성이 있지만, 모델이 그 여지를 잘 사용했는지는 학습 과정에 달려 있습니다. 데이터의 언어와 품질, 전체 학습 token, 중복과 오염, optimizer와 학습률, architecture, instruction tuning과 안전 조정이 모두 결과를 바꿉니다. Google DeepMind의 compute-optimal 연구는 고정된 계산 예산에서 model 크기만 늘리는 대신 training token도 함께 배분해야 함을 실험했습니다. 이 결과는 특정 비율을 모든 모델에 영구 적용하라는 규칙이 아니라, 크기 하나만으로 학습 완성도를 판단할 수 없다는 근거입니다.

예를 들어 한국어 택배 문의를 다섯 범주로 나누는 업무는 출력 형식이 명확하고 정답을 확인하기 쉽습니다. 한국어와 해당 분류에 맞게 조정된 8B가 범용 70B보다 높은 형식 준수율을 보일 수 있습니다. 반대로 여러 문서의 상충 조건을 비교하거나 복잡한 프로그램의 상태 변화를 추적하는 과제에서는 더 큰 모델이 유리할 수 있습니다. 두 결과는 모순이 아닙니다. 모델의 “좋음”은 업무, prompt, 평가 지표와 허용 비용을 포함한 문장으로 정의해야 하기 때문입니다.

공정한 비교는 같은 model variant, 같은 tokenizer와 chat template, 같은 정밀도, 같은 입력·출력 한도와 같은 평가 세트를 사용합니다. 공개 benchmark는 제조자가 적은 shot 수, prompt, 언어, 채점 방식과 model revision이라는 조건 안에서 읽습니다. 내 업무에서는 정확도뿐 아니라 근거 충실도, 형식 준수, 첫 token 지연, 생성 속도, peak memory와 실패 복구까지 측정합니다. 이 기준을 통과하는 가장 작은 후보부터 선택하면 비용을 줄이면서 품질 부족 시 한 단계씩 확장할 수 있습니다.

왜 이런가

업무 기준으로 비교해야 공개 순위와 실제 사용자의 성공률이 다른 이유를 설명하고 재현 가능한 선택을 할 수 있습니다.

언제 문제가 되는가

서로 다른 prompt와 quantization으로 나온 점수를 한 표에서 단순 비교하면 크기 효과와 설정 효과를 분리할 수 없습니다.

초보자가 자주 하는 오해

큰 모델이 유리한 경향이 있다는 말과 모든 업무·비용 조건에서 큰 모델이 최선이라는 말은 같지 않습니다.

직접 확인하는 방법

내 업무의 정상 20개·경계 5개·실패 5개를 고정하고 두 후보에 같은 설정으로 실행해 품질·지연·메모리를 함께 기록하십시오.

Tokenizer가 “보고서를 수정했다”를 token ID 배열로 바꾸면 model은 각 ID를 그대로 산술 계산하지 않습니다. Vocabulary size×hidden size 모양의 embedding matrix에서 해당 행을 찾아 벡터로 바꿉니다. Hidden size가 4,096이면 token 위치 하나를 4,096개의 숫자로 표현합니다. 이 좌표들은 사람이 지정한 뜻 목록이 아니며 학습 중 함께 조정됩니다. 자주 비슷한 문맥에서 쓰인 token은 일부 관계가 비슷하게 나타날 수 있지만, 입력 embedding만 보고 문장 속 최종 의미를 확정해서는 안 됩니다.

문장에는 순서가 있으므로 위치 표현도 필요합니다. 같은 token을 사용한 “관리자가 사용자를 승인했다”와 “사용자가 관리자를 승인했다”는 주체가 반대입니다. Transformer 원 논문은 sinusoidal positional encoding을 사용했고 현대 causal model은 Rotary Position Embedding(RoPE) 같은 방식을 사용할 수 있습니다. 위치 처리 방식과 학습 범위를 무시하고 runtime에서 context 숫자만 크게 늘리면 모델이 먼 위치를 제대로 활용하지 못하거나 품질이 나빠질 수 있습니다.

Embedding과 위치가 결합된 상태는 여러 layer의 attention과 FFN을 거치며 바뀝니다. “그녀”라는 token의 ID는 같아도 앞에 “민지는 보고서를 고쳤다”가 있으면 민지와 연결되는 표현을 만들 수 있고, 다른 문맥에서는 다른 대상을 가리킬 수 있습니다. 이를 확인할 때는 embedding을 사람에게 해석 가능한 좌표표로 과장하지 않습니다. 동일 문장을 넣고 특정 layer의 hidden state를 관찰하는 연구 도구는 관계를 탐색할 단서가 될 뿐, 모델이 그 이유로만 답했다고 증명하는 완전한 설명은 아닙니다.

왜 이런가

입력 ID, embedding, 문맥 hidden state를 구분해야 tokenizer 불일치와 model reasoning 문제를 서로 다른 층에서 진단할 수 있습니다.

언제 문제가 되는가

다른 tokenizer를 같은 weight에 연결하면 ID가 가리키는 embedding 행이 어긋나 반복 문자, 무의미한 출력과 종료 실패가 생길 수 있습니다.

초보자가 자주 하는 오해

Embedding의 각 숫자에 사람이 읽을 수 있는 단일 의미가 붙는 것은 아니며, 가까운 벡터가 모든 문맥에서 같은 뜻이라는 보장도 없습니다.

직접 확인하는 방법

배포 artifact에서 tokenizer revision, vocab size, special token ID와 config의 vocab_size가 일치하는지 확인하고 대표 prompt의 token ID를 이전 배포와 비교하십시오.

Decoder-only Transformer의 한 block을 단순화하면 normalization, masked self-attention, residual addition, normalization, FFN, residual addition 순서로 볼 수 있습니다. Masked self-attention은 다음 token을 미리 보지 못하도록 현재 위치보다 뒤쪽을 가리고 앞선 문맥의 관계를 계산합니다. FFN은 위치 사이를 직접 섞지 않고 각 위치의 상태를 더 넓은 intermediate dimension으로 변환했다가 hidden size로 돌려보냅니다. 현대 구현은 normalization 위치와 activation, attention 변형이 다를 수 있으므로 실제 배선은 model architecture 문서가 정본입니다.

Residual connection은 block 입력을 새 계산 결과에 더합니다. 깊은 network가 매 단계에서 이전 정보를 전부 덮어쓰지 않고 필요한 수정값을 누적하며, 학습 신호도 여러 층으로 전달되기 쉬워집니다. Normalization은 값의 분포와 규모를 다뤄 계산을 안정시키지만 사실을 기억하는 데이터베이스가 아닙니다. “Attention이 모든 지식을 저장한다”거나 “FFN이 지식, attention이 추론”처럼 한 문장으로 역할을 완전히 분리하면 실제로 얽혀 있는 계산을 지나치게 단순화합니다.

이 구조는 장애 증상에도 연결됩니다. Checkpoint weight의 tensor shape와 config의 hidden size·intermediate size·layer 수가 다르면 loader가 크기 불일치 오류를 냅니다. 변환 도구가 weight 이름을 잘못 연결하면 파일이 열려도 출력 품질이 무너질 수 있습니다. 복구할 때 임의로 누락 tensor를 채우지 말고 공식 원본 revision, architecture class와 config를 다시 맞춘 뒤 변환 전후 대표 입력을 비교해야 합니다. 구조 도해는 이 확인 순서를 잃지 않게 하는 지도입니다.

왜 이런가

Block 전체를 알아야 attention 시각화 하나로 모델 전체를 설명하는 오류를 피하고 config·weight 불일치를 체계적으로 찾을 수 있습니다.

언제 문제가 되는가

Architecture가 다른 checkpoint를 억지로 변환하면 shape mismatch로 로드가 실패하거나 조용한 품질 회귀가 발생할 수 있습니다.

초보자가 자주 하는 오해

원 논문의 encoder-decoder 그림과 모든 최신 decoder-only 모델의 세부 순서가 완전히 같지는 않습니다.

직접 확인하는 방법

공식 architecture 문서와 config를 열어 normalization 종류, layer 수, hidden·intermediate size, activation과 attention 종류를 한 표에 적으십시오.

Self-attention은 각 token 상태에서 Query(Q), Key(K), Value(V) 벡터를 만듭니다. 질문에 비유하면 Query는 “현재 위치가 무엇을 찾는가”, Key는 “각 문맥 위치가 어떤 단서를 제공하는가”, Value는 “선택됐을 때 가져올 내용”에 가깝습니다. Query와 Key의 내적을 head dimension의 제곱근으로 조정한 뒤 mask와 softmax를 적용해 합이 1인 attention weight를 만들고, 그 weight로 Value를 섞습니다. 이 비유는 계산 순서를 이해하기 위한 것이며 벡터에 사람이 쓴 질문 문장이 실제로 들어 있다는 뜻은 아닙니다.

“민지는 보고서를 고쳤다. 그녀는 오류를 발견했다”에서 “그녀” 위치는 앞의 “민지”와 관련된 정보를 모을 수 있습니다. 하지만 attention weight 하나가 대명사 해석의 완전한 원인이라고 단정할 수는 없습니다. 여러 head와 layer가 동시에 작동하고 FFN과 residual이 뒤이어 상태를 바꿉니다. 모델이 특정 token을 많이 바라봤다는 시각화는 탐색 단서이며, 답의 인과적 설명을 확정하려면 입력을 바꾸는 개입 실험과 출력 비교가 추가로 필요합니다.

Causal mask도 중요합니다. 다음 token을 생성하는 모델이 학습 중 미래 답을 미리 보면 실제 추론과 조건이 달라집니다. 그래서 현재 위치는 자신과 이전 위치만 참고하도록 뒤쪽 attention score를 가립니다. Mask 구현이나 padding 위치가 잘못되면 답을 누설해 학습 지표가 비정상적으로 좋아지거나, 실제 생성에서는 품질이 급격히 나빠질 수 있습니다. 학습과 추론의 mask·padding·position ID를 같은 대표 sequence로 검증해야 합니다.

왜 이런가

Q·K·V와 causal mask를 이해하면 attention 그림을 정확히 읽고 학습 누설과 padding 오류의 증상을 구분할 수 있습니다.

언제 문제가 되는가

미래 token mask가 깨지면 학습 loss는 낮아 보여도 실제 autoregressive 생성에서는 이용할 수 없는 정보를 전제로 학습하게 됩니다.

초보자가 자주 하는 오해

Attention weight가 높다는 사실만으로 모델의 인간식 이유나 최종 판단 원인을 완전히 설명할 수는 없습니다.

직접 확인하는 방법

짧은 가명 문장에서 현재 token이 볼 수 있는 위치를 직접 표시하고, causal attention mask의 위삼각 영역이 차단되는지 framework 출력으로 확인하십시오.

Multi-Head Attention(MHA)은 여러 head가 서로 다른 표현 부분공간에서 관계를 계산하도록 Query·Key·Value를 나눕니다. 일반적인 MHA에서는 Query head 수와 KV head 수가 같습니다. Multi-Query Attention(MQA)은 모든 Query head가 하나의 Key head와 Value head를 공유합니다. Grouped-Query Attention(GQA)은 두 방식 사이에서 여러 Query head를 몇 개의 KV 그룹에 나눕니다. GQA 원 논문은 KV head가 하나보다 많고 Query head보다 적은 중간 구성을 도입해 MHA에 가까운 품질과 MQA에 가까운 속도를 목표로 설명합니다.

32 Query head와 8 KV head라면 네 Query head가 하나의 KV 그룹을 공유합니다. 같은 layer 수, head dimension, token 수, 정밀도와 batch라면 KV cache에서 저장하는 head 항목은 32개 MHA의 4분의 1입니다. 하지만 전체 실행 메모리가 4분의 1이 되는 것은 아닙니다. Embedding과 FFN, Query와 output projection, model weight의 다른 부분, runtime 작업 공간은 사라지지 않습니다. “GQA라서 70B가 8B 메모리로 실행된다” 같은 결론은 잘못입니다.

Model config를 읽을 때 num_attention_heads와 num_key_value_heads를 따로 적고 hidden_size÷num_attention_heads로 head dimension을 확인합니다. Query head 수가 KV head 수로 나누어지지 않으면 단순한 균등 그룹 구성이 아니거나 config를 잘못 읽었을 수 있습니다. Llama 3.1 공식 model card는 8B·70B·405B 모두 GQA를 사용한다고 명시하지만 구체적인 tensor shape와 runtime 지원은 해당 model config와 구현을 함께 확인해야 합니다.

왜 이런가

KV head를 정확히 읽어야 긴 context와 동시 요청의 cache 메모리를 과대·과소 계산하지 않습니다.

언제 문제가 되는가

Query head 수를 KV cache 식에 그대로 넣으면 GQA 모델의 cache를 과대 계산하고, 반대로 GQA 비율을 모델 전체에 적용하면 총 메모리를 과소 계산합니다.

초보자가 자주 하는 오해

Head 하나가 문법·사실·추론을 각각 전담한다거나, GQA가 Query head 자체를 줄이는 구조라고 단정하면 안 됩니다.

직접 확인하는 방법

공식 config에서 두 head 수를 찾고 그룹 크기를 계산한 뒤, 동일 context에서 runtime이 보고한 cache memory와 추정값의 차이를 기록하십시오.

입문용 근사에서는 embedding parameter를 vocabulary size×hidden size로 계산합니다. 출력 projection이 입력 embedding과 weight tying(가중치 공유)을 하면 이 표를 재사용하고, 공유하지 않으면 비슷한 크기의 출력 행렬이 추가됩니다. Attention은 Q·K·V·output projection의 shape를 합치고, gated FFN은 구현에 따라 hidden×intermediate 크기의 큰 행렬 세 개를 사용하는 경우가 많습니다. 여기에 layer 수를 곱하고 normalization 같은 작은 항목을 더하면 model 총량의 대략적인 구성을 볼 수 있습니다.

이 계산의 목적은 공식 parameter 수를 역산해 맞히는 놀이가 아닙니다. 어느 설정이 어떤 비용을 움직이는지 이해하는 데 있습니다. Vocabulary를 늘리면 embedding과 경우에 따라 출력 표가 커지고, hidden size를 늘리면 여러 제곱형 projection이 크게 증가하며, intermediate size는 FFN을 직접 키우고, layer 수는 block 비용을 반복합니다. KV head를 줄이면 K·V projection과 cache가 줄지만 Query·output·FFN은 그대로라는 사실도 수식에서 드러납니다.

실제 architecture는 bias, gated activation의 행렬 개수, tied embedding, local·global attention, mixture of experts와 multimodal projector가 달라 단순식과 정확히 일치하지 않습니다. 따라서 실습 결과에는 “교육용 근사”라는 조건을 붙이고, 최종 확인은 공식 model card·config와 weight index의 tensor shape 합으로 수행합니다. 예상과 공식 수가 크게 다르면 모델이 틀린 것이 아니라 내가 생략한 구조를 찾아 설명해야 합니다.

왜 이런가

전체 B 숫자를 구성 요소로 나누면 hidden·FFN·head 변경이 용량과 cache에 서로 다르게 영향을 주는 이유를 이해할 수 있습니다.

언제 문제가 되는가

Gated FFN을 행렬 두 개로만 세거나 untied output을 빼면 추정값이 크게 작아지고 장비 예산을 잘못 세울 수 있습니다.

초보자가 자주 하는 오해

교육용 근사식이 모든 architecture의 공식 parameter count를 대체하지 않으며, 숫자가 맞았다고 구현 호환성이 증명되는 것도 아닙니다.

직접 확인하는 방법

첫 번째 실습에서 구성별 비중을 계산한 뒤 공식 weight index의 tensor shape 합과 비교하고 빠진 항목 이름을 기록하십시오.

Model card를 읽을 때 첫 줄의 크기만 가져오지 않습니다. 개발 조직과 release date, pretrained/base인지 instruction-tuned인지, text-only인지 vision 입력이 있는지, 지원 언어와 knowledge cutoff, architecture, context, intended use와 알려진 한계, 평가 방법, license와 acceptable use를 순서대로 확인합니다. Config에서는 vocab·hidden·intermediate size, layer, Query·KV head, position과 dtype을 대조합니다. 두 문서의 숫자가 다른 경우 정확한 variant와 revision을 보고 있는지 먼저 확인합니다.

Meta의 Llama 3.1 공식 model card는 text 모델의 8B·70B·405B 크기, 128K context와 모든 크기의 GQA 사용을 명시합니다. 이 주장은 해당 공개 모델군의 구조 정보를 뒷받침하지만 내 한국어 업무 정확도, 양자화 파일의 품질, 128K에서의 지연과 consumer GPU 실행 가능성을 보증하지 않습니다. Google의 Gemma 3 model card도 크기별 입력 modality와 context 조건을 구분합니다. 가족 이름이 같다고 모든 size가 같은 기능과 한도를 가진다고 가정해서는 안 됩니다.

배포 기록에는 정확한 model ID와 commit 또는 revision, weight hash, tokenizer·chat template, quantization과 dtype, runtime·driver, context·batch, license 검토일, 평가 세트 결과와 rollback artifact를 남깁니다. 업데이트 뒤 출력이 반복되면 model weight, tokenizer, template, runtime 중 어느 항목이 바뀌었는지 diff하고 이전 묶음으로 복구합니다. 이 기록이 있어야 “같은 8B인데 왜 달라졌는가”를 이름 추측이 아니라 재현 가능한 증거로 설명할 수 있습니다.

왜 이런가

모델은 weight 하나가 아니라 입력 형식과 실행 조건을 포함한 artifact 묶음이므로 함께 고정해야 비교와 rollback이 가능합니다.

언제 문제가 되는가

움직이는 latest만 기록하면 upstream 변경 뒤 같은 실험을 재현하지 못하고 license·template·config 변화를 놓칠 수 있습니다.

초보자가 자주 하는 오해

공식 최대 context와 benchmark는 해당 조건의 보고값이며 모든 언어·runtime·정밀도에서 같은 결과를 약속하는 보증서가 아닙니다.

직접 확인하는 방법

후보마다 model ID·revision·hash·variant·context·tokenizer·template·license·runtime·평가 결과를 한 행에 적고 빈칸이 있는 후보는 승격하지 마십시오.

언어 model은 token ID를 hidden vector로 바꾸는 input embedding과 마지막 hidden state를 vocabulary logit으로 바꾸는 output projection을 가집니다. 두 행렬은 vocabulary size×hidden size처럼 대응되는 shape를 가질 수 있습니다. Weight tying은 output이 input embedding과 같은 parameter를 공유하는 설계입니다. 역할은 두 개지만 저장·학습 tensor는 하나이므로 단순 계산에서 두 번 더하면 총량을 과대 추정합니다.

Config의 `tie_word_embeddings` 같은 필드는 단서지만 모든 architecture가 같은 이름과 저장 방식을 사용하지 않습니다. Weight index에서 input과 output 이름이 같은 storage를 참조하는지, checkpoint가 output tensor를 별도로 포함하는지 framework loader와 공식 architecture 문서로 확인합니다. Safetensors shard의 byte 합만으로 parameter 공유를 완전히 설명하기 어렵다면 loaded model의 named parameter와 data pointer·공식 count를 대조합니다.

Parameter sharing은 embedding에만 한정되지 않습니다. 일부 architecture는 layer 사이 weight를 재사용하거나 expert·adapter를 조건부로 연결할 수 있습니다. 반대로 multimodal model은 vision encoder, projector와 audio component를 추가해 text model 이름보다 많은 tensor를 가질 수 있습니다. 교육용 Dense decoder 근사식을 모든 checkpoint에 강제로 맞추지 않고 예상과 공식 count의 차이를 구조 목록으로 설명합니다.

Conversion과 quantization 뒤에도 sharing이 유지되는지 확인합니다. Converter가 공유 tensor를 두 번 materialize하면 parameter count 표시는 같아 보여도 artifact byte와 load memory가 늘 수 있고, 반대로 alias 처리 방식 때문에 file 목록에 하나만 보일 수 있습니다. 원본·변환물의 tensor 이름·shape·dtype·storage byte를 비교하고 동일 prompt 품질과 peak memory를 재시험해 변환 계약을 닫습니다.

왜 이런가

Parameter는 계산 역할이 아니라 실제로 독립 학습되는 tensor 원소를 세므로 같은 weight를 여러 곳에서 쓰면 한 번만 집계해야 합니다.

언제 문제가 되는가

Embedding과 output을 무조건 두 번 세거나 변환물의 sharing이 깨지면 parameter·file·memory 추정이 공식 수치와 크게 어긋납니다.

초보자가 자주 하는 오해

Shape가 같으면 자동으로 같은 weight이거나 config의 공유 flag 하나만으로 모든 artifact alias가 증명되는 것은 아닙니다.

직접 확인하는 방법

공식 config·weight index·loaded parameter에서 input·output tensor의 이름·shape·storage 공유를 확인하고 변환 전후 byte·peak를 비교하십시오.

8B parameter를 4bit로 저장하면 단순 weight 하한은 약 4GB이지만 scale·metadata와 mixed tensor가 더해지고 runtime은 graph·kernel workspace와 allocator를 사용합니다. Parameter 수가 고정돼도 activation과 KV cache는 input·output token, layer, hidden·KV head, batch와 concurrency에 따라 달라집니다. “8B Q4 file이 6GiB이므로 8GiB 장치에 안전하다”는 결론에는 최장 요청의 실행 상태가 빠져 있습니다.

Inference에서 prefill activation은 kernel과 implementation에 따라 일시 peak를 만들고 decode 동안 KV cache가 token과 sequence에 따라 자랍니다. Static cache는 최대 공간을 미리 잡을 수 있고 paged runtime은 block과 allocator overhead를 가집니다. 같은 model parameter라도 context 4K 한 요청과 32K 네 요청의 peak가 다른 이유입니다. Load, prefill, decode와 target concurrency별 GPU·system memory를 따로 측정합니다.

Training은 weight뿐 아니라 gradient, optimizer state와 backward를 위한 activation을 저장합니다. Adam 계열 optimizer는 parameter당 여러 상태를 유지할 수 있고 mixed precision training은 master weight를 둘 수 있습니다. LoRA·QLoRA는 학습 parameter와 weight memory를 줄일 수 있지만 activation, quantization metadata와 optimizer가 사라지는 것은 아닙니다. Inference가 되는 장비에서 training도 된다고 B 숫자 하나로 결론 내리지 않습니다.

운영 표에는 artifact byte, loaded weight, load·prefill·decode peak, KV cache, host offload와 training peak를 별도 열로 둡니다. 각 값에는 측정 시점, exact model·runtime, input·output token과 동시성을 붙여 다른 조건의 숫자가 한 열에서 섞이지 않게 합니다. 장비 구매표에도 가중치 하한만 옮기지 말고 대표 입력과 최장 입력, 한 사용자와 목표 사용자 수의 실제 최대치를 나란히 적습니다. 시스템 메모리로 일부 층을 내보냈다면 장치 메모리 감소와 함께 전송 지연, 중앙 처리 장치 사용량과 응답 하위 백분위도 남겨야 합니다. 측정하지 못한 칸은 영으로 채우지 말고 미확인으로 표시해 승인자가 남은 위험을 알게 합니다. 승인 전에는 다른 담당자가 표의 입력 조건과 단위를 다시 확인합니다. 새 runtime·context·batch·quant를 적용할 때 한 항목씩 바꾸고 같은 failure input으로 peak·latency·품질을 재시험합니다. OOM이 나면 parameter 이름만 작은 model로 즉시 교체하기보다 어느 장부가 늘었는지 확인하고 admission limit과 이전 설정 rollback을 먼저 복구합니다.

왜 이런가

가중치는 고정 tensor지만 activation·cache·gradient·optimizer는 실행 목적과 요청·batch에 따라 생성되고 증가하기 때문입니다.

언제 문제가 되는가

File과 weight 계산은 맞는데 prefill·동시성 또는 training에서 OOM이면 별도 상태·workspace 장부가 빠졌을 가능성이 큽니다.

초보자가 자주 하는 오해

Parameter×bit÷8이 model의 모든 실행·학습 memory이거나 quantization 비율만큼 전체 peak도 정확히 줄어드는 것은 아닙니다.

직접 확인하는 방법

같은 artifact에서 load·prefill·decode·concurrency와 training 단계의 device·host peak를 측정해 weight 하한과 차이를 항목별로 설명하십시오.