LLM 101: 실전 가이드 (2026년 에디션)

반복문부터 시작하세요. 텍스트는 토큰으로 변환됩니다. 토큰은 Transformer를 통과합니다. Attention은 이전 토큰 중 어떤 것이 중요한지 결정합니다. 런타임은 KV 캐시를 유지하여 모델이 매번 전체 대화를 다시 계산하지 않도록 합니다. 그런 다음 모델은 다음 토큰을 선택하고 다시 반복합니다.

LLM이 어떻게 작동하는지, 모델이 한 번에 하나의 토큰으로 어떻게 생각하는지, 그리고 로컬에서 어떻게 실행하는지에 대한 실용적인 가이드입니다.

이 반복문을 이해하면 하드웨어와 소프트웨어 선택이 더 쉬워집니다. VRAM, 양자화, 컨텍스트 길이, 채팅 템플릿, 디코딩, RAG, 서빙 엔진, 모델 선택 모두 동일한 메커니즘에서 비롯됩니다.

반복문부터 시작하세요: 토큰이 들어오고, 확률이 나가고, 한 번에 하나의 다음 토큰이 생성됩니다. 가중치는 모델이 학습한 패턴을 알려줍니다. 컨텍스트는 모델이 현재 무엇을 보고 있는지 알려줍니다. KV 캐시는 반복문을 사용 가능하게 유지하는 작업 메모리입니다. 하드웨어, 런타임, 모델 선택은 모델이 따르는 메모리, 컨텍스트, 포맷팅 규칙을 이해한 후에야 의미가 있습니다.

목표는 먼저 로컬 LLM 메커니즘을 직관적으로 이해하게 한 다음, 하드웨어, 런타임, 서빙, 그리고 2026년 5월 21일 기준 최신 LLM 연구로 가는 실용적인 경로를 제공하는 것입니다.

초점

이 가이드는 모델 우선 접근 방식입니다. 먼저 메커니즘부터 시작합니다: 추론, 토큰, Transformer, 어텐션, KV 캐시, 프리필, 디코드, 디코딩 제어, 모델 패키지, 채팅 템플릿, 모델 유형, 긴 컨텍스트, RAG, 에이전트, 파인튜닝, 멀티모달 모델.

그 후에는 로컬 배포 레이어로 넘어갑니다: 로컬의 실제 의미, 양자화, VRAM 계산, 하드웨어 계층, 런타임 선택, 서빙 모드, 라이선스, 모델 선택, 프라이버시, 문제 해결, 벤치마크, 설정 경로, 실용적인 사용 사례.

이 순서는 중요합니다. GPU를 선택하기 전에 긴 프롬프트가 왜 메모리를 소모하는지 이해해야 합니다. 모델을 평가하기 전에 채팅 템플릿이 왜 중요한지 이해해야 합니다. 초당 토큰 수를 신경 쓰기 전에 디코드가 왜 순차적인지 이해해야 합니다.

더 깊은 하드웨어 및 소프트웨어 경로를 위해 셀프 호스팅 LLM / 로컬 AI를 가르치는 3부작 시리즈가 있습니다:

처음 두 편은 하드웨어 용량과 대역폭 계산을 설명합니다. 세 번째는 해당 하드웨어를 사용 가능한 추론으로 바꾸는 소프트웨어 레이어를 설명합니다. 이 글은 먼저 모델 측 기반을 제공한 다음, 메커니즘이 명확해지면 해당 배포 레이어로 다시 연결합니다.

LLM이 실제로 하는 일

모델을 실행하는 것을 추론이라고 합니다. 표준 디코더 전용 LLM의 경우 추론은 동일한 반복문을 계속해서 반복합니다:

텍스트를 토큰으로 변환합니다.
해당 토큰을 모델에 공급합니다.
가능한 모든 다음 토큰에 대한 점수를 계산합니다.
디코딩 정책으로 하나의 토큰을 선택합니다.
해당 토큰을 시퀀스에 추가합니다.
모델이 중단되거나, 사용자가 중단하거나, 토큰 제한에 도달할 때까지 반복합니다.

모델은 한 번에 전체 답변을 작성하는 것이 아닙니다. 한 번에 하나의 토큰을 생성합니다. 새로운 각 토큰은 다음 토큰에 영향을 미치는 시퀀스의 일부가 됩니다.

수학적으로 모델은 학습된 함수입니다:

f(theta, sequence) -> next_token에 대한 확률 분포

여기서:

theta는 모델 가중치를 의미합니다.
sequence는 프롬프트와 지금까지 생성된 토큰을 의미합니다.
Logits는 softmax 이전의 원시 점수입니다.
Probabilities는 softmax 이후의 정규화된 점수입니다.
Decoding은 이러한 확률을 하나의 선택된 토큰으로 변환합니다.

이것이 로컬 생성 속도가 초당 토큰 수로 측정되는 이유입니다. 시스템은 순방향 패스를 반복적으로 실행하고, 토큰을 선택하거나 샘플링하고, KV 캐시를 업데이트하고, 계속 진행합니다.

여기서 인지가 중요합니다. 긴 프리필은 첫 번째 단어가 나타나기 전에 긴 멈춤을 의미합니다. 느린 디코드는 답변이 느리게 스트리밍됨을 의미합니다. 로컬 빌더는 종종 사용자가 느끼는 것이기 때문에 디코드 속도에 집착하지만, 프리필 시간은 10K 토큰 문서를 붙여넣을 때 고통스러운 부분입니다.

토큰

LLM은 원시 텍스트를 단어로 보지 않습니다. 토큰으로 봅니다: 내부적으로 정수 ID로 표현되는 텍스트의 작은 조각입니다.

토큰은 다음과 같을 수 있습니다:

전체 단어: "hello"
단어 조각: "inter", "national", "ization"
구두점
공백이 포함된 문자열
바이트 수준 폴백
<|user|>, <|assistant|>, , 또는 와 같은 특수 제어 마커

토크나이저는 텍스트를 토큰 ID로 매핑하고 토큰 ID를 다시 텍스트로 매핑합니다. 일반적인 토크나이저 계열에는 BPE 스타일 토크나이저와 SentencePiece 스타일 토크나이저가 있습니다. 다른 모델 계열은 다른 토크나이저를 사용하며, 이것은 중요합니다. 4,000단어 문서는 한 토크나이저에서는 5,000토큰일 수 있지만 다른 토크나이저에서는 7,500토큰일 수 있습니다.

어휘 크기도 중요합니다. 더 큰 어휘를 가진 토크나이저는 일부 텍스트를 더 적은 토큰으로 압축할 수 있지만, 임베딩 및 출력 투영 크기도 변경합니다. 이것이 초당 토큰 수가 모델 계열 간에 완벽하게 비교 가능하지 않은 이유 중 하나입니다.

토큰이 중요한 이유는 다음을 결정하기 때문입니다:

컨텍스트 윈도우에 얼마나 많은 텍스트가 들어맞는지.
KV 캐시가 얼마나 커지는지.
프롬프트 처리 중 지연 시간이 얼마나 되는지.
다국어 또는 코드 중심 텍스트가 효율적인지.
모델이 특수 채팅 마커를 올바르게 보는지.

모델의 컨텍스트 윈도우는 한 번에 처리할 수 있는 최대 토큰 수입니다. 2026년에는 일반적인 로컬 사용 가능 모델이 8K 및 32K 컨텍스트부터 128K, 256K, 심지어 서버급 시스템에서는 1M 토큰 컨텍스트까지 다양합니다.

하지만 지원되는 컨텍스트 길이가 저렴하거나, 빠르거나, 동등하게 정확한 컨텍스트를 의미하는 것은 아닙니다. 기술적으로 128K 토큰을 처리할 수 있는 모델도 64K에서는 속도가 크게 느려지고 100K에서는 일관성을 잃을 수 있습니다. 항상 실제로 사용할 컨텍스트 길이를 테스트하세요.

토큰은 작업 단위입니다. 이것을 이해하면 긴 컨텍스트는 더 이상 마법처럼 보이지 않고 예측 가능한 비용처럼 보이기 시작합니다.

도움이 되는 연습: 토크나이저 데모 앱을 사용하여 텍스트가 실시간으로 어떻게 토큰으로 분할되는지 확인해 보세요.

Transformer

대부분의 최신 LLM은 Transformer 아키텍처를 기반으로 합니다. 대부분의 로컬 채팅 LLM은 디코더 전용 Transformer입니다: 이전 토큰을 참조하면서 다음 토큰을 예측합니다.

이 지점 위의 모든 것(토큰, 가중치, 설정, 채팅 템플릿 포함)은 실제 엔진의 설정 단계입니다. Transformer는 숫자를 이동시키는 뼈대입니다.

단순화된 Transformer 레이어에는 다음이 포함됩니다:

토큰 임베딩: 토큰 ID가 벡터가 됩니다.
위치 정보: 모델은 토큰 순서가 필요합니다. 많은 최신 LLM은 표현을 회전시켜 위치를 인코딩하는 RoPE(회전 위치 임베딩)를 사용합니다.
셀프 어텐션: 각 토큰 표현은 이전 토큰 표현을 참조하여 무엇이 중요한지 결정합니다.
MLP / 피드포워드 블록: 표현을 확장하고 압축하는 조밀한 비선형 계산입니다. 파라미터의 많은 부분이 여기에 있습니다.
레이어 정규화 및 잔차 연결: 심층 네트워크를 안정화하고 많은 레이어를 통해 정보 흐름을 돕습니다.
출력 투영: 최종 은닉 상태가 어휘에 대한 로짓이 됩니다.

이 레시피를 수십 또는 수백 번 쌓으면 언어 모델을 얻을 수 있습니다.

Transformer 요약: 토큰이 벡터가 되고, 어텐션이 시퀀스를 연결하고, MLP가 표현을 재구성하고, RoPE가 위치를 유지하며, 최종 투영이 마지막 은닉 상태를 다음 토큰 로짓으로 변환합니다.

어텐션

어텐션은 토큰이 다음 예측을 위해 이전 토큰 중 어떤 것이 중요한지 결정하는 방법입니다. 또한 로컬 추론이 메모리에 민감한 이유 중 하나이기도 합니다.

클래식 MHA(멀티 헤드 어텐션)는 많은 헤드에 대해 별도의 키/값 상태를 저장합니다. 모델에 유연성을 제공하지만 KV 캐시를 크게 만듭니다.

최신 로컬 모델은 종종 더 효율적인 어텐션 설계를 사용합니다:

MQA: 여러 쿼리 헤드가 하나의 키/값 헤드를 공유합니다. 메모리 효율적이지만 표현력이 떨어질 수 있습니다.
GQA: 쿼리 헤드 그룹이 키/값 헤드를 공유합니다. 많은 최신 로컬 모델에서 일반적인 중간 지점입니다.
MHA: 전체 멀티 헤드 어텐션. 강력할 수 있지만 긴 컨텍스트는 빠르게 비용이 많이 듭니다.

FlashAttention 및 SDPA 스타일 구현과 같은 최신 커널은 어텐션 메모리 트래픽을 줄이고 GPU를 더 바쁘게 유지합니다. 좋은 어텐션 커널이 있는 런타임은 동일한 모델과 하드웨어에서도 그렇지 않은 것보다 훨씬 빠를 수 있습니다.

이것이 두 개의 7B 모델이 긴 컨텍스트에서 매우 다르게 동작할 수 있는 이유입니다. 파라미터 수가 전부는 아닙니다. 128K 컨텍스트의 7B MHA 모델은 24GB GPU를 모두 사용할 수 있지만, 동일한 광고된 컨텍스트를 가진 7B GQA 모델은 여유 공간이 있을 수 있습니다.

모델을 비교할 때는 파라미터 수뿐만 아니라 어텐션 유형, KV 헤드, 컨텍스트 길이, 런타임 지원을 살펴보세요.

KV 캐시

KV 캐시는 생성 중 모델의 작업 메모리입니다. 이전 토큰에 대한 키/값 어텐션 상태를 저장하므로 모델이 생성된 모든 토큰에 대해 처음부터 전체 기록을 다시 계산하지 않아도 됩니다.

KV 캐시가 없으면 생성은 엄청나게 비효율적입니다. KV 캐시가 있으면 생성이 사용 가능하지만, 캐시는 다음에 비례하여 메모리를 소비합니다:

tokens x layers x kv_heads x head_dim x precision x 2

x 2는 키와 값을 위한 것입니다.

이전 Llama 스타일 7B MHA 모델에 대한 유용한 경험 법칙은 FP16 KV 캐시에서 토큰당 약 0.5MB입니다. 즉, 4K 토큰은 KV 캐시만으로 약 2GB가 소요될 수 있습니다. 32K 토큰에서는 KV 캐시만 16GB가 될 수 있습니다.

최신 GQA/MQA 모델은 이를 크게 줄입니다. 일부 런타임은 FP8 또는 INT8 KV 캐시도 지원합니다. 이것이 2026년 로컬 사용자에게 권장하는 실용적인 압축 하한선인 경우가 많습니다.

8비트 미만 KV 캐시를 기본값으로 취급하지 마세요. KIVI, KVQuant 및 최신 압축 캐시 커널과 같은 연구 시스템은 주의 깊은 알고리즘, 보정 및 사용자 정의 커널을 통해 2비트에서 4비트 KV가 작동할 수 있음을 보여줍니다. 데스크톱 런타임에서 Q4 KV 토글을 아무렇게나 켜는 것과는 다릅니다. 8비트 미만에서는 특히 코딩, 도구 호출, JSON, 긴 컨텍스트 검색 및 이전 토큰이 정확히 일치해야 하는 작업에 대해 철저히 벤치마킹하세요.

또한 KV 캐시 양자화를 추측 디코딩과 혼동하지 마세요. DFlash와 DDTree는 종종 비공식적으로 DTree로 축약되며, 미래 토큰을 초안 작성하고 검증하여 디코드 지연 시간을 줄입니다. 속도를 향상시킬 수 있지만 KV 캐시 메모리 비용을 없애지는 않습니다.

이것이 빈 프롬프트에서는 모델이 맞지만 긴 문서를 로드할 때 충돌하는 이유입니다. 가중치는 맞습니다. 작업 메모리가 맞지 않았습니다.

프리필 및 디코드

LLM 추론에는 프리필과 디코드라는 두 가지 다른 성능 영역이 있습니다.

프리필은 모델에 제공한 프롬프트를 처리합니다. 20,000토큰 문서를 붙여넣으면 모델은 첫 번째 답변 토큰을 생성하기 전에 해당 20,000토큰을 처리해야 합니다. 프리필은 비교적 병렬화가 가능하므로 GPU가 효율적으로 처리할 수 있지만 여전히 비용이 많이 들 수 있습니다.

첫 번째 토큰이 나타날 때까지 기다리는 시간은 일반적으로 프리필 시간입니다.

디코드는 한 번에 하나씩 새 토큰을 생성합니다. 각 생성된 토큰은 지금까지의 시퀀스에 의존하므로 디코드는 훨씬 더 순차적입니다. 이것이 스트리밍 타이핑 효과가 발생하는 곳이며, 일반적으로 모델이 빠른지 느린지를 결정하는 단계입니다.

긴 프롬프트는 프리필을 불리하게 만듭니다. 긴 답변은 디코드를 불리하게 만듭니다. 긴 대화는 KV 캐시가 커지기 때문에 둘 다 불리하게 만듭니다.

채팅 세션에서는 모든 턴이 캐시에 추가됩니다. 대화를 16K 토큰까지 실행하면 새로 생성된 모든 토큰에 대해 16K 토큰 모두의 메모리 비용을 지불하는 것입니다. 이것이 무한 기록을 유지하는 채팅 UI가 결국 느려지거나 충돌하는 이유입니다.

디코딩

모델이 로짓을 생성한 후에는 아직 아무것도 작성하지 않았습니다. 가능한 모든 다음 토큰에 점수를 매겼을 뿐입니다. 디코딩은 이러한 점수를 하나의 실제 토큰으로 변환하고, 해당 토큰을 컨텍스트에 추가하고, 반복문을 반복하는 정책입니다.

런타임 또는 추론 엔진은 여러 방식으로 토큰을 선택할 수 있습니다. 매번 가장 높은 확률의 토큰을 선택할 수 있습니다. 좁혀진 가능한 토큰 집합에서 샘플링할 수 있습니다. 반복을 페널티할 수 있습니다. 구분자에서 중단할 수 있습니다. 고정 시드를 사용하여 동일한 프롬프트가 재현 가능하게 동작하도록 할 수 있습니다.

이러한 선택은 모델 가중치를 변경하지 않지만 모델의 어조, 결정론, 창의성, 위험 프로필, 반복 경향을 변경합니다.

중요한 조정은 세 가지 실용적인 질문에 답합니다:

무작위성: 얼마나 많은 변형이 허용됩니까?
꼬리 도달: 샘플러가 낮은 확률의 토큰까지 얼마나 멀리 갈 수 있습니까?
경계: 루프, 잡담, 스키마 위반 또는 통제 불능 출력을 방지하는 것은 무엇입니까?

정밀한 작업의 경우 좁게 시작하세요: 낮은 온도, 짧은 최대 토큰 제한, 명시적 중지 시퀀스, 출력이 JSON 또는 스키마와 일치해야 할 때 제한된 디코딩을 사용하세요. 창의적인 작업의 경우 더 높은 온도, top-p, 그리고 이후에 여러 후보를 순위 지정하여 샘플러에 더 많은 여유를 주세요. 코딩의 경우 첫 번째 패스는 보수적으로 유지하고, 의도적으로 탐색할 때만 대안을 샘플링하세요.

탐욕 디코딩이 항상 더 정확한 것은 아닙니다. 종종 취약합니다. 탐욕 디코더는 대안을 탐색하지 않기 때문에 루프에 빠지거나 일반적인 답변을 생성할 수 있습니다. 평가의 경우 결정론적 설정을 사용하세요. 아이디어 구상의 경우 모델이 자유롭게 하세요.

모델 패키지의 구성 요소

실행 가능한 로컬 LLM은 하나의 큰 가중치 파일 그 이상입니다. 모델 패키지에는 일반적으로 다음이 포함됩니다:

아키텍처/설정: 레이어 수, 은닉 크기, 어텐션 유형, RoPE 설정, 어휘 크기, 특수 토큰, 컨텍스트 길이.
가중치: 학습된 파라미터로, 종종 safetensors, GGUF, GPTQ, AWQ, EXL2 또는 다른 런타임별 형식으로 저장됩니다.
토크나이저: 텍스트를 토큰 ID로 변환하고 토큰 ID를 다시 텍스트로 변환하는 규칙.
채팅 템플릿: 시스템, 사용자, 어시스턴트, 도구, 추론 메시지에 대한 정확한 마크업.
생성 설정: 온도, top-p, 중지 토큰, 반복 페널티, 최대 토큰의 기본값.
라이선스 및 모델 카드: 모델이 어떻게 사용될 수 있는지에 대한 법적 및 운영 지침.

가중치가 가장 큰 파일이지만 전체 모델은 아닙니다. 토크나이저, 설정 또는 채팅 템플릿이 잘못되면 동일한 가중치도 망가진 것처럼 느껴질 수 있습니다.

패키지 섹션은 함께 이동해야 하는 것을 알려줍니다. 다음 섹션에서는 사람들이 가장 자주 망가뜨리는 부분이 채팅 템플릿인 이유를 설명합니다.

채팅 템플릿

채팅 모델은 특정 대화 형식으로 학습되었습니다. 예를 들어, 다음과 같은 형식을 기대할 수 있습니다:

<|system|> 당신은 도움이 되는 어시스턴트입니다. <|user|> KV 캐시에 대해 설명해 주세요. <|assistant|>

다른 모델은 다음을 기대할 수 있습니다:

[BOS] [INST] KV 캐시에 대해 설명해 주세요. [/INST]

다른 모델은 ChatML 스타일 마커를 사용할 수 있습니다. 다른 모델은 특수 추론 토큰이 필요할 수 있습니다. 다른 모델은 도구 호출 XML 또는 JSON 래퍼가 필요할 수 있습니다.

잘못된 형식을 사용하면 횡설수설, 역할 혼동, 시스템 프롬프트 무시, 프롬프트 반복, 거부 이상, 도구 호출 중단, 잘못된 벤치마크 결과, 그리고 실제 버그는 템플릿인데 모델이 멍청하다는 결론을 초래할 수 있습니다.

모범 사례:

Transformers를 사용할 때는 토크나이저의 apply_chat_template을 사용하세요.
Harbor 기반 프론트엔드, llama.cpp, LM Studio, vLLM 또는 SGLang에서는 모델별 템플릿을 사용하세요.
모델이 base, instruct, chat, reasoning, tool-tuned 중 무엇인지 확인하세요.
BOS/EOS 토큰이 올바른지 확인하세요.
시스템 프롬프트는 길어야 하는 경우가 아니면 짧게 유지하세요.
도구 사용의 경우 모델/런타임이 예상하는 정확한 스키마를 따르세요.

사용자가 모델을 전환할 수 있는 애플리케이션을 구축하는 경우 템플릿 전환도 필요합니다. 하나의 템플릿 형식을 하드코딩한 다음 다른 형식을 기대하는 모델을 로드하는 것은 잘못된 로컬 모델 평가의 일반적인 원인입니다.

템플릿을 API 계약처럼 취급하세요. 잘못 사용하면 실제로 테스트하려는 모델을 테스트하는 것이 아닙니다.

모델 유형

모든 LLM이 동일한 동작으로 튜닝된 것은 아닙니다.

대부분의 사용자에게 기본 시작점은 메모리에 편안하게 맞는 크기의 최신 instruct/chat 튜닝 모델이어야 합니다.

이유를 알지 못하면 base 모델로 시작하지 마세요. Base 모델은 답변보다는 프롬프트를 완성합니다. 연구자, 파인튜너, 사용자 정의 파이프라인을 구축하는 사람들에게 유용합니다. 다른 모든 사람에게는 실망스럽습니다.

Base 모델에 "프랑스의 수도는 무엇인가요?"라고 묻으면 "파리의 인구는 얼마인가요?"라고 답변하는 대신 계속 이어갈 수 있습니다.

실용적인 구분은 간단합니다:

Base 모델: 사전 학습 연구, 파인튜닝, 사용자 정의 파이프라인에 적합합니다.
Instruct 모델: 직접적인 명령 수행에 적합합니다.
Chat 모델: 역할 형식을 사용한 다중 턴 대화에 적합합니다.
Reasoning 모델: 추가적인 사고 토큰과 검증이 작업에 도움이 될 때 적합합니다.
Tool-tuned 모델: 구조화된 호출, JSON 또는 함수 사용이 중요할 때 적합합니다.

로컬의 실제 의미

로컬 LLM은 가중치와 추론 런타임이 사용자 통제하에 있는 모델입니다. 어떤 모델을 실행할지, 어떻게 실행할지, 어떤 데이터를 볼지, 출력물에 어떤 일이 일어날지 결정합니다.

그 자유에는 작업이 따릅니다. 이제 당신은 운영팀입니다. 다운로드, 업데이트, 호환성, 메모리 제한, 보안을 처리합니다. 문제가 발생하면 제출할 지원 티켓이 없습니다. 오직 당신, 로그, 문서만 있을 뿐입니다.

로컬은 다음을 의미할 수 있습니다:

휴대폰에서 실행되는 2B 파라미터 모델.
소비자 GPU에서 실행되는 7B~14B 모델.
고성능 워크스테이션에서 실행되는 30B~70B 모델.
하나 이상의 데이터센터 GPU에서 실행되는 희소 MoE 모델.
vLLM, SGLang, TensorRT-LLM, llama.cpp, Harbor, LM Studio 또는 사용자 정의 PyTorch 스택을 사용하는 개인 배포.

핵심: 로컬이 자동으로 오프라인, 비공개, 안전, 저렴 또는 오픈소스를 의미하지는 않습니다. 단지 직접 모델을 실행하고 있다는 것만 의미합니다. 로컬 앱도 여전히 본사에 전화를 걸 수 있습니다. 모델이 오픈 가중치일 수 있지만 오픈소스는 아닐 수 있습니다. 모델이 로컬이지만 로드하기에 안전하지 않을 수 있습니다. 양자화된 모델이 메모리에 맞을 수 있지만 제대로 답변하지 못할 수 있습니다.

프라이버시, 낮은 지연 시간, 사용자 정의 동작, 오프라인 작동 또는 규모에 따른 비용 제어가 필요할 때 트레이드오프는 가치가 있습니다. 절대적으로 최고의 모델 품질이 필요하고 이를 뒷받침할 하드웨어가 없을 때는 가치가 없습니다. 그 경우 호스팅된 API가 올바른 도구입니다.

로컬 LLM은 하나의 방정식을 이해할 때 실용적입니다:

로컬 LLM 성공 = 모델 적합성 + 올바른 프롬프트 형식 + 좋은 런타임 + 현실적인 평가.

다른 모든 것은 세부 사항입니다. 세부 사항은 중요합니다.

양자화

양자화는 메모리 사용량을 줄이고 때로는 처리량을 개선하기 위해 가중치를 더 낮은 정밀도로 저장합니다.

2026년 로컬 사용자를 위한 경험 법칙:

FP16/BF16: 메모리가 충분할 때 최고 품질. 평가의 기준선으로 사용하세요.
Q8 / INT8: 많은 작업에서 거의 손실이 없지만 여전히 큽니다. VRAM이 있고 최소한의 품질 손실을 원할 때 좋습니다.
Q6 / Q5: 적당한 절약으로 우수한 품질. 강력한 중간 지점입니다.
Q4: 많은 채팅 및 문서 작업 흐름에 대한 기본 소비자 최적 지점입니다.
Q3 / Q2: 더 큰 모델을 맞춰야 할 때만 사용하세요. 수학, 코드, 구조화된 출력, 도구 사용이 먼저 저하됩니다.

가중치 양자화는 KV 캐시 양자화와 다릅니다. 가중치 양자화는 모델을 축소합니다. KV 캐시 양자화는 라이브 컨텍스트 메모리를 축소합니다.

KV 캐시의 경우 FP16/BF16을 깨끗한 기준선으로, FP8/INT8을 실용적인 로컬 압축 하한선으로 취급하세요. 8비트 미만은 연구 중심이며 워크로드에 민감합니다. 실제 프롬프트에서 품질을 측정한 후에만 사용하세요.

양자화 실패는 수학, 다단계 추론, 코드 정확성, 도구 사용 신뢰성, JSON/스키마 준수, 미묘한 명령 수행, 긴 컨텍스트 검색에서 먼저 나타납니다.

더 높은 정밀도의 더 작은 모델은 너무 적은 비트로 압축된 더 큰 모델을 이길 수 있습니다. 파라미터 수를 숭배하지 마세요. Q6의 7B 모델은 Q2의 13B 모델보다 추론 작업에서 더 적은 메모리를 사용하고 더 빠르게 실행할 수 있습니다.

파일 형식 및 로드 안전성

safetensors는 Python pickle 동작 없이 텐서를 저장하도록 설계된 안전한 텐서 직렬화 형식입니다. 가능하면, 특히 PyTorch/Transformers 모델의 경우 safetensors를 사용하세요.

신뢰할 수 없는 출처의 임의의 .bin 파일은 피하세요. PyTorch pickle 기반 로딩은 역직렬화 중에 임의의 코드를 실행할 수 있습니다. 로컬 AI 보안 규칙 1번: 낯선 사람의 모델 파일이 낯선 사람의 코드 실행이 되도록 두지 마세요.

GGUF는 llama.cpp 에코시스템의 바이너리 모델 형식입니다. llama.cpp, CPU 추론, Apple Silicon 추론, 간단한 로컬 서버, 휴대용 양자화 모델, LM Studio와 같은 데스크톱 도구를 원할 때 GGUF를 사용하세요.

ONNX는 표준화된 배포 및 하드웨어별 가속, 특히 일반적인 PyTorch 스택 외부에서 유용합니다. Intel NPU, ARM 기기 또는 사용자 정의 가속기에 배포하는 경우 ONNX가 종종 가장 저항이 적은 경로입니다.

TensorRT-LLM은 프로덕션 GPU 배포를 위한 NVIDIA의 고성능 추론 경로입니다. 강력하지만 llama.cpp나 Harbor보다 복잡합니다. 일반적으로 체크포인트를 TensorRT 엔진으로 변환해야 하며, 시간과 GPU 메모리가 소요되지만 일단 구축되면 우수한 처리량을 제공합니다.

EXL2 / GPTQ / AWQ 형식은 특히 더 큰 모델을 단일 GPU에 맞추기 위해 GPU 중심 로컬 추론 커뮤니티에서 일반적입니다.

파일 형식 선택은 외형적인 것이 아닙니다. 어떤 런타임이 모델을 로드할 수 있는지, 어떤 양자화를 사용할 수 있는지, 얼마나 빠르게 실행되는지를 결정합니다.

런타임 및 서빙 모드

런타임은 모델을 로드하고 추론을 수행하는 소프트웨어입니다. 2026년에는 로컬 LLM 런타임 생태계가 성숙하고 유용하며 파편화되어 있습니다.

로컬에서 실험하는 단일 사용자의 경우 Harbor, LM Studio 또는 llama.cpp로 시작하세요. Harbor는 프론트엔드, 백엔드 및 지원 서비스가 함께 연결된 완전한 로컬 스택을 원할 때 가장 적합합니다. LM Studio는 가장 쉬운 데스크톱 우선 경로입니다. llama.cpp는 휴대용 저수준 작업 동기입니다.

팀 또는 개인 서비스의 경우 vLLM 또는 SGLang을 살펴보세요. 최대 NVIDIA 프로덕션 성능을 위해 TensorRT-LLM을 조사하세요. 브라우저 또는 모바일 배포의 경우 MLC 또는 WebLLM을 살펴보세요.

런타임 선택은 종종 형식 생태계에 고정됩니다. llama.cpp는 GGUF를 의미합니다. vLLM과 SGLang은 일반적으로 safetensors 또는 Hugging Face 체크포인트를 의미합니다. TensorRT-LLM은 ONNX 또는 최적화된 엔진을 의미합니다. 먼저 런타임을 선택한 다음 올바른 형식의 모델을 찾으세요.

세 가지 실용적인 서빙 모드가 있습니다.

단일 사용자 로컬은 한 사람을 위한 데스크톱 앱, CLI 스택 또는 명령줄 서버를 의미합니다. Harbor, LM Studio, llama.cpp 서버, ExLlama/TabbyAPI 및 소규모 Transformers 스크립트가 모두 여기에 해당합니다. 목표는 빠른 반복입니다: 운영 플랫폼을 구축하지 않고 동작, 속도, 메모리 사용량 및 프롬프트 형식을 비교합니다.

팀 또는 개인 API는 워크스테이션 또는 서버에서 OpenAI 호환 엔드포인트를 의미합니다. vLLM, SGLang, TensorRT-LLM 및 llama.cpp 서버는 모두 모델 크기와 처리량 요구 사항에 따라 여기에 나타납니다. 여러 사람이나 작업이 모델을 공유하면 모니터링, 프롬프트/버전 관리, 라우팅 및 현실적인 지연 시간 측정이 필요합니다.

프로덕션 서빙은 완전히 다른 작업입니다. 여기서는 지속적 배치(continuous batching), 프리픽스 캐싱(prefix caching), 추측 디코딩(speculative decoding), 페이징 어텐션(paged attention), 텐서 병렬화(tensor parallelism), 파이프라인 병렬화(pipeline parallelism), 양자화 서빙(quantized serving), 구조화된 출력(structured outputs), 로드 밸런싱(load balancing), GPU 활용률, 지연 시간 백분위수, 프롬프트 캐싱(prompt caching), 승인 제어(admission control), 로깅, 장애 조치(failover), 프라이버시, 비용 관리 등이 논의됩니다.

프로덕션 규모에서 "모델을 로드할 수 있나요?"는 쉬운 질문입니다. 어려운 질문은 "실제 트래픽에서 안정적으로 서빙할 수 있나요?"입니다.

로컬 모델을 위한 VRAM 계산

메모리 소비는 크게 세 가지입니다:

모델 가중치
KV 캐시
런타임 오버헤드

대략적인 가중치 메모리 공식은 다음과 같습니다:

weight_memory ~= parameters x bytes_per_parameter

유용한 근사치:

FP16/BF16: 파라미터당 약 2 바이트
INT8/Q8: 파라미터당 약 1 바이트
Q4: 파라미터당 약 0.5 바이트 + 포맷 오버헤드

그런 다음 추가:

런타임 오버헤드: 프레임워크 버퍼, CUDA 오버헤드, 메모리 단편화, 임시 텐서
KV 캐시: 활성 컨텍스트의 모든 토큰과 함께 증가
배치/동시성 메모리: 각 동시 요청은 자체 캐시가 필요
비전 인코더 메모리: 이미지도 토큰이 됨
추측 디코딩 메모리: 드래프트 모델, 드래프트 헤드, 또는 추가 검증 구조는 무료가 아님
어댑터 메모리: LoRA 어댑터는 작지만 실제 메모리를 사용함

MoE 모델은 한 가지 더 복잡한 점을 추가합니다. 모델이 토큰당 파라미터의 일부만 활성화할 수 있지만, 비활성 전문가(experts)는 일반적으로 여전히 메모리 어딘가에 존재해야 합니다. 활성 파라미터는 계산 비용에 영향을 미칩니다. 총 파라미터는 로딩 및 용량 계획에 여전히 영향을 미칩니다.

현실적인 추정치는 다음과 같습니다:

total_memory = quantized_weightsKV_cache_for_context runtime_overhead batch_or_concurrency_overhead safety_margin

여기 함정이 있습니다: 13B 모델을 Q4로 사용할 때 8K 컨텍스트에서는 쉽게 맞지만, KV 캐시가 4배로 증가하는 32K에서는 실패할 수 있습니다. 가중치는 변하지 않았습니다. 컨텍스트가 변한 것입니다.

10~20%의 여유를 남겨두세요. VRAM 사용률 99%에서 실행하는 것은 메모리 부족 오류와 단편화 실패를 자초하는 것입니다.

실제 하드웨어 계층

다음은 2026년 실용적인 경험 법칙으로, 양자화된 추론과 적절한 컨텍스트 길이를 가정합니다. 정확한 결과는 런타임, 양자화, 모델 아키텍처, 어텐션 유형, 컨텍스트 길이, OS/드라이버 오버헤드에 따라 다릅니다.

2026년 대부분의 진지한 로컬 사용자에게 16GB는 편안한 최소 GPU 계층, 24GB는 최고의 가치를 제공하는 매니아 계층, 48GB 이상은 강력한 로컬 세계가 열리는 계층입니다.

성능은 메모리 대역폭, GPU FLOPs, VRAM 용량, KV 캐시 크기, 어텐션 구현, 양자화, 배치 크기, 프롬프트 길이, 생성 길이, 런타임 성숙도에 따라 달라집니다.

디코딩은 종종 메모리 대역폭에 바운드됩니다. GPU는 바이트당 상대적으로 적은 계산을 수행하면서 가중치를 반복적으로 스트리밍합니다. 프리필은 프롬프트를 병렬로 처리할 수 있기 때문에 계산 바운드에 더 가깝습니다. 이것이 동일한 VRAM 용량을 가진 두 개의 카드가 메모리 대역폭이 훨씬 높은 경우 매우 다른 토큰 속도를 가질 수 있는 이유입니다.

가장 고통스러운 로컬 설정은 모델이 거의 맞지만 레이어가 CPU로 넘쳐흐르는 경우입니다. 기술적으로는 실행될 수 있지만 토큰 속도가 급락할 수 있습니다. CPU 오프로드는 실험용으로는 허용됩니다. 성능 전략은 아닙니다.

맞는 모델 선택하기

실질적인 질문은 "최고의 모델이 무엇인가?"가 아닙니다. "내 하드웨어에서 실제 워크로드를 이길 수 있는 가장 작은 모델은 무엇인가?"입니다.

실제로 필요한 컨텍스트 길이에 편안하게 맞는 최신 instruct/chat 모델부터 시작하세요. VRAM 또는 통합 메모리가 8GB에서 12GB라면 작게 시작하세요. 16GB에서 24GB라면 먼저 7B에서 14B 클래스 모델을 테스트하세요. 48GB 이상이라면 더 큰 밀집 모델과 MoE 모델이 현실적이 됩니다.

특정 체크포인트에 마음을 빼앗기기 전에 이 메모리 게이트를 사용하세요:

weights + KV cache + runtime overhead <= 80 to 90 percent of available memory

그런 다음 후보 모델들을 대상으로 동일한 20~50개의 프롬프트를 실행하세요. 실제 작업(코딩 편집, 문서 Q&A, JSON 출력, 요약, 도구 호출, 긴 컨텍스트 등 실제로 필요한 모든 것)을 포함하세요. 답변 품질, 지연 시간, 메모리 사용량, 템플릿 신뢰성, 실패 모드를 측정하세요.

실용적인 모델 선택은 일반적으로 다섯 가지 확인 사항으로 귀결됩니다:

작업 적합성: 채팅, 코딩, 문서, 에이전트, 멀티모달, 엣지, 또는 파인튜닝
메모리 적합성: 가중치, KV 캐시, 런타임 오버헤드, 안전 여유
인터페이스 적합성: 토크나이저, 채팅 템플릿, 중지 토큰, 도구 스키마, 추론 모드
런타임 적합성: 런타임이 이 아키텍처, 양자화, 컨텍스트 길이, 서빙 모드를 잘 지원하는가?
라이선스 적합성: 실제로 사용하려는 곳에서 사용할 수 있는가?

리더보드는 발견에 유용합니다. 그러나 자체 평가를 대체하지는 않습니다. 당신의 워크로드가 중요한 벤치마크입니다.

간단한 로컬 어시스턴트의 경우, 최신 7B~14B instruct 모델, Q4/Q5 양자화, 올바른 채팅 템플릿, 8K~32K 컨텍스트, 그리고 Harbor, LM Studio 또는 llama.cpp를 선택하세요. 거대한 크기보다 응답성을 우선시하세요.

로컬 코딩 어시스턴트의 경우, VRAM이 충분하다면 코딩 가능한 14B~32B 모델을 선택하세요. 낮은 온도, 저장소 검색, 테스트 실행, 패치 기반 워크플로를 사용하세요. 도구 없는 코드 모델은 반쪽짜리 제품입니다.

개인 문서 어시스턴트의 경우, 강력한 instruct 모델, 로컬 임베딩 모델, 리랭커, RAG 파이프라인, 인용 강제, 중간~긴 컨텍스트를 선택하세요. 200페이지 PDF를 붙여넣고 기대하지 마세요.

추론 설정의 경우, 추론에 특화된 모델을 선택하고, 추가 토큰을 예산에 포함시키고, 낮은~중간 온도를 사용하고, 검증을 추가하고, 수학, 코드 또는 검색을 위한 도구를 사용하세요. 추론 모델은 더 많은 토큰을 소비합니다. 예산을 그에 맞게 책정하세요.

저사양 설정의 경우, 1B~4B 모델, Q4/Q5, 짧은 프롬프트, 구조화된 작업, 검색 또는 도구, 그리고 빡빡한 출력 스키마를 선택하세요. 작업이 제한될 때 작은 모델이 유용해집니다.

속도를 결정하는 요소

초당 토큰 수는 하나의 요소로 결정되지 않습니다. 모델 크기, 메모리 대역폭, 계산, 어텐션 커널, 컨텍스트 길이, 양자화, 배치, 런타임 품질의 결과입니다.

주요 레버는 다음과 같습니다:

메모리 대역폭: 디코딩은 종종 모델 가중치를 반복적으로 스트리밍하므로, 대역폭이 단일 사용자 토큰 속도를 지배합니다.
GPU FLOPs: 프리필과 대규모 배치는 더 많은 병렬 계산을 사용하므로, FLOPs가 여기서 더 중요합니다.
VRAM 용량: 모델이나 KV 캐시가 CPU로 넘치면 성능이 급락할 수 있습니다.
어텐션 구현: FlashAttention, SDPA, 페이징 어텐션, 런타임별 커널은 속도와 메모리 동작을 모두 변경합니다.
양자화: 더 작은 가중치는 메모리 이동을 줄이지만, 과도한 양자화는 품질을 떨어뜨리고 때로는 역양자화 오버헤드를 추가할 수 있습니다.
배치 크기 및 동시성: 배치는 처리량을 향상시키지만, 각 활성 시퀀스에는 KV 캐시가 필요합니다.
프롬프트 길이: 긴 프롬프트는 프리필 시간을 증가시킵니다.
생성 길이: 긴 답변은 디코딩 속도를 드러냅니다.
추측 디코딩: EAGLE 스타일 방법, MTP, DFlash, DDTree는 지원되는 경우 대상 패스당 하나 이상의 드래프트 토큰을 검증할 수 있습니다.

고통스러운 설정은 거의 맞는 설정입니다. 레이어나 캐시가 CPU로 넘치는 모델은 기술적으로 실행될 수 있지만, 토큰 속도는 사용 가능한 수준에서 비참한 수준으로 떨어질 수 있습니다.

사용하려는 정확한 런타임, 양자화, 컨텍스트 길이, 프롬프트 형태, 워크로드로 벤치마킹하세요. BF16 리더보드 숫자는 Q4 로컬 스택이 어떤 느낌일지 알려주지 않습니다.

긴 컨텍스트

긴 컨텍스트는 마법처럼 들립니다: 하나의 프롬프트에 128K, 256K, 심지어 1M 토큰. 유용하지만 실제 비용이 따릅니다.

더 많은 컨텍스트는 더 많은 KV 캐시 메모리, 더 느린 프롬프트 처리, 더 많은 어텐션 작업, 더 어려운 평가, 그리고 관련 없는 텍스트가 모델을 산만하게 할 더 많은 방법을 의미합니다. 품질도 거리에 따라 저하될 수 있습니다. 모델이 긴 문서의 끝 부분을 잘 처리하면서 시작 부분 근처에 묻힌 중요한 세부 사항을 놓칠 수 있습니다.

긴 컨텍스트는 전체 문서 분석, 코드베이스 조각, 법률 또는 기술 검토, 대본 요약, 다중 파일 추론, 그리고 검색이 컨텍스트를 놓쳤을 때 RAG 대비책으로 사용하세요.

긴 컨텍스트를 검색의 대체물로 취급하지 마세요. 보완 관계입니다. 대규모 코퍼스에는 RAG를 사용하고 최종 선택된 증거에는 긴 컨텍스트를 사용하세요.

실용적인 습관이 도움이 됩니다:

중요한 지침은 시작 부분과 끝 부분 근처에 배치하세요.
섹션 헤더와 구분 기호를 사용하세요.
소스 청크에 연결된 인용을 요청하세요.
관련 없는 기록을 압축하세요.
무한 채팅 기록 대신 요약 메모리를 사용하세요.

긴 컨텍스트를 값비싼 어텐션으로 생각하세요. 무료 노트북이 아닙니다.

멀티모달

로컬 멀티모달 모델은 텍스트 외에도 이미지, 때로는 오디오나 비디오를 입력으로 받습니다. 최신 오픈 가중치 생태계는 점점 이러한 모델을 포함하고 있습니다.

숨겨진 비용은 비텍스트 입력도 토큰이 된다는 것입니다. 비전 인코더는 메모리를 추가합니다. 이미지 패치는 컨텍스트를 소비합니다. 오디오와 비디오는 입력 예산을 폭발시킬 수 있습니다. 멀티모달 템플릿은 텍스트 전용 템플릿보다 실수하기 쉽습니다.

단일 고해상도 이미지는 컨텍스트 윈도우에서 수천 개의 토큰을 소비할 수 있습니다. 로컬에서 멀티모달 모델을 실행하는 경우, 이미지 토큰을 텍스트 토큰과 동일한 방식으로 계산하세요. 동일한 예산에서 나옵니다.

작은 VLM은 시각적 세부 사항을 환각할 수 있습니다. OCR 신뢰성은 다양합니다. 차트와 표는 여전히 어렵습니다. 진지한 문서나 이미지 워크플로의 경우 실제 샘플로 평가하세요. 간단한 사진 데모를 보고 송장 추출 품질을 증명했다고 믿지 마세요.

2026년 로컬 모델 풍경

모델 풍경은 빠르게 변합니다. 2026년 5월 21일 기준, 로컬 LLM 사용자는 하나의 최고 모델이 아니라 제품군과 생태계 측면에서 생각해야 합니다.

Qwen 3.5 / Qwen 3.6은 주요 오픈 가중치 제품군입니다. 노트북용 소형 모델, 워크스테이션용 밀집 중형 모델, 멀티 GPU 서빙용 MoE 모델, FP8 변종, 긴 컨텍스트, 다국어 작업, 코딩, 도구, 에이전트 워크플로 등 전체 스택을 다루기 때문입니다. 실용적인 결론은 간단합니다: Qwen은 랩탑 실험부터 진지한 로컬 서빙까지 아우르는 하나의 생태계를 원할 때 강력한 기본 선택입니다.

Gemma 4가 중요한 이유는 Google DeepMind가 이 제품군을 유용한 로컬 배포 쪽으로 밀고 있기 때문입니다: 효율적인 엣지 모델, 더 큰 밀집 및 MoE 옵션, 멀티모달, 더 큰 모델의 긴 컨텍스트, 광범위한 언어 지원, 더 강력한 코딩/에이전트 동작, Apache 2.0 라이선스. 이러한 조합은 상업적 사용과 디바이스 측 배포가 중요할 때 테스트해볼 가치가 있습니다.

Kimi / Moonshot AI, GLM / Z.ai, DeepSeek, MiniMax, Mistral도 추적해야 할 핵심 제품군입니다. Kimi는 장기 코딩, 멀티모달 추론, 도구 사용, 에이전트 워크플로와 관련이 있습니다. GLM은 코딩 에이전트, 장기 작업, MoE 시스템, 배포 지향적 모델 출시에 중요합니다. DeepSeek은 대규모 MoE 시스템, Multi-head Latent Attention, DeepSeekMoE, FP8 서빙 경로, 희소 어텐션, 고처리량 자체 호스팅으로 인해 여전히 영향력이 있습니다. MiniMax는 실용적인 에이전트 워크로드와 추론 효율적인 MoE 모델로 주목할 가치가 있습니다. Mistral은 일반, 코딩, 추론, 멀티모달, 전문가 사용 사례를 강력한 배포 지원과 함께 아우르는 라인업 때문에 여전히 중요합니다.

Nemotron 3는 NVIDIA 하드웨어에서 프로덕션 등급 에이전트 시스템을 위한 NVIDIA의 오픈 모델 제품군입니다. 이 제품군에는 Nano, Super, Ultra 크기가 포함되며, 하이브리드 Mamba-Transformer MoE 설계를 사용하고 TensorRT-LLM, NIM, Dynamo, Blackwell NVFP4/FP8 경로, 엔터프라이즈 에이전트 배포와 밀접하게 연결되어 있습니다. 데스크탑 채팅 제품군이라기보다는 NVIDIA가 오픈 가중치 서빙 스택을 어디로 이끌고 싶어하는지에 대한 신호로 취급하세요.

오픈 가중치 AI는 더 이상 Llama 대 나머지의 구도가 아닙니다. 당신은 생태계를 선택하고 있습니다: 가중치, 라이선스, 토크나이저, 템플릿, 양자화, 런타임 지원, 서빙 경로, 커뮤니티 도구, 실패 모드.

Qwen 27B 밀집 모델

Qwen 3.5 / 3.6 27B (Dense)는 코딩, 다국어 작업, 도구 사용, 사고/비사고 모드, 긴 컨텍스트에 관심이 있는 로컬 사용자에게 가장 실용적인 공개 가중치 옵션 중 하나입니다. Qwen 3.5 27B 및 Qwen 3.6 27B 모델 카드는 OpenAI 호환 서빙 경로, 사고 모드 기본값, 도구 사용, 최대 262,144 토큰의 컨텍스트 길이를 설명하며, 지원되는 프레임워크에서 YaRN을 통한 더 긴 컨텍스트 확장을 제공합니다.

Qwen은 런타임이 코딩, 에이전트 또는 다국어 지원에 맞게 올바르게 구성된 2x RTX 3090 설정에서 강력한 기본값입니다.

추론 연구

2026년의 최전선은 모델 품질만이 아닙니다. 추론 효율성도 중요합니다. PagedAttention은 서빙에서 KV 캐시 메모리 낭비를 공격합니다. FP8 KV 캐시는 이제 vLLM과 같은 시스템에서 실용적인 런타임 기능입니다. DFlash와 DDTree는 블록 확산 드래프트 모델 및 드래프트 트리를 사용한 추측 디코딩을 탐구합니다. NVFP4는 지원되는 스택에서 실용적인 배포 논의를 변경하기 때문에 NVIDIA 하드웨어에서 주목할 가치가 있습니다.

이 중 일부는 프로덕션 준비가 되었습니다. 일부는 여전히 연구 단계입니다. 일부는 런타임이 깔끔하게 지원하는 경우에만 중요합니다. 데스크탑 앱의 체크리스트로 논문 속도 향상을 취급하지 마세요.

실패 모드 및 해결 방법

대부분의 로컬 LLM 실패는 신비롭지 않습니다. 일반적으로 메모리 적합성, 포맷팅, 런타임 지원, 디코딩 설정 또는 검색 품질에서 비롯됩니다.

메모리 부족: 가중치, KV 캐시, 런타임 오버헤드 또는 배치 크기가 맞지 않습니다. 더 작은 모델을 사용하고, 컨텍스트를 줄이고, 배치/동시성을 낮추고, 더 나은 양자화를 선택하거나, 더 많은 여유를 두세요.

횡설수설 또는 역할 혼동: 채팅 템플릿, 토크나이저, BOS/EOS 토큰, 추론 모드 전환 또는 도구 스키마가 잘못되었습니다. 모델 품질을 탓하기 전에 모델 카드와 런타임 템플릿을 확인하세요.

느린 첫 토큰: 프리필이 비쌉니다. 프롬프트를 줄이고, 프리픽스 캐싱을 사용하고, 검색을 개선하고, 컨텍스트를 줄이거나, 더 빠른 런타임을 사용하세요.

느린 스트리밍: 디코딩이 병목입니다. 메모리 대역폭, 양자화, CPU 넘침, 어텐션 백엔드, 추측 디코딩 지원, 모델이 하드웨어에 비해 단순히 너무 큰지 확인하세요.

잘못된 문서 답변: 검색이 실패했을 가능성이 큽니다. 구문 분석된 텍스트, 청크 경계, 메타데이터, 상위 k 검색, 리랭킹, 인용 근거를 검사하세요.

잘못된 JSON 또는 도구 호출: 더 낮은 온도, 제한된 디코딩, 더 엄격한 스키마, 더 나은 예제, 도구 사용에 특화된 모델을 사용하세요.

반복 루프: 온도나 top-p를 낮추고, 반복 페널티를 추가하고, 중지 토큰을 확인하고, 템플릿이 모델이 자신의 답변을 새 프롬프트로 보게 하지 않는지 확인하세요.

지루한 확인부터 시작하세요. 모델을 교체하는 것보다 더 많은 문제를 해결합니다.

스택 확장하는 방법

초급: 가장 쉬운 유용한 설정

Harbor 또는 LM Studio, 최신 4B~9B instruct 모델, Q4 양자화, 8K~32K 컨텍스트, 내장 채팅 UI를 사용하세요. 동일한 크기 클래스의 모델 2~3개를 다운로드하고 동일한 프롬프트로 비교하세요.

목표: 프롬프팅 학습, 모델 비교, 속도와 메모리 이해, 처음에는 커스텀 코드 피하기.

중급: 개발자 설정

llama.cpp 또는 Transformers, GGUF 또는 safetensors, OpenAI 호환 로컬 서버, 간단한 RAG 파이프라인, 소규모 평가 세트를 사용하세요. 채팅 UI만 사용하지 말고 실제 애플리케이션이나 스크립트에서 로컬 서버를 호출하세요.

목표: 로컬 앱 구축, 검색 테스트, 품질 측정, localhost에서 서빙.

고급: 개인 서빙 설정

vLLM 또는 SGLang, 하나 이상의 GPU, OpenAI 호환 API, 모니터링, 프롬프트/버전 관리, 평가 제품군, 리랭킹을 포함한 RAG, 도구 샌드박싱을 사용하세요.

목표: 실제 사용자 또는 내부 워크플로우 서빙, 처리량 및 지연 시간 최적화, 안전성 및 관찰 가능성 유지.

전문가: 맞춤 최적화

TensorRT-LLM, 커스텀 커널, 전문화된 런타임, 양자화 실험, 추측 디코딩, 멀티 GPU 병렬화, 파인튜닝, 증류, 프로덕션 평가를 사용하세요.

목표: 규모에 맞게 엔지니어링 시간을 추론 효율성, 비용 절감, 품질 향상으로 교환.

프라이버시는 자동이 아닙니다

로컬 LLM은 프롬프트와 출력이 하드웨어에 남을 수 있기 때문에 프라이버시를 향상시킵니다. 그러나 로컬이 자동으로 안전을 의미하지는 않습니다.

위협에는 악의적인 모델 파일, pickle 기반 가중치 로딩, 신뢰할 수 없는 trust_remote_code, 검색된 문서의 프롬프트 인젝션, 도구 호출 남용, 로그를 통한 비밀 유출, 데스크탑 앱의 텔레메트리, 브라우저 확장 프로그램 또는 플러그인, 중요 상황에서의 모델 환각, 라이선스 위반, 파인튜닝 중 데이터 오염이 포함됩니다.

실행 가능한 로컬 AI 보안 기준은 네 가지 습관으로 구성됩니다:

조심히 로드하기: 평판이 좋은 출처의 safetensors 또는 GGUF를 선호하고, 신뢰할 수 없는 .bin 파일을 피하고, trust_remote_code를 가볍게 활성화하지 마세요.
경계를 가지고 실행하기: 권한이 낮은 사용자, 에이전트용 컨테이너 또는 샌드박스, 오프라인 프라이버시가 중요할 때 네트워크 액세스 비활성화를 사용하세요.
비밀 보호하기: 프롬프트와 RAG 인덱스에서 자격 증명을 제외하고, 데스크탑 앱 텔레메트리 설정을 검토하고, 실행 전에 도구 호출을 검증하세요.
중요한 것 버전 관리하기: 모델, 프롬프트, 어댑터, 런타임, 양자화 버전을 추적하고, 프라이버시 재앙을 만들지 않으면서 디버깅에 충분한 로그를 남기세요.

로컬 AI 보안은 대부분 지루한 운영 규율입니다. 그것이 또한 무작위 체크포인트를 다운로드하여 루트로 실행하고 로컬 AI를 로컬 침해로 바꾸지 않는 방법입니다.

중요한 벤치마크

실제로 실행할 스택을 벤치마킹하세요. 모델의 BF16 리더보드 점수는 Q4 로컬 현실이 아닙니다.

품질, 지연 시간, 메모리, 신뢰성, 운영 적합성을 측정하세요:

품질: 일반적인 벤치마크뿐만 아니라 실제 작업에 대한 정확성
지연 시간: 첫 번째 토큰까지의 시간, 초당 디코딩 토큰 수, 종단 간 시간
메모리: 가중치 메모리, KV 캐시 증가, 최대 VRAM, 부하 상태에서의 여유
포맷팅: 채팅 템플릿 정확성, JSON/스키마 성공, 도구 호출 신뢰성, 중지 토큰 동작
검색: 인용 신뢰성, 답변 근거, 증거 누락 시 동작, 리랭커 영향
운영: 시작 시간, 워밍업 동작, 충돌 복구, 로깅, 프라이버시, 버전 추적

30~100개의 대표적인 프롬프트로 소규모 평가 세트를 만드세요. 예상 답변 또는 채점 기준, 지연 시간 및 메모리 측정, 실패 범주, RAG 특화 근거 확인, 관련된 경우 JSON 준수 확인, 모호한 작업에 대한 인간 검토를 포함하세요.

그런 다음 모델을 비교하세요. 리더보드가 로컬 스택을 선택하도록 두지 마세요.

로컬 모델로 코딩하기

코딩은 로컬 LLM의 가장 좋은 사용 사례 중 하나입니다. 프롬프트에 종종 비공개 코드가 포함되고, 지연 시간이 중요하며, 반복이 빈번하고, API 비용이 빠르게 증가할 수 있으며, 로컬 모델이 편집기, 셸, grep, 테스트 러너, 패치 워크플로와 통합될 수 있기 때문입니다.

가장 강력한 로컬 코딩 설정은 단순한 챗봇이 아닙니다. 대상 저장소 컨텍스트, 코드베이스 검색, 파일 경로, 관련 스니펫, 테스트 실행, 패치 루프에 연결된 코딩 가능한 instruct 모델입니다.

디코딩을 결정론적이거나 낮은 온도로 유지하세요. 막연한 조언 대신 패치를 요청하세요. 테스트를 자동으로 실행하세요. 실제 버그와 작업에 대한 작은 평가 세트를 유지하여 새 모델이 실제로 더 나은지 알 수 있도록 하세요.

로컬 모델이 검토 없이 대규모 코드베이스를 재작성하도록 두지 마세요. 로컬이 코딩 에이전트를 현명하게 만들지 않습니다. 컨텍스트를 비공개로 만들고, 루프를 더 저렴하게 만들고, 통합을 제어하기 쉽게 만들 뿐입니다.

로컬 에이전트에는 보호 장치가 필요합니다

로컬 LLM이 도구를 사용할 수 있을 때 훨씬 더 유용해집니다: 파일 검색, 셸 명령, 브라우저 자동화, 데이터베이스, 코드 실행, 캘린더, 티켓 시스템, 내부 API, 벡터 데이터베이스, 홈 오토메이션, 로보틱스, 엣지 디바이스.

도구 사용은 안전 모델을 변경합니다. 환각하는 챗봇은 성가십니다. 파일 시스템에 접근할 수 있는 에이전트는 파일을 삭제할 수 있습니다. 브라우저에 접근할 수 있는 에이전트는 비밀을 유출할 수 있습니다. 셸에 접근할 수 있는 에이전트는 당신이 로그를 읽는 것보다 더 빨리 기계를 손상시킬 수 있습니다.

로컬 에이전트 안전에는 네 가지 계층이 있습니다. 에이전트에 실제로 필요한 디렉토리, API, 네트워크 액세스 및 자격 증명만 부여하여 범위를 좁히세요. 샌드박스, 컨테이너, 최소 권한 사용자, 파괴적 작업에 대한 확인, 스키마 검증된 도구 인수로 실행을 제한하세요. 검색된 문서, 웹 페이지, 티켓 및 이메일에는 프롬프트 인젝션이 포함될 수 있으므로 입력을 적대적으로 취급하세요. 도구 호출, 모델 버전, 프롬프트 및 승인을 로그에 비밀을 덤프하지 않고 기록하여 감사 추적을 유지하세요.

구조화된 출력은 도움이 되지만 보안 경계는 아닙니다. JSON 스키마, 제한된 디코딩, 함수 시그니처는 도구 호출을 검증하기 쉽게 만듭니다. 모델이 요청을 이해했거나, 안전한 작업을 선택했거나, 주입된 명령을 피했음을 증명하지는 않습니다.

진지한 도구 사용을 위해 정책 검사는 모델 외부에 두세요.

RAG가 거대한 프롬프트를 이깁니다

RAG는 Retrieval-Augmented Generation을 의미합니다. 모든 정보를 프롬프트에 집어넣는 대신, 지식 베이스에서 관련 청크를 검색하여 해당 청크만 모델에 제공합니다.

좋은 로컬 RAG 시스템은 일반적으로 문서 수집, 구문 분석, 청킹, 임베딩, 벡터 인덱스, 검색, 리랭킹, 프롬프트 구성, 답변 생성, 근거 확인, 평가를 포함합니다. 각 단계는 실패 지점입니다.

잘못된 구문 분석은 표를 쓰레기로 만듭니다. 잘못된 청킹은 답변을 경계선에서 나누어 버립니다. 잘못된 검색은 관련 없는 단락을 반환합니다. 잘못된 리랭킹은 올바른 답변을 20위에 묻어버립니다. 좋은 모델이라도 받은 적 없는 증거를 바탕으로 안정적으로 답변할 수 없습니다.

대부분의 나쁜 RAG 시스템은 LLM 때문에 나쁜 것이 아닙니다. 청킹, 검색, 리랭킹, 평가 때문에 나쁩니다.

청킹 전략은 조용한 킬러입니다. 겹침 없는 고정 크기 청크는 문장을 나누고 컨텍스트를 잃을 수 있습니다. 의미론적 청킹이나 부모 문서 검색을 사용한 계층적 청킹이 종종 더 잘 작동하지만, 보편적인 답은 없습니다. 실제 문서에서 청크 크기, 겹침, 분할 규칙을 평가해야 합니다.

좋은 리랭커는 평범한 검색을 구할 수 있습니다. 수집 중에 답을 잃어버린 청크를 리랭커가 고칠 수는 없습니다.

문서 및 지식 작업

비공개 문서의 경우 로컬 LLM이 빛을 발합니다: 회의 기록 요약, 계약 검토, 기술 문서 Q&A, 연구 노트 종합, 이메일 초안 작성, 정책 검색, 내부 지원 어시스턴트, 규정 준수 워크플로 모두 소스 자료를 소유한 기계나 조직 가까이에 보관하는 이점을 누립니다.

워크플로는 간단하지만 냉혹합니다. 문서를 신중하게 구문 분석하고, 페이지 및 섹션 메타데이터를 보존하고, 의미론적으로 청킹하고, 임베딩과 리랭커를 사용하고, 인용을 요청하고, 답변을 일반 추론과 소스에서 분리하고, 인용 신뢰성을 평가하세요.

모델이 문서에 무엇이 있는지 알고 있다고 가정하지 마세요. 모델은 프롬프트에 넣거나 컨텍스트로 검색한 것만 알 수 있습니다.

회의 기록의 경우 화자 레이블과 타임스탬프를 보존하세요. 계약 검토의 경우 임의의 토큰 수 대신 조항이나 섹션별로 청킹하세요. 기술 문서 Q&A의 경우 검색된 청크에 페이지 번호나 섹션 앵커를 포함하여 모델이 출처를 정확하게 인용할 수 있도록 하세요.

문서 작업의 경우, 파서와 리트리버가 모델만큼 중요합니다.

엣지 배포

소형 모델은 점점 더 휴대폰, 노트북, 로봇, IoT 게이트웨이, 공장 장치, 차량, 의료 기기, 오프라인 현장 장비, 브라우저 앱에서 유용해지고 있습니다. 엣지는 단지 워크스테이션의 더 작은 버전이 아닙니다. 다른 제약 조건 세트가 있습니다.

에지 배포는 낮은 메모리, 낮은 전력, 열 제한, 간헐적 연결, 개인정보 보호 요구사항, 실시간 지연 시간, 작은 컨텍스트 윈도우, 예측 가능한 폴백 동작에 의해 좌우됩니다. 이러한 기기에서는 작고 신뢰할 수 있는 모델이 크고 깨지기 쉬운 모델보다 낫습니다.

실용적인 에지 설정은 종종 0.5B 에서 4B 모델, 공격적인 가중치 양자화, 작은 프롬프트, 고정된 스키마, 도구 지원 워크플로우, 로컬 임베딩, 캐싱을 사용하며 불필요한 채팅 기록은 없습니다.

연결이 끊어졌을 때, 계속 작동하는 로컬 모델이 실패하는 더 큰 모델보다 더 가치 있습니다. 로컬 AI 의 미래는 거대한 워크스테이션 모델만이 아닙니다. 데이터 가까이에서 유용한 작업을 수행하는 작은 모델도 포함합니다.

로컬 LLM 런북

로컬 모델을 실제 작업에 신뢰하기 전 최종 관문으로 사용하세요.

선택 및 적용: 작업에 적합한 모델군을 선택하고, 라이선스를 읽고, 하드웨어 요구 사항을 확인하고, 양자화 수준을 선택하고, 전체 메모리 사용량을 추정하세요. 가중치 크기에서 멈추지 마세요. KV 캐시, 런타임 오버헤드, 배치/동시성, 안전 여유를 포함하세요.

로드 및 포맷: 신뢰할 수 있는 출처의 safetensors 또는 GGUF 를 선호하고, 신뢰할 수 없는 pickle 기반 파일을 피하며, 토크나이저와 채팅 템플릿을 확인하고, 컨텍스트 길이를 의도적으로 설정하고, 작업에 맞는 디코딩 매개변수를 선택하세요. 템플릿이 잘못되면 평가가 무효화됩니다.

평가 및 운영: 대표적인 프롬프트로 테스트하고, 첫 토큰까지의 시간과 디코딩 속도를 측정하고, 최대 메모리를 추적하고, RAG 를 추가하기 전에 검색을 평가하고, 에이전트를 추가하기 전에 도구를 샌드박스 처리하며, 더 간단한 방법이 실패한 후에만 미세 조정하세요.

중요한 모든 것을 버전 관리하세요: 모델, 양자화, 런타임, 프롬프트, 채팅 템플릿, 어댑터, 임베딩 모델, 리랭커, 평가 세트, 하드웨어 프로필. 로컬 시스템은 실행한 내용을 재현할 수 있을 때만 제어하기 쉽습니다.

파인 튜닝

파인 튜닝은 추가 데이터로 학습하여 모델 동작을 변경합니다. 로컬 사용자에게 가장 중요한 방법은 LoRA 와 QLoRA 입니다.

LoRA 는 기본 모델을 고정하고 작은 저랭크 어댑터 가중치를 학습시킵니다. 이를 통해 학습 가능한 매개변수를 줄이고 여러 개의 가벼운 어댑터를 유지할 수 있습니다. QLoRA 는 이를 확장하여 고정된 4비트 양자화 모델을 통해 LoRA 어댑터로 파인 튜닝합니다.

일관된 글쓰기 스타일, 도메인별 출력 형식, 반복적인 분류 또는 추출 동작, 도구 호출 형식 신뢰성, 특화된 어시스턴트 페르소나, RAG 로 해결할 수 없는 도메인 적응, 또는 좁은 작업에서 더 나은 소형 모델 성능이 필요할 때 파인 튜닝하세요.

먼저 파인 튜닝하지 마세요. 다음 순서를 시도하세요: 올바른 채팅 템플릿, 더 나은 프롬프팅, 더 나은 모델, 더 나은 디코딩, RAG, 리랭킹, 퓨샷 예제, 그다음 파인 튜닝.

모델이 내 도메인을 이해하지 못하는 것처럼 보이는 대부분의 문제는 실제로 내 프롬프트가 모호하거나, 템플릿이 잘못되었거나, 검색이 고장난 경우입니다.

좋은 파인 튜닝 계획에는 깨끗한 데이터, 학습/검증/테스트 분할, 기준 평가, 명확한 목표 동작, 안전 검토, 과적합 확인, 회귀 평가, 어댑터 버전 관리, 라이선스 검토, 롤백 계획이 포함됩니다.

오픈웨이트가 오픈소스를 의미하지는 않습니다

2026 년, '오픈 모델'이라는 표현은 종종 부정확하게 사용됩니다. 오픈웨이트, 소스 이용 가능, 오픈소스, 로컬 호환성을 구분해야 합니다.

오픈웨이트는 일반적으로 가중치를 다운로드할 수 있음을 의미합니다. 상업적으로 사용할 수 있거나, 자유롭게 수정할 수 있거나, 출력으로 학습할 수 있거나, 모든 규모로 배포할 수 있거나, 저작자 표시 요구 사항을 무시할 수 있다는 것을 자동으로 의미하지는 않습니다.

소스 이용 가능은 코드나 가중치를 볼 수 있음을 의미합니다. 반드시 라이선스가 오픈소스라는 뜻은 아닙니다.

오픈소스 AI 모델은 더 강력한 주장입니다. OSI 의 오픈소스 AI 정의는 AI 시스템이 아키텍처, 매개변수/가중치, 추론 코드, 그리고 매개변수를 도출하는 데 사용된 충분한 데이터 정보와 코드를 포함한다고 봅니다. 이는 가중치가 Hugging Face 에 있는 것보다 훨씬 높은 기준입니다.

일부 라이선스는 허용적으로 보이지만 제한 사항이 포함되어 있습니다: 경쟁적 사용 금지, 출력에 대한 학습 금지, 특정 규모 이상 배포 금지, 지리적 제외, 저작자 표시 요구 사항, 특허 조항, 또는 파생물에 대한 카피레프트와 유사한 의무 등.

규칙: 모델을 상업적으로 사용하기 전에 모델 카드와 라이선스를 읽으세요. 모델이 훌륭하고, 다운로드 가능하며, 로컬에서 실행 가능하더라도 법적 또는 배포 제약 조건에 맞지 않을 수 있습니다.

용어집

모델 및 튜닝 용어

Active Parameters: MoE 모델에서 특정 토큰에 대해 일부 매개변수만 사용됩니다. 모델은 수천억 개의 전체 매개변수를 가질 수 있지만 토큰당 활성 매개변수는 훨씬 적습니다.
Adapter: 기본 모델에 추가되는 작은 학습 가능한 모듈로, 종종 LoRA 를 통해 구현됩니다.
Base Model: 채팅이나 명령 수행에 특별히 튜닝되지 않은 사전 학습된 모델입니다.
Fine-Tuning: 대상 도메인이나 출력 스타일에 맞게 모델 동작을 변경하는 추가 학습입니다.
Instruct Model: 명령을 따르도록 튜닝된 모델입니다.
LoRA / QLoRA: 저랭크 어댑터를 사용하는 효율적인 파인 튜닝 방법으로, QLoRA 는 양자화된 기본 모델을 통해 학습합니다.
MoE: Mixture of Experts. 토큰별로 선택된 전문가 하위 네트워크만 활성화되는 희소 아키텍처입니다.
Weights / Parameters: 모델 내부의 학습된 수치 값입니다.

추론 메커니즘

BOS / EOS: 시퀀스 시작 및 종료 토큰입니다.
Chat Template: 시스템, 사용자, 어시스턴트, 도구 메시지를 표현하는 데 사용되는 포맷입니다.
Context Window: 모델이 한 번에 처리할 수 있는 최대 토큰 수입니다.
Decode: 모델이 새로운 토큰을 하나씩 생성하는 단계입니다.
DFlash: 2026 년의 추측 디코딩 접근 방식으로, 블록 확산을 사용한 병렬 초안 작성을 활용합니다.
DDTree / DTree: 블록 확산 분포에서 초안 트리를 구축하고 효율적으로 검증하는 추측 디코딩 방법입니다.
GQA / MQA: KV 캐시 크기를 줄이고 추론 효율성을 개선하는 어텐션 변형입니다.
Inference: 모델을 실행하여 출력을 생성하는 과정입니다.
KV Cache: 이전 토큰에 대한 저장된 키/값 어텐션 상태입니다.
Prefill: 모델이 생성 전에 입력 프롬프트를 처리하는 단계입니다.
RoPE: Rotary Position Embeddings, 최신 LLM 에서 흔히 사용되는 위치 인코딩 방법입니다.
Speculative Decoding: 더 저렴한 초안자가 토큰을 제안하고 대상 모델이 이를 검증하는 속도 기술입니다.
Tokenizer: 텍스트를 토큰 ID 로 변환하고 다시 변환하는 구성 요소입니다.
Top-p / Top-k / Temperature: 토큰 생성을 위한 샘플링 제어입니다.

검색, 파일 및 서빙

AWQ: 활성화 인식 가중치 양자화입니다.
Embedding Model: 텍스트를 벡터로 변환하여 검색/추출에 사용하는 모델입니다.
FP8 KV Cache: 일부 런타임에서 지원되는 실용적인 8비트 KV 캐시 압축 모드입니다.
GGUF: llama.cpp 에서 많이 사용되는 모델 파일 형식입니다.
PagedAttention: vLLM 스타일 서빙에서 사용되는 KV 캐시 메모리 관리 기술입니다.
Quantization: 메모리를 절약하고 효율성을 개선하기 위해 수치 정밀도를 낮추는 것입니다.
RAG: Retrieval-Augmented Generation. 관련 외부 컨텍스트를 검색하여 모델에 제공합니다.
Reranker: 검색된 구절을 관련성에 따라 재정렬하는 모델입니다.
Safetensors: pickle 기반 실행 위험을 피하는 더 안전한 텐서 직렬화 형식입니다.

마무리

로컬 LLM 생태계에는 소형 에지 모델, 강력한 7B~32B 소비자 모델, 대형 MoE 오픈웨이트 시스템, 멀티모달 모델, 장기 컨텍스트 모델, 로컬 추론 모델, 성숙한 추론 런타임, 점점 더 강력해지는 비공개 서빙 스택이 포함됩니다.

그러나 기본 원칙은 변하지 않았습니다: 모델은 한 번에 하나의 토큰을 예측하고, 토큰은 단어가 아니며, 가중치가 모델 전체가 아니고, 채팅 템플릿이 중요하며, KV 캐시는 숨겨진 메모리 비용이고, 양자화는 트레이드오프이며, 긴 컨텍스트는 공짜가 아니고, RAG 품질은 검색에 달려 있으며, 파인 튜닝에는 평가가 필요하고, 로컬 개인정보 보호는 여전히 보안 규율을 요구합니다.

로컬 모델을 잘 실행하기 위해 신화가 필요하지 않습니다. 메모리에 무엇이 들어맞는지, 모델이 어떤 템플릿을 기대하는지, 런타임이 어떻게 동작하는지, 평가가 관심 있는 작업과 일치하는지 알아야 합니다.

로컬 LLM 은 주로 메모리 계산에 포맷팅과 평가를 더한 것입니다. 이것들을 올바르게 하면 나머지 스택에 대해 추론하기가 훨씬 쉬워집니다.

다음에 또 만나요.

-Ahmad