LangTailor페이지 목차
이 페이지에서 검색
로컬 LLM
이 페이지에 묻기
로컬 LLM · 현재 차시와 목차 본문에서만 찾아 답합니다. 답을 지어내지 않고 해당하는 대목을 그대로 보여 주며, 여기에 없으면 없다고 알려 드립니다.
생성형 AI가 아니라 이 페이지 본문을 찾아 그대로 보여 주는 방식입니다. 외부로 나가는 요청이 없습니다.
LOCAL · LLM
로컬 LLM
생성 수정
로컬 모델 실행과 GPU·메모리 이해부터 서빙·RAG·도구 호출·업무형 앱 구현까지 차례로 살펴봅니다.
42개 문서 · 길잡이·부록 · 1 / 42
00 · 이 노트를 읽는 법 + 전체 목차
이 문서는 본문이 아닙니다. 지도 입니다.
처음 읽는다면 2장(정의하는 법) , 4장(전체 구조) , 5장(판별 축 지도) 만 먼저 읽고 1차시로 넘어가세요. 나머지는 필요할 때 돌아와 찾아 읽으면 됩니다.
이 노트는 이 폴더만으로 완결 되도록 썼습니다. 다른 교재나 자료를 찾아보지 않아도 되며, 처음 나오는 개념은 그 자리에서 설명합니다.
이 문서를 다 읽으면
- 이 과정이 무엇을 만들고, 무엇은 다루지 않는지 말할 수 있다.
- 새 용어를 만났을 때 던질 네 개의 질문 을 순서대로 댈 수 있다.
- 로컬 LLM 서비스를 다섯 개의 층 으로 나누고, 5일이 각각 어느 층을 맡는지 말할 수 있다.
- 이 노트 전체를 관통하는 여덟 개의 판별 축 을 대고, 각 축이 이 과정에서 어디에 나오는지 찾아갈 수 있다.
- 이 분야의 번역어 함정 (추론, 토큰, 파라미터 등)을 알고 헷갈리지 않을 수 있다.
- 각 차시 노트에서 "AI에게 맡기는 자리"와 "내가 검수하는 자리" 를 구분해 읽을 수 있다.
1. 이 과정은 무엇인가
1.1 한 문장
외부로 데이터를 보내지 않고, 내 GPU 위에서 LLM을 돌려, 여러 사람이 쓸 수 있는 AI 업무 서비스를 만든다.
과정이 끝나면 세 가지가 남습니다.
| 산출물 | 내용 | 주로 만드는 날 |
|---|---|---|
| 모델 선택 근거 | 어떤 모델을 어떤 형식(양자화)으로 돌릴지 메모리 · 속도 · 품질 숫자로 설명한 기록 | 2일차 |
| LLM 서버 | vLLM(또는 Ollama)으로 띄운 OpenAI 호환 API 서버 | 3일차 |
| 업무형 AI 애플리케이션 | 스트리밍 · 대화 · 프롬프트 · 구조화 출력 · 도구 호출을 갖춘 서비스 | 4~5일차 |
1.2 이 과정이 다루지 않는 것
| 다루지 않는 것 | 무엇인가 | 왜 빠졌나 |
|---|---|---|
| RAG (검색 증강 생성) | 질문과 관련된 사내 문서를 찾아 프롬프트에 함께 넣어 주는 기법 | 이 과정은 모델을 돌리고 서비스하는 층 에 집중합니다. RAG는 이 과정이 만든 서버 위에 그대로 얹을 수 있는 다음 단계입니다 (40차시) |
| 파인튜닝 (미세조정) | 내 데이터로 모델의 가중치를 추가 학습시키는 것 | 학습은 추론보다 훨씬 많은 자원이 들고, 별도 과정이 필요합니다 |
1.3 일정
| 일차 | 날짜 | 주제 |
|---|---|---|
| 1일차 | 11.28 (토) | 로컬 LLM 이해와 실행 (Ollama까지) |
| 2일차 | 11.29 (일) | 메모리 · 양자화 · 추론 성능 |
| 3일차 | 12.04 (금) | vLLM 서빙 |
| 4일차 | 12.05 (토) | LLM 애플리케이션 기능 |
| 5일차 | 12.06 (일) | 프로젝트 |
2. 이 노트의 사고방식 — 정의하는 법
2.1 비유보다 범주를 먼저
"Ollama는 LLM용 앱스토어 같은 거예요", "vLLM은 고속도로 같은 거예요" 같은 비유는 기억에는 좋지만 서로 겹칩니다. 겹치면 경계가 흐려지고, 둘이 무엇이 다른지 말할 수 없게 됩니다.
그래서 이 노트는 항상 이 순서 로 씁니다.
| 순서 | 무엇을 하는가 | 예 |
|---|---|---|
| ① | 소속 범주부터 — "이것은 ~의 한 종류다" | vLLM은 서빙 프레임워크 의 한 종류다 |
| ② | 형제 개념과의 경계선 — 0/1로 갈리는 축 | Ollama는 1인 실행 , vLLM은 다수 동시 서빙 |
| ③ | 반례 — "이건 아니다" | Transformers는 서빙 프레임워크가 아니라 Python 라이브러리 다 |
| ④ | 그 다음에야 비유 — 기억 보조용으로만 | 개인 주방 ↔ 단체 급식 주방 |
2.2 정의는 이 형식으로 씁니다
X — [상위 범주]인데, [ 종차 ]는 점에서 [형제 개념]과 구별된다.
상위 범주 는 "무엇의 한 종류인가"이고, 종차(種差) 는 "같은 종류 안의 형제들과 무엇이 다른가"입니다. 예를 들면 이렇습니다.
| 용어 | 정의 |
|---|---|
| KV 캐시 | [메모리 영역]인데, [ 이미 처리한 토큰들의 계산 결과를 저장해 재계산을 피한다 ]는 점에서 응답 자체를 저장하는 웹 캐시와 구별된다. |
| 양자화 | [모델 압축 기법]인데, [ 가중치 숫자를 더 적은 비트로 근사한다 ]는 점에서 모델 구조를 바꾸는 다른 경량화와 구별된다. |
2.3 새 용어를 만났을 때 던질 네 개의 질문 ⭐
- 이것은 무엇의 한 종류인가? (상위 범주)
- 형제 개념과 무엇으로 갈리는가? (5장의 여덟 축 중 어디에 꽂히는가 )
- 이건 아니다 — 반례는 무엇인가?
- 그다음에야 비유를 찾는다. (기억 보조용으로만)
이 과정에 나오는 새 도구와 용어도, 수업 뒤에 만날 다음 도구도 이 네 질문으로 열립니다.
3. 각 차시 노트의 구조
모든 차시가 같은 자리 로 되어 있습니다.
┌──────────────────────────────────────────────────┐
│ 지도 위치 ← 몇 일차, 어느 층, 앞뒤 차시 │
│ 이 차시를 다 읽으면 ← 학습 목표 │
│ 0. 이 차시의 판별 축 ← 0/1 축 표, 5장의 어느 큰 축인가 │
│ 1~N. 본문 ← 정의 → 경계 → 반례 → 비유 │
│ N. 실습 — 맡기고 검수하기 ← AI에게 줄 지시, 받을 증거, │
│ 내가 직접 볼 숫자 │
├──────────────────────────────────────────────────┤
│ 부록 A. 스스로 확인하기 (질문 + 답이 있는 절) │
│ 부록 B. 자주 하는 실수 (❌ / ⭕) │
│ 부록 C. NotebookLM 복습 프롬프트 │
└──────────────────────────────────────────────────┘
| 자리 | 어떻게 쓰는가 |
|---|---|
| 이 차시를 다 읽으면 | 읽기 전에 한 번, 읽고 나서 한 번 봅니다. 두 번째에 못 하겠는 항목이 다시 볼 곳입니다 |
| 0. 판별 축 | 본문보다 먼저 봅니다. 그 차시의 뼈대입니다 |
| 본문 | 순서대로 읽습니다. ⭐가 붙은 절이 중심입니다 |
| 실습 — 맡기고 검수하기 | 코드를 직접 짜지 않고 AI에게 맡기는 방식입니다. 9장 참고 |
| 부록 A | 답을 먼저 보지 말고 절 번호로 되돌아가세요 |
| 부록 B | 막혔을 때 가장 먼저 볼 곳입니다 |
기호 약속
| 기호 | 뜻 |
|---|---|
| ⭐ | 그 차시의 핵심 |
| ⚠️ | 주의. 여기서 대부분 틀립니다 |
| 💡 | 팁 |
| ❌ / ⭕ | 잘못된 것 / 올바른 것 |
| 🔍 읽는 포인트 | 코드 블록에서 이 줄만 알아보면 되는 곳 |
> 앞으로 다시 만납니다 | 뒤 차시에 대한 예고. 그 자리에서 반드시 회수됩니다 |
| "앞에서 배운 ~ (N차시)" | 이 노트의 앞 차시에서 이어지는 자리 |
4. 전체 구조 — 다섯 개의 층
로컬 LLM 서비스는 아래 다섯 층입니다. 이 그림이 과정 전체의 지도입니다.
┌──────────────────────────────────────────────────────────┐
│ ⑤ 애플리케이션 스트리밍 · 대화 · 프롬프트 · JSON 출력 · 도구 호출 │ ← 4일차, 5일차
├──────────────────────────────────────────────────────────┤
│ ④ API OpenAI 호환 API (= 포트, 5장 축 ②) │ ← 3일차
├──────────────────────────────────────────────────────────┤
│ ③ 추론 엔진 Transformers · llama.cpp · Ollama · vLLM │ ← 1일차, 3일차
│ (= 어댑터, 5장 축 ②) │
├──────────────────────────────────────────────────────────┤
│ ② 모델 파일 가중치 + 형식 (FP16 · 8bit · 4bit · GGUF) │ ← 2일차
├──────────────────────────────────────────────────────────┤
│ ① 하드웨어 GPU VRAM · 메모리 대역폭 · CPU/RAM │ ← 1일차, 2일차
└──────────────────────────────────────────────────────────┘
| 일차 | 이 날 답하는 질문 | 주로 다루는 층 | 주요 산출물 |
|---|---|---|---|
| 1일차 | 로컬 LLM이란 무엇이고 내 컴퓨터에서 어떻게 돌리나? | ①③⑤ 맛보기 | 개발 환경, Ollama 챗봇 |
| 2일차 | 내 GPU에 어떤 모델을 어떻게 맞춰 넣나? | ①② | 메모리 계산, 양자화 비교표, 모델 선정 근거 |
| 3일차 | 여러 사람이 동시에 쓰게 하려면? | ③④ | vLLM 서버, 성능 측정표, Ollama와 비교 |
| 4일차 | LLM 위에 쓸모 있는 기능을 어떻게 만드나? | ⑤ | 스트리밍 · 대화 · 구조화 · 도구 호출 |
| 5일차 | 처음부터 끝까지 하나의 서비스로 | 전부 | 프로젝트 서비스, 발표 |
1일차가 다섯 층을 가장 쉬운 도구(Ollama)로 한 번 훑고, 2~4일차가 층별로 깊이 들어가며, 5일차에 다시 전부를 합칩니다. 넓게 → 깊게 → 다시 넓게.
5. ⭐ 판별 축 지도
판별 축 — 두 개념을 0과 1로 가르는 하나의 질문 입니다.
축은 비유와 다릅니다. 비유는 개념마다 새로 만들어야 하고 서로 겹치지만, 축은 여덟 개로 이 과정 전체를 덮고 서로 겹치지 않습니다. 새 용어가 나오면 새 비유를 만들 필요 없이 어느 축의 어느 쪽에 꽂히는지만 정하면 됩니다.
5.1 여덟 개의 큰 축 — 정의
| 축 | 왼쪽 (0) | 오른쪽 (1) | 이 축이 묻는 질문 | 일반적인 예 |
|---|---|---|---|---|
| ① 디스크 ↔ 메모리 | 디스크 — 영구 · 느림 · 꺼도 남음 | 메모리 — 휘발 · 빠름 · 실행 중에만 있음 | 이것은 저장된 것인가, 지금 올라와 실행 중인 것인가? | 설치된 프로그램 파일 ↔ 실행 중인 프로그램 |
| ② 추상 ↔ 구상 | 추상 — 무엇을 해야 하는가 (계약 · 약속) | 구상 — 어떻게 하는가 (구현 · 기술) | 이것은 약속인가, 그 약속을 지키는 실제 부품인가? | 콘센트 규격 ↔ 그 규격에 맞춘 각 회사의 플러그 |
| ③ 속성 ↔ 기능 | 속성 — 값 · 데이터 · 설명 | 기능 — 동작 · 실행 | 이것은 가지고 있는 값인가, 수행하는 동작인가? | 주문 정보 ↔ 주문 조회하기 |
| ④ 로컬 ↔ 원격 | 로컬 — 내 컴퓨터 · 내 건물 | 원격 — 남의 컴퓨터 · 인터넷 너머 | 이것은 내 손 안에 있는가, 밖에 있는가? | 내 PC의 폴더 ↔ 클라우드 저장소 |
| ⑤ 하나 ↔ 여럿 | 하나로 뭉침 — 단순 · 빠름, 대신 같이 멈춤 | 여럿으로 나눔 — 안전 · 확장, 대신 통신 비용 | 한 덩어리로 둘 것인가, 나눌 것인가? | 한 사람이 다 하는 가게 ↔ 역할을 나눈 팀 |
| ⑥ 동기 ↔ 비동기 | 동기 — 끝날 때까지 기다린다 | 비동기 — 기다리지 않고 다른 일을 한다 | 결과를 기다리는 동안 멈춰 있는가? | 전화 통화 ↔ 문자 메시지 |
| ⑦ 무상태 ↔ 상태 | 무상태 — 이전 일을 기억하지 않는다 | 상태 — 이전 일을 기억한다 | 이것은 지난번을 기억하는가? | 자판기 ↔ 단골 손님을 기억하는 직원 |
| ⑧ 구문론 ↔ 의미론 | 구문 — 형식 이 맞는가 | 의미 — 뜻 이 맞는가 | 겉모양을 검사하는가, 내용을 검사하는가? | 맞춤법 검사 ↔ 내용이 사실인지 검토 |
⚠️ 두 개를 미리 짚어 둡니다.
- ⑥ 비동기는 "더 빠른 것"이 아닙니다. 일 하나에 걸리는 시간은 같습니다. 기다리는 시간에 다른 일을 하므로 같은 시간에 처리하는 양(처리량) 이 늘어날 뿐입니다. 이 구분이 14 · 21 · 22 · 26차시에서 계속 나옵니다.
- ⑤의 어느 쪽도 "발전된 형태"가 아닙니다. 규모와 실패 비용에 따라 답이 정해집니다.
5.2 여덟 축이 이 과정에서 나오는 자리
| 큰 축 | 이 과정에서의 모습 | 주로 나오는 차시 |
|---|---|---|
| ① 디스크 ↔ 메모리 | 모델 파일(디스크) ↔ GPU 메모리에 올라간 모델 / GPU 메모리 ↔ 일반 메모리(RAM)로 내려보내기 / KV 캐시는 순수한 메모리 | ⭐ 3, 5, 9, 12, 19 |
| ② 추상 ↔ 구상 | OpenAI 호환 API(약속) ↔ Ollama · vLLM(구현) / 모델의 구조 설정 ↔ 실제 가중치 값 | ⭐ 20, 25, 32 |
| ③ 속성 ↔ 기능 | 도구의 정의 (이름 · 설명 · 인자 형식) ↔ 도구의 실행 (실제 함수) | 2, 30 |
| ④ 로컬 ↔ 원격 | 로컬 LLM ↔ 상용 API / 내 모델 파일 ↔ Hugging Face 저장소 / 폐쇄망 반입 | ⭐ 1, 4 |
| ⑤ 하나 ↔ 여럿 | 요청 하나 ↔ 여러 요청 묶어 계산(배치) / Ollama(1인) ↔ vLLM(다수) / 앱 안에 모델 ↔ 모델 서버 분리 | ⭐ 17, 21, 24 |
| ⑥ 동기 ↔ 비동기 | 한 번에 받기 ↔ 스트리밍 / 부하 테스트 클라이언트 | 7, 22, 26 |
| ⑦ 무상태 ↔ 상태 | ⭐ LLM API는 무상태 → 대화 기록을 매번 다시 보낸다 / KV 캐시 · 프리픽스 캐시는 서버 쪽 상태 | ⭐ 8, 21, 27 |
| ⑧ 구문론 ↔ 의미론 | 토크나이저(글을 자름) ↔ 어텐션(문맥을 입힘) / ⭐ JSON 형식 검증 ↔ 내용 평가 | ⭐ 2, 29, 31 |
5.3 이 과정에서 자주 쓰는 파생 축
큰 축에서 갈라져 나온 축들입니다. 부모 축을 잡으면 자동으로 따라옵니다.
| 파생 축 | 왼쪽 (0) | 오른쪽 (1) | 부모 축 | 나오는 차시 |
|---|---|---|---|---|
| 순차 ↔ 병렬 | 하나씩 차례로 (Decode) | 한꺼번에 동시에 (Prefill) | ⚠️ ⑥과 다른 축 | 2, 14, 21 |
| 계산 병목 ↔ 메모리 병목 | 계산량이 많아서 느림 (Prefill) | 메모리를 읽느라 느림 (Decode) | ① | 2, 9, 15 |
| 한 건의 시간 ↔ 전체 처리량 | Latency · TTFT | Throughput | ⑤ | ⭐ 14, 22, 24 |
| 누가 값을 정하는가 | 학습이 정함 (모델 파라미터) | 사람이 실행 전에 정함 (추론 파라미터) | ⑦ | 6, 13 |
| 결정론 ↔ 확률론 | 같은 입력 → 같은 출력 (Temperature 0) | 같은 입력 → 다른 출력 가능 (Temperature > 0) | ⑧ | 6, 13, 29 |
| 정밀도 | 높음 (FP16) | 낮음 (INT4) | ① | 10~12, 15 |
| 한 번 계산 ↔ 여럿에게 제공 | Inference | Serving | ⑤ | 17 |
| 사람이 손을 대는가 | 사람 확인 후 실행 | 자동 실행 | ⑦ | 30, 38 |
| 멱등 ↔ 비멱등 | 여러 번 해도 결과 상태가 같음 (조회) | 할 때마다 상태가 바뀜 (주문 취소, 결제) | ⑦ | 25, 30, 38 |
⚠️ 순차 ↔ 병렬 과 동기 ↔ 비동기 는 자주 헷갈립니다.
| 축 | 무엇에 대한 이야기인가 |
|---|---|
| 동기 ↔ 비동기 (⑥) | 기다림 — 기다리는 시간을 놀리지 않는 법 |
| 순차 ↔ 병렬 | 일꾼 수 — 계산을 몇 개의 연산 장치가 나눠 하는가 (CPU는 소수의 강한 일꾼, GPU는 수천 개의 단순한 일꾼) |
비동기는 계산 자체를 빠르게 하지 않습니다. 계산 자체를 빠르게 하는 것이 병렬화이고, 그 하드웨어가 GPU입니다.
6. 번역어 함정 — 이 과정에서 반드시 짚을 단어들
이 분야는 같은 한국어 단어가 전혀 다른 영어 단어를 가리키는 경우가 많습니다.
| 단어 | ❌ 흔한 오해 | ⭕ 원 뜻 | 다루는 곳 |
|---|---|---|---|
| 추론 | 생각하기 (Reasoning) | 이 과정의 "추론"은 거의 전부 Inference = 학습이 끝난 모델을 실행해서 출력을 얻는 것 | 2, 17차시 |
| 토큰 | 로그인 토큰 | LLM의 토큰은 글을 쪼갠 조각 . 웹 로그인에 쓰는 인증 토큰(JWT 등)과 같은 철자, 다른 범주 | 2차시 |
| 파라미터 | 하나의 뜻 | ① 모델 파라미터 (가중치, 8B의 B) ② 추론 파라미터 (Temperature 등) ③ 함수 매개변수 . 셋이 다름 | 2, 6, 13차시 |
| 오픈소스 LLM | 소스 코드가 다 공개됨 | 대부분 가중치 공개(Open Weights) . 학습 데이터 · 코드는 비공개인 경우가 많고, 라이선스도 제각각 | 1, 4차시 |
| 온프레미스 | 오프라인, 인터넷 안 됨 | premises = 건물 · 구내 . "우리 건물 안의 장비에서". 인터넷 연결 여부와는 무관 | 1차시 |
| 양자화 | 물리학 용어, 어려운 것 | 숫자를 더 적은 비트로 근사 하는 것 | 10차시 |
| 서빙 (Serving) | 그냥 실행 | 여러 클라이언트에게 지속적으로 제공 하는 것. 한 번 실행(Inference)과 다른 층 | 17차시 |
| 컨텍스트 | 문맥(일반 명사) | 컨텍스트 길이(Context Length) = 모델이 한 번에 볼 수 있는 토큰 수의 상한 | 2, 13, 27차시 |
| 배치 (Batch) | 정해진 시간에 몰아서 하는 작업 | 이 과정에서는 여러 요청을 GPU 한 번에 같이 계산 하는 것 | 13, 21차시 |
| 캐시 (KV Cache) | 웹 캐시처럼 응답을 저장 | 앞 토큰들의 계산 중간값(Key · Value) 을 저장. 응답 저장이 아님 | 2, 9, 21차시 |
| 포트 | 하나의 뜻 | ① 네트워크 포트 (11434, 8000 같은 번호 — 한 컴퓨터 안의 창구 번호) ② 아키텍처 포트 (OpenAI 호환 API라는 약속, 5장 축 ②) | 5, 19, 20차시 |
7. 과정 전체를 관통하는 세 문장
문장 1. 모든 것은 GPU 메모리(VRAM) 예산 싸움이다 (축 ①)
필요한 VRAM ≈ 모델 가중치 + KV 캐시(컨텍스트 길이 × 동시 요청 수) + 여유분
가중치 ≈ 파라미터 수 × 숫자 하나의 바이트 수 (예: 80억 × 2바이트 ≈ 16GB)
모델 크기, 양자화, 컨텍스트 길이, 동시 처리는 전부 이 한 줄의 예산을 어떻게 나눌지 의 문제입니다. 숫자를 외우지 말고 계산식을 외우세요. 새 모델이 나와도 필요 사양을 스스로 계산할 수 있습니다. → 9차시에서 완성
문장 2. 품질 · 속도 · 메모리는 셋 다 가질 수 없다. 측정해서 고른다
품질
/ \
속도 ──── 메모리
양자화하면 메모리와 속도를 얻고 품질을 조금 잃습니다. 큰 모델은 품질을 얻고 메모리와 속도를 잃습니다. 이런 맞바꿈을 트레이드오프(Trade-off) 라고 합니다. 먼저 "내 업무에 충분한 품질" 을 평가셋으로 정하고, 나머지를 최적화합니다. → 6, 14, 15, 16, 33, 39차시
문장 3. 표준 API(약속)로 층을 나누면 엔진(구현)을 갈아 끼울 수 있다 (축 ②)
앱은 OpenAI 호환 API 만 알고, 그 뒤가 Ollama인지 vLLM인지 모릅니다. 콘센트 규격만 맞으면 어느 회사 플러그든 꽂히는 것과 같습니다. 개발은 Ollama로, 운영은 vLLM으로 하는 방식이 여기서 가능해집니다. → 20차시에서 회수
8. 노트 전체에서 쓰는 예제 서비스와 실습 환경
8.1 예제 서비스 — 문의봇
문의봇 — 쇼핑몰 고객센터로 들어오는 문의를 요약 · 분류 · 정보 추출 하고 답변 초안 을 만드는 사내 도우미. 필요하면 주문 조회 도구 를 호출한다.
| 항목 | 내용 | 관련 축 · 차시 |
|---|---|---|
| 왜 로컬인가 | 문의 본문에 고객 이름 · 연락처 · 주소 · 주문번호 → 외부 API로 보낼 수 없음 | ④, 1차시 |
| 사용자 | 상담원 10명 동시 사용 | ⑤, 3일차 |
| 까다로운 지점 ① | 한국어 품질 | 6, 16차시 |
| 까다로운 지점 ② | 긴 문의 메일 | 13, 27차시 |
| 까다로운 지점 ③ | 분류값은 정해진 것만 나와야 함 | ⑧, 29차시 |
| 까다로운 지점 ④ | 주문 조회 도구의 오용, 주문 취소 같은 되돌릴 수 없는 작업 | ⑦, 30차시 |
(실제 수업 예제와 다를 수 있습니다. 개념을 붙잡을 고리로만 쓰세요.)
8.2 실습 기준 환경
| 항목 | 기준 | 비고 |
|---|---|---|
| GPU | NVIDIA, VRAM 24GB (RTX 3090 / 4090급) | 8 · 12 · 16GB 경우는 16차시 표 |
| OS | Linux (Ubuntu) | vLLM은 Linux + NVIDIA GPU가 기본 |
| RAM | 32~64GB | CPU 혼합 추론(12차시)에서 중요 |
| 디스크 | 여유 200GB 이상 | 모델 하나가 수 GB ~ 수십 GB |
| 예시 모델 | Qwen3-8B (Ollama: qwen3:8b, Hugging Face: Qwen/Qwen3-8B) | 수업에서 쓰는 모델로 바꿔 읽으세요 |
9. AI에게 맡기는 방식으로 읽기
이 과정에는 Python 코드, 터미널 명령, 설정값이 많이 나옵니다. 코드를 다 이해하려 하지 마세요. 코드 작성은 AI(코딩 에이전트)에게 맡기고, 당신은 아래 세 가지를 쥡니다.
| 당신이 쥐는 것 | 왜 | 어디서 배우나 |
|---|---|---|
| 결정 | 어떤 모델 · 양자화 · 엔진 · 품질 기준으로 갈지 | 1, 6, 16, 24, 33, 34차시 |
| 숫자 읽기 | GPU 메모리 사용량, 첫 응답 시간, 초당 생성량, 처리량. AI의 "빨라졌습니다"를 숫자로 확인 | 3, 9, 14, 22차시 |
| 평가셋 | 실제 문의 수십 개와 기대 답. AI의 "품질이 좋습니다"를 직접 채점 | 6, 28, 31, 33차시 |
각 차시의 실습은 세 자리로 되어 있습니다.
| 실습의 자리 | 하는 일 |
|---|---|
| 지시 | 목표 · 참고할 문서 · 하지 말 것 · 보고 형식(표) 을 정해 AI에게 맡김 |
| 받을 증거 | "완료했습니다"라는 말 대신 실행한 명령과 출력 원문, 측정 숫자 를 받음 |
| 내가 직접 볼 것 | nvidia-smi, 응답 시간, 평가셋 채점처럼 코드 없이 읽을 수 있는 것 만 직접 봄 |
이 분야에서 AI에게 맡길 때 특히 조심할 점 ⚠️
| 위험 | 왜 | 대응 |
|---|---|---|
| AI의 기억이 오래됨 | 모델 이름 · 라이브러리 옵션 · 명령어가 몇 달 단위로 바뀜. 없는 모델명이나 사라진 옵션을 자신 있게 씀 | 모델 카드와 공식 문서를 함께 주고 , 실행 결과로 확인 |
| 추정을 측정처럼 말함 | "약 40 tok/s 정도입니다"는 측정이 아닐 수 있음 | 실행 출력 원문 이 붙은 숫자만 믿음 |
| 품질 자가 채점 | 같은 모델이 만든 답을 같은 모델이 채점하면 관대함 | 평가셋 + 사람의 눈 이 기준 |
| 시스템 변경 | 드라이버 · CUDA 재설치는 시스템 전체에 영향 | 실행 전 설명을 받고 사람이 승인 |
10. 전체 목차
1일차 (11.28 토) · 로컬 LLM 이해와 실행
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 1 | 로컬 LLM과 생성형 AI 이해 | ④ 로컬 ↔ 원격 |
| 2 | LLM 구조와 추론 원리 | ⑧ 구문 ↔ 의미, 순차 ↔ 병렬 |
| 3 | 로컬 LLM 개발환경 구축 | ① 디스크 ↔ 메모리, 순차 ↔ 병렬 |
| 4 | Hugging Face 오픈소스 LLM 활용 | ④ 로컬 ↔ 원격 |
| 5 | Ollama 설치 및 LLM 실행 | ① 디스크 ↔ 메모리 |
| 6 | 로컬 LLM 모델 및 Prompt 활용 | 누가 값을 정하는가, 결정론 ↔ 확률론 |
| 7 | Ollama API 활용 | ⑥ 동기 ↔ 비동기 |
| 8 | Ollama 기반 AI 앱 구현 | ⑦ 무상태 ↔ 상태 |
2일차 (11.29 일) · 자원 · 양자화 · 성능
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 9 | LLM 메모리 구조와 GPU 자원 분석 | ① 디스크 ↔ 메모리 |
| 10 | LLM 양자화 원리 | 정밀도 |
| 11 | 8bit · 4bit 양자화 실습 | 정밀도 |
| 12 | GGUF와 경량 LLM | ① VRAM ↔ RAM |
| 13 | LLM 추론 파라미터 최적화 | 누가 값을 정하는가 |
| 14 | LLM 추론 성능 측정 | 한 건의 시간 ↔ 전체 처리량 |
| 15 | 모델별 최적화 비교 | 계산 병목 ↔ 메모리 병목 |
| 16 | 하드웨어별 최적 모델 선정 | 트레이드오프 |
3일차 (12.04 금) · LLM 서빙
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 17 | LLM Serving 아키텍처 | ⑤ 하나 ↔ 여럿 |
| 18 | vLLM 환경 구축 | ⑤ (환경 분리) |
| 19 | vLLM 서버 구축 | ① 디스크 ↔ 메모리 |
| 20 | OpenAI 호환 API 활용 | ⭐ ② 추상 ↔ 구상 |
| 21 | vLLM 추론 구조 이해 | ⑤, ⑦ |
| 22 | LLM Serving 성능 측정 | 한 건의 시간 ↔ 전체 처리량 |
| 23 | vLLM 서버 성능 최적화 | 트레이드오프 |
| 24 | Ollama와 vLLM 비교 | ⑤ 하나 ↔ 여럿 |
4일차 (12.05 토) · LLM 애플리케이션 기능
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 25 | 로컬 LLM API 애플리케이션 | ② 추상 ↔ 구상 |
| 26 | Streaming 기반 AI 서비스 | ⑥ 동기 ↔ 비동기 |
| 27 | 대화형 AI 서비스 구현 | ⭐ ⑦ 무상태 ↔ 상태 |
| 28 | Prompt 기반 AI 기능 구현 | 결정론 ↔ 확률론 |
| 29 | Structured Output 활용 | ⭐ ⑧ 구문 ↔ 의미 |
| 30 | Tool Calling 이해 및 활용 | ③ 속성 ↔ 기능, 멱등 ↔ 비멱등 |
| 31 | 로컬 LLM 업무형 앱 구현 | ⑧ |
| 32 | AI 애플리케이션 통합 | ② |
5일차 (12.06 일) · 프로젝트
| 차시 | 노트 | 핵심 축 |
|---|---|---|
| 33 | 프로젝트 요구사항 분석 | ⑧ |
| 34 | LLM 모델 선정 및 최적화 | 트레이드오프 |
| 35 | LLM Serving 구축 | ⑤ |
| 36 | AI 기능 구현 | ⑧ |
| 37 | 애플리케이션 구현 | ⑥ ⑦ |
| 38 | Function Calling 및 서비스 통합 | 사람이 손을 대는가 |
| 39 | 성능 테스트 및 최적화 | 한 건의 시간 ↔ 전체 처리량 |
| 40 | 프로젝트 발표 및 평가 | 전체 정산 |
부록
- 용어 사전 — 상위 범주 열 포함, 헷갈리는 짝 모음