Ollama pull redirect target not allowed, 로컬 GGUF로 모델 만들기

레지스트리에서 모델을 못 받는 상황이 와도, 손에 있는 GGUF 파일만으로 Ollama 모델을 만들고 답을 받을 수 있는지가 이번 점검의 유일한 질문이었습니다. 다운로드 단계의 문제와 추론 단계의 문제를 갈라 놓아야 복구 경로가 보이기 때문에, Debian 13에서 다운로드 오류를 먼저 재현하고 로컬 GGUF로 create와 run, API 호출을 차례로 실행해 그 출력과 캡처를 아래에 실었습니다. 이번에는 Ollama 0.40.3의 ollama pull qwen2.5:0.5b가 redirect target not allowed로 끝났고, 같은 장비에 있던 Qwen2.5 0.5B Instruct GGUF를 Modelfile의 FROM으로 지정했습니다. 그다음 ollama create로 만든 모델이 CLI와 API에서 같은 질문에 같은 답을 하는지 보았습니다.

모델을 만들고 돌린 곳은 Debian이고, Windows 설치 요구 사항은 공식 문서에 적힌 내용으로만 설명합니다. 스크립트는 세 개입니다. 재현 스크립트는 pull 오류를 다시 일으키고, 해결 스크립트는 로컬 GGUF로 qwen-gguf-test를 만들어 CLI로 실행합니다. 점검 스크립트는 없는 모델 이름, /api/generate, num_ctx를 둔 두 번째 Modelfile을 맡습니다. 아래 코드는 모두 발췌이며, 스크립트에 설정된 작업 경로와 환경 변수를 그대로 씁니다.

먼저 실행 환경입니다. 표에는 실행 로그에 찍힌 값만 옮겼습니다. 바이너리 경로와 서버 버전을 같이 적어 둔 이유는, 나중에 다른 설치본이 섞여 들어왔는지 가려낼 기준이 필요하기 때문입니다.

항목	값	출력
OS	Debian GNU/Linux 13 (trixie)	실행 로그의 PRETTY_NAME
커널	Linux 6.12.94+ x86_64	`uname -srm`
Ollama	0.40.3	`ollama --version`와 `/api/version`
바이너리	/home/user/.local/opt/ollama-0.40.3/bin/ollama	`readlink -f`
Python	3.13.5	실행 로그
CPU	nproc 8	실행 로그
실행일	2026-10-14	`date +%F`
GGUF 바이트	491400032	`stat -L -c %s`

qwen2.5:0.5b pull이 redirect target not allowed로 멈출 때

재현 스크립트는 작업 폴더 아래에 HOME과 모델 디렉터리를 따로 두고, Ollama가 127.0.0.1:11435에서 응답하는지 본 다음 레지스트리 이름을 pull합니다. 이번 출력에서 /api/version은 {"version":"0.40.3"}을 돌려주었고, ollama --version도 ollama version is 0.40.3이었습니다. 서버가 살아 있는 상태에서 다운로드를 시도하는 셈이라, 서비스가 안 뜬 경우와 모델을 못 받은 경우를 섞지 않고 볼 수 있습니다.

getent hosts registry.ollama.com
timeout 20 ollama pull qwen2.5:0.5b

이름 조회 결과를 먼저 남기고 나서 timeout 20으로 pull을 겁니다. 출력을 보면 레지스트리 주소는 198.18.0.1, 서버 버전은 0.40.3입니다. 서비스가 멀쩡해도 리디렉트 대상 검증에서 다운로드가 끊길 수 있으니, 종료 상태까지 확인해야 합니다.

+ date +%F
2026-10-14
+ uname -srm
Linux 6.12.94+ x86_64
+ grep ^PRETTY_NAME= /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
+ nproc
8
+ curl -sS -m 5 http://127.0.0.1:11435/api/version
{"version":"0.40.3"}
+ ollama --version
ollama version is 0.40.3
+ getent hosts registry.ollama.com
198.18.0.1      registry.ollama.com
+ timeout 20 ollama pull qwen2.5:0.5b
pulling manifest ⠋ pulling manifest ⠙ pulling manifest ⠹ pulling manifest ⠸ pulling manifest ⠼ pulling manifest ⠴ pulling manifest ⠦ pulling manifest ⠧ pulling manifest ⠇ pulling manifest ⠏ pulling manifest ⠋ pulling manifest ⠙ pulling manifest ⠹ pulling manifest ⠸ pulling manifest ⠼ pulling manifest ⠴ pulling manifest ⠦ pulling manifest ⠧ pulling manifest ⠇ pulling manifest 
Error: redirect target not allowed: dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com resolves to non-public 198.18.0.1
pull_exit=1

매니페스트 진행 표시가 나온 뒤 다운로드가 끊긴 장면입니다. 오류는 리디렉트 대상이 198.18.0.1로 해석되었다고 말하고, 종료 값은 pull_exit=1입니다. 여기서 판단은 갈립니다. 문제는 모델이 아니라 다운로드 주소 쪽에 있으니, 이미 가진 GGUF를 쓰는 경로로 방향을 틀었습니다.

Ollama pull 실행 화면: ollama pull이 리디렉션 대상을 거부하고 pull_exit=1로 종료합니다 — 2026-10-14 14:30:03 KST, Debian 13 — ollama pull이 리디렉션 대상을 거부하고 pull_exit=1로 종료합니다.

getent hosts registry.ollama.com은 198.18.0.1을 돌려줍니다. pull 출력은 매니페스트 진행 표시 뒤에 다음 오류로 끝나고, 이어서 pull_exit=1입니다.

오류 문장은 Error: redirect target not allowed: dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com resolves to non-public 198.18.0.1입니다. 클라이언트는 리디렉트 대상 호스트가 비공개 주소로 풀렸다고 보고 받기를 멈춘 것입니다. 레지스트리 호스트의 조회 결과도 같은 198.18.0.1입니다. 이름이 레지스트리에 있는 모델이라도, DNS가 비공개 주소를 돌려주는 네트워크에서는 그 다음 파일까지 내려가지 않습니다.

모델 다운로드 주소가 비공개 IP로 풀리는 것이 원인

오류가 짚은 호스트는 r2.cloudflarestorage.com 아래의 이름이고, 그 이름이 비공개 주소 198.18.0.1로 풀렸다고 적혀 있습니다. 출력도 매니페스트 진행 표시 다음 바로 그 줄에서 멈춥니다. 이번 실행에서 레지스트리 이름으로 모델을 받는 길은 이 오류에서 막혔습니다.

레지스트리 이름으로 받는 방법은 이름을 그대로 지정하면 된다는 점이 편하지만, 이번 qwen2.5:0.5b pull은 redirect target not allowed로 끝났고 pull_exit=1입니다.

로컬 GGUF를 Modelfile FROM에 적고 create하기

해결 스크립트는 디스크에 있던 qwen2.5-0.5b-instruct-q4_k_m.gguf를 이 폴더의 gguf로 연결하고, stat -L -c %s로 대상 파일의 바이트를 찍습니다. 이번 값은 491400032입니다. Modelfile은 FROM 한 줄과 PARAMETER temperature 0, PARAMETER num_predict 16입니다.

ln -sfn /home/user/hands/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf "$ROOT/run/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf"
stat -L -c %s "$ROOT/run/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf"

cat > "$ROOT/run/Modelfile" << EOF
FROM $ROOT/run/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf
PARAMETER temperature 0
PARAMETER num_predict 16
EOF

ollama create qwen-gguf-test -f "$ROOT/run/Modelfile"
ollama list
ollama run qwen-gguf-test '한 문장으로만 답하세요. 2+2는?'
ollama ps
ollama show qwen-gguf-test --modelfile

순서는 원본 GGUF를 연결하고, Modelfile에 경로와 생성 옵션을 적는 것입니다. temperature 0과 num_predict 16은 이번 짧은 질문을 위한 실행 조건입니다. 아래 출력에서는 파일 크기, 모델 생성 상태, 실제 응답을 차례로 맞춰 볼 수 있습니다. 원본 파일 경로와 모델 저장 경로를 함께 보관해 두면, 서버를 옮길 때 무엇을 챙겨야 하는지 헷갈리지 않습니다.

+ date +%F
2026-10-14
+ uname -srm
Linux 6.12.94+ x86_64
+ grep ^PRETTY_NAME= /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
+ command -v ollama
/home/user/.local/bin/ollama
+ readlink -f /home/user/.local/bin/ollama
/home/user/.local/opt/ollama-0.40.3/bin/ollama
+ ollama --version
ollama version is 0.40.3
+ nproc
8
+ curl -sS -m 5 http://127.0.0.1:11435/api/version
{"version":"0.40.3"}
+ ln -sfn /home/user/hands/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf
+ stat -L -c %s gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf
491400032
+ cat > Modelfile
+ cat Modelfile
FROM /home/user/ollama/run/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf
PARAMETER temperature 0
PARAMETER num_predict 16
+ ollama create qwen-gguf-test -f Modelfile
gathering model components ⠙ gathering model components ⠹ gathering model components ⠸ gathering model components ⠸ gathering model components ⠴ gathering model components ⠦ gathering model components ⠧ gathering model components 
parsing GGUF ⠋ gathering model components 
parsing GGUF 
using existing layer sha256:74a4da8c9fdbcd15bd1f6d01d621410d31c6fc00986f5eb687824e7b93d7a9db 
using existing layer sha256:d13a100805f4f975baaad40dcac75b9803d6e9561a9e0ad471e2b125a8cc83f9 
writing manifest ⠋ gathering model components 
parsing GGUF 
using existing layer sha256:74a4da8c9fdbcd15bd1f6d01d621410d31c6fc00986f5eb687824e7b93d7a9db 
using existing layer sha256:d13a100805f4f975baaad40dcac75b9803d6e9561a9e0ad471e2b125a8cc83f9 
writing manifest 
success 
SOLVED create_status=success
+ ollama list
NAME                     ID              SIZE      MODIFIED               
qwen-gguf-test:latest    5cc36c088e88    491 MB    Less than a second ago    
qwen-gguf-ctx:latest     25cfa0104fe0    491 MB    8 minutes ago             
+ ollama run qwen-gguf-test '한 문장으로만 답하세요. 2+2는?'
⠙ ⠹ ⠸ ⠼ ⠴ ⠦ ⠧ ⠇ ⠏ ⠋ ⠙ ⠹ ⠸ ⠼ ⠴ ⠦ ⠧ ⠇ ⠏ 2+2는 4입니다.

run_exit=0
+ ollama ps
NAME                     ID              SIZE      PROCESSOR          CONTEXT    RUNNER      UNTIL              
qwen-gguf-test:latest    5cc36c088e88    595 MB    60%/40% CPU/GPU    4096       llamacpp    9 seconds from now    
+ ollama show qwen-gguf-test --modelfile
# Modelfile generated by "ollama show"
# To build a new Modelfile based on this, replace FROM with:
# FROM qwen-gguf-test:latest

FROM /home/user/ollama/run/models/blobs/sha256-74a4da8c9fdbcd15bd1f6d01d621410d31c6fc00986f5eb687824e7b93d7a9db
TEMPLATE {{ .Prompt }}
PARAMETER num_predict 16
PARAMETER temperature 0

+ ollama stop qwen-gguf-test

로컬 파일을 가져온 뒤의 생성과 실행 결과입니다. 목록상 크기는 491 MB, 실행 중 크기는 595 MB로 서로 다르게 나옵니다. 응답은 2+2는 4입니다.이고 run_exit=0으로 끝났습니다. 파일 등록에서 멈추지 않고 실제 생성 요청까지 통과했다는 점이 중요합니다. 그래서 다운로드가 막혔을 때 쓸 복구 경로로 이 방법을 택했습니다.

Ollama pull 실행 화면: 모델 생성 성공 뒤 ollama run이 2+2는 4입니다를 답합니다 — 2026-10-14 14:30:09 KST, Debian 13 — 모델 생성 성공 뒤 ollama run이 2+2는 4입니다를 답합니다.

캡처의 FROM 줄은 작업 폴더 경로를 그대로 보여 주고, 본문 Modelfile에서는 같은 줄을 /home/user/ollama로 줄여 적었습니다. 블롭 이름과 sha256 값은 같습니다.

create 출력은 writing manifest 다음에 success가 나오고, 스크립트는 SOLVED create_status=success를 찍습니다. ollama list의 qwen-gguf-test:latest SIZE는 491 MB입니다. 이 SIZE는 목록이 보여주는 모델 크기이고, stat의 491400032바이트와 칸이 다릅니다. 이어서 CLI 실행은 run_exit=0으로 끝납니다. 진행 표시 뒤의 응답 문장은 2+2는 4입니다.입니다.

ollama ps에서 같은 이름의 SIZE는 595 MB이고 CONTEXT는 4096입니다. 목록의 491 MB와 실행 중 595 MB는 서로 다른 명령의 SIZE 값입니다. UNTIL 열의 남은 시간과 MODIFIED 열의 상대 시각은 재실행마다 달라지므로 여기서 반복하지 않습니다. ollama show가 돌려준 FROM은 심볼릭 링크 경로가 아니라 models/blobs 아래의 블롭입니다. TEMPLATE은 {{ .Prompt }}이고, 넣어 둔 temperature와 num_predict는 그대로 남습니다. 모델 파일이 이 폴더의 models에 있다는 것은 그 FROM 경로로 확인합니다.

공식 import 문서의 GGUF 절에는 가져올 때 다시 양자화하지 않는다는 문장과, 단일 파일 예시 FROM /path/to/file.gguf, 명령 예시 ollama create my-model이 있습니다. 점검 스크립트가 Ollama v0.40.3의 docs/import.mdx에서 이 세 줄을 찾았고 import_found_count=3입니다. 이번 create는 그 예시처럼 단일 파일을 FROM에 적었고, 양자화 플래그는 주지 않았습니다. 문서의 예시 이름 my-model 대신 이번 실행의 이름은 qwen-gguf-test입니다.

디스크의 GGUF를 지정한 create는 success가 되고, CLI 실행도 run_exit=0으로 끝납니다. 대신 GGUF 파일을 미리 가지고 있어야 하고, show의 FROM은 원본 경로가 아니라 models 아래의 블롭을 가리킨다는 점을 기억해 둬야 합니다.

없는 이름의 manifest 오류, API 응답, num_ctx, CPU 로그

점검 스크립트는 먼저 nvidia-smi가 PATH에 있는지 보고 nvidia_smi=absent를 찍습니다. 그다음 목록에 없는 no-such-model:1b를 run합니다. 오류는 Error: pull model manifest: file does not exist이고 missing_exit=1입니다. 앞의 qwen2.5:0.5b 리디렉트 거부와 종료 값은 같아도 메시지가 가리키는 대상이 다릅니다. 하나는 다운로드 주소, 다른 하나는 존재하지 않는 모델 이름이니 둘을 같은 장애로 묶으면 안 됩니다.

timeout 20 ollama run no-such-model:1b hi

timeout 20 curl -sS -m 20 http://127.0.0.1:11435/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen-gguf-test","prompt":"한 문장으로만 답하세요. 2+2는?","stream":false,"options":{"num_predict":16,"temperature":0}}'

cat > "$ROOT/run/Modelfile.ctx" << EOF
FROM $ROOT/run/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf
PARAMETER num_ctx 1024
PARAMETER temperature 0
PARAMETER num_predict 8
EOF

ollama create qwen-gguf-ctx -f "$ROOT/run/Modelfile.ctx"
ollama show qwen-gguf-ctx --modelfile
grep -E 'inference compute|vram-based default context' "$ROOT/run/tmp/serve.log"

이 코드는 없는 이름을 불렀을 때의 오류와, 이미 등록한 모델의 API 응답을 나란히 놓고 보려고 짰습니다. API 요청은 stream을 false로 두고 생성 옵션을 함께 보냅니다. 따로 만든 Modelfile에는 num_ctx 1024를 넣어, 생성 후 설정이 저장되는지 확인합니다. 로그를 읽을 때는 응답까지 실행한 이름과 설정만 조회한 이름이 다르다는 점을 놓치지 마십시오.

+ date +%F
2026-10-14
+ python3 --version
Python 3.13.5
+ ollama --version
ollama version is 0.40.3
+ command -v nvidia-smi
nvidia_smi=absent
+ timeout 20 ollama run no-such-model:1b hi
pulling manifest ⠋ pulling manifest ⠙ pulling manifest ⠹ pulling manifest 
Error: pull model manifest: file does not exist
missing_exit=1
+ curl -fsSL -m 12 -o tmp/import.mdx https://raw.githubusercontent.com/ollama/ollama/v0.40.3/docs/import.mdx
+ curl -fsSL -m 12 -o tmp/windows.html https://docs.ollama.com/windows
+ curl -fsSL -m 12 -o tmp/linux.html https://docs.ollama.com/linux
+ curl -fsSL -m 12 -o tmp/hf.html https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF
+ python3 -
import_found_count=3
import_line=Ollama does not quantize GGUF models during import.
import_line=FROM /path/to/file.gguf
import_line=ollama create my-model
windows_found_count=5
windows_line=Ollama runs as a native Windows application, including NVIDIA and AMD Radeon GPU support.
windows_line=Windows 10 22H2 or newer, Home or Pro
windows_line=NVIDIA 551.61 or newer Drivers if you have an NVIDIA card
windows_line=AMD ROCm v7 / HIP7-capable driver stack for ROCm acceleration, or a Vulkan-capable AMD Radeon driver for Vulkan acceleration
windows_line=http://localhost:11434
linux_key=ollama-linux-amd64.tar.zst pos=1058
linux_snippet=d remove the old libraries with sudo rm -rf /usr/lib/ollama first. Download and extract the package: curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst \ | sudo tar x -C /usr Start Ollama: ollama serve In another terminal, verify that Ollama is running: ollama -v  AMD GPU install If you have an AMD GPU, also download and e
linux_key=sudo tar pos=1089
linux_snippet= sudo rm -rf /usr/lib/ollama first. Download and extract the package: curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst \ | sudo tar x -C /usr Start Ollama: ollama serve In another terminal, verify that Ollama is running: ollama -v  AMD GPU install If you have an AMD GPU, also download and extract the additional ROCm pack
hf_has_apache-2.0=true
hf_has_491400032=false
head_status=200 url=https://docs.ollama.com/import
head_status=200 url=https://docs.ollama.com/linux
head_status=200 url=https://docs.ollama.com/cli
head_status=200 url=https://docs.ollama.com/modelfile
head_status=200 url=https://docs.ollama.com/windows
head_status=200 url=https://docs.ollama.com/api-reference/get-version
head_status=200 url=https://github.com/ollama/ollama/releases/tag/v0.40.3
head_status=200 url=https://huggingface.co/Qwen/Qwen2.5-0.5B-Instruct-GGUF
head_status=200 url=https://raw.githubusercontent.com/ollama/ollama/v0.40.3/docs/import.mdx
+ cat > Modelfile.ctx
+ cat Modelfile.ctx
FROM /home/user/ollama/run/gguf/qwen2.5-0.5b-instruct-q4_k_m.gguf
PARAMETER num_ctx 1024
PARAMETER temperature 0
PARAMETER num_predict 8
+ ollama create qwen-gguf-ctx -f Modelfile.ctx
gathering model components ⠋ gathering model components ⠹ gathering model components ⠹ gathering model components ⠸ gathering model components ⠴ gathering model components 
parsing GGUF ⠋ gathering model components 
parsing GGUF ⠙ gathering model components 
parsing GGUF 
using existing layer sha256:74a4da8c9fdbcd15bd1f6d01d621410d31c6fc00986f5eb687824e7b93d7a9db 
using existing layer sha256:3f7e89c11c43843df26824cae3a251e983cb8399abbee35295d8b8d4462799a8 
writing manifest 
success 
SOLVED ctx_create_status=success
+ ollama show qwen-gguf-ctx --modelfile
# Modelfile generated by "ollama show"
# To build a new Modelfile based on this, replace FROM with:
# FROM qwen-gguf-ctx:latest

FROM /home/user/ollama/run/models/blobs/sha256-74a4da8c9fdbcd15bd1f6d01d621410d31c6fc00986f5eb687824e7b93d7a9db
TEMPLATE {{ .Prompt }}
PARAMETER num_ctx 1024
PARAMETER num_predict 8
PARAMETER temperature 0

+ curl -sS -m 20 http://127.0.0.1:11435/api/generate
api_generate_exit=0
api_done=true
api_done_reason=stop
api_model=qwen-gguf-test
api_response=2+2는 4입니다.
+ ollama ps
NAME                     ID              SIZE      PROCESSOR          CONTEXT    RUNNER      UNTIL              
qwen-gguf-test:latest    5cc36c088e88    595 MB    60%/40% CPU/GPU    4096       llamacpp    9 seconds from now    
+ grep -E 'inference compute|vram-based default context' tmp/serve.log
time=2026-10-14T14:19:15.316+09:00 level=INFO source=types.go:50 msg="inference compute" id=cpu library=cpu compute="" name=cpu description=cpu libdirs=ollama driver="" pci_id="" type="" total="15.6 GiB" available="918.3 MiB"
time=2026-10-14T14:19:15.317+09:00 level=INFO source=routes.go:2485 msg="vram-based default context" total_vram="0 B" default_num_ctx=4096
+ ollama stop qwen-gguf-test
+ ollama stop qwen-gguf-ctx

API 결과와 모델 설정 조회가 한 화면에 있습니다. API는 api_done=true와 api_done_reason=stop을 돌려주었고, 실행 모델의 CONTEXT는 4096입니다. 그런데 num_ctx 1024는 별도로 만든 다른 모델의 설정 조회 결과입니다. 한 화면에 섞여 있으니, 운영 점검 기록에도 모델 이름을 꼭 같이 남겨야 서로 다른 설정의 결과를 혼동하지 않습니다.

Ollama pull 실행 화면: API의 done=true·응답과 ps의 CONTEXT 4096을 함께 표시합니다 — 2026-10-14 14:30:17 KST, Debian 13 — API의 done=true·응답과 ps의 CONTEXT 4096을 함께 표시합니다.

같은 스크립트는 이미 만든 qwen-gguf-test에 POST /api/generate를 보냅니다. 옵션은 num_predict 16과 temperature 0입니다. 결과는 api_generate_exit=0, api_done=true, api_done_reason=stop, api_model=qwen-gguf-test입니다. api_response 줄도 2+2는 4입니다.입니다. 직후 ollama ps의 CONTEXT는 4096이고 SIZE는 595 MB입니다.

서버 로그의 inference compute 줄에서 library는 cpu이고, 다음 줄은 total_vram="0 B", default_num_ctx=4096입니다. ps의 PROCESSOR 열은 CPU와 GPU 비율을 함께 적지만, 그 비율만으로는 이 장비의 NVIDIA 가속 여부를 판단할 수 없습니다. nvidia_smi=absent이고 total_vram은 0 B이며, 로그의 id와 library도 cpu입니다. 그런데도 ps에 GPU 몫 40%가 찍히는 까닭은 CPU의 AMX 버퍼입니다. 같은 GGUF 블롭(sha256:74a4da8c…)을 쓰는 qwen2.5-0.5b-local을 2026-10-17 16:33 KST에 이 서버에서 컨텍스트 4096으로 다시 올리자 ps는 똑같이 595 MB, 60%/40% CPU/GPU를 보였고, 서버 로그에는 library=cpu와 함께 AMX model buffer size = 225.48 MiB가 찍혔습니다. 225.48 MiB는 /api/ps의 size_vram 236432916바이트와 같고, 이 값을 size 595832339로 나누면 0.397, 곧 40%입니다. 두 값이 바이트 단위로 같으므로, CPU의 AMX 연산용으로 잡힌 이 버퍼를 Ollama가 GPU 몫(size_vram)으로 집계한 것으로 판단합니다. 재실행 로그는 LLM 메모리 계산: CPU에서 잰 Q4_K_M 6.16비트와 Ollama 적재 크기 글에 실었습니다. available 용량과 로그 시각은 재실행마다 달라질 수 있어 본문에 숫자를 반복하지 않습니다. ps의 CONTEXT 4096은 로그의 default_num_ctx=4096과 같습니다. 기본 Modelfile에는 num_ctx를 적지 않았습니다.

두 번째 Modelfile Modelfile.ctx는 같은 GGUF에 PARAMETER num_ctx 1024, PARAMETER num_predict 8, PARAMETER temperature 0을 둡니다. ollama create qwen-gguf-ctx -f Modelfile.ctx는 SOLVED ctx_create_status=success로 끝납니다. 출력에는 using existing layer가 있습니다. ollama show에는 PARAMETER num_ctx 1024가 있습니다. 이 이름은 create와 show까지 수행했습니다. 한 문장 실행과 /api/generate는 qwen-gguf-test에만 했습니다.

설치 문서의 주소와 Ollama 서버가 실제로 쓰는 주소

업데이트할 때 설치 문서의 예시 주소를 헬스체크에 그대로 옮겨 적으면, 실제 서비스가 다른 주소에서 돌고 있을 때 엉뚱한 곳을 점검하게 됩니다. 기준은 실제 서비스의 접속 설정이어야 합니다. 버전 차이나 API 폐기는 이번 출력만으로 단정할 수 없으니, 변경 대응은 실제 응답과 저장된 설정을 비교하는 절차로 관리합니다. 설치본을 바꿨다면 실행 바이너리 경로와 서비스가 참조하는 경로를 다시 대조하고, CLI와 서버의 버전 응답을 같이 기록합니다. 버전 조회가 성공했다고 끝이 아닙니다. 등록된 모델에 생성 요청까지 보내야 추론할 준비가 됐는지 알 수 있습니다.

주소와 모델 저장 경로도 따져 봐야 합니다. Windows 문서에서 뽑은 주소는 http://localhost:11434인데 이번 서버 요청은 127.0.0.1:11435를 썼습니다. 헬스체크와 생성 요청이 같은 서버를 보고 있는지 맞춰야 하는 이유입니다. 모델 설정은 ollama show로 다시 읽어 보면, FROM이 원본 GGUF가 아니라 저장소의 블롭 경로를 가리킵니다. 백업과 복구 경로도 이 사실에 맞춰 정해야 합니다. 설정 파일에 적은 값과 서버가 실제로 쓴 값을 나란히 비교해 두면, 주소나 설치 경로가 바뀐 것을 모델 오류로 착각하는 일이 생기지 않습니다.

문서에서 뽑은 설치 문장

Windows 문서와 Linux 수동 설치 문장은 점검 스크립트가 받은 페이지에서 뽑은 문장입니다. Windows 페이지에서 찾은 줄은 다섯 개이고 windows_found_count=5입니다. 네이티브 Windows 애플리케이션이며 NVIDIA와 AMD Radeon GPU를 지원한다는 문장, Windows 10 22H2 or newer, Home or Pro, NVIDIA 카드가 있을 때의 드라이버 551.61, API 주소 http://localhost:11434가 거기에 있습니다.

Linux 페이지 조각에는 curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr와, 다른 터미널에서 ollama -v로 확인하라는 문장이 있습니다. 이 실습에서 실제로 쓴 파일은 command -v의 /home/user/.local/bin/ollama이고, readlink -f는 /home/user/.local/opt/ollama-0.40.3/bin/ollama를 가리킵니다. 사용자 경로의 이 바이너리로 version, create, run을 수행했습니다.

Hugging Face 모델 카드 페이지의 텍스트에는 apache-2.0이 있어 hf_has_apache-2.0=true입니다. 파일 크기는 로컬 stat -L의 491400032를 사용합니다. 아래 링크는 curl -sI 결과가 head_status=200인 주소만 둡니다. 실행일은 2026-10-14입니다.

Importing a Model. 단일 GGUF의 FROM과, import 때 다시 양자화하지 않는다는 문장입니다.
import.mdx (v0.40.3). 위에서 찾은 세 줄의 원문입니다.
Linux. 수동 설치 조각의 tar.zst와 sudo tar 문장입니다.
Windows. 요구 사항으로 뽑은 다섯 줄의 페이지입니다.
CLI Reference. 문서 페이지의 HEAD가 200이었습니다.
Modelfile Reference. 문서 페이지의 HEAD가 200이었습니다.
Get version. 이번 /api/version 응답은 0.40.3입니다.
Ollama v0.40.3 릴리스 태그. 태그 페이지의 HEAD가 200이었습니다.
Qwen2.5-0.5B-Instruct-GGUF. 페이지 텍스트에 apache-2.0이 있습니다.

이 경로에서 얻은 것은 두 가지입니다. API 호출도 CLI와 같은 모델에서 api_done=true로 끝났고, num_ctx를 둔 두 번째 이름은 기존 블롭을 재사용해 create가 success가 됩니다. 걸리는 곳도 분명합니다. 없는 이름은 매니페스트 오류로 끝나고, ps의 CPU/GPU 비율은 로그의 cpu와 total_vram 0 B와 따로 읽어야 합니다. qwen-gguf-ctx는 파라미터 확인까지만 했습니다.

이미 등록된 로컬 태그로 바로 돌려 보기, 다른 이름의 pull 실패와 verbose 측정값

GGUF로 새 모델을 만들기 전에, 서버에 이미 등록된 태그가 있다면 그 태그로 먼저 서비스 경로를 확인하는 편이 빠릅니다. 2026-10-12 17:51 KST에 GPU가 없는 Debian 13 서버(nproc 8, 메모리 15Gi, Ollama 0.40.3)에서 같은 pull 실패가 한 번 더 났습니다. 목록에는 qwen2.5-0.5b-local:latest(ID 9806541f10f4, 491 MB)만 있었고, 목록에 없던 qwen3:0.6b를 받으려 하자 아래처럼 멈췄습니다.

$ timeout 60 ollama run qwen3:0.6b 'hi'
pulling manifest
Error: redirect target not allowed: dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com resolves to non-public 198.18.0.1

모델 이름은 달라도 오류 문장은 앞에서 본 것과 같습니다. 다운로드 호스트가 비공개 대역 198.18.0.1로 풀린다는 점도 같습니다. 그래서 원인은 특정 모델이 아니라 이 서버의 DNS 해석 쪽에 있다고 봅니다. 이름을 바꿔 다시 받아 보는 시도로는 풀리지 않으니, 이미 등록된 태그로 서비스가 도는지부터 확인하는 순서가 맞습니다.

등록된 태그는 ollama run에 --verbose를 붙여 실행했습니다. 응답 아래에 로드, 프롬프트 평가, 생성 단계의 시간과 토큰 수가 함께 찍힙니다.

$ ollama run qwen2.5-0.5b-local --verbose '로컬 LLM의 장점을 한 문장으로.'
total duration:       6.961546706s
load duration:        5.839702ms
prompt eval count:    41 token(s)
prompt eval cached:   24 token(s)
prompt eval duration: 686.411ms
prompt eval rate:     24.77 tokens/s
eval count:           115 token(s)
eval duration:        6.238186s
eval rate:            18.43 tokens/s

load duration이 5.839702ms로 짧은 것은 모델이 이미 메모리에 올라와 있었기 때문입니다. 전체 6.961546706s 가운데 6.238186s가 115토큰 생성에 쓰였고, 생성 속도는 18.43 tokens/s였습니다. 프롬프트 41토큰 중 24토큰은 캐시에서 처리됐습니다. 이 값은 이 장비에서 짧은 프롬프트를 한 번 실행한 결과이므로 처리량 기준값으로 쓰지 않고, 서비스 경로가 살아 있는지 확인하는 용도로만 씁니다.

Debian 13 터미널. qwen2.5-0.5b-local --verbose의 total duration 6.961546706s, eval rate 18.43 tokens/s, 실행 후 ps. — 2026-10-12 17:51 KST, Debian 13, GPU 없음 — 이미 등록된 qwen2.5-0.5b-local 태그의 verbose 통계와 실행 직후 ps.

한 문장을 요청했지만 답은 4)와 5)까지 이어졌습니다. 작은 모델은 요청한 형식을 넘겨 쓰는 일이 있으므로, 대체 태그로 서비스를 이어 갈 때는 속도만 보지 말고 응답 길이와 형식도 함께 확인해야 합니다. 길이를 묶어 두려면 Modelfile의 num_predict로 상한을 정하는 방법이 있습니다. 실행 직후 ollama ps는 595 MB, CONTEXT 4096으로 앞의 qwen-gguf-test와 같은 컨텍스트 값을 보였습니다.

이미 등록된 태그는 다운로드가 필요 없으니 DNS가 막힌 동안에도 바로 실행되고, --verbose 한 번이면 로드, 프롬프트 평가, 생성 시간이 나뉘어 찍힙니다. 대신 등록된 모델이 원래 쓰려던 모델과 다르면 응답 형식과 품질도 달라질 수 있고, 한 번의 측정값이라 처리량 비교나 용량 산정의 근거로는 부족합니다.

레지스트리 pull 대신 로컬 GGUF로 create한 결과 비교

성공 결과가 남은 선택지만 표로 비교했습니다. 모델 생성, CLI 응답, HTTP 응답, 설정 저장은 서로 다른 점검 단계입니다. 운영 절차에 단계마다 모델 이름과 성공 상태를 남겨 두면, 장애가 어디서 났는지 빨리 좁혀 들어갈 수 있습니다.

선택	이번 명령	이번 결과
로컬 GGUF create	`ollama create qwen-gguf-test -f Modelfile`	`SOLVED create_status=success`. list SIZE는 491 MB입니다.
만든 이름으로 CLI 실행	`ollama run qwen-gguf-test '한 문장으로만 답하세요. 2+2는?'`	`run_exit=0`. 응답 문장은 `2+2는 4입니다.`입니다.
같은 모델의 HTTP 실행	`POST /api/generate`	`api_done=true`, `api_done_reason=stop`입니다.
num_ctx를 둔 두 번째 이름	`ollama create qwen-gguf-ctx -f Modelfile.ctx`	`SOLVED ctx_create_status=success`. show에 `num_ctx 1024`가 있습니다.

레지스트리 pull이 redirect target not allowed로 끝나면, 받아 둔 단일 GGUF를 Modelfile의 FROM으로 ollama create하는 쪽을 권합니다. 이번 실행에서는 그 create가 success였고, CLI run과 /api/generate가 같은 문장으로 끝났습니다. 짧은 확인이라면 qwen-gguf-test처럼 기본 컨텍스트로 만든 이름에 CLI나 API를 쓰면 됩니다.

컨텍스트를 1024로 고정하고 싶다면 qwen-gguf-ctx처럼 PARAMETER num_ctx를 둔 두 번째 이름을 만들고 ollama show로 파라미터를 확인하면 됩니다. 기본 이름의 ps CONTEXT와 서버 로그의 default_num_ctx는 이번 실행에서 둘 다 4096이었습니다. 없는 이름을 run하면 매니페스트 오류가 나므로, ollama list에 있는 이름을 지정합니다.

ps에 CPU와 GPU 비율이 함께 있어도, GPU가 없는 테스트 장비라면 서버 로그의 library=cpu와 total_vram="0 B", 그리고 nvidia_smi=absent를 함께 보고 판단합니다. Windows에 두는 설치는 공식 Windows 문서에 적힌 버전과 드라이버 문장을 기준으로 준비하면 됩니다. 이 글에서 모델을 만들고 한 문장을 실행한 환경은 Debian GNU/Linux 13과 Ollama 0.40.3입니다.

출력을 정리해 내린 결론은 이렇습니다. 다운로드가 막힌 환경에서 짧은 동작 점검을 시작하려면, 로컬 GGUF와 Modelfile을 한 묶음으로 관리하는 구성이 실용적입니다. 원본 파일과 생성 옵션을 보관하고, ollama list로 등록 이름을 확인한 다음 CLI와 API 응답을 점검하는 순서를 권합니다. 메모리 계획은 목록의 491 MB만 보고 세우면 실행 중 크기를 놓칩니다. 실행 중 595 MB와 서버 로그의 가용 메모리까지 함께 봐야 합니다. 실시간 서비스라면 응답 지연과 동시 요청을 따로 재서 필요한 CPU·메모리와 가속 구성을 정하고, 자원이 부족하면 GPU를 쓸 수 있는 서버나 별도 추론 서비스로 요청을 넘기는 대안을 검토합니다. 컨텍스트를 1024로 지정하는 구성은 저장된 설정을 확인한 뒤 실제 요청으로 검증하고, 기본 4096 구성과 무엇이 다른지 판단하는 것이 좋습니다. 이번 실행에서 성공한 CLI와 API 응답은 배포 전 점검 기준으로 삼되, 운영해도 되는지는 결국 서비스가 요구하는 응답 시간을 맞추는지로 결정합니다.