KV 캐시KV Cache
이미 처리한 토큰의 어텐션 키와 값을 들고 있어, 토큰을 하나 더 뽑을 때마다 앞을 다시 계산하지 않게 하는 메모리.
긴 대화가 느려지고 GPU 메모리가 터지는 이유의 대부분이 이것이다. 컨텍스트가 길수록, 동시 사용자가 많을수록 선형으로 불어난다.
같이 볼 것 PagedAttention · 컨텍스트 창 · VRAM · 프리필 단계
카드에 자꾸 나오는 용어와, 그걸 알고 나면 무엇이 달리 읽히는지.
24개
이미 처리한 토큰의 어텐션 키와 값을 들고 있어, 토큰을 하나 더 뽑을 때마다 앞을 다시 계산하지 않게 하는 메모리.
긴 대화가 느려지고 GPU 메모리가 터지는 이유의 대부분이 이것이다. 컨텍스트가 길수록, 동시 사용자가 많을수록 선형으로 불어난다.
같이 볼 것 PagedAttention · 컨텍스트 창 · VRAM · 프리필 단계
모델 가중치를 낮은 비트 수로 줄여 저장해 메모리와 대역폭을 아끼는 변환.
모델 이름 뒤에 붙은 FP8, Q4, GGUF는 전부 이 이야기다. 크기를 줄인 만큼 품질이 조금씩 깎이고, 어디까지 깎을지가 논쟁거리다.
값 하나를 8비트 부동소수점으로 저장하는 정밀도로, 16비트 대비 메모리를 절반으로 줄인다.
카드에 FP8이 붙으면 같은 모델을 절반 메모리로 돌린다는 뜻이다. 단 네이티브 연산은 H100·4090급 이후 GPU에서만 된다.
llama.cpp 계열에서 쓰는 단일 파일 모델 포맷으로, 양자화된 가중치와 메타데이터를 함께 담는다.
모델 이름에 GGUF가 붙어 있으면 클라우드가 아니라 내 노트북에서 돌리라고 올린 파일이다. Ollama와 LM Studio가 읽는 것도 이것.
어텐션 계산을 GPU 안 빠른 메모리에서 쪼개 처리해 느린 메모리 왕복을 줄인 구현.
긴 컨텍스트가 현실이 된 계기다. 정확도는 그대로 두고 메모리 접근만 줄여서, 지금은 대부분의 엔진에 기본으로 들어 있다.
애플이 애플 실리콘에 맞춰 만든 머신러닝 프레임워크와, 그 위에서 돌리려고 변환해 둔 가중치 형식.
모델 이름 뒤에 MLX가 붙으면 맥에서 돌리라고 올린 것이다. 통합 메모리 덕에 맥은 VRAM 한계가 GPU와 다르게 잡힌다.
모델을 API나 서버 뒤에 올려두고 여러 요청을 동시에 받아 처리하는 운영 방식.
모델을 한 번 돌리는 것과 수천 명에게 돌려주는 것은 다른 문제다. 서빙이 붙은 제목은 성능이 아니라 동시성과 단가 이야기다.
가중치 하나를 4비트로 줄인 양자화 등급으로, 원본 16비트 대비 용량이 약 4분의 1이다.
24GB GPU에 27B 모델이 들어가느냐를 가르는 선이 대개 여기다. Q4_0, Q4_K_M 같은 꼬리표는 같은 4비트 안의 방식 차이다.
값 하나를 16비트로 담는 정밀도로, 지금 공개되는 모델 가중치의 기본 형태다.
모델 크기를 어림할 때 기준이 이것이다. 27B 모델이 BF16이면 대략 54GB, 여기서 FP8은 절반, Q4는 4분의 1로 내려간다.
KV 캐시를 운영체제 페이징처럼 작은 블록으로 쪼개 관리해 낭비되는 GPU 메모리를 줄이는 기법.
vLLM이 유명해진 이유가 이것이다. 같은 GPU에서 동시에 받는 요청 수가 몇 배로 늘어난다는 주장은 대개 여기서 나온다.
요청을 묶어 한 번에 계산하되, 끝난 자리에 새 요청을 바로 채워 넣는 스케줄링 방식.
GPU는 한 명을 위해 돌리나 서른 명을 위해 돌리나 비슷하게 걸린다. 서빙 단가가 사용자 수로 나뉘는 게 이 덕분이다.
같이 볼 것 서빙 · 처리량 · PagedAttention · vLLM
작은 모델이 다음 토큰 여러 개를 미리 찍고, 큰 모델이 한 번에 검사해 맞은 만큼 건너뛰는 방식.
출력이 달라지지 않으면서 속도만 오르는 드문 최적화다. 같은 모델인데 왜 갑자기 빨라졌냐는 이야기는 대개 여기서 나온다.
입력 프롬프트 전체를 한 번에 계산해 KV 캐시를 채우는 추론의 앞 구간. 첫 토큰은 이게 끝나야 나온다.
여기는 연산에 묶여서 입력이 길수록 첫 글자가 늦게 뜬다. 프롬프트 캐싱이 값을 깎는 자리도 정확히 이 구간이다.
요청을 보낸 뒤 첫 토큰이 화면에 뜨기까지 걸리는 시간.
사람이 느끼는 느림은 대부분 여기서 결정된다. 초당 토큰 수가 아무리 좋아도 TTFT가 길면 체감은 그대로 느리다.
초당 몇 개의 토큰을 뽑아내는지, 또는 서버 전체가 초당 몇 요청을 처리하는지를 나타내는 수치.
한 명 기준 숫자와 서버 전체 기준 숫자가 다른데 둘 다 처리량이라 부른다. 벤치마크를 볼 때 어느 쪽인지부터 확인해야 한다.
GPU에 다 안 들어가는 층을 CPU 메모리나 디스크에 내려두고 필요할 때 불러 쓰는 방식.
안 돌아가던 모델이 돌아가긴 한다. 대신 속도가 몇 배로 느려져서, 된다는 후기와 못 쓰겠다는 후기가 같이 달린다.
여러 요청을 한 GPU에 몰아 처리하도록 만든 오픈소스 서빙 엔진.
자체 서빙 이야기의 사실상 기본값이라, 논문과 회사 발표가 처리량을 비교할 때 기준선으로 잡는 쪽이 대개 이것이다.
같이 볼 것 서빙 · PagedAttention · 연속 배칭 · 처리량
C++로 쓴 로컬 추론 엔진으로, 개인 PC의 CPU와 GPU에서 양자화 모델을 돌린다.
개인이 모델을 돌린다는 이야기의 바닥에 거의 항상 이게 있다. GGUF, Ollama, LM Studio가 전부 이 위에 얹혀 있다.
명령 한 줄로 모델을 내려받아 로컬에서 띄우고 API까지 열어주는 실행 도구.
로컬로 돌려봤다는 글은 대개 이 도구 기준이다. 실제 계산은 밑에 깔린 llama.cpp 계열 엔진이 하는 것이라, 속도 이야기는 그쪽 이야기다.
매번 똑같이 들어가는 앞부분 입력의 계산 결과를 재사용해 비용과 지연을 줄이는 기능.
시스템 프롬프트와 문서를 매 턴 다시 밀어 넣는 에이전트에서 청구서가 몇 배로 갈린다. 캐시 히트율이 곧 요금이다.
입력과 출력 토큰 100만 개당 얼마로 매기는 API 과금 방식.
출력이 입력보다 몇 배 비싸다. 그래서 길게 생각하는 모델일수록 같은 질문에 청구서가 커지고, 벤치마크 옆에 달러가 같이 붙는다.
서버로 보내지 않고 노트북이나 휴대폰 안에서 모델을 직접 돌리는 방식.
요금과 데이터 유출이 사라지는 대신 메모리와 대역폭이 기기 사양에 묶인다. 작은 MoE와 4비트 모델이 계속 나오는 이유다.
다음 토큰을 뽑을 때 확률 분포를 얼마나 평평하게 할지(temperature), 후보를 몇 개까지 남길지(top-p·top-k) 정하는 값.
모델 카드가 'temperature 0.6, top_p 0.95'를 못박는 이유 — 같은 가중치도 이 값이 어긋나면 벤치마크 점수가 재현되지 않는다.
프리필이 끝난 뒤 토큰을 하나씩 뽑아내는 구간. 한 토큰마다 가중치 전체와 캐시를 메모리에서 다시 읽는다.
여기는 연산이 아니라 메모리 대역폭에 묶인다 — 코어만 많은 칩이 생성 속도를 못 올리고, 서빙 글이 HBM을 따지는 이유다.