CanRun

CanRun 계산 방법: 판정, 속도 추정, 오차 범위

CanRun의 모든 답은 같은 계산에서 나옵니다. 계산기, GPU 페이지, 모델 페이지, 가이드 어디서 보든 숫자가 같습니다. 이 페이지에서는 그 계산이 어떻게 돌아가는지, 실제 벤치마크와 비교해 얼마나 맞았는지, 어디서 틀릴 수 있는지 설명합니다.

판정

모델마다 네 가지 판정 중 하나가 붙습니다. 기준은 대부분 처음 시작하는 설정인 Q4_K_M 양자화, 8k 컨텍스트, f16 KV 캐시입니다.

판정 읽는 법

쾌적
GPU에 전부 올라가고 20 tok/s 이상
원활
GPU에 전부 올라가고 8~20 tok/s, MoE 전문가를 시스템 RAM에 두고 20 tok/s 이상, 또는 GPU에 90% 이상 올라가고 8 tok/s 이상
겨우 가능
2~8 tok/s, CPU 전용, GPU에 90% 미만, 또는 MoE 전문가를 RAM에 두고 20 tok/s 미만
불가
메모리에 안 들어가거나 2 tok/s 미만

답하기 전에 생각하는 과정을 먼저 쓰는 생각 모드(thinking)가 있는 모델은 답 하나에 기다려야 하는 토큰이 훨씬 많습니다. 그래서 속도 기준을 1.5배 높게 잡습니다. 생각 모드를 끄고 켤 수 있는 모델도 같은 기준을 씁니다. 공식 모델 카드와 채팅 템플릿으로 생각 모드가 있는지 확인합니다. Q4_K_M으로 좋은 판정이 나오지 않는 모델은 더 작은 양자화나 더 많은 시스템 RAM으로 무엇이 달라지는지도 함께 보여 드립니다.

메모리

모델에 필요한 메모리는 세 가지를 더한 값입니다.

  • 모델 가중치: 파라미터 수로 어림하지 않고, Hugging Face에 올라온 양자화별 실제 GGUF 파일 크기에서 출발합니다. 그래픽카드에서는 llama.cpp가 올리지 않는 부분을 뺍니다. 입력 임베딩 표는 늘 시스템 RAM에 두고, 일부 최신 모델에 들어 있는 MTP(다중 토큰 예측) 블록은 MTP를 켤 때만 불러옵니다(EXAONE 4.5의 MTP 블록은 llama.cpp가 아직 쓰지 않아 아예 불러오지 않습니다). 두 부분의 크기는 파일 헤더에서 읽습니다. 맥은 파일 전체로 계산합니다. 계산기에 모델 값을 직접 넣은 경우만 예외입니다. 실제 파일이 없어서 파라미터 수로 어림합니다(아래 ‘알려진 한계’ 참고).
  • KV 캐시: 지금까지의 대화를 담아 두는 메모리입니다. 컨텍스트가 길어질수록 커지는데, 얼마나 빨리 커지는지는 모델 구조에 따라 다릅니다. 슬라이딩 윈도 층이 있는 모델은 긴 컨텍스트에서 훨씬 적게 씁니다. 각 모델이 공개한 설정값으로 계산합니다.
  • 연산 버퍼: 글을 생성하는 동안 런타임이 쓰는 작업 메모리입니다.

이 합계를 카드에 적힌 용량이 아니라 실제로 쓸 수 있는 메모리와 비교합니다. 화면 출력까지 맡은 그래픽카드는 운영체제가 메모리 일부를 쓰고, 맥은 통합 메모리를 macOS와 나눠 씁니다. 맥과 다른 통합 메모리 PC는 메모리의 약 70%를 GPU 몫으로 봅니다. DGX Spark는 사용자들이 공개한 부팅 기록 가운데 가장 낮은 값에서 Linux와 데스크톱이 쓰는 몫을 뺀 양을 GPU 몫으로 봅니다. 모델이 다 들어가지 않으면 일부를 시스템 RAM에서 돌릴 수 있는지, 그러면 얼마나 느려지는지도 계산합니다.

속도

토큰 하나를 만들 때마다 모델 가중치와 KV 캐시를 메모리에서 읽어야 하므로, 속도는 메모리 대역폭이 좌우합니다. 카드의 대역폭과 토큰당 읽는 양으로 먼저 추정하고, 하드웨어 종류(NVIDIA·AMD·인텔·애플 GPU, CPU)마다 효율 계수를 곱합니다. 이 계수는 공개 벤치마크에 맞춰 보정한 값입니다. 모델 일부가 시스템 RAM에 있으면 그 부분은 더 느린 RAM 대역폭으로 계산합니다.

MoE 모델은 토큰마다 공유 층과 라우터가 고른 전문가 몇 개만 읽습니다. 그래서 읽는 양은 GGUF 파일 헤더에 적힌 텐서 크기로 셉니다. 읽는 시간과 별도로, 토큰마다 층 하나에서 전문가 하나를 돌릴 때마다 작은 고정 시간이 붙습니다. 전문가를 고르는 라우팅과 잘게 나뉜 행렬 연산에 드는 시간입니다. 빠른 하드웨어에서 작은 MoE 모델을 돌리면 이 시간이 읽는 시간만큼 커지기도 합니다. 이 값은 하드웨어 종류마다 2026년 llama.cpp 빌드의 공개 벤치마크에 맞췄습니다.

신뢰 라벨

CanRun의 속도는 모두 범위로 보여 드리고, 라벨이 함께 붙습니다.

  • ‘실측’: 같은 GPU·모델·양자화로 잰 벤치마크 결과입니다. 공개된 결과이거나, CanRun이 직접 재고 원본 기록을 공개한 결과입니다. 어디서, 어떤 조건으로 잰 값인지 함께 적습니다.
  • ‘보정된 추정’: 비슷한 구성의 벤치마크로 검증한 추정치입니다. NVIDIA·AMD 그래픽카드에 dense 모델을 전부 올린 경우는 ±12%, 그 밖의 하드웨어와 MoE 모델, 시스템 RAM을 함께 쓰는 경우는 ±20% 범위로 보여 드립니다.
  • ‘이론 추정’: 아직 벤치마크로 확인하지 못한 구성의 추정치로, ±30% 범위로 보여 드립니다.

첫 토큰이 나오기 전까지 걸리는 프롬프트 처리 속도는 ±40% 범위의 대략적인 값으로만 보여 드립니다. GPU의 FP16 연산 성능으로 7B 모델의 속도를 잡고, 이를 모델 크기로 나눕니다. 프롬프트를 읽을 때는 토큰마다 파라미터 하나당 연산이 두 번쯤 들기 때문에, 70B 모델은 7B 모델의 10분의 1쯤 되는 속도로 읽습니다. 토큰마다 모델과 상관없이 드는 시간도 있어서, 작은 모델은 크기가 작은 만큼 빨라지지는 않습니다. MoE 모델은 활성 파라미터보다 큰 모델처럼 계산합니다. 한 번에 읽는 프롬프트 토큰이 전문가마다 나뉘어 각 전문가가 맡는 양이 적기 때문이고, 활성 전문가에 비해 전문가 수가 많을수록 더 크게 칩니다. 라데온 카드는 AMD가 밝힌 FP16 행렬 연산 성능을 씁니다. GPU 코어마다 행렬 연산 가속기가 들어 있는 애플 M5 계열은 그 칩들의 공개 벤치마크에 따로 맞춘 계수를 씁니다. M5 계열과 Strix Halo에서는 Q4_K_M 같은 K-quant 파일이 Q4_0·Q8_0 파일보다 프롬프트를 느리게 읽어서, 이 차이도 계산에 넣습니다. 애플은 칩의 연산 성능을 밝히지 않아서, 애플 칩은 위키백과 'Apple silicon' 표의 이론값을 씁니다. 애플 GPU는 FP16을 FP32와 같은 속도로 처리합니다.

얼마나 맞았나요

계산을 실제 데이터와 비교하는 검사는 코드나 데이터가 바뀔 때마다 자동으로 다시 돌아갑니다.

  • 모델 파일 크기: 실제 GGUF 파일 11개와 비교해 평균 오차 0.7%, 최대 1.6%였습니다.
  • KV 캐시: 확인한 모델 구조 7종 모두 공식과 정확히 일치했습니다.
  • 속도: 기준 벤치마크 12건과 비교해 평균 오차 4.2%, 최대 10.5%였습니다. 가장 크게 빗나간 경우는 애플 M5 Pro와 CPU만 쓰는 구성으로, 둘 다 약 10% 낮게 추정했습니다.
  • MoE 모델 속도: 2026년 llama.cpp 빌드로 잰 공개 벤치마크 49건과 비교해 평균 오차 8.3%, 최대 19.9%였습니다. NVIDIA·AMD·애플 GPU와 DGX Spark, Strix Halo가 들어 있습니다.
  • 프롬프트 처리 속도: 2026년 llama.cpp 빌드로 잰 공개 벤치마크 91건과 비교해 평균 오차 11.6%, 최대 35%였습니다. 0.6B부터 120B까지 dense·MoE 모델이 들어 있고, 하드웨어 종류는 위와 같습니다. 2026년 10월 16일 전에는 같은 카드면 모델이 달라도 같은 값을 보여 드렸습니다. 이 가운데 그때 추정이 있던 83건(DGX Spark는 추정이 없었습니다)과 비교하면 평균 92% 빗나갔고, 많게는 8배 높았습니다.

이 수치는 2026년 8월 9일에 처음 확인했습니다. 2026년 10월 15일에는 2023년 llama.cpp 빌드로 잰 애플 속도 벤치마크 2건을 지금 빌드로 잰 결과로 바꿨습니다. 같은 날 MoE 모델 속도 계산 방식도 바꾸고 MoE 검사를 더했습니다. 10월 16일에는 Strix Halo의 계수를 지금 llama.cpp 빌드로 잰 결과에 다시 맞추고, MoE 검사에 Strix Halo 결과 4건을 더했습니다. 같은 날 프롬프트 처리 추정이 모델 크기를 반영하도록 바꾸고 프롬프트 처리 검사를 더했습니다. 자동 검사가 이 수치보다 나빠지지 않게 지키고 있습니다.

알려진 한계

  • 전문가를 시스템 RAM에 두는 MoE 모델은 VRAM에 들어가는 만큼 전문가를 GPU에 두고 나머지만 RAM에 둔다고 보고 계산합니다. 최신 llama.cpp와 Ollama가 자동으로 나눠 올리는 방식과 같고, 실행 명령의 --n-cpu-moe 값도 이 배치를 따릅니다. NVIDIA 그래픽카드 공개 벤치마크 35건과 비교하면 평균 오차가 약 10%였고 89%가 ±20% 안에 들었습니다. 다만 운영체제·백엔드·RAM 구성에 따라 3분의 1쯤 벌어진 경우도 있어 ‘이론 추정’(±30%)으로 표시합니다(2026년 10월 1일 확인, 10월 15일 다시 확인).
  • MoE 모델의 속도는 크기만이 아니라 구조에 따라서도 달라집니다. 전문가 하나에 붙는 고정 시간을 하드웨어 종류마다 한 값으로 쓰기 때문에, 층마다 하는 일이 많거나 적은 모델은 20% 안팎까지 벗어날 수 있습니다. Q8_0 파일은 추정보다 조금 빠르게 도는 편입니다. 수치는 2026년 llama.cpp 빌드를 따릅니다. 2025년 빌드로 잰 맥의 MoE 벤치마크는 지금 추정보다 최대 30%쯤 낮았습니다.
  • 프롬프트 처리 속도는 가장 거친 값입니다. 짧은 프롬프트를 llama.cpp 기본값인 512토큰씩 묶어 처리할 때 기준입니다. 컨텍스트가 길어지면 어텐션 계산이 늘어 프롬프트 처리 속도가 떨어집니다. 묶음을 크게 하면(llama.cpp의 gpt-oss 안내가 권하는 -ub 2048) MoE 모델은 CanRun 값보다 빠르게 읽습니다. llama.cpp 빌드가 바뀌면 프롬프트 처리 속도도 빠르게 바뀝니다. NVIDIA 카드의 MoE 프롬프트 처리는 2026년 중반에 40%쯤 빨라졌습니다. 인텔 Arc 카드는 표준 모델로 잰 최근 벤치마크가 없어 프롬프트 처리 추정이 가장 불확실합니다.
  • 백엔드에 따라 속도가 달라집니다. Strix Halo 수치는 그 기기에서 더 빠른 llama.cpp의 Vulkan 백엔드를 따릅니다. 같은 기기·같은 빌드로 비교한 공개 결과에서 ROCm은 생성 속도가 3~12% 느렸습니다.
  • 벤치마크마다 재는 방식이 다릅니다. 긴 컨텍스트에서 평균을 내기도 하고 짧은 프롬프트로 재기도 해서, 벤치마크마다 컨텍스트 조건을 기록하고 같은 조건끼리 비교합니다.
  • 내 PC에서는 다를 수 있습니다. 노트북의 전력·발열 제한, 싱글 채널 RAM, 드라이버, 백그라운드 프로그램에 따라 실제 속도가 달라집니다. 범위가 이런 차이를 어느 정도 담지만 전부는 아닙니다.
  • 런타임은 스스로 판단합니다. Ollama와 llama.cpp는 메모리를 자기 방식으로 계산해서 CanRun 계산과 다르게 GPU와 CPU에 나눠 올릴 수 있습니다. llama.cpp의 자동 배치는 GPU마다 VRAM을 조금 비워 두고, 최근 Ollama도 같은 방식으로 모델을 올립니다. 그래서 CanRun 계산으로 아슬아슬하게 들어가는 모델은 일부가 시스템 RAM으로 넘어갈 수 있습니다. 내 PC에서 실제로 어떻게 올라갔는지는 ollama ps로 확인하세요.
  • DGX Spark의 GPU 몫은 낮은 쪽으로 잡았습니다. 사용자들이 공개한 부팅 기록 가운데 가장 낮은 값에서 출발합니다. 이 값은 이전 커널보다 메모리를 몇 GB 더 예약하는 커널을 쓰는 DGX OS에서 나왔습니다. 여기서 데스크톱이 가만히 있을 때 쓰는 메모리를 뺍니다. 이전 커널이나 문제가 고쳐진 커널을 쓰거나 데스크톱 없이 쓰면, 이 계산보다 조금 더 큰 모델이 들어갈 수 있습니다. 64GB 구성은 아직 공개된 값이 없어서 128GB 구성과 같은 고정 몫을 뺐습니다. 그 몫 가운데 일부는 보통 메모리 크기에 비례하므로, 실제로는 조금 더 남을 수 있습니다.
  • MTP를 켜면 메모리가 더 듭니다. 그래픽카드에 다 올리는 경우 CanRun은 MTP 블록을 불러오지 않는 llama.cpp 기본 설정을 가정해 이 블록을 뺍니다. 맥과, 모델 일부를 시스템 RAM에 두는 경우는 이 블록까지 넣어 계산합니다. MTP 추측 디코딩을 켜면 그 블록과 MTP용 KV 캐시만큼 더 필요하고, 블록 크기는 그래픽카드에 다 올라가는 조합 페이지의 메모리 그림 아래에 적어 두었습니다. EXAONE 4.5는 llama.cpp가 MTP 블록을 아직 쓰지 않아 켤 수 없습니다.
  • 계산기에 모델 값을 직접 넣으면 파일 크기를 파라미터 수와 양자화 비트 수로 어림합니다. 목록에 있는 모델과 비교해 보면 dense 모델은 실제 파일과의 차이가 9% 안쪽이었고, MoE 모델은 더 크게 벗어나 가장 큰 차이가 34%였습니다. KV 캐시는 넣은 층 수로 계산합니다. config.json에 kv_lora_rank가 있는 모델(DeepSeek V3 같은 MLA 구조)은 KV 캐시를 저장하는 방식이 달라서 직접 넣은 값으로는 맞게 계산되지 않습니다. 실제 파일도, 확인할 벤치마크도 없어서 이런 모델의 결과는 늘 ‘이론 추정’(±30%)으로 보여 드립니다.
  • GPU를 여러 장 쓰는 구성은 계산기에서만 베타로 계산합니다. llama.cpp 기본 방식대로 카드마다 남은 메모리에 비례해 층을 나눠 올린다고 봅니다. VRAM은 합쳐지지만 메모리 대역폭은 합쳐지지 않습니다. 토큰 하나를 만들 때 카드를 차례로 거치므로, 서로 다른 카드를 섞으면 느린 카드에 올라간 몫만큼 전체 속도가 떨어집니다. 여러 장 구성은 비교할 공개 벤치마크가 적고, 서로 다른 카드를 섞은 구성은 특히 몇 건뿐입니다. 그래서 이 결과는 늘 ‘이론 추정’(±30%)으로 보여 드립니다. GPU 페이지와 모델 페이지, 조합 페이지는 그래픽카드 1장으로 계산합니다.
  • DGX Spark 여러 대 연결(두 대~네 대 — GPU 페이지 표와 계산기)은 llama.cpp RPC로 층을 기기마다 나눠 올린다고 보고 계산합니다. 메모리는 합쳐지지만 토큰마다 모든 기기를 차례로 지나므로, 한 대가 토큰 하나에 쓰는 시간에 기기를 건널 때마다 드는 시간을 더해 속도를 셉니다. 이 시간은 두 대를 TCP로 이은 공개 결과에서 구했습니다. RDMA로 잇거나 CPU 유휴 상태를 끈 설정에서는 이 수치가 실제보다 최대 16%쯤 낮게 나왔고, 아주 긴 컨텍스트에서는 실제보다 높게 나왔습니다. 세 대·네 대는 공개 벤치마크가 없어 두 대 값을 늘려 잡았고, 여러 대 수치는 모두 이론 추정입니다. 그 표에서 기준 양자화(Q4_K_M, gpt-oss와 DeepSeek V4 Flash는 MXFP4)가 같은 메모리 한 대의 GPU에 이미 다 들어가는 모델은 이어 봐야 느려지기만 합니다. 그래서 여러 대 판정 대신 ‘1대로 충분’이라고 적습니다. NVIDIA 공식 안내에서 쓰는 vLLM 텐서 병렬은 llama.cpp보다 빠를 수 있지만 계산하지 않습니다.

독립성

판정과 추천은 위 데이터로만 계산합니다. 광고나 제휴 링크, 제조사와의 관계는 결과에 영향을 주지 않습니다. 가격을 보여 줄 때는 확인한 날짜를 함께 적습니다.

출처