맥에서 Ollama를 Docker로 돌리면 GPU도 사용할 수 있을까

실행 환경에 따라 자원 접근이 달라지는 상황을 비유한 AI 생성 이미지입니다.

Mac에서 Ollama의 로컬 GPU 사용이 필요하면 네이티브 실행과 Docker Desktop 실행을 구분하고 실제 모델 배치를 확인하세요.

Mac에 GPU가 있고 Ollama도 GPU를 지원하니 Docker 안에서 실행해도 같을 것 같지만, 실행 경로가 다릅니다. macOS의 네이티브 Ollama와 Docker Desktop의 일반 Ollama 컨테이너를 같은 환경으로 보면 CPU 실행의 원인을 잘못 짚을 수 있습니다.

2026년 9월 13일 확인한 Ollama FAQ는 macOS의 Docker Desktop에서 일반 Ollama 컨테이너의 GPU 가속을 사용할 수 없다고 안내합니다. 반면 Apple M 시리즈의 네이티브 macOS 실행은 CPU와 GPU 지원 대상입니다. 이 글에서는 이 차이와 확인 순서를 설명하며, 설치·모델 다운로드·컨테이너 실행이나 GPU 성능 측정은 하지 않았습니다. Ollama Docker GPU 안내, macOS 지원 조건

컨테이너가 실행되는 곳부터 다릅니다

Docker Desktop의 Docker Engine은 가벼운 Linux 가상 머신 안에서 실행됩니다. 컨테이너가 Mac 화면에서 관리된다는 사실과 그 프로세스가 macOS 네이티브 API를 그대로 사용한다는 사실은 다릅니다. Docker Desktop의 실행 구조

Ollama의 Apple GPU 가속은 Metal API를 사용합니다. 일반 Linux 컨테이너에 같은 프로그램을 넣었다고 호스트의 Metal 경로가 자동으로 연결되는 것은 아닙니다. Ollama FAQ의 macOS Docker 제한도 GPU 전달·에뮬레이션 경로의 부재로 설명돼 있습니다. Ollama의 Metal 지원

Linux나 Windows WSL2에서 NVIDIA GPU를 연결하는 문서의 옵션을 Mac에 그대로 복사해 해결하려는 것도 적절하지 않습니다. GPU 공급자와 호스트 운영체제, 컨테이너 런타임의 지원 경로가 다릅니다. --gpus all이라는 문자열이 모든 플랫폼의 GPU를 공통으로 열어 주는 것은 아닙니다.

또한 “Mac”이라는 이름으로 하드웨어를 한 묶음으로 보지 않습니다. 문서 확인일 기준 Ollama의 macOS 안내는 Apple M 시리즈에 CPU·GPU 지원을, x86에는 CPU 전용을 표시합니다. 내 기기의 칩과 운영체제 요구사항부터 확인해야 합니다.

선택지는 전체 Docker와 전체 네이티브만 있는 것이 아닙니다

모델 추론의 GPU 사용이 필요하다면 Ollama는 Mac 호스트에서 네이티브로 실행하고, 이를 호출하는 앱의 서버 부분만 Docker에 두는 구성을 검토할 수 있습니다. 컨테이너는 API 요청을 보내고 실제 추론은 호스트의 Ollama가 수행하는 방식입니다.

가상의 예로 문서 검색 앱의 백엔드를 컨테이너에 두고, 해당 백엔드가 Mac의 Ollama에 질문을 보내는 상황을 생각할 수 있습니다. 앱의 의존성과 실행 환경은 컨테이너로 관리하면서 모델 추론은 네이티브 경로를 유지하려는 선택입니다.

이 구성에서 “앱이 Docker에 있다”는 설명은 맞지만 “Ollama가 컨테이너 안에서 Metal GPU를 쓴다”는 설명은 아닙니다. 어떤 프로세스가 모델을 로드했는지와 API를 호출한 주체를 구분해야 합니다.

반대로 CPU 전용 테스트나 컨테이너 배포 동작 확인이 목적이라면 일반 Ollama 컨테이너를 사용하는 이유가 있을 수 있습니다. GPU가 연결되지 않은 구성을 무조건 잘못된 설치라고 볼 필요는 없습니다. 필요한 처리량과 대기 시간이 그 구성으로 충족되는지 별도로 평가합니다.

localhost가 누구의 주소인지 확인합니다

컨테이너 내부의 백엔드가 localhost:11434에 요청하면 보통 그 컨테이너 자신을 가리킵니다. 호스트 Mac의 Ollama를 뜻하는 주소라고 가정하면 연결이 실패하거나 다른 서비스에 요청할 수 있습니다.

Docker Desktop은 컨테이너에서 호스트 서비스로 접근할 때 host.docker.internal이라는 이름을 안내합니다. 예시 구성에서는 컨테이너 백엔드가 http://host.docker.internal:11434를 호스트 API의 후보 주소로 사용할 수 있습니다. 컨테이너에서 호스트 서비스에 연결

다만 이름을 바꿨다는 이유만으로 연결 가능성이 검증된 것은 아닙니다. 호스트에서 실제로 서버가 실행 중인지, 해당 주소와 포트에 대한 수신 범위·방화벽·네트워크 설정이 맞는지 확인해야 합니다.

Ollama의 기본 바인딩은 127.0.0.1의 11434 포트입니다. 연결 문제를 해결하려고 무조건 모든 인터페이스로 공개하기 전에 필요한 접근 범위를 먼저 정합니다. 컨테이너 한 곳의 접근을 허용하는 일과 로컬 네트워크 전체에 추론 API를 여는 일은 다른 변경입니다. Ollama의 기본 수신 주소

여기서 말하는 호출자는 컨테이너 안의 백엔드입니다. 웹 페이지의 JavaScript가 브라우저에서 직접 Ollama를 호출한다면 요청의 출발점과 CORS 조건이 달라집니다. 프런트엔드 파일을 컨테이너에서 제공한다는 이유로 브라우저 요청도 컨테이너 내부에서 출발한다고 생각하지 않습니다.

API 연결 성공 뒤에는 실제 모델 배치를 봅니다

HTTP 응답이 온다는 사실은 서버까지 연결됐다는 증거입니다. GPU에 모델이 올라갔다는 증거는 아닙니다. 모델이 현재 메모리에 로드된 상태에서 다음 명령으로 배치를 확인할 수 있습니다.

ollama ps

이 글에서는 명령을 실행하지 않았고 실제 출력도 제시하지 않습니다. Ollama FAQ는 PROCESSOR 열로 모델이 GPU에 전부 올라갔는지, CPU 메모리에 있는지, 나뉘어 배치됐는지를 확인하도록 안내합니다. 로드된 모델의 CPU·GPU 배치

여기서 100% GPU라는 표시를 GPU 연산 장치가 지금 100% 바쁘다는 사용률로 읽으면 안 됩니다. 이 열은 모델의 배치에 관한 정보입니다. 실제 장치 사용량과 생성 속도는 다른 관측이 필요합니다.

아무 모델도 표시되지 않는다면 지금 조회한 서버에 로드된 모델이 없는지 확인합니다. 모델이 내려간 시점인지, 명령이 앱과 같은 Ollama 서버를 바라보는지부터 봅니다. 빈 목록을 바로 “GPU 미지원”으로 해석하지 않습니다.

Mac 네이티브 서버와 컨테이너 서버를 동시에 실행했다면 이 확인이 특히 중요합니다. 화면은 한 서버를 호출하고 터미널은 다른 서버를 확인할 수 있습니다. 호출 주소·프로세스·모델 식별자를 함께 맞춰야 배치 기록이 실제 요청과 연결됩니다.

Docker Model Runner의 GPU 지원과 혼동하지 않습니다

Docker 관련 문서에서 Mac의 GPU 가속을 봤다고 Ollama FAQ와 모순이라고 결론 내릴 필요는 없습니다. Docker Model Runner는 별도의 모델 실행 기능이며, macOS에서는 그 추론 엔진이 컨테이너 내부가 아닌 환경에서 실행된다고 문서가 설명합니다. Docker Model Runner의 실행 환경

해당 기능의 llama.cpp 엔진은 Apple Silicon에서 Metal 가속을 지원합니다. 이것은 Docker가 관리하는 별도 추론 경로의 지원이지 일반 ollama/ollama 컨테이너에 Metal 전달이 생겼다는 뜻은 아닙니다. Model Runner 엔진별 GPU 지원

따라서 비교 자료에서는 “Docker에서 된다”라는 표현 대신 제품 기능과 엔진, 호스트 실행 여부를 적습니다. 같은 UI에서 관리된다고 내부 구조까지 같지는 않습니다.

Ollama를 유지할지 다른 실행 기능으로 바꿀지는 API·모델 파일·설정과 운영 방식까지 비교할 별도 결정입니다. 이 글은 기능을 설치하거나 전환하지 않고 두 지원 범위를 구분하는 데 그칩니다.

느리다는 원인은 GPU 유무 하나로 끝나지 않습니다

네이티브 실행에서도 모델 크기와 양자화, 입력 길이, 생성 길이, 동시에 처리하는 요청에 따라 필요한 메모리와 시간이 달라집니다. GPU 지원 대상이라는 사실이 모든 모델을 원하는 문맥 길이로 실행할 수 있다는 보장은 아닙니다.

비교를 설계할 때는 같은 모델 파일과 같은 입력·생성 조건을 맞춥니다. 네이티브에서는 작은 모델, 컨테이너에서는 큰 모델을 실행하고 속도 차이를 전부 GPU 효과라고 해석해서는 안 됩니다.

모델을 처음 메모리에 올리는 시간과 이미 올라온 모델의 응답 시간도 나눠 봅니다. 전체 소요 시간만 한 번 재면 로딩 여부와 추론 속도가 섞일 수 있습니다. 실제 출력 토큰 수가 다른 경우에도 같은 작업이라고 가정하지 않습니다.

컨테이너 앱에서만 느리다면 호스트에서 같은 API를 호출하는 경우와 대조해 네트워크·프록시·앱 후처리를 분리합니다. 반대로 두 경로가 모두 느리다면 모델의 실제 배치와 메모리 압력, 입력 처리 조건을 확인할 차례입니다. 이 글에는 어느 경로가 몇 배 빠르다는 실측 결과가 없습니다.

연결 범위를 넓히는 변경은 별도로 검토합니다

모델을 로컬에서 실행한다는 사실과 API가 안전하게 접근 제한됐다는 사실도 다릅니다. 수신 주소나 포트 공개를 바꿀 때는 누가 접근할 수 있는지, 불필요한 외부 요청이 모델 자원을 사용할 수 있는지 확인해야 합니다.

GPU 테스트를 하려고 무분별하게 프록시나 공개 터널을 여는 것은 이 문제의 필수 단계가 아닙니다. 먼저 의도한 로컬 경로에서 서버 식별과 연결, 모델 배치를 확인하는 것으로 범위를 좁힙니다.

또한 클라우드 모델을 사용하는 설정이라면 실제 연산이 로컬 Mac에서 이루어지는지부터 확인해야 합니다. 빠른 응답을 받았다는 사실만으로 로컬 GPU를 썼다고 판단하지 않습니다. 모델과 서버의 실행 위치는 성능 비교와 데이터 처리 범위 모두에 중요합니다.

확인할 순서는 실행 위치, 연결, 배치입니다

Mac에서 Ollama의 GPU 사용을 확인하려면 먼저 일반 컨테이너인지 네이티브 실행인지 구분합니다. 컨테이너 앱이 네이티브 Ollama를 부르는 구성이라면 요청이 어디에서 출발해 어느 서버에 도착하는지 확인합니다. 그다음 같은 서버의 로드된 모델 배치를 읽습니다.

GPU가 필요한데 일반 macOS Docker 컨테이너 경로를 쓰고 있다면 옵션을 무작정 추가하기보다 네이티브 추론 경로를 검토할 때입니다. 그 경로에서도 모델과 문맥을 실제 장비 조건에 맞춰 확인해야 합니다. 이렇게 실행 위치와 요청 경로를 나누면 연결 문제를 GPU 문제로, 다른 추론 엔진의 지원을 Ollama 컨테이너의 지원으로 오해하지 않을 수 있습니다.