자체 호스팅 가능한 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비트 양자화 기준 1B에서 4B 크기의 모델을 4096 토큰의 기본 컨텍스트로 실행할 수 있는 용량입니다. 2026년 8월 기준으로 이 등급에는 Llama 3.2 3B, Qwen 3 1.7B 및 4B, 그리고 소형 Gemma 및 Phi 릴리스가 포함됩니다. 이 모델들은 권장 사항이 아니라 크기 예시로 간주하십시오. 모델 이름은 몇 달마다 바뀌지만, 계산 방식은 변하지 않습니다.

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

이 등급에서 발생하는 주요 장애 유형은 스왑(swap)입니다. 모델이 메모리에 맞지 않더라도 Linux는 로드를 거부하지 않습니다. 대신 메모리 내용을 디스크로 페이징하는데, 단일 토큰을 생성할 때마다 모든 가중치를 한 번씩 읽어야 하므로 생성 속도가 토큰당 수 초 단위로 급격히 떨어집니다. 모델이 응답하는 동안 free -h 명령을 실행하여 si 및 so 열의 vmstat 1 값을 확인하십시오. 생성 중에 스왑 인(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분이 소요됩니다. 이러한 모델은 배치 처리 도구로 적합합니다. 밤새 문서 큐를 처리하도록 설정한다면 속도는 문제가 되지 않습니다. 하지만 채팅창 뒤에 배치한다면 속도는 매우 중요한 요소가 됩니다.

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비트 양자화된 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 속도에 훨씬 가깝게 떨어집니다. 의도하지 않은 분할이 발생하면 먼저 컨텍스트 길이를 줄이십시오. 보통 캐시가 용량을 초과하게 만드는 주원인입니다.

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

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

직접 호스팅할 수 없는 것

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

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

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

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

선택하기 전에 보유 자원을 확인하십시오

free -h
nproc
lscpu | grep 'Model name'

free -h의 available 열을 기준으로 계획을 세우십시오. total 열은 사용하지 마십시오. 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에서 불러와야 하므로, 몇 개의 코어가 메모리 채널을 포화시키면 나머지 코어는 대기 상태가 됩니다. 또 다른 흔한 원인은 스왑(swap)입니다. 모델이 응답하는 동안 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 비용과 하드웨어 비용을 비교해 보십시오.