AI/LLM 관련
RAG(Retrieval-Augmented Generation) 파이프라인을 구축하다 보면 어느 순간 묘한 벽에 부딪힌다. LLM은 GPT-4급을 쓰고 있고, 문서도 수만 건을 인덱싱했는데, 정작 사용자가 던진 질문에 대해 모델은 엉뚱한 답변을 내놓는다. 이때 대부분의 개발자는 프롬프트를 고치거나 더 큰 모델로 교체하는 방향을 먼저 떠올린다. 하지만 진짜 문제는 대체로 다른 곳에 있다. 검색 단계가 엉망이면 LLM에 무엇을 집어넣어도 소용없다. 검색 품질이 … 더 읽기
AI 개발의 지배적 내러티브는 오랫동안 단순했다. 더 크게, 더 많은 데이터, 더 많은 컴퓨팅. 그런데 지금 현장에서 실제로 쓰이는 모델들을 들여다보면 그 방향이 적어도 일부에서는 정반대로 흐르고 있다. Scaling Law의 균열 — 데이터가 파라미터를 이기는 경우 신경망 연구자들이 오랫동안 믿어온 공식이 있다. 파라미터를 두 배로 늘리면 성능이 예측 가능한 방식으로 향상된다는 이른바 스케일링 법칙(Scaling Law)이다. … 더 읽기
컨텍스트 길이가 늘어날수록 KV 캐시가 메모리를 잡아먹는다는 사실은 이제 어느 정도 알려져 있다. 그런데 그 문제를 해결하겠다고 나온 기법들이 실제로 어떤 원리로 동작하는지는 의외로 피상적으로만 알려진 경우가 많다. PagedAttention이 “페이지 테이블에서 착안했다”는 설명은 들어봤어도, 정확히 어느 지점에서 어떤 이득이 생기는지, GQA가 MHA와 구체적으로 무엇이 다른지, H2O가 어떤 토큰을 어떤 기준으로 버리는지는 실제 논문이나 구현 코드를 … 더 읽기
AI 모델을 서비스에 얹는 순간, 엔지니어는 불편한 진실 하나와 마주하게 된다. Throughput(처리량)을 높이려 할수록 Latency(지연)가 나빠지고, Latency를 줄이려 하면 GPU가 놀게 된다는 것이다. 이 둘은 단순히 설정값을 조정하면 해결되는 문제가 아니라, GPU가 동작하는 방식 자체에서 비롯된 구조적 긴장관계다. GPU는 수천 개의 코어가 동시에 동일한 연산을 처리하는 병렬 프로세서다. 이 구조가 최대 효율을 낼 수 있는 … 더 읽기
128K 토큰짜리 컨텍스트 창이 이제는 흔한 사양이 됐다. Claude, GPT-4o, Gemini 1.5는 이미 그 선을 넘었고, 일부 모델은 백만 토큰을 공언하기도 한다. 그런데 이 숫자들이 실제로 얼마나 잘 “작동”하는지는 별개의 이야기다. 컨텍스트 창 확장의 병목은 두 갈래다. 하나는 이미 많이 알려진 KV 캐시(Key-Value Cache) 메모리 비용이고, 다른 하나는 Attention 연산 자체의 계산 복잡도다. 전자는 얼마나 … 더 읽기
거대 언어 모델(LLM)을 사용할 때 가장 답답한 순간은 무엇일까요? 아마도 텍스트가 한 글자씩 느릿하게 출력되는 ‘자기회귀적(Autoregressive) 생성’의 속도일 것입니다. 모델이 커질수록 이 문제는 더욱 심각해지며, 이는 실시간 대화형 AI 서비스의 가장 큰 기술적 장벽이 됩니다. 최근 이 문제를 해결하기 위해 등장한 Speculative Decoding(추측적 디코딩)은 매우 영리한 접근 방식을 취합니다. “작고 빠른 모델이 미리 예측하고, 큰 … 더 읽기
맥북 스펙표에 “38 TOPS Neural Engine”이라고 적혀 있으면, 자연스럽게 이런 생각이 든다. 저 칩이 LLM 추론을 가속해주는 거 아닐까. 그런데 실제로 Ollama를 돌려보면 ANE 사용률은 거의 0에 가깝다. ANE(Apple Neural Engine)는 Apple이 A11 Bionic부터 도입한 전용 추론 가속기다. M4 칩 기준으로 38 TOPS(Tera Operations Per Second)의 연산 처리 능력을 갖추고 있고, 설계 철학은 명확하다. 전력을 … 더 읽기
LLM을 매일 쓰는 개발자라면 한 번쯤 이 계산을 해봤을 것이다. “내가 매달 API에 얼마를 쓰고 있지?” 그리고 그 다음 질문은 자연스럽게 이어진다. “맥북 한 대 사서 로컬로 돌리면 본전은 뽑을 수 있을까?” 막연한 질문이지만, 숫자를 직접 뽑아보면 생각보다 선명한 그림이 나온다. 이 글에서는 하루 약 100K 토큰을 소비하는 개인 개발자·연구자 시나리오를 기준으로, API 비용과 로컬 … 더 읽기
커뮤니티에서 “이 모델 토큰 속도 85 t/s 나왔어요”라는 글을 보면 솔깃해진다. 그런데 막상 동일한 모델을 내 맥북이나 서버에 올려보면 절반도 안 나오는 경우가 허다하다. 측정 방법이 잘못된 것도, 내 하드웨어가 고장난 것도 아니다. 벤치마크를 기록한 사람과 나의 실행 조건이 전혀 다른 것이다. 로컬 LLM 생태계가 빠르게 성장하면서 llama.cpp, Ollama, LM Studio, vLLM 같은 런타임이 저마다 … 더 읽기
로컬 LLM을 처음 세팅하고 나서 가장 먼저 확인하게 되는 숫자가 tokens/sec다. “이 모델은 43 t/s 나온다”는 말을 들으면 빠르다는 인상을 받는다. 그런데 막상 써보면 질문을 입력하고 나서 한참 동안 커서만 깜빡이다가 갑자기 텍스트가 쏟아진다. 분명 숫자는 좋은데 체감은 둔하다. 이 불일치의 원인이 바로 TTFT, 즉 Time To First Token이다. LLM 추론은 크게 두 단계로 나뉜다. … 더 읽기