KV 캐시가 터지지 않으려면 — 압축 기법들이 실제로 하는 일

컨텍스트 길이가 늘어날수록 KV 캐시가 메모리를 잡아먹는다는 사실은 이제 어느 정도 알려져 있다. 그런데 그 문제를 해결하겠다고 나온 기법들이 실제로 어떤 원리로 동작하는지는 의외로 피상적으로만 알려진 경우가 많다. PagedAttention이 “페이지 테이블에서 착안했다”는 설명은 들어봤어도, 정확히 어느 지점에서 어떤 이득이 생기는지, GQA가 MHA와 구체적으로 무엇이 다른지, H2O가 어떤 토큰을 어떤 기준으로 버리는지는 실제 논문이나 구현 코드를 … 더 읽기

GPU 한 장을 어떻게 쓸 것인가 — AI 추론 서버 아키텍처의 근본적 선택

AI 모델을 서비스에 얹는 순간, 엔지니어는 불편한 진실 하나와 마주하게 된다. Throughput(처리량)을 높이려 할수록 Latency(지연)가 나빠지고, Latency를 줄이려 하면 GPU가 놀게 된다는 것이다. 이 둘은 단순히 설정값을 조정하면 해결되는 문제가 아니라, GPU가 동작하는 방식 자체에서 비롯된 구조적 긴장관계다. GPU는 수천 개의 코어가 동시에 동일한 연산을 처리하는 병렬 프로세서다. 이 구조가 최대 효율을 낼 수 있는 … 더 읽기

128K 컨텍스트 창의 진짜 병목 — Attention의 이차 복잡도와 그 너머

128K 토큰짜리 컨텍스트 창이 이제는 흔한 사양이 됐다. Claude, GPT-4o, Gemini 1.5는 이미 그 선을 넘었고, 일부 모델은 백만 토큰을 공언하기도 한다. 그런데 이 숫자들이 실제로 얼마나 잘 “작동”하는지는 별개의 이야기다. 컨텍스트 창 확장의 병목은 두 갈래다. 하나는 이미 많이 알려진 KV 캐시(Key-Value Cache) 메모리 비용이고, 다른 하나는 Attention 연산 자체의 계산 복잡도다. 전자는 얼마나 … 더 읽기

Speculative Decoding: 작은 모델이 큰 모델의 속도를 높이는 원리

거대 언어 모델(LLM)을 사용할 때 가장 답답한 순간은 무엇일까요? 아마도 텍스트가 한 글자씩 느릿하게 출력되는 ‘자기회귀적(Autoregressive) 생성’의 속도일 것입니다. 모델이 커질수록 이 문제는 더욱 심각해지며, 이는 실시간 대화형 AI 서비스의 가장 큰 기술적 장벽이 됩니다. 최근 이 문제를 해결하기 위해 등장한 Speculative Decoding(추측적 디코딩)은 매우 영리한 접근 방식을 취합니다. “작고 빠른 모델이 미리 예측하고, 큰 … 더 읽기

Apple Neural Engine은 LLM 추론에 실제로 쓰이나 — ANE의 역할과 한계

맥북 스펙표에 “38 TOPS Neural Engine”이라고 적혀 있으면, 자연스럽게 이런 생각이 든다. 저 칩이 LLM 추론을 가속해주는 거 아닐까. 그런데 실제로 Ollama를 돌려보면 ANE 사용률은 거의 0에 가깝다. ANE(Apple Neural Engine)는 Apple이 A11 Bionic부터 도입한 전용 추론 가속기다. M4 칩 기준으로 38 TOPS(Tera Operations Per Second)의 연산 처리 능력을 갖추고 있고, 설계 철학은 명확하다. 전력을 … 더 읽기

Apple Silicon으로 로컬 LLM 1년, API 비용을 실제로 얼마나 아꼈나

LLM을 매일 쓰는 개발자라면 한 번쯤 이 계산을 해봤을 것이다. “내가 매달 API에 얼마를 쓰고 있지?” 그리고 그 다음 질문은 자연스럽게 이어진다. “맥북 한 대 사서 로컬로 돌리면 본전은 뽑을 수 있을까?” 막연한 질문이지만, 숫자를 직접 뽑아보면 생각보다 선명한 그림이 나온다. 이 글에서는 하루 약 100K 토큰을 소비하는 개인 개발자·연구자 시나리오를 기준으로, API 비용과 로컬 … 더 읽기

로컬 LLM 벤치마크를 곧이곧대로 믿으면 안 되는 이유

커뮤니티에서 “이 모델 토큰 속도 85 t/s 나왔어요”라는 글을 보면 솔깃해진다. 그런데 막상 동일한 모델을 내 맥북이나 서버에 올려보면 절반도 안 나오는 경우가 허다하다. 측정 방법이 잘못된 것도, 내 하드웨어가 고장난 것도 아니다. 벤치마크를 기록한 사람과 나의 실행 조건이 전혀 다른 것이다. 로컬 LLM 생태계가 빠르게 성장하면서 llama.cpp, Ollama, LM Studio, vLLM 같은 런타임이 저마다 … 더 읽기

tokens/sec 숫자만 믿다가 낭패 보는 이유 — TTFT(첫 토큰 지연)가 체감 속도를 결정한다

로컬 LLM을 처음 세팅하고 나서 가장 먼저 확인하게 되는 숫자가 tokens/sec다. “이 모델은 43 t/s 나온다”는 말을 들으면 빠르다는 인상을 받는다. 그런데 막상 써보면 질문을 입력하고 나서 한참 동안 커서만 깜빡이다가 갑자기 텍스트가 쏟아진다. 분명 숫자는 좋은데 체감은 둔하다. 이 불일치의 원인이 바로 TTFT, 즉 Time To First Token이다. LLM 추론은 크게 두 단계로 나뉜다. … 더 읽기

“8B면 충분하다”는 말이 맞는 경우와 틀린 경우

로컬 LLM을 처음 써본 사람들이 가장 자주 하는 말 중 하나가 “생각보다 잘 되네”다. Llama 3.1 8B를 처음 돌려보고, 짧은 번역이나 요약이 그럭저럭 나오면 “이 정도면 충분하지 않나”라는 생각이 든다. 벤치마크 점수도 뒷받침해준다. Qwen2.5 7B는 특정 코딩 벤치마크에서 GPT-4o와 비슷한 수치를 보여줬고, Llama 3.1 8B는 같은 사이즈 이전 세대 모델들을 압도한다. 그러나 “충분하다”는 말은 항상 … 더 읽기

외장 SSD에 LLM 모델을 저장하면 속도는 얼마나 느려질까

로컬 LLM을 쓰다 보면 어느 순간 내장 드라이브가 빡빡해진다. 7B짜리 모델 하나가 4~5GB, 13B는 8~9GB, 70B 모델이면 압축해도 40GB 안팎이다. 모델 서너 개만 받아도 100GB가 훌쩍 넘어간다. 그래서 자연스럽게 드는 질문이 하나 있다. 외장 SSD에 모델을 옮기면 실제로 얼마나 느려질까? 결론부터 말하면, 스토리지 속도가 LLM 성능에 영향을 미치는 시점은 딱 하나다. 모델을 처음 메모리에 올릴 … 더 읽기