올라마 모델 기본 태그 실측 — 219개 중 196개가 4비트이고, 크기가 여럿인 97개 중 75개는 작은 쪽에 가까운 크기를 받아요

로컬에서 모델을 돌릴 때 제일 먼저 하는 일이 이름 하나 적고 받는 거예요. 그런데 그 이름만으로는 무엇이 오는지 화면에 안 적혀 있어요.

결론부터 적을게요. 올라마 공식 라이브러리에 실린 235개를 레지스트리에서 전수로 열어 보니, 기본 태그가 응답한 219개 중 196개가 4비트 파일이었어요. 그리고 크기 선택지가 둘 이상인 97개 중 75개는 기본 태그가 작은 쪽에 가까운 크기에 붙어 있었어요.

말을 먼저 맞춰 둘게요. 이 글에서 기본 태그는 이름 뒤에 아무것도 안 붙였을 때 붙는 :latest 를 가리켜요. 크기 선택지는 라이브러리 카드에 파란 알약으로 붙어 있는 8b·70b·405b 같은 표기고요. 그리고 75 대 22 라는 판정은 산술 거리 기준이에요. 카드의 제일 작은 알약과 제일 큰 알약을 양 끝으로 두고, 기본 태그의 파라미터 수가 어느 쪽에 산술적으로 더 가까운지로 갈랐어요. 비율로 가르면 답이 67 대 30 으로 바뀌어요. 아래에서 두 숫자를 나란히 놓고 다시 볼게요.

잰 범위부터 밝힐게요. 이 글의 숫자는 전부 2026년 8월 24일 오후 4시 48분에서 4시 56분 사이(한국 시각) 에 공개 경로를 직접 받아 센 값이에요. 전수 집계 235와 219는 오후 4시 50분에 받은 한 번의 스냅샷에서 나왔어요. 뒤에 나오는 404 본문 확인과 다섯 카드 해시 재대조 두 가지만 같은 날 오후 5시 42분과 5시 46분에 따로 받았어요. ollama pull 은 한 번도 실행하지 않았어요.

어떤 조건에서 쟀는지 먼저 못박을게요

값이 조회 시점에 묶이는 종류의 측정이라 조건이 숫자보다 먼저예요.

200이 왔다고 데이터가 온 건 아니에요. 그래서 색인 응답의 첫 15바이트를 찍어 확인했어요. 개행 뒤에 <!doct 로 시작하는 HTML 이 맞았고, 레지스트리 응답은 JSON 파싱이 통과했어요. 404 응답은 엔드포인트마다 본문이 달랐어요. manifests/latest 는 {"errors":[{"code":"MANIFEST_UNKNOWN","message":"manifest unknown"}]} 였고, tags/list 는 404 page not found 였어요.

모집단도 검산했어요. 정렬을 popular 과 newest 두 갈래로 받았는데 둘이 같은 235개 집합이었어요. 차집합이 양쪽 다 비어 있어요. 페이지 나눔 흔적인 ?page= 와 rel="next" 는 0회 나왔고요. 검색 경로로도 세 갈래를 던져 봤는데 결과가 한 건도 235 밖으로 나가지 않았어요.

다만 여기서 한 걸음 물러설게요. 이건 "235가 전부다"의 증명이 아니에요. 검색은 한 번에 20건까지만 돌려줘서 전수 확인이 못 돼요. 관측된 건 "두 정렬이 같은 집합을 줬고, 페이지 나눔 흔적이 없었고, 검색 세 건이 밖으로 나가지 않았다"까지예요. 그리고 이 색인은 공식 라이브러리만 담아요. 사용자가 올린 모델은 이번 범위 밖이에요.

219개 중 196개가 4비트였어요

config blob 의 file_type 값을 그대로 세면 이렇게 나와요.

102 더하기 94 더하기 15 더하기 5 더하기 2 더하기 1은 219예요. 빠진 모델은 없어요. 그리고 이름이 Q4 로 시작하는 게 196개예요.

압축을 안 한 쪽도 성격이 뚜렷해요. F16 15개 중 10개가 색인 카드에 embedding 뱃지를 달고 있어요. 문장을 벡터로 바꾸는 용도라 원래 크기가 작아서 굳이 줄일 이유가 없는 계열이에요. 나머지 5개 중 둘은 OCR 계열이고 셋은 뱃지가 없어요.

MXFP4 두 개는 gpt-oss 와 gpt-oss-safeguard 예요. Q8_0 다섯은 functiongemma·granite3-guardian·laguna-s-2.1·smallthinker·smollm2 고요. BF16 하나는 embeddinggemma 예요.

여기서 읽어 낼 건 하나예요. 로컬 모델을 처음 받는 사람이 기본 태그를 쓰면, 열에 아홉은 원본이 아니라 4비트로 줄인 파일을 받는 거예요. 이건 나쁜 일이 아니에요. 오히려 그래서 일반 PC 에 들어가는 거고요. 다만 "받았으니 원본을 돌리고 있다"고 생각하면 그건 어긋나요.

같은 4비트인데 이름이 둘이에요

4비트 196개가 Q4_0 102개와 Q4_K_M 94개로 갈려요. 이름이 왜 둘인지 보려고 색인 카드의 마지막 갱신 시각을 같이 뽑아 교차표를 만들었어요. 235개 카드 전부에 갱신 시각이 있었어요.

40 더하기 97 더하기 56 더하기 26은 219예요.

표를 대각선으로 읽어 주세요. Q4_0 102개 중 101개가 2024년 이전에 마지막으로 갱신됐어요. 2025년 이후로 넘어간 Q4_0 은 mistral-nemo 하나뿐이에요. 반대로 Q4_K_M 94개 중 71개가 2025년 이후고요.

그러니까 실무에서는 이렇게 읽으면 돼요. Q4_0 이라는 표시는 그 카드가 오래 손을 안 탔다는 신호에 가까워요. 모델을 고를 때 성능표만 보지 마시고 이 값을 같이 보시면, 최근에 관리되는 카드인지 아닌지가 한 번에 보여요.

다만 여기서 멈춰야 해요. 이건 상관이지 인과가 아니에요. 올라마가 기본 양자화를 언제 무엇으로 바꿨다는 발표문을 저는 찾아보지 않았어요. 관측된 건 연도별 분포까지예요. 로컬 환경을 처음 세우는 순서 자체가 궁금하시면 로컬 LLM 을 무료로 세우는 순서를 정리한 기록에 따로 적어 뒀어요.

라벨이 파일 크기와 맞는지 직접 검산했어요

file_type 은 그냥 문자열이에요. 이 값이 실제 파일 크기와 맞는지는 따로 확인해야 해요. 그래서 외부 문서를 인용하지 않고 제가 받은 숫자만으로 검산했어요. manifest 에 적힌 model 레이어 바이트를 config 의 파라미터 수로 나눈 거예요.

라벨과 파일이 맞아요. 4비트라고 적힌 것은 4.57비트와 4.93비트, 16비트라고 적힌 것은 16.06비트와 16.17비트로 나왔어요. 4비트가 딱 4.00이 아닌 건 정상이에요. 블록마다 배율 값이 함께 저장되니까 실제로는 4를 조금 넘게 돼요.

Q4_0 과 Q4_K_M 의 차이도 여기서 숫자로 보여요. 가중치당 0.36비트, 파일로는 8% 정도 차이예요. 8B 모델이면 대략 400MB 안팎 갈리는 셈이고요. 정확도가 얼마나 갈리는지는 이번에 재지 않았어요.

219개 중 4개는 라벨과 크기가 서로 안 맞아요

밴드를 정해 놓고 벗어나는 걸 골라 봤어요. 밴드는 제가 임의로 잡았어요. 4비트 계열은 3.6에서 7.0비트, 8비트는 7.0에서 10.0, 16비트는 14.0에서 18.0으로 뒀어요.

219개 중 4개예요. aya 는 16비트라고 적혀 있는데 8B 모델이 4.47GiB 밖에 안 돼요. 반대로 gemma4 는 4비트라고 적혀 있는데 8B 모델이 8.95GiB 예요.

왜 그런지는 확인하지 못했어요. gemma3n 과 gemma4 는 카드의 크기 알약이 e2b·e4b 같은 표기라 model_type 이 총 파라미터가 아닌 다른 값을 담고 있을 여지가 있어요. 하지만 그건 제 추측이고 검증하지 않았어요. 관측된 사실은 "219개 중 4개는 라벨로 파일 크기가 설명되지 않는다"까지예요.

크기 선택지가 여럿일 때 기본 태그는 어느 쪽일까요

이제 처음의 물음이에요. 카드에 8b·70b·405b 가 다 적혀 있으면 이름만 적었을 때 뭐가 올까요.

먼저 모집단을 정확히 적을게요. 219개 중 크기 알약이 눈에 둘 이상 보이는 카드는 102개예요. 그중 5개는 알약이 8x7b·16x17b·e2b 같은 표기라 숫자 하나로 안 읽혀서 뺐어요. 그래서 숫자로 읽히는 알약이 둘 이상인 카드가 97개예요. 나머지는 숫자로 읽히는 알약이 하나뿐인 카드 104개, 숫자로 읽히는 알약이 하나도 없는 카드 18개고요. 눈에 보이는 알약으로만 세면 하나뿐인 카드가 105개, 아예 없는 카드가 12개예요.

단위도 검산했어요. m 접미사가 백만 파라미터가 맞는지, 값을 아는 카드로 맞춰 봤어요. all-minilm 은 알약이 22m·33m 인데 기본 태그의 model_type 이 23M 이에요. bge-large 는 335m 에 334.09M, embeddinggemma 는 300m 에 307.58M 이고요. 아홉 카드가 전부 자기 알약과 반올림 범위에서 맞았어요.

예외를 하나 찾았어요. internlm2 의 알약이 1m·1.8b·7b·20b 인데 기본 태그는 7.7B 예요. 1M 파라미터짜리 internlm2 는 없어요. 이 1m 은 파라미터 수가 아니에요. 무엇인지는 확인하지 못했고, 대신 이 값을 넣었을 때와 뺐을 때 답이 갈리는지를 확인했어요.

네 규칙이 전부 같은 답을 냈어요. 파싱을 어떻게 바꿔도 75 대 22 는 흔들리지 않았어요.

그런데 거리를 재는 자를 바꾸면 답이 바뀌어요. 위는 산술 거리예요. 비율로 재면 67 대 30 이 돼요. 예를 들어 gemma3 는 기본이 4.3B 이고 알약이 270m 부터 27b 까지 있는데, 산술로는 작은 쪽에 가깝고 비율로는 큰 쪽에 가까워요. 어느 자가 옳다는 근거는 없어요. 그래서 두 숫자를 같이 적어 두는 게 맞아요.

더 나은 물음은 "정확히 몇 번째 알약이냐"예요

가깝다 멀다 대신, 기본 태그가 어느 알약 하나에 대응하는지로 물으면 자가 필요 없어져요. 97개를 그렇게 세면 이렇게 나와요.

그리고 97개 중 96개는 대응 알약과의 오차가 35% 안이라, 대응 자체는 대체로 뚜렷해요.

"기본은 늘 제일 작은 것"이라고 외우면 틀려요. 제일 큰 알약이 기본인 카드가 20개 있어요. llama3.2·mistral-small·smollm2·gemma·codegemma·granite3.2·granite3.3·llama-guard3·opencoder·yi-coder 같은 것들이에요. 이 카드들은 크기 선택지가 둘뿐인 경우가 많아서, 큰 쪽이라고 해 봐야 부담이 크지 않은 편이고요.

manifest 해시를 맞대 보니 정확히 겹쳤어요

위 대응이 추정인지 사실인지 확인해야 해요. 그래서 표본 9개 모델에서 기본 태그 manifest 원문과 크기 태그 manifest 원문의 해시를 직접 비교했어요.

9개 중 9개가 앞의 대응표와 일치했어요. 그리고 이건 근사가 아니라 바이트 단위로 같은 문서예요. 로그 축자를 보시면 이래요.

llama3.1:latest  manifest_sha=46e0c10c039e0191 model_bytes=4920738944
   llama3.1:8b   manifest_sha=46e0c10c039e0191 model_bytes=4920738944 SAME_AS_LATEST=True
   llama3.1:70b  manifest_sha=711a9e8463afd8ed model_bytes=42520398176 SAME_AS_LATEST=False
   llama3.1:405b manifest_sha=dbd6b9ea93de4707 model_bytes=243069610720 SAME_AS_LATEST=False

즉 llama3.1 과 llama3.1:8b 는 다른 이름이 붙은 같은 파일이에요. 태그만 둘일 뿐이에요.

여기서도 범위를 좁혀 둘게요. 이 대응표의 표본은 9개예요. 뒤에서 다섯 카드를 더 대조해 해시로 맞대 본 모델은 모두 13개인데, 그래도 97개 전부를 대조하지는 않았어요. "97개 전부에서 검증됐다"고 읽으시면 안 돼요.

실제로 몇 바이트가 내려오는지 재 봤어요

파라미터 수는 감이 잘 안 와요. 그래서 기본 태그와 그 카드의 제일 큰 태그를 둘 다 열어 model 레이어 바이트를 읽었어요. 이게 디스크에 실제로 쌓이는 숫자예요.

맨 윗줄이 이 글에서 제일 큰 숫자예요. deepseek-r1 은 이름만 적으면 4.87GiB 가 오고, :671b 를 붙이면 376.65GiB 가 와요. 같은 이름 아래에 77배 다른 두 파일이 들어 있는 거예요.

맨 아랫줄도 봐 주세요. llama3.2 는 제일 큰 태그와 기본 태그의 바이트가 완전히 같아요. 이 카드에서는 기본이 곧 최대예요.

파라미터 배수와 바이트 배수는 다르다는 것도 짚고 갈게요. deepseek-r1 은 파라미터로 671b 대 8.2B 라 81.8배인데, 파일로는 77.4배예요. 두 태그의 양자화가 서로 달라서 생기는 차이예요. 그러니까 "몇 B 짜리"로 계산한 용량은 실제와 어긋나요. 크기 선택지가 여럿인 카드 전체로 보면 97개 중 82개에서 제일 큰 알약의 숫자가 기본 태그의 파라미터 수보다 커요. 다만 이건 알약에 적힌 숫자와 model_type 을 견준 값이라 파일 비교가 아니에요. 실제로 82개 중 5개는 알약 숫자만 반올림으로 클 뿐 파일은 제일 큰 태그와 같아요. mistral-small(알약 22b·24b 에 model_type 23.6B)·opencoder·qwen3-embedding·snowflake-arctic-embed·yi-coder 다섯인데, 이 다섯은 기본 태그와 제일 큰 태그의 manifest 해시를 직접 맞대 바이트 단위로 같은 문서임을 확인했어요. 어느 모델을 골라야 할지부터 정리하고 싶으시면 작업별로 무료 모델을 고르는 기준을 정리한 기록이 도움이 될 거예요.

219개가 디스크에서 차지하는 크기는 이렇게 갈려요

기본 태그만 놓고 219개의 model 레이어 크기를 전부 세웠어요.

대표값은 이래요.

중앙값 4.39GiB 가 이 글의 실용적인 답이에요. 이름만 적고 받으면 보통 4GiB 언저리가 내려와요. 그리고 8GiB 미만이 158개라, 기본 태그로만 쓰면 219개 중 열에 일곱은 내려받는 파일이 8GiB 아래예요. 다만 이건 파일 크기고, 그래픽카드에 실제로 올라가는지는 컨텍스트 길이와 캐시까지 봐야 해서 이번에 재지 않았어요.

100GiB 를 넘는 4개는 cogito-2.1(1,250.08GiB)·deepseek-v3(376.7GiB)·deepseek-v3.1(376.7GiB)·deepseek-v2.5(123.8GiB) 예요. cogito-2.1 은 671B 를 16비트로 담고 있어서 혼자 1.34TB 예요. 이름 하나 적고 엔터를 누르면 이게 내려오기 시작해요. 오픈 웨이트 대형 모델을 실제로 골라 쓰는 기준은 오픈 웨이트 코딩 모델 네 종을 실전 조건에서 비교한 기록에 따로 정리해 뒀어요.

목록에 있는데 이름만으로는 못 받는 16개가 있어요

235개 중 16개는 기본 태그 요청이 404 로 돌아왔어요. 태그 목록 조회도 16개 전부 404 였고요. 그런데 웹 태그 페이지는 16개 전부 200 이에요. 그래서 그 페이지에서 태그 이름을 긁어 갈랐어요.

첫 갈래 11개는 glm-5.1·glm-5.2·kimi-k2.6·kimi-k2.7-code·kimi-k3·minimax-m2.7·minimax-m3·nemotron-3-ultra·deepseek-v4-flash·deepseek-v4-pro·mistral-large-3 예요. 태그가 cloud 하나이거나 0731-cloud·675b-cloud 처럼 cloud 로 끝나는 것뿐이에요.

다만 cloud 뱃지만 보고 가르면 어긋나요. 색인 카드에 cloud 뱃지가 붙은 카드는 235개 중 16개인데, 그중 11개만 위의 첫 갈래고 나머지 5개(gpt-oss·gemma4·qwen3.5·nemotron-3-nano·nemotron-3-super)는 기본 태그가 정상으로 열려요. gpt-oss 는 이 글 앞의 바이트 표에 12.85GiB 로 적혀 있는 바로 그 카드고요. 그러니까 cloud 뱃지는 클라우드로도 쓸 수 있다는 표시일 뿐, 내려받을 파일이 없다는 뜻이 아니에요. 내려받을 게 있는지는 뱃지가 아니라 기본 태그 manifest 의 응답으로 갈라야 해요. 그리고 cloud 태그로 무엇이 일어나는지는 확인하지 않았어요. 요청이 어디로 가는지, 과금이 있는지, 로그인이 필요한지 전부 안 봤어요.

두 번째 갈래 5개는 granite4.1(태그 48개)·granite4.1-guardian(16개)·nemotron3(4개)·ornith-1.5(3개)·wizardlm(73개) 예요. 진짜 크기 태그가 줄줄이 있는데 그중 latest 라는 이름만 없어요. 이런 카드는 이름만 적으면 실패하고, 크기를 붙이면 내려받을 수 있어요.

받기 전에 확인하는 순서

키가 필요 없어서 브라우저 주소창에 붙여 넣어도 열려요.

curl -s -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \
  https://registry.ollama.ai/v2/library/llama3.1/manifests/latest

앞부분에 {"schemaVersion":2 가 보이면 JSON 이 온 거예요. {"errors":[{"code":"MANIFEST_UNKNOWN" 가 보이면 그 이름에는 기본 태그가 없는 거고요.

layers 배열에서 mediaType 이 application/vnd.ollama.image.model 인 항목의 size 가 실제로 내려올 가중치 파일 바이트예요. 나머지 레이어는 대개 템플릿·라이선스·파라미터라 다 합쳐도 몇십 KB 수준인데, 219개 중 11개는 예외예요. 이미지를 읽는 계열에는 application/vnd.ollama.image.projector 레이어가 따로 붙고 이게 작지 않아요. llava 는 595.5MiB, minicpm-v4.6 은 1,057.4MiB, muse-glimmer 는 1,335.5MiB 예요. 이런 카드는 model 레이어만 보면 manifest 에 적힌 총량과 어긋나니 layers 를 전부 더해 보세요. projector 가 없는 카드에서는 나머지 레이어 합이 제일 큰 것도 6만 바이트가 안 됐어요.

몇 비트인지까지 보려면 한 걸음 더 가요.

DIGEST=$(curl -s -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \
  https://registry.ollama.ai/v2/library/llama3.1/manifests/latest \
  | python -c "import sys,json;print(json.load(sys.stdin)['config']['digest'])")
curl -s https://registry.ollama.ai/v2/library/llama3.1/blobs/$DIGEST

응답에 file_type 과 model_type 이 들어 있어요. llama3.1 은 Q4_K_M 에 8.0B 로 나와요.

받기 전에 밟을 순서를 정리하면 이래요.

1. 라이브러리 카드에서 크기 알약이 몇 개인지 센다. 하나면 고민할 게 없다.
2. 알약이 여럿이면 기본 태그가 그중 무엇인지 manifest 로 확인한다.
3. model 레이어의 size 를 보고 디스크 용량에 들어오는지 판단한다. 이미지를 읽는 계열이면 projector 레이어까지 더한다.
4. config 의 file_type 을 보고 4비트인지 16비트인지 확인한다.
5. 카드에 cloud 뱃지가 있어도 그것만으로는 판단하지 않는다. 기본 태그 manifest 가 404 이고 태그 페이지의 태그가 전부 cloud 계열일 때만 내려받을 파일이 없는 것이다.
6. 원하는 크기가 따로 있으면 이름 뒤에 그 알약을 그대로 붙인다. 알약 문자열이 곧 태그 이름이다.

2번과 3번을 굳이 나눈 이유가 있어요. 둘은 다른 값이에요. 파라미터 수로 계산한 용량과 실제 파일 바이트가 어긋나거든요. 앞의 deepseek-r1 이 81.8배 대 77.4배로 갈린 게 그 자리예요.

확인하지 못한 것도 적어 둘게요

이 글이 말하지 않는 것들이에요.

첫째, ollama pull 을 한 번도 실행하지 않았어요. 이 PC 에 올라마가 설치돼 있는지조차 확인하지 않았어요. 전부 레지스트리 HTTP 응답을 읽은 값이에요. 실제로 받았을 때 디스크에 정확히 몇 바이트가 남는지, 레이어가 모델끼리 공유돼 절약되는지는 확인하지 못했어요.

둘째, ollama show 출력과 대조하지 않았어요. CLI 가 같은 file_type 과 model_type 을 어떻게 보여 주는지 안 봤어요. 이 글의 값은 전부 HTTP 응답 기준이에요.

셋째, config 의 architecture 가 219개 전부 amd64, os 가 전부 linux 인데 그 뜻을 확인하지 못했어요. 맥이나 윈도에서 받을 때 다른 manifest 가 오는지 검증하지 않았어요.

넷째, Q4_0 과 Q4_K_M 의 품질 차이를 재지 않았어요. 잰 건 파일 크기뿐이에요. 4.57비트와 4.93비트라는 숫자가 정확도나 속도로 어떻게 이어지는지는 이 관측의 범위 밖이에요.

다섯째, 갱신 연도와 양자화의 관계는 상관이에요. 올라마가 기본값을 언제 바꿨다는 발표문을 찾아보지 않았어요. 인과로 읽으시면 안 돼요.

여섯째, 라벨을 벗어난 4개의 원인을 모르는 상태예요. aya·laguna-s-2.1·gemma3n·gemma4 가 왜 어긋나는지 확인하지 못했어요.

일곱째, cloud 태그의 동작을 확인하지 않았어요. 관측한 건 "태그 이름이 cloud 계열이고 기본 태그 manifest 가 404"까지예요. 그 태그로 요청하면 무슨 일이 일어나는지는 안 봤어요.

여덟째, internlm2 의 1m 알약이 무엇인지 확인하지 못했어요. 파라미터 수가 아니라는 것까지만 알아요.

아홉째, manifest 해시 대조 표본은 13개예요. 대응표 검증에 9개, 82개 안의 반올림 사례 확인에 4개를 더 썼어요. 97개 전부를 대조하지 않았어요. 그래서 82개 중 파일까지 같은 카드가 정확히 5개뿐인지도 확인하지 못했어요.

열째, 235가 전부라는 걸 증명하지 못했어요. 정렬 두 갈래가 같은 집합을 줬고 페이지 나눔 흔적이 없었으며 검색 세 건이 밖으로 나가지 않았다는 것까지가 관측이에요. 검색은 한 번에 20건 상한이라 전수 확인이 못 돼요. 그리고 이건 공식 라이브러리만 센 값이라 사용자가 올린 모델은 안 들어가요.

열한째, 75 대 22 는 산술 거리 기준이에요. 비율로 재면 67 대 30 이에요. 어느 자가 옳은지는 근거가 없어요. 자에 의존하지 않는 값은 아래 정리표의 55 대 22 대 20 쪽이에요.

열두째, 그래픽카드 메모리 요구량을 계산하지 않았어요. 잰 건 내려받는 파일 크기예요. 실행에 필요한 메모리는 컨텍스트 길이와 캐시에 따라 달라져서 파일 크기만으로 정해지지 않아요. 그래서 이 글의 8GiB·16GiB 숫자를 그래픽카드 용량 판정으로 옮기시면 안 돼요.

열셋째, cloud 뱃지가 붙은 16개 중 5개가 왜 뱃지와 로컬 파일을 함께 갖는지 확인하지 못했어요. 관측한 건 "뱃지가 붙었고 기본 태그가 200이며 model 레이어가 있다"까지예요.

열넷째, projector 레이어가 실제로 함께 내려오는지 확인하지 못했어요. manifest 의 layers 에 들어 있다는 것까지가 관측이에요.

정리하면

이름 하나만 적고 엔터를 누르는 건 편해요. 다만 그 한 줄이 크기와 압축 방식을 대신 골라 주고 있다는 건 알고 계시는 게 좋아요. 97개 카드에서는 그 선택이 대체로 작은 쪽이고, 20개에서는 제일 큰 쪽이에요. 그리고 82개에서는 카드에 적힌 제일 큰 숫자가 기본 태그의 파라미터 수보다 커요. 다만 그중 5개는 알약 숫자만 반올림으로 큰 것이고 파일은 제일 큰 태그와 같아요. 확인에 걸리는 시간은 요청 한 번이에요.

확인한 자료: 올라마 공식 모델 라이브러리 색인 https://ollama.com/library?sort=popular 와 ?sort=newest 두 쪽(각 HTTP 200, 805,167바이트, 모델 235개), 올라마 레지스트리 https://registry.ollama.ai/v2/library/<이름>/manifests/latest 235건과 그에 딸린 config blob 219건, tags/list 16건, 크기 태그 manifest 대조 26건, 웹 태그 페이지 16건, 검색 3건. 여기까지는 2026년 8월 24일 오후 4시 48분 17초에서 4시 55분 44초 사이(한국 시각)에 파이썬 urllib 로 직접 받은 값이에요. 여기에 더해 404 본문을 엔드포인트별로 갈라 확인한 12건(오후 5시 42분 20초)과 mistral-small·opencoder·qwen3-embedding·snowflake-arctic-embed·yi-coder 의 기본 태그 대 최대 태그 manifest 10건(오후 5시 46분 25초)을 같은 방식으로 받았어요. 시각은 전부 스크립트가 찍은 값을 그대로 옮겼어요. ollama pull 은 실행하지 않았어요.