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

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

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

두 가지 비용이 결과를 결정합니다. 가중치는 매개변수 개수와 양자화에 의해 결정되는 고정 비용입니다. 컨텍스트 윈도우는 실행 비용이며, 어제 로드되었던 모델이 오늘 로드되지 않을 때 사람들이 뒤늦게 깨닫는 요소입니다.

모델 크기 산정: 파라미터당 비트 수

모델 파일은 거의 대부분 가중치(weights)로 구성됩니다. 각 가중치는 특정 비트 수로 저장됩니다. 양자화(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비트 미만으로 내려가면 품질 저하가 급격히 커지므로, 동일 세대의 32B 모델(4비트)보다 70B 모델을 2비트로 압축한 결과가 더 나쁜 답변을 내놓는 경우가 많습니다. 메모리가 부족할 때는 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비트로 양자화하면 캐시 크기를 절반으로 줄일 수 있으나, 긴 컨텍스트에 대한 기억력(recall)이 다소 저하될 수 있습니다.

상주 모델은 언로드되기 전까지 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비트 32B 모델과 달리 70B 모델은 약 42 GB가 필요하므로, 캐시를 추가하기 전부터 이미 64 GB 메모리가 필요합니다.

다음으로 속도를 냉정하게 고려해야 합니다. CPU에서 32B 모델은 초당 0.6에서 1.5 토큰을 생성하며, 70B 모델은 초당 0.2에서 0.5 토큰을 생성합니다. 70B 모델에서 500 토큰 분량의 답변을 얻으려면 약 20분이 소요됩니다. 이 속도로는 모델이 답변을 완료하기 전에 요청이 중단되는 경우가 많습니다. Ollama 앞단에 있는 클라이언트나 프록시의 타임아웃이 먼저 발생하기 때문이며, 이것이 바로 컨텍스트 마감 시간 초과 오류가 발생하는 원인입니다. 이러한 모델은 배치 작업용 도구입니다. 밤사이에 문서 큐를 처리하도록 설정한다면 속도는 문제가 되지 않습니다. 하지만 채팅창 뒤에 배치한다면 속도는 매우 중요한 요소가 됩니다.

Mixture of Experts(MoE) 라우팅은 이러한 연산 방식을 변화시키며, 반드시 알아두어야 할 아키텍처 세부 사항입니다. MoE 모델은 각 토큰을 가중치의 일부 경로로만 전달합니다. 전체 파라미터가 30B이고 토큰당 활성 파라미터가 3B인 모델은 30B 모델만큼의 메모리를 필요로 하지만, 각 토큰이 활성 전문가만 읽기 때문에 3B 밀집 모델과 비슷한 속도로 생성합니다. 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 스틸 타임 때문입니다.

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

GPU를 추가할 때 변경되는 사항

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

• 8 GB VRAM: 4 bit 양자화된 7B 또는 8B 모델을 짧은 컨텍스트로 구동 가능합니다.
• 16 GB VRAM: 4 bit 양자화된 14B 모델을 실제 컨텍스트로 구동하거나, 8 bit 양자화된 8B 모델을 구동 가능합니다.
• 24 GB VRAM: 4 bit 양자화된 32B 모델을 짧은 컨텍스트로 구동 가능합니다.
• 48 GB 이상: 4 bit 양자화된 70B 모델을 캐시 및 동시성 여유를 두고 구동 가능합니다.

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

동시성(concurrency) 또한 용량을 늘려야 하는 이유입니다. 가중치(weights)는 동시 요청 간에 공유되지만, 활성화된 각 요청은 고유한 KV 캐시가 필요합니다. 따라서 8k 컨텍스트의 8B 모델을 10명의 사용자가 동시에 사용할 경우, 가중치 외에도 1 GB의 캐시가 10배 필요합니다. 자체 호스팅 모델로 동시 사용자 서비스하기에서 해당 한계점에 도달하는 과정을 다룹니다.

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

직접 호스팅할 수 없는 것

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

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

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

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

선택하기 전에 현재 상태 확인하기

free -h
nproc
lscpu | grep 'Model name'

모델 크기 산정 방법

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

FAQ

8B 모델을 실행하려면 RAM이 얼마나 필요한가요?

4비트 양자화 모델 가중치에 약 4.8 GB가 필요하며, 여기에 컨텍스트 길이에 따른 KV 캐시, 그리고 운영체제와 모델 서버 구동을 위한 약 1 GB의 RAM이 추가로 필요합니다. 8192 토큰 컨텍스트에서는 캐시가 약 1 GB를 차지하므로 8 GB 플랜은 가능하지만 4 GB 플랜은 부족합니다. 모델 카드에서 명시하는 128k 컨텍스트 전체를 사용하려면 캐시만 16 GB가 필요하므로 32 GB 플랜을 고려해야 합니다.

VPS의 vCPU가 충분한데도 모델이 느린 이유는 무엇인가요?

생성 속도는 코어 수가 아니라 메모리 대역폭에 의해 제한되기 때문입니다. 토큰 하나를 생성할 때마다 전체 가중치 세트를 RAM에서 불러와야 하므로, 메모리 채널이 몇 개의 코어만으로도 포화 상태에 이르면 나머지 코어는 대기하게 됩니다. 또 다른 흔한 원인은 스왑입니다. 모델이 응답하는 동안 vmstat 1 명령에서 si와 so 값이 0이 아니라면, 가중치가 RAM에 다 올라가지 못해 디스크에서 데이터를 읽어오고 있는 것입니다. 이는 예상보다 훨씬 큰 성능 저하를 유발합니다.

컨텍스트 윈도우가 길어지면 정말 메모리가 더 많이 필요한가요?

네, 토큰 수에 비례하여 선형적으로 증가합니다. 일반적인 8B 모델은 토큰당 약 128 KiB의 KV 캐시를 사용하므로, 8192 토큰에는 1 GB가, 131072 토큰에는 16 GB가 필요합니다. 캐시는 대화가 길어질 때가 아니라 모델이 로드될 때 미리 할당됩니다. 따라서 128k 컨텍스트를 설정하면 실제 프롬프트가 200 토큰에 불과하더라도 해당 메모리를 즉시 점유하게 됩니다.

큰 모델을 2비트로 돌리는 것과 작은 모델을 4비트로 돌리는 것 중 무엇이 나은가요?

작은 모델을 4비트로 사용하는 것이 좋습니다. 모델 품질은 8비트에서 4비트까지는 서서히 떨어지지만 4비트 미만에서는 급격히 저하됩니다. 따라서 70B 모델을 2비트로 압축하는 것보다 같은 세대의 32B 모델을 4비트로 사용하는 것이 보통 더 나은 답변을 제공합니다. 과도한 양자화는 오류 메시지 대신 반복적인 답변이나 지시 사항 무시로 나타나기 때문에, 사용자는 이를 프롬프트 문제로 오해하기 쉽습니다. 4비트를 하한선으로 정하고 모델의 파라미터 크기를 조절하십시오.

상용 대형 모델만큼 성능이 좋은 모델을 직접 호스팅할 수 있나요?

일반적인 VPS에서는 불가능합니다. 가장 강력한 오픈 웨이트 모델은 수천억 개의 파라미터를 가지며, 4비트 양자화 시 KV 캐시를 제외하고도 200 GB 이상의 RAM이 필요합니다. 또한 가장 강력한 상용 모델은 아예 배포되지 않습니다. 일반적인 하드웨어는 특정 작업을 수행하는 8B~32B 모델을 실행하는 데 적합하며, 잘 설계된 프롬프트를 사용하는 소형 모델은 범용 모델과 대등한 성능을 내기도 합니다. 최상위 수준의 품질이 필요하다면 하드웨어를 구매하기 전에 API 비용과 하드웨어 비용을 비교해 보십시오.