카테고리
AI 기술·원리
모델 구조와 추론, RAG, 컨텍스트, 압축 같은 AI의 작동 원리를 공식 자료 기준으로 해설합니다.
-
XOR은 직선 하나로 못 푼다 — 2-4-1 신경망의 가운데 4가 하는 일
신경망을 처음 볼 때 다들 뉴런 그림에 압도당한다. 원과 화살표가 층층이 이어진 그 도해 말이다. 그런데 정작 신경망이 하는 일은 단순하다. 답을 내고, 얼마나 틀렸는지 재고, 그 오차만큼 내부 숫자를 되돌린다. 이 세 동작의 반복이 학습의 전부다. 이 글은 …
-
4GB 노트북으로 문서 검색과 답변을 다 돌린다, GPU 없이
사내 계약서나 개인 진료 기록을 ChatGPT에 붙여넣고 요약을 시키는 순간, 그 문서는 이미 내 컴퓨터를 떠난다. 많은 사람이 여기서 멈칫한다. 그렇다고 답변 자동화를 포기하긴 아깝다. RAG는 바로 이 딜레마를 푸는 구조다 — 문서를 밖으로 보내지 않고, …
-
AI 서비스 설계, 모델은 7단계 중 5번째다
AI 기능 하나를 붙이는 코드는 반나절이면 짠다. 문제는 그게 서비스가 되는 순간이다. 응답이 느려지고, 비용이 새고, 그럴듯한 오답이 나가고, 남의 개인정보가 답변에 섞인다. 그런데 대부분은 이 문제를 “더 좋은 모델로 바꾸면 되지 않나”로 해결하려 한다. …
-
66GB를 22GB로 줄이고도 품질을 지킨 비결: 압축이 아니라 되돌리기다
모델을 작게 만든다고 하면 대부분 “숫자를 4비트로 줄였다” 정도로 이해하고 넘어간다. 그런데 NVIDIA가 Nemotron 3.5 Lightning을 66GB에서 22GB로, 즉 3분의 1로 줄이면서 공개한 과정을 뜯어보면 진짜 어려운 대목은 압축이 아니었다…
-
긴 지시문이 안 먹히는 3가지 순간, 작은 전용 모델이 답이다
“프롬프트를 더 잘 써라”는 조언에는 함정이 있다. 규칙이 정말 복잡한 업무에선 지시문을 아무리 정교하게 늘려도 벽에 부딪힌다. 항목이 빠지고, 없던 내용이 붙고, 분기 규칙이 어긋난다. 그런데 여기서 대부분은 “더 큰 모델을 쓰자”로 간다 — 실은 방향이 틀…
-
리더보드 1위 모델을 그대로 붙였다가 청구서에 후회하는 이유
AI 모델을 고를 때 다들 리더보드 1위부터 본다. 그런데 리더보드 최상단 모델을 그대로 붙였다가 청구서를 보고 후회하는 일이 훨씬 흔하다. 벤치마크 점수는 “이 모델이 어떤 시험을 잘 봤다”는 기록일 뿐, “내 서비스에서 싸고 빠르게 돌아간다”는 보장이 아니…
-
prefill은 연산, decode는 메모리 — LLM 추론 병목은 하나가 아니다
“모델을 더 작게 만들면 추론이 빨라진다.” 절반만 맞는 말이다. LLM 추론은 성격이 완전히 다른 두 단계로 쪼개진다. 입력 프롬프트를 한꺼번에 읽는 prefill과, 토큰을 한 개씩 뱉는 decode다. 이 둘은 병목이 정반대라서, 한쪽에 잘 듣는 처방이 …
-
큰 모델부터 붙이지 마라 — 좁은 업무엔 3B SmolLM3가 먼저다
AI 모델을 고를 때 대부분 크기부터 키우고 본다. 큰 모델이 더 똑똑하니까, 일단 제일 큰 걸 붙이면 안전할 거라고. 그런데 고객 문의를 종류별로 나누거나, 어떤 언어로 왔는지 감지하는 일에 70B급 모델을 붙이는 건 택배 하나 보내려고 트럭을 렌트하는 격이…
-
긴 입력에서 정보가 밀려나던 문제, Transformer는 이렇게 우회했다
Transformer를 설명하는 글은 대부분 query·key·value부터 들이민다. 순서가 거꾸로다. 이 구조는 어느 날 갑자기 발명된 게 아니라, RNN이 긴 문장에서 계속 실패하던 구체적인 병목을 하나씩 우회하다 나온 결과물이다. 그래서 구조를 외우는 …
-
어텐션은 왜 128K에서 추론 시간의 85%를 먹어치우나
모델 성능을 이야기할 때 우리는 보통 파라미터 수나 벤치마크 점수를 본다. 그런데 긴 문맥을 다루기 시작하면 진짜 발목을 잡는 건 다른 곳에 있다. 바로 어텐션이다. 짧은 프롬프트에서는 존재감도 없던 이 연산이, 문맥이 128K로 길어지면 추론 시간의 85%를…