로컬 LLM

지도 위치 : 3일차 · ③추론 엔진 ↔ ④API 층의 경계 · 3일차 출발점 | 이전: 16차시 하드웨어별 최적 모델 선정 | 다음: 18차시 vLLM 환경 구축 키워드 : LLM Inference와 Serving, Model Server, API Server, 클라이언트-서버 구조

이 차시를 다 읽으면

1. Inference와 Serving 을 유와 종차로 정의하고, "서빙"이라는 번역어의 함정을 말할 수 있다.
2. 클라이언트 → API 서버 → 모델 서버 → GPU 네 칸 구조도를 그리고, 칸마다 맡는 일과 맡지 않는 일을 말할 수 있다.
3. 앱 프로세스 안에서 모델을 직접 돌리면 생기는 세 가지 문제 를 축 ⑤(하나 ↔ 여럿)로 설명할 수 있다.
4. 서빙 층이 해결해야 할 다섯 가지 (동시성 · 큐 · 인증 · 모니터링 · 모델 관리)를 댈 수 있다.
5. "느리다 / 동시 요청에서 죽는다"라는 뭉뚱그린 증상을 쪼개어, 각각이 3일차의 어느 차시 로 이어지는지 말할 수 있다.

---

0. 이 차시의 판별 축

1~2일차는 사실상 혼자 쓰는 쪽 (축 3의 왼쪽)에서 모델 하나, 요청 하나를 들여다봤습니다. 3일차는 같은 모델을 상담원 10명이 동시에 쓰게 만듭니다. 이 전환은 소프트웨어가 자라면서 흔히 거치는 "스크립트에서 서버로" 의 한 사례입니다.

5차시의 Ollama가 이미 작은 서버였습니다(ollama run도 사실은 서버에 요청을 보내는 클라이언트). 이번 차시는 같은 전환을 여러 사람 · GPU 한 장 이라는 조건에서 제대로 설계합니다.

---

1. Inference와 Serving — 같은 모델, 다른 층

1.1 정의

추론 (Inference) — 앞에서 정의한 대로(2차시 1절) [모델 사용 단계]인데, [ 가중치를 바꾸지 않고 입력에 대한 출력만 계산한다 ]는 점에서 학습과 구별된다.

서빙 (Serving) — [모델 운영 방식]인데, [ 학습된 모델을 네트워크 너머 여러 클라이언트에게 지속적으로 · 동시에 제공한다 ]는 점에서 한 번 실행해 결과를 얻는 추론(Inference)과 구별된다.

⭐ Serving은 Inference를 포함합니다. 서빙 서버 안에서도 결국 요청마다 추론이 일어납니다. 서빙은 그 위에 "여럿 · 계속" 을 얹은 층입니다.

1.2 ⚠️ 번역어 함정 — "서빙"

"서빙"을 "모델을 실행한다" 정도로 읽으면 3일차 전체가 흐려집니다. 원 뜻은 식당의 serve , 즉 손님에게 계속 내어 주는 일 입니다(README 6장).

💡 비유는 마지막에, 기억 보조로만 씁니다. 식당으로 그리면 요리 한 접시를 만드는 것 이 Inference, 식당을 열어 손님을 계속 받는 것 이 Serving입니다.

---

2. ⭐ 구조도 — 네 칸

[클라이언트]   상담원 브라우저 × 10, 사내 시스템
     │  HTTP (JSON)                      ← 7차시에 Ollama에 보낸 것과 같은 종류의 요청
     ▼
[API 서버]     FastAPI — 앱 로직 · 인증 · 프롬프트 조립 · 입력 검증 · 로그
     │  HTTP (OpenAI 호환 API)            ← 20차시: 이 화살표가 "포트"
     ▼
[모델 서버]    vLLM 또는 Ollama — 토큰화 · 배칭 · KV 캐시 관리 · 생성
     │  CUDA
     ▼
[GPU]         가중치 + KV 캐시 (VRAM)      ← 9차시의 예산식

2.1 칸마다 정의

모델 서버 (Model Server) — [서버 프로세스]인데, [ 모델을 VRAM에 상주시켜 두고 추론 요청만 받아 처리한다 ]는 점에서 업무 규칙을 다루는 API 서버와 구별된다. 이 과정의 vLLM · Ollama · llama-server가 여기에 속합니다.

API 서버 (API Server) — [서버 프로세스]인데, [ 업무 규칙 · 인증 · 입출력 검증을 맡고 추론은 모델 서버에 위임한다 ]는 점에서 모델 서버와 구별된다. 이 과정에서는 FastAPI (Python으로 HTTP API 서버를 만드는 웹 프레임워크)로 만드는 문의봇 백엔드가 이 자리입니다(25차시).

클라이언트-서버 구조 — [프로그램 배치 방식]인데, [ 요청하는 쪽(클라이언트)과 응답하는 쪽(서버)을 나누고, 둘이 네트워크 규약으로만 대화한다 ]는 점에서 한 프로그램 안에서 함수를 직접 부르는 방식과 구별된다. 그 규약이 HTTP 입니다. 클라이언트가 주소 · 메서드(GET · POST 등) · 본문(JSON) 으로 요청하면, 서버가 상태 코드(200 성공, 401 인증 실패 등) · 본문 으로 답합니다(7차시에서 Ollama에 curl로 보낸 것이 이것). 3일차에 달라지는 것은 서버가 두 겹 이 되었다는 점 하나입니다. API 서버는 브라우저에게는 서버이고, 모델 서버에게는 클라이언트 입니다.

2.2 칸마다 책임

2.3 반례 — "API 서버 없이 모델 서버를 바로 열면 안 되나?"

웹 서비스의 오래된 원칙 하나가 답입니다. 사용자는 데이터베이스(DB)에 직접 붙지 않고, 반드시 백엔드 서버를 거친다. 백엔드가 권한 확인 · 잘못된 요청 차단 · 데이터 보호 · 선행 처리를 맡기 때문입니다. 모델 서버도 같은 이유로 안 됩니다. DB 자리에 모델 서버를 넣기만 하면 됩니다.

상담원 → API 서버 → 모델 서버     ⭕
상담원 → 모델 서버                ❌

첫 줄의 두 단어를 갈라 둡니다. 인증 (Authentication)은 "누구인가" 를 확인하는 것(로그인, API 키)이고, 인가 (Authorization)는 "그 사람이 이것을 해도 되는가" 를 판단하는 것입니다. 키 하나로는 "누군가 키를 가졌다"까지만 알 수 있고, 상담원마다 다른 권한은 가를 수 없습니다.

2.4 모델 서버는 허브다

모델 서버 하나를 문의봇, 사내 검색, 요약 배치가 함께 쓰기 시작하면 모양이 스타 토폴로지 가 됩니다. 가운데 하나( 허브 )에 여럿( 스포크 )이 매달린 연결 모양입니다. 모델 서버가 허브, 앱들이 스포크입니다.

⚠️ 이 모양의 약점은 분명합니다. 허브가 죽으면 전부 죽습니다. 이런 지점을 단일 장애점 (SPOF, Single Point of Failure)이라고 합니다. 3일차에서는 대책 두 가지를 지킵니다. 헬스 체크 (서버가 살아 있는지 주기적으로 묻는 짧은 요청)는 19차시의 /health로, 허브를 얇게 유지하기 (허브에 기능을 몰아넣지 않아 고장 날 거리를 줄이기)는 "모델 서버에는 업무 로직을 넣지 않는다"(2.2 표)로 지킵니다.

---

3. ⭐ 왜 앱 프로세스 안에서 모델을 직접 돌리면 안 되나

3.1 흔히 처음 만드는 모양

AI에게 "요약 API 만들어 줘"라고 하면 이런 코드가 자주 나옵니다.

from fastapi import FastAPI
from transformers import AutoModelForCausalLM, AutoTokenizer

app = FastAPI()
tok = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")
model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-8B", torch_dtype="auto", device_map="auto")

@app.post("/summarize")
def summarize(body: dict):
    inputs = tok(body["text"], return_tensors="pt").to(model.device)
    out = model.generate(**inputs, max_new_tokens=300)
    return {"summary": tok.decode(out[0], skip_special_tokens=True)}

🔍 읽는 포인트

• from_pretrained(...)가 앱 파일 맨 위 에 있습니다 → 앱 프로세스가 곧 모델입니다.
• model.generate(...) 한 줄이 요청 하나를 GPU에서 끝까지 처리합니다. 다른 요청과 묶는 장치가 없습니다.

혼자 쓸 때는 잘 돕니다. 상담원 10명이 쓰기 시작하면 세 가지가 터집니다.

🔍 1번 행의 단어들 — 블로킹 은 한 일이 끝날 때까지 다음 일이 멈춰 서는 것입니다. async def 는 Python에서 함수를 비동기 (기다리는 동안 다른 일을 하는 방식, README 축 ⑥)로 만드는 표시입니다. 비동기는 I/O-bound 일, 즉 네트워크 응답이나 디스크를 기다리느라 느린 일에는 효과가 큽니다. 기다리는 동안 다른 요청을 처리하면 되니까요. 하지만 CPU-bound 일, 즉 계산 장치가 쉬지 않고 계산하느라 느린 일에는 효과가 없습니다. 놀고 있는 시간이 없기 때문입니다. 앱 프로세스 안의 model.generate는 뒤쪽입니다(자세히 22차시 3.3).

3.2 축 ⑤로 다시 읽기 — 모놀리식 ↔ MSA

3.1의 3번 문제는 시스템을 한 덩어리로 둘 것인가, 나눌 것인가 의 문제입니다. 이 선택에는 이름이 있습니다.

앱 안에 모델을 넣는 것이 모놀리식이고, 모델 서버를 떼어 내는 것이 MSA 쪽으로 한 걸음 가는 것입니다. 둘의 거래는 README 5.1의 축 ⑤ 한 줄, "뭉치면 단순하고 빠르지만 같이 멈추고, 나누면 안전하고 따로 늘릴 수 있지만 통신 비용을 낸다" 가 그대로 적용됩니다.

⚠️ 반례 — 뭉치는 게 맞는 경우도 있습니다. 혼자 쓰는 실험 노트북, 한 번 돌리고 끝나는 배치 처리(18차시의 오프라인 추론)는 서버를 세우는 비용이 더 큽니다. README 5.1의 경고처럼 어느 쪽도 발전된 형태가 아닙니다. 규모와 실패 비용이 답을 정합니다.

3.3 "스크립트에서 서버로"의 반복

0절에서 본 전환이 이번에는 모델을 들고 한 번 더 일어납니다. 실행의 주체 란 "누가 언제 내 코드를 부르는가"입니다. 스크립트는 내가 실행할 때 돌고, 서버에서는 프레임워크가 요청이 올 때마다 내 코드를 부릅니다.

---

4. 서빙이 해결해야 할 다섯 가지

4.1 목록

4.2 "느리다 / 죽는다"를 증상별로 쪼개기

LLM 서비스가 느리거나 동시 요청에서 죽으면, 흔히 원인을 "서빙 설정 문제" 한 줄로 뭉뚱그립니다. 그래서는 어디를 손볼지 알 수 없습니다. 3일차는 이 한 줄을 증상별로 쪼갭니다.

앞으로 다시 만납니다 — 3일차 순서: 18 설치 → 19 서버 띄우기 → 20 포트(OpenAI 호환 API) → 21 엔진 내부 → 22 측정 → 23 최적화 → 24 Ollama와 비교. 5일차 35차시에서 이 구조를 프로젝트로 다시 세웁니다.

---

5. 실습 — 맡기고 검수하기

이 차시는 설계 입니다. 코드를 받기 전에 구조와 책임을 먼저 받습니다.

지시

문의봇의 서빙 구조를 설계해줘.
조건: 상담원 10명 동시 사용, 문의에 고객 개인정보 포함(외부 전송 금지),
     RTX 4090 24GB 1대, 모델 Qwen3-8B, 앱은 FastAPI.

1. [클라이언트 → API 서버 → 모델 서버 → GPU] 구조도를 텍스트 그림으로.
2. [칸 | 맡는 일 | 맡지 않는 일 | 이 칸이 죽으면 생기는 일] 표.
3. [동시성 | 큐 | 인증 | 모니터링 | 모델 관리] 각각을 어느 칸이 맡는지 표.
4. 첨부한 내 8차시 앱 코드가 모델을 앱 프로세스 안에서 돌리는지,
   모델 서버에 HTTP로 요청하는지 판정하고, 근거가 된 코드 줄을 그대로 인용해줘.
vLLM · Ollama의 기능은 공식 문서에 근거가 있는 것만 쓰고, 확인 못 한 것은 "확인 필요"라고 써.

받을 증거

• 구조도와 표 세 개
• 4번 판정의 근거 코드 줄 원문 (판정만 있고 줄이 없으면 다시 요청)

내가 직접 볼 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 17차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"Inference와 Serving의 차이", "앱 안에서 모델을 돌리면 생기는 세 문제", "모델 서버를 직접 노출하면 안 되는 이유"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.