자체 호스팅 가능한 AI 모델 선택 및 RAM 용량 계산법

어떤 AI 모델을 자체 호스팅할 수 있는지 결정하는 요소

어떤 AI 모델을 자체 호스팅할 수 있는지는 서버의 RAM 용량이라는 단 하나의 수치로 결정됩니다. 모델 제품군이나 프레임워크보다 중요한 것은 모델 가중치가 메모리에 여유 공간을 두고 적재될 수 있는지 여부입니다. 이 글에서는 이를 계산하는 방법을 다룹니다. 런타임 설치는 별개의 작업이며, VPS에서 Ollama를 실행하는 가이드에서 확인할 수 있습니다.

두 가지 비용이 결과를 결정합니다. 가중치는 매개변수 수와 양자화 방식에 따라 결정되는 고정 비용입니다. 컨텍스트 윈도우는 가변 비용이며, 어제 잘 작동하던 모델이 오늘 갑자기 로드되지 않을 때 사람들이 가장 흔히 간과하는 요소입니다.

파라미터당 비트 수 계산법

모델 파일은 대부분 가중치로 구성됩니다. 각 가중치는 특정 비트 수로 저장됩니다. 양자화(Quantisation)란 모델 학습 시의 정밀도보다 낮은 비트로 가중치를 저장하는 것을 의미하며, 약간의 정확도 손실을 감수하는 대신 메모리를 크게 절약합니다. 모델 크기는 이 비트 수에 따라 결정됩니다.

weights in GB = (parameters in billions x bits per weight) / 8

모델은 보통 16비트로 출시되며, 이는 10억 파라미터당 2 GB를 차지합니다. VPS에서 출시 정밀도 그대로 모델을 실행하는 경우가 거의 없는 이유가 바로 이것입니다. 다음은 실제 환경에서 접하게 될 양자화 방식과 가중치당 평균 비트 수입니다.

• Q8_0은 가중치당 약 8.5비트를 저장하며, 10억 파라미터당 약 1.1 GB입니다.
• Q6_K은 약 6.6비트를 저장하며, 10억 파라미터당 약 0.83 GB입니다.
• Q5_K_M는 약 5.7비트를 저장하며, 10억 파라미터당 약 0.71 GB입니다.
• Q4_K_M은 약 4.8비트를 저장하며, 10억 파라미터당 약 0.6 GB입니다.

계산 시 10억 파라미터당 0.6 GB를 기준으로 삼으십시오. 메모리가 제한된 환경에서는 Q4_K_M이 합리적인 기본값입니다. 대부분의 작업에서 8비트 대비 품질 저하는 적으면서 파일 크기는 거의 절반으로 줄어듭니다. 4비트 미만으로 내려가면 성능 저하가 급격히 커지므로, 70B 모델을 2비트로 압축하는 것보다 같은 세대의 32B 모델을 4비트로 사용하는 것이 보통 더 나은 답변을 제공합니다. 메모리가 부족할 때는 4비트 미만으로 낮추기보다 모델 크기 등급을 한 단계 낮추는 것이 좋습니다.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

위의 가중치 열은 10억 파라미터당 0.6 GB 규칙을 적용한 결과입니다. 실제 GGUF 파일은 임베딩 및 출력 레이어가 나머지 부분보다 높은 정밀도로 유지되기 때문에 이 수치와 몇 퍼센트 내외의 차이를 보입니다. 4비트 기준 3B 모델은 약 1.8 GB입니다. 8B 모델은 4.8 GB입니다. 32B 모델은 19.2 GB이며, 70B 모델은 42 GB입니다.

컨텍스트 길이가 모델 가중치보다 더 많은 RAM을 소모하는 이유

KV 캐시(key value cache, 모델이 현재 대화의 모든 토큰에 대해 유지하는 어텐션 상태)가 두 번째 비용 요소입니다. 이는 모델이 로드될 때 할당되며, 사용자가 요청한 컨텍스트 길이에 맞춰 크기가 결정되고, 그 길이에 비례하여 선형적으로 증가합니다.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama의 기본 컨텍스트에서 해당 8B 모델은 캐시에 0.5GB를 사용합니다. 8192 토큰에서는 1 GB를 사용합니다. 모델 카드에서 광고하는 128k 컨텍스트에서는 16 GB를 사용하는데, 이는 모델 가중치보다 3배 이상 큰 용량입니다. 70B 모델은 반대 경우입니다. 128k에서의 캐시 용량은 40 GB로, 모델 가중치보다 작습니다. 이는 그룹화된 쿼리 어텐션(grouped query attention) 덕분에 토큰당 비용이 파라미터 수만큼 빠르게 증가하지 않기 때문입니다.

Ollama의 기본 컨텍스트 길이는 CPU 전용 서버에서 4096 토큰입니다. GPU가 있는 경우 VRAM 용량에 따라 기본값을 선택합니다. 24~48 GiB 사이에서는 32k, 48 GiB 이상에서는 256k가 적용됩니다. 서버에서 OLLAMA_CONTEXT_LENGTH 변수를 사용하여 이를 높일 수 있으며, 실행 중인 모델이 실제로 적용받은 값은 ollama ps의 CONTEXT 열에서 확인할 수 있습니다. 해당 설정의 메모리 계산 방식은 num_ctx와 컨텍스트 길이에 관한 게시물에서 자세히 다룹니다.

캐시 메모리 사용량을 줄이는 방법은 두 가지가 있습니다. 모델 카드가 광고하는 컨텍스트 대신 실제로 필요한 만큼의 컨텍스트만 요청하십시오. 대부분의 채팅 및 코딩 작업은 8k에서 32k 이내로 충분합니다. 또는 캐시 자체를 8비트로 양자화하여 크기를 절반으로 줄일 수 있으나, 이 경우 긴 컨텍스트에 대한 기억 성능이 다소 저하될 수 있습니다.

상주 모델은 언로드되기 전까지 RAM을 점유합니다

Ollama는 마지막 요청 이후 5분 동안 모델을 메모리에 유지하다가 언로드합니다. 이 기본 설정은 노트북에는 적합하지만 서버에는 부적절합니다. 서버에서는 유휴 상태가 지난 후 첫 요청이 들어올 때마다 모델 로드 시간을 다시 기다려야 하기 때문입니다.

ollama ps
ollama stop qwen3:4b

ollama ps는 현재 상주 중인 모델 목록을 보여줍니다. SIZE 열은 모델이 점유 중인 메모리 양을, UNTIL 열은 만료 시점을 나타냅니다. 모델을 영구적으로 고정하려면 서비스에 OLLAMA_KEEP_ALIVE=-1를 설정하십시오. 0 값을 설정하면 응답이 완료되는 즉시 모델이 언로드됩니다.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

프롬프트를 하나 보낸 뒤 10분 후에 ollama ps을 다시 실행해 보십시오. 모델이 여전히 목록에 남아 있을 것입니다. 이것이 바로 핵심입니다. 사용 여부와 관계없이 RAM을 계속 점유하고 있기 때문입니다. 고정된 모델은 여유 자원이 아닙니다. 16 GB VPS에서 8k 컨텍스트의 8B 모델은 서비스가 실행되는 동안 약 6 GB를 점유합니다. 따라서 서버 사양을 결정할 때는 모델 단독 크기가 아니라 모델과 애플리케이션의 크기를 합산하여 산정해야 합니다. 메모리에 모델 고정하기에서 콜드 스타트 지연 시간과의 트레이드오프를 다룹니다.

4 GB VPS에서 실행 가능한 작업

운영 체제와 모델 서버를 위해 약 1 GB를 확보하면, 대략 3 GB의 여유 공간이 남습니다. 이는 4 bit 양자화 기준 1B에서 4B 크기의 모델을 4096 토큰의 기본 컨텍스트로 실행할 수 있는 용량입니다. 2026년 8월 기준으로 이 등급에는 Llama 3.2 3B, Qwen 3 1.7B 및 4B, 그리고 소형 Gemma 및 Phi 릴리스가 포함됩니다. 이 모델들은 권장 사항이 아니라 크기 예시로 간주하십시오. 모델 명칭은 몇 달마다 바뀌지만 연산 원리는 변하지 않습니다.

초당 약 6에서 14 토큰의 속도를 예상하십시오. 이처럼 작은 모델은 분류, 태그 추출, 짧은 요약, 특정 문체로의 문단 재작성 등 좁은 범위의 작업에 적합합니다. 다단계 추론이나 여러 파일에 걸친 코드 작업에는 성능이 부족하며, 어떤 프롬프트를 사용하더라도 이를 해결할 수는 없습니다.

이 등급에서 발생하는 주요 장애 유형은 스왑(swap)입니다. 모델이 메모리에 맞지 않더라도 Linux는 로드를 거부하지 않습니다. 대신 메모리를 디스크로 페이징 처리하는데, 단일 토큰을 생성할 때마다 모든 가중치를 한 번씩 읽어야 하므로 생성 속도가 토큰당 수 초 단위로 급격히 떨어집니다. 모델이 응답하는 동안 free -h을 모니터링하고 vmstat 1의 si 및 so 열을 확인하십시오. 생성 중에 스왑 인(swap in)과 스왑 아웃(swap out) 값이 0이 아니라면 해당 모델은 현재 플랜의 사양보다 너무 큰 것입니다.

8 GB에서 16 GB VPS에서 실행 가능한 작업

이 정도 사양부터는 자가 호스팅 모델이 실질적으로 유용해집니다. 8 GB RAM에서는 4비트 양자화된 7B 또는 8B 모델을 실행할 수 있으며, 이는 약 4.8 GB의 가중치를 차지하고 8k 컨텍스트를 지원합니다. 16 GB RAM에서는 4비트 양자화된 13B 또는 14B 모델(약 8.4 GB)을 실행하거나, 매개변수 수보다 정밀도가 중요하다면 8B 모델을 8비트로 실행할 수 있습니다.

문제는 속도입니다. CPU에서 8B 모델을 실행하면 초당 약 3에서 7 토큰이 생성되며, 14B 모델은 약 1.5에서 3.5 토큰이 생성됩니다. 사람이 읽는 속도가 초당 약 5에서 10 토큰임을 고려하면, CPU 기반 VPS에서 8B 모델을 사용하는 것은 느린 타이피스트가 글을 쓰는 것을 지켜보는 것과 같습니다. 이는 백그라운드 작업에는 적합하지만, 대화형 채팅 용도로는 피로감을 줄 수 있습니다. VPS에서 측정한 Qwen 3 8B 이상 모델의 실행 결과를 통해 실제 성능을 확인할 수 있습니다.

32 GB에서 64 GB VPS에서 실행 가능한 작업

4비트 양자화된 32B 모델은 약 19.2 GB를 차지하므로, 짧은 컨텍스트를 사용할 경우 32 GB 플랜에서 실행할 수 있으며 48 GB나 64 GB 환경에서는 여유롭게 동작합니다. 4비트 70B 모델은 약 42 GB를 차지하므로, 캐시를 추가하기 전에도 최소 64 GB의 메모리가 필요합니다.

그다음에는 속도를 있는 그대로 평가해야 한다. CPU에서 32B 모델은 초당 약 0.6~1.5 토큰을 생성하고, 70B 모델은 초당 0.2~0.5 토큰을 생성한다. 따라서 70B 모델이 500 토큰으로 답변하려면 약 20분이 걸린다. 이 속도에서는 모델이 답변을 끝내기 전에 요청이 보통 종료된다. Ollama 앞에 있는 클라이언트나 프록시의 timeout이 먼저 발생하기 때문이다. 이때 context deadline exceeded 오류가 발생한다. 이러한 도구는 batch 작업에 적합하다. 밤새 문서 대기열을 처리하게 두면 속도는 중요하지 않다. 반면 chat 창 뒤에 연결하면 속도가 매우 중요하다.

Mixture of experts(MoE) 라우팅은 이러한 계산 방식을 변화시키며, 반드시 알아두어야 할 아키텍처 세부 사항입니다. MoE 모델은 각 토큰을 전체 가중치의 일부만 통과시킵니다. 총 파라미터가 30B이고 토큰당 활성 파라미터가 3B인 모델은 30B 모델 수준의 메모리가 필요하지만, 각 토큰이 활성 전문가만 읽기 때문에 3B 밀집(dense) 모델에 가까운 속도로 생성합니다. 32 GB 서버에서는 이러한 형태의 MoE 모델이 밀집 30B 모델보다 훨씬 유용합니다. 기억해야 할 규칙은 다음과 같습니다. 총 파라미터는 메모리 요구량을 결정하고, 활성 파라미터는 속도를 결정합니다.

CPU 추론 속도는 실제로 어느 정도입니까?

토큰 하나를 생성하려면 활성화된 모든 가중치를 메모리에서 한 번 읽어야 합니다. 이를 피할 방법은 없으므로 CPU의 생성 속도는 코어 수가 아니라 메모리 대역폭에 의해 결정됩니다. 최대 속도는 가용 메모리 대역폭을 가중치 크기(바이트 단위)로 나눈 값입니다. 소규모 공유 VPS는 vCPU를 통해 현실적으로 초당 10~25 GB의 대역폭을 제공하므로, 4.8 GB 모델의 경우 초당 약 2~5 토큰 정도가 한계입니다.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

위 수치는 일반적인 VPS 하드웨어에서 흔히 보고되는 범위이며, 특정 장비의 벤치마크 결과가 아닙니다. 실제 수치는 메모리 세대, 호스트의 채널 수, 그리고 자원을 공유하는 이웃 인스턴스의 수에 따라 달라집니다. 이미 보유한 모델 태그를 사용하여 직접 측정해 보십시오.

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

답변 생성 후 출력되는 요약 정보는 eval rate: ... tokens/s라는 줄로 끝납니다. 이 값이 귀하의 생성 속도입니다. 세션의 첫 번째 실행 결과는 무시하십시오. 동일한 요약 정보에 포함된 load duration은 디스크에서 가중치를 읽어오는 시간을 포함하기 때문입니다. 토큰당 초당 속도를 올바르게 측정하는 방법에서 비교 가능한 수치를 얻는 방법을 다룹니다.

여기서 두 가지 결과가 사용자들을 놀라게 합니다. vCPU를 추가해도 성능 향상은 금방 멈춥니다. 약 8개 코어를 넘어가면 추가된 코어들은 연산이 아니라 메모리를 기다리는 상태가 되기 때문입니다. 또한 공유 플랜에서는 같은 명령을 실행해도 시간대에 따라 결과값이 다른데, 이는 설정 오류가 아니라 노이즈 이웃으로 인한 CPU 스틸 타임 때문입니다.

프롬프트를 읽는 작업은 답변을 생성하는 작업과 다릅니다. 프롬프트 처리는 연산 집약적이므로 코어 수에 비례하여 성능이 향상되며, GPU가 가장 큰 격차를 벌리는 지점이기도 합니다. 긴 문서를 읽는 데 CPU는 수 분이 걸리지만 GPU는 수 초면 충분합니다. 이는 호스팅 중인 모델에 코딩 에이전트를 연결할 때 마주하게 되는 첫 번째 장벽입니다. 답변의 첫 토큰이 나오기 전에 매번 파일 컨텍스트와 도구 정의를 다시 전송해야 하기 때문입니다.

GPU를 추가할 때 달라지는 점

연산 방식은 변하지 않으며, 단지 연산이 수행되는 자원 풀만 달라집니다. VRAM은 엄격한 제한 요소이므로, 서버를 대여하기 전에 무엇을 수용할 수 있는지 계산해야 합니다.

• 8 GB VRAM: 4비트 양자화된 7B 또는 8B 모델을 짧은 컨텍스트로 구동 가능합니다.
• 16 GB VRAM: 4비트 14B 모델을 충분한 컨텍스트로 구동하거나, 8비트 8B 모델을 구동할 수 있습니다.
• 24 GB VRAM: 4비트 32B 모델을 짧은 컨텍스트로 구동할 수 있습니다.
• 48 GB 이상: 4비트 70B 모델을 캐시와 동시성 처리를 위한 여유 공간과 함께 구동할 수 있습니다.

모델이 VRAM에 모두 들어가지 않으면 Ollama는 이를 분할합니다. 일부 레이어는 GPU에서, 나머지는 CPU에서 처리합니다. ollama ps는 PROCESSOR 열에 78%/22% CPU/GPU와 같은 형식으로 분할 상태를 보고합니다. 이는 기능이라기보다 경고로 받아들여야 합니다. 모든 토큰이 CPU에 할당된 레이어를 거쳐야 하므로 CPU 쪽이 전체 속도를 결정합니다. 따라서 레이어의 4분의 1만 CPU에서 처리하더라도 모델은 GPU 속도가 아닌 CPU 속도에 훨씬 가깝게 동작합니다. 의도치 않은 분할이 발생하면 먼저 컨텍스트 길이를 줄이십시오. 보통 캐시가 용량을 초과하게 만드는 주원인입니다.

동시성 또한 사양을 높여야 하는 이유 중 하나입니다. 모델 가중치는 동시 요청 간에 공유되지만, 활성화된 각 요청은 고유한 KV 캐시를 필요로 합니다. 예를 들어 8B 모델을 8k 컨텍스트로 10명의 사용자가 동시에 사용할 경우, 가중치 외에도 1 GB의 캐시가 10배 필요합니다. 단일 자체 호스팅 모델로 동시 사용자 서비스하기에서 해당 한계점이 어디인지 다룹니다.

GPU 대여가 비용 효율적인지는 결국 산술적인 문제이며, 매달 실제로 생성하는 토큰의 양에 달려 있습니다. GPU VPS와 API 토큰 간의 손익분기점에서 관련 수치를 확인할 수 있습니다.

직접 호스팅할 수 없는 것

여기에는 두 가지 다른 장벽이 존재하며, 어떤 장벽에 부딪혔는지 파악하는 것이 중요합니다.

첫 번째는 폐쇄형 가중치(closed weights)입니다. 최첨단 상용 모델은 배포되지 않으므로 다운로드할 파일이 없으며, RAM을 아무리 늘려도 해결할 수 없습니다. 인터페이스, 검색 계층, 에이전트 루프, 로그 등 모델 주변의 모든 요소는 직접 호스팅할 수 있습니다. 모델 자체는 원격 API로 남습니다. Claude를 직접 호스팅할 수 있는지 여부에서 이 내용을 자세히 다룹니다.

두 번째는 너무 커서 직접 호스팅하기 어려운 오픈 가중치 모델입니다. 가장 큰 오픈 소스 릴리스는 수천억 개의 전체 파라미터를 가진 전문가 혼합(mixture of experts) 설계 방식입니다. 이 모델들에도 동일한 규칙이 적용됩니다. 4비트 양자화된 400B 파라미터 모델은 캐시를 제외하고도 가중치만 약 240 GB의 메모리가 필요합니다. 이는 전문 하드웨어가 필요한 영역이며, 이를 매달 대여하는 비용은 대부분의 사용자가 1년 동안 API 토큰에 지출하는 비용보다 훨씬 큽니다. Kimi급 모델을 직접 호스팅하는 데 필요한 것에서 실제 요구 사항을 살펴봅니다. 이와 같은 구분은 Ollama 라이브러리 내부에서도 나타나는데, GLM 5.2는 클라우드 모델로만 나열되어 있으며 실제 VPS에 다운로드할 수 있는 것은 훨씬 작은 규모의 모델입니다.

이 두 가지 사이의 솔직한 기준은 다음과 같습니다. 부하가 일정하고 데이터를 서버 외부로 유출해서는 안 될 때는 직접 호스팅하십시오. 부하가 불규칙하거나 최첨단 모델의 답변 품질이 반드시 필요한 경우에는 토큰을 구매하십시오.

선택 전 가용 자원 확인

free -h
nproc
lscpu | grep 'Model name'

free -h의 available 열을 기준으로 계획을 세우십시오. total 열은 사용하지 마십시오. total에는 시스템이 이미 사용 중인 메모리가 포함되어 있기 때문입니다. 운영 체제와 모델 서버를 위해 약 1 GB를 뺍니다. 남은 용량을 0.6으로 나누면 4비트 양자화 상태에서 수용 가능한 최대 파라미터 수(단위: 십억)를 구할 수 있습니다. 그 후 실제 필요한 컨텍스트 길이에 맞춰 KV 캐시를 뺍니다. 이렇게 계산된 결과가 최종 수치이며, 고정된 모델 목록과 달리 시간이 지나도 유효합니다.

FAQ

How much RAM do I need to run an 8B model?

About 4.8 GB for the weights at 4 bit quantisation, plus the KV cache for your context length, plus roughly 1 GB for the operating system and the model server. At an 8192 token context the cache adds about 1 GB, so an 8 GB plan works and a 4 GB plan does not. If you want the full 128k context the model card advertises, the cache alone is 16 GB and you are looking at a 32 GB plan.

Why is my model slow even though the VPS has plenty of vCPUs?

Because generation is limited by memory bandwidth, not by cores. Every token requires pulling the whole active weight set out of RAM, so once a few cores saturate the memory channels the rest just wait. The other common cause is swap. If vmstat 1 shows non zero si and so while the model is answering, the weights do not fit in RAM and part of every token is being served from disk, which costs far more than it looks like it should.

Does a longer context window really need more memory?

Yes, and the growth is linear in tokens. A typical 8B model spends about 128 KiB of KV cache per token, so 8192 tokens costs 1 GB and 131072 tokens costs 16 GB. The cache is allocated when the model loads rather than when the conversation grows, so asking for a 128k context reserves that memory immediately, even if every prompt you send is 200 tokens long.

Should I run a large model at 2 bits or a smaller one at 4 bits?

Take the smaller model at 4 bits. Quality falls slowly from 8 bits down to 4 and quickly below 4, so a 70B squeezed to 2 bits usually gives worse answers than a 32B at 4 bits from the same model generation. Heavy quantisation shows up as repetition and dropped instructions rather than as an error message, which makes it easy to blame on your prompt. Treat 4 bits as the floor and change the parameter count instead.

Can I self-host a model as capable as the big commercial ones?

Not on an ordinary VPS. The strongest open weight models run to hundreds of billions of parameters, which at 4 bits means over 200 GB of RAM before any KV cache, and the strongest commercial models are not distributed at all. What ordinary hardware does well is run a good 8B to 32B model for one specific job, where a narrow and well prompted small model often matches a general one. If you need frontier quality, price the API against the hardware before you buy either.