모델 파일은 메모리에 들어갈 것 같은데, 실제 실행에 필요한 메모리까지는 알기 어렵습니다.
판정: 먼저 양자화 가중치와 컨텍스트, 실행 환경을 합산해 피크 메모리를 측정하세요. CPU-only는 테스트와 낮은 빈도의 추론, 배치 작업에는 검토할 수 있지만, 높은 처리량이나 동시 요청이 목표라면 큰 메모리만으로 GPU를 대신할 수 없습니다.
이 글은 Qwen3.5 CPU-only 배포를 검토하는 개발자와 소규모 팀을 위한 안내입니다.
모델 크기만 보지 않고 실제 피크 사용량과 작업 요구를 확인해 서버 메모리를 선택합니다.
마지막 업데이트: 2026년 10월 24일. Qwen3.5 공식 저장소와 Ollama 모델 목록을 기준으로 확인했습니다. 모델 태그와 파일 정보는 바뀔 수 있으므로 배포 시점에 다시 확인해야 합니다.
Qwen3.5 CPU 배포 메모리 산정 순서
양자화 모델의 파일 크기는 첫 번째 지표일 뿐입니다. 모델을 불러올 때 필요한 런타임 메모리에는 가중치 외에 컨텍스트 캐시, 실행 프레임워크의 오버헤드, 운영체제와 함께 실행하는 서비스가 포함됩니다. 따라서 파일 하나의 크기를 곧바로 서버의 최소 메모리로 보면 안 됩니다.
Qwen3.5의 공식 저장소에는 릴리스와 모델 관련 정보가 기록되어 있습니다. 실제 배포에서는 사용할 모델 변형과 라이선스, 지원하는 입력 유형을 먼저 공식 저장소에서 확인하세요. 실행 도구를 Ollama로 정했다면 현재 제공되는 태그와 파일 정보를 모델 목록에서 확인해야 합니다. 이름이 비슷해도 태그와 양자화가 다르면 필요한 자원이 달라집니다.
기본 산정은 다음과 같이 시작합니다.
- 가중치의 이론상 바이트 수 = 파라미터 수 × 양자화 비트 수 ÷ 8
- 여기에 컨텍스트 캐시와 추론 런타임의 추가 사용량을 더합니다.
- 마지막으로 운영체제, 컨테이너, 애플리케이션과 벡터 검색 서비스의 메모리를 합산합니다.
첫 번째 줄은 계산의 출발점이지 실제 실행 메모리의 보증값이 아닙니다. 모델 파일의 실제 크기와 로딩 후 최대 메모리를 확인하고, 같은 양자화라도 프레임워크와 설정에 따라 결과가 달라질 수 있음을 반영해야 합니다.
양자화 모델 파일과 실제 실행 메모리의 차이
같지 않습니다. 파일 크기는 가중치의 저장량을 보여주지만, 요청을 처리하는 동안 필요한 메모리 전체를 나타내지는 않습니다. 모델을 로드할 때 쓰는 버퍼와 런타임 구성도 더해질 수 있습니다. 특히 컨테이너에 메모리 제한을 걸어 둔 경우에는 서버 전체에 여유가 있어도 컨테이너가 먼저 제한에 닿을 수 있습니다. Docker의 컨테이너 메모리 제한 안내를 확인하고, 컨테이너 제한과 서버의 실제 여유 공간을 따로 기록하세요.
첫 단계: 사용할 모델 파일을 고정합니다
공식 모델 페이지에서 실제 사용할 태그와 양자화 파일을 정합니다. 파일 크기만 기록하지 말고 파라미터 수와 양자화 방식도 함께 남기세요. 배포 후 다른 파일로 바꾸면 기존 메모리 추정은 다시 검토해야 합니다. 라이선스와 모델 종류도 선택한 항목의 문서에서 확인합니다.
다음 단계: 목표 입력으로 피크를 측정합니다
실제 서비스에서 사용할 프롬프트와 목표 컨텍스트 길이로 모델을 실행합니다. 짧은 입력만 시험하면 긴 입력에서 나타나는 사용량 증가를 놓칠 수 있습니다. 단일 요청과 예상하는 동시 요청 조건을 각각 시험하고, 모델이 로드된 뒤 응답을 생성하는 동안의 최대 사용량을 기록합니다.
리눅스에서는 /proc 정보를 사용해 프로세스와 시스템 상태를 확인할 수 있습니다. 커널 문서의 /proc 설명을 참고해 관측 지점을 정하세요. 컨테이너 내부 수치만 볼 때는 호스트 전체의 여유 메모리와 구분해서 기록해야 합니다.
컨텍스트 길이에 따른 메모리 변화
컨텍스트가 커지면 모델이 입력과 생성 내용을 처리하는 데 쓰는 캐시도 달라질 수 있습니다. 다만 증가량은 모델 구조와 실행 프레임워크, 설정에 따라 달라지므로 일괄적인 추가 용량으로 단정할 수 없습니다. 여러 요청을 동시에 처리하면 요청별 상태가 겹쳐 메모리 사용량이 늘어날 수도 있습니다. 이미지나 다른 유형의 입력을 쓰는 경우에는 해당 입력 경로까지 포함해 시험해야 합니다.
따라서 다음 조건을 나눠 측정합니다.
- 서비스에서 허용할 입력 길이와 생성 길이
- 동시에 처리하도록 설정할 요청 수
- 텍스트 외 입력을 실제로 사용할지 여부
- 모델 로드 직후와 요청 처리 중의 메모리 변화
llama.cpp 서버 문서처럼 선택한 실행 도구의 서버 설정을 확인하고, 실제 배포 옵션으로 측정하세요. 모델 파일을 다른 태그로 바꾸거나 동시 요청 설정을 바꾼 뒤에는 피크 측정을 다시 해야 합니다.
CPU-only 추론에 적합한 작업 범위
모델을 메모리에 올릴 수 있는지와 응답 속도가 업무에 적합한지는 별개의 판정입니다. CPU-only 추론은 개발 단계의 기능 확인, 낮은 빈도의 내부 요청, 급하지 않은 배치 처리를 검토할 수 있습니다. 반대로 대기 시간이 엄격한 온라인 기능이나 많은 요청을 동시에 처리해야 하는 서비스는 실제 부하 시험에서 지연과 처리량이 목표에 못 미치면 CPU 서버만으로 진행하지 않는 편이 안전합니다.
서버 CPU를 볼 때는 명령어 지원도 확인해야 합니다. AMD EPYC 7543P는 Zen 3 계열이며, AMD의 공식 사양을 기준으로 실행 환경과 프레임워크 빌드가 지원하는 명령어 경로를 검토할 수 있습니다. 이 제품 구성은 AVX2까지 지원하며 AVX-512는 지원하지 않습니다. 따라서 지원되지 않는 명령어를 전제로 한 바이너리나 커널을 사용하지 않도록 배포 파일을 확인해야 합니다.
함께 실행하는 서비스의 메모리 예산
모델 외 서비스의 메모리를 빼면 실제 피크를 과소평가하기 쉽습니다. 운영체제와 컨테이너, API 또는 웹 애플리케이션, 벡터 검색 서비스가 같은 서버에서 실행된다면 각각의 상주 사용량과 부하 중 변화를 따로 측정합니다. Dify 같은 애플리케이션 플랫폼이나 데이터베이스를 함께 둔다면 모델 프로세스와 한 덩어리로 추정하지 말고 서비스별로 기록하세요.
다음 순서로 산정하면 원인을 구분하기 쉽습니다.
- 모델 없이 기본 서비스만 실행해 기준 메모리를 기록합니다.
- 모델을 로드한 뒤 같은 조건에서 증가한 사용량을 기록합니다.
- 실제 입력과 동시 요청 조건에서 전체 피크를 측정합니다.
- 컨테이너 제한에 먼저 도달했는지, 호스트 전체 메모리가 부족한지 구분합니다.
- 운영 중 필요한 여유를 남기고, 백업이나 로그 작업이 겹치는 시간대도 확인합니다.
CloudUDP의 확인된 선택지에는 128GB 또는 256GB 메모리 구성이 있습니다. 현재 서버 플랜에서 실제 제공 구성을 확인하고, 필요 용량은 모델 파일 크기가 아니라 위 측정 결과와 상주 서비스 예산으로 결정하세요. 메모리 구성은 선택 단계에서 맞춰야 하며, 배포 뒤 추가할 수 있다고 가정하면 안 됩니다.
측정 결과에 따른 서버 구성 선택
아래 체크 항목을 위에서부터 확인합니다. 모델과 모든 상주 서비스를 함께 실행한 피크 메모리를 기준으로 하며, 선택한 구성에 운영 중 변동을 감당할 여유가 남는지도 판단합니다.
- [ ] 피크 메모리와 운영 여유를 합산한 값이 128GB 안에 들어오고 CPU 응답 시간이 실제 업무에 맞습니다. 이 조건을 모두 충족하면 128GB 구성을 선택합니다.
- [ ] 128GB 안에는 여유 있게 들어오지 않지만 256GB 안에서는 필요한 여유를 확보할 수 있습니다. 이 조건이면 256GB 구성을 선택합니다.
- [ ] 256GB 구성에도 필요한 여유가 없습니다. 모델이나 동시 요청을 줄여 다시 측정하거나, 함께 실행하는 서비스를 분리합니다.
- [ ] CPU 지연이나 처리량이 업무 요구를 충족하지 못합니다. GPU 자원을 포함한 다른 실행 방안을 평가합니다. CloudUDP 구성이 GPU를 제공한다고 전제할 수 없습니다.
CloudUDP의 AMD EPYC 7543P 구성은 32코어와 64스레드이며, 메모리 구성은 128GB와 256GB로 나뉩니다. 저장장치는 NVMe 두 개를 직접 연결하는 방식이며 하드웨어 RAID가 아닙니다. 이 사양은 CPU 추론과 애플리케이션을 함께 배치할 때의 선택 조건이지, 특정 Qwen3.5 처리량이나 응답 시간을 보장하지 않습니다. 각 항목은 AMD의 사양과 현재 플랜의 구성 정보를 기준으로 확인해야 합니다.
서버에 모델과 내부 데이터를 함께 보관한다면 저장장치 구성과 별도로 백업 계획도 세우세요. 직접 연결된 디스크를 데이터 사본으로 간주해서는 안 됩니다.
배포 전 최종 판단
측정 결과가 128GB 또는 256GB 구성에 여유를 두고 들어오고, CPU 응답 시간이 실제 업무에 맞으면 독립 서버를 검토할 근거가 됩니다. 공유형 VPS는 다른 사용자의 부하가 영향을 줄 수 있고, CPU 자원과 메모리 배분이 제한될 수 있습니다. 모델 파일과 데이터를 둘 저장 공간이나 실행 환경을 원하는 방식으로 통제하기 어려운 경우도 있습니다. 이런 조건에서 장기간 일정한 자원을 사용해야 한다면, 공유형 인스턴스보다 한 대를 독점하는 CloudUDP AMD 물리 서버가 더 적합할 수 있습니다.
반대로 몇 시간만 시험하거나 부하가 매우 낮고 변동이 큰 작업이라면 공유 서버가 비용과 운영 면에서 나을 수 있습니다. 높은 추론 처리량이 필수라면 CloudUDP 구성을 GPU 대안으로 오해하지 말고, GPU 자원을 제공하는 실행 방안부터 별도로 비교하세요. 메모리 산정과 부하 시험이 끝난 뒤 CloudUDP 서버 플랜에서 현재 선택 가능한 사양을 확인하면 됩니다.
EPYC 7543P 단독 사용 물리 서버, 월 $454부터