treeru.com
AI

CPU만으로 LLM을 돌리면 몇 토큰이나 나올까 - 구형 Xeon + 램 256GB 실측

2026-08-10
Treeru

GPU 없이 램만 넉넉하게 꽂힌 구형 서버가 한 대 있다면, 이걸로 로컬 오픈소스 LLM을 돌리면 실제로 초당 몇 토큰이나 나올까요? 검색하면 “느려서 못 쓴다”와 “의외로 쓸 만하다”가 반반인데, 정작 구체적인 숫자는 잘 안 보입니다.

그래서 직접 쟀습니다. 10코어 구형 Xeon과 DDR4 램 256GB로 120B부터 4B까지 5개 모델을 돌려본 결과를, 반올림 없이 그대로 공개합니다. 스레드 수를 바꾸면 무슨 일이 생기는지, 전기는 얼마나 더 먹는지까지요.

어두운 서버실에서 열려 있는 구형 랙 서버 내부. GPU 없이 CPU 방열판과 램 슬롯을 가득 채운 메모리 모듈이 보이는 장면
GPU 없이 램만 가득한 서버. 이 구성으로 LLM이 얼마나 돌아가는지 재봤다.

11.3 t/s

최고 생성 속도 (Qwen3-30B-A3B)

약 7배

하이퍼스레딩 켰을 때 생성 속도 하락

+22W

지속 부하 시 전력 증가

+3°C

CPU 패키지 온도 상승

1GPU 없이 램만 넉넉한 서버가 있다면

로컬 LLM 이야기는 대부분 GPU에서 시작합니다. 그런데 현실의 많은 사무실·연구실에는 다른 그림이 흔합니다. 램 슬롯이 8개씩 달린 2소켓 지원 구형 랙 서버가 어딘가에 한 대쯤 놀고 있는 경우죠.

이런 서버에는 예전에 채워둔 램이 그대로 꽂혀 있곤 합니다. DDR4 ECC 램이 한때 아주 저렴하던 시절이 있었지만, 요즘은 램 시세가 생각보다 많이 올랐습니다. 그래서 지금 새로 사서 채우는 그림보다는, 이미 램이 꽂힌 채 놀고 있는 서버를 살려 쓰는 상황이 이 글의 출발점입니다.

램이 256GB면 파일 크기 60GB짜리 120B 모델도 통째로 올라갑니다. 물론 “올라간다”와 “쓸 만한 속도로 돈다”는 전혀 다른 문제입니다. 이 글은 그 간극을 숫자로 메우는 실측 리포트입니다.

ℹ️ 알아두세요

t/s(tokens per second)는 모델이 1초에 만들어내는 토큰 수입니다. 경험적으로 생성 기준 10 t/s 안팎은 나와야 사람이 읽는 속도를 그럭저럭 따라옵니다. 그 아래로 내려가면 대화가 답답해집니다.

2무엇으로, 어떻게 쟀나

주인공은 이 서버입니다.

CPU

Intel Xeon Silver 4210 (10코어/20스레드)

메모리

DDR4-2400 RDIMM 256GB

GPU

없음. 순수 CPU 추론.

측정 도구는 llama.cpp 공식 프리빌드 b10333(CPU 빌드) llama-bench입니다. 모델은 전부 GGUF 양자화본을 썼습니다. 표에 나오는 두 지표는 이렇게 읽으면 됩니다.

  • pp512: prefill 속도. 입력(프롬프트) 512토큰을 읽어들이는 초당 토큰 수. 긴 문서를 넣을 때 기다리는 시간을 좌우합니다.
  • tg128: generation 속도. 답변 128토큰을 생성하는 초당 토큰 수. 체감 속도의 핵심입니다.

± 표기는 반복 측정의 표준편차입니다.

3하이퍼스레딩의 배신: 스레드는 물리코어까지만

첫 번째 발견부터 강렬했습니다. 10코어/20스레드 CPU니까 스레드를 20개 주면 더 빠를 것 같지만, 결과는 정반대였습니다. 파일 크기 60GB짜리 gpt-oss-120b(MXFP4)로 스레드 수만 바꿔 잰 결과입니다.

스레드 수pp512 (t/s)tg128 (t/s)
10 (물리코어 수)10.34 ± 0.336.87 ± 0.04
20 (하이퍼스레딩 포함)9.18 ± 2.070.95 ± 0.19

생성 속도가 6.87에서 0.95로, 약 7배 폭락했습니다. 살짝 느려지는 정도가 아니라 사실상 못 쓰는 속도가 됩니다.

이유는 병목의 위치에 있습니다. CPU 추론의 병목은 연산이 아니라 메모리 대역폭입니다. 논리 스레드 20개가 같은 메모리 컨트롤러를 두고 경합하면서 서로를 방해하는 것이죠.

흥미로운 대비도 있었습니다. 활성 파라미터가 3B로 작은 Qwen3-30B-A3B는 20스레드에서도 생성 10.9 t/s로 거의 유지됐습니다. 한 번에 움직이는 데이터가 작으면 경합의 타격도 작다는 뜻입니다.

그래도 결론은 같습니다. 이득이 없으니, 스레드 수는 물리코어 수만큼만 주는 게 정답입니다.

⚠️ 주의사항

llama.cpp는 기본값이 전체 논리 스레드가 아니지만, 직접 -t 옵션을 줄 때 무심코 스레드 수를 20, 32처럼 논리 스레드로 넣기 쉽습니다. 이 값 하나로 결과가 몇 배씩 갈립니다.

4생성 속도는 램 대역폭이 정한다

그럼 모델은 뭘 골라야 할까요? 5개 모델을 전부 스레드 10(물리코어)으로 잰 결과입니다. 괄호 안은 MoE 모델의 활성 파라미터, 토큰 하나를 만들 때 실제로 읽어야 하는 가중치의 크기입니다.

모델파일 크기pp512tg128
gpt-oss-120b MXFP4 (활성 5.1B)60GB10.36.9
gemma-4-26B-A4B UD-Q4_K_XL (활성 4B)16GB17.96.8
Qwen3-30B-A3B-2507 UD-Q4_K_XL (활성 3B)16.5GB22.311.3
Qwen3.5-4B UD-Q4_K_XL (dense)2.8GB18.17.9
gemma-4-E4B UD-Q4_K_XL4.9GB26.37.3

이 표의 핵심은 한 줄입니다. 파일 60GB짜리 120B 모델보다 16.5GB짜리 30B 모델이 모든 면에서 빨랐다는 것. 종합 1위는 Qwen3-30B-A3B로, prefill 22.3 / 생성 11.3 t/s를 기록했습니다.

램이 넉넉해서 큰 모델이 “올라간다”고 해도, 나오는 속도는 모델 전체 크기가 아니라 토큰마다 램에서 읽어야 하는 활성 파라미터 크기에 반비례합니다. 생성 속도의 지배 변수는 램 대역폭이고, 활성 5.1B(120B)보다 활성 3B(30B)가 빠른 건 그 자연스러운 결과입니다.

MoE 구조가 왜 이렇게 동작하는지는 MoE vs Dense 실전 비교에서 더 자세히 다뤘습니다.

운영 관점의 기록도 남겨둡니다. 120B(60GB 파일) 실행 시 피크 메모리는 약 96GB(mmap 페이지캐시 포함)였고 스왑은 0이었습니다. 60GB 파일을 디스크에서 처음 올리는 데는 약 5분(디스크 약 200MB/s)이 걸리는데, 이 구간은 iowait이라 전력도 오르지 않습니다.

💡 핵심 포인트

CPU 추론에서 모델을 고를 땐 총 파라미터가 아니라 활성 파라미터를 보세요. “램에 올라가는 가장 큰 모델”이 아니라 “활성 파라미터가 작으면서 품질이 충분한 모델”이 정답에 가깝습니다.

5열도 전력도 거의 안 오른다

GPU 추론은 부하가 걸리면 소비 전력이 수백 W씩 뛰고 팬이 울부짖습니다. CPU 추론은 어떨까요? Qwen3-30B-A3B로 약 4분간 지속 부하를 걸고 서버 관리 컨트롤러(BMC)로 계측했습니다.

시스템 전력

유휴 209W → 부하 220~231W. 겨우 +22W입니다. 전구 하나 더 켠 수준입니다.

온도

CPU 패키지 47°C → 50°C(+3°C), 배기 41 → 42°C, 흡기 34°C 그대로. 같은 섀시의 HDD 온도(37~46°C 범위)도 부하 전후 완전 동일했습니다.

팬 소음

팬 RPM은 부하 전후 동일. 팬 커브가 반응할 만큼도 온도가 오르지 않았습니다.

성능도 흔들리지 않았습니다. 지속 부하 중 pp1024 21.3 t/s, tg256 11.2 t/s로 단발 벤치와 같은 수준이었습니다. 지속 부하로 인한 성능 열화가 없었습니다.

이유는 앞 섹션과 같은 원리입니다. 병목이 메모리 대역폭이라 CPU 연산 유닛이 상당 시간 데이터를 기다리며 놀고 있고, 그래서 전력도 발열도 거의 오르지 않습니다. 부하가 걸리는 순간 전력·발열이 치솟는 GPU 추론과 정반대 특성입니다.

한 가지 정직하게 밝혀둘 것: 램 모듈(DIMM) 자체의 온도 센서 값은 이번에 수집하지 않았습니다. 위 수치는 흡기·배기·CPU 패키지·HDD 온도까지입니다.

6최신 데스크톱과 나란히 세워보면

이 숫자가 어느 정도인지 감을 잡기 위해, 최신 데스크톱급 CPU에서 같은 빌드·같은 모델 파일(Qwen3-30B-A3B-2507 UD-Q4_K_XL)로 대조 측정을 했습니다. 대조군은 AMD Ryzen 9 9950X3D(16코어/32스레드) + DDR5 듀얼채널 96GB, 역시 GPU 미사용입니다.

구성스레드pp512tg128
데스크톱급 (Ryzen 9 9950X3D, DDR5)16 (물리)259.324.8
데스크톱급 (Ryzen 9 9950X3D, DDR5)32 (SMT)103.95.4
구형 서버 (Xeon Silver 4210, DDR4-2400)10 (물리)22.311.3

차이는 prefill 약 11.6배, 생성 약 2.2배. 코어 수 차이(16 vs 10)로는 설명이 안 되는 격차입니다. 갈린 건 코어가 아니라 메모리 세대, 즉 DDR4-2400과 DDR5의 대역폭 차이입니다.

그리고 여기서도 똑같이, SMT를 켠 32스레드는 생성이 24.8에서 5.4로 반토막 이하가 됐습니다. “스레드는 물리코어까지만”은 Intel이냐 AMD냐와 무관한 공통 법칙이었습니다.

그럼 구형 서버는 무의미할까요? 트레이드오프가 하나 남습니다. 데스크톱의 96GB에는 60GB 모델을 올리면 여유가 빠듯하지만, 램 256GB가 꽂힌 구형 서버에는 큰 모델이 아예 올라간다는 것 자체가 강점입니다. 속도의 데스크톱, 용량의 구형 서버인 셈입니다.

7정직한 결론: 어디까지 쓸 만한가

숫자를 다 본 뒤의 솔직한 판정입니다.

  1. 대화형 실시간 응답에는 부족하다.

    생성 11.3 t/s는 읽는 속도를 간신히 따라오는 수준이고, 그보다 아픈 건 prefill 22.3 t/s입니다. 긴 문서를 붙여 넣으면 첫 글자가 나오기 전에 수십 초를 기다려야 합니다.

    실시간 대화나 코딩 보조가 목적이라면 16GB급 보급형 GPU 한 장을 다는 쪽이 훨씬 현실적인 선택입니다. 그 급의 GPU가 실제로 어느 정도를 해내는지는 RTX 5060 Ti 실측 글에 정리해 뒀습니다. 용도가 다를 뿐, 그렇다고 CPU 추론이 무의미해지는 건 아닙니다. 다음 항목이 그 이유입니다.

  2. 기다려도 되는 일에는 충분히 쓸 만하다.

    야간 배치 요약, 문서 분류, 외부로 보낼 수 없는 비공개 데이터 처리처럼 사람이 앞에서 기다리지 않는 작업이라면 이야기가 달라집니다. 생성 11 t/s면 밤새 수십만 토큰을 만들고, 추가 전력은 +22W. 하룻밤 돌려도 전기요금 몇십 원 수준입니다.

  3. 세팅의 8할은 두 가지다.

    스레드는 물리코어 수만큼만, 모델은 활성 파라미터가 작은 것으로. 이 두 가지만 지켜도 같은 하드웨어에서 몇 배의 차이가 납니다.

“남는 서버로 무료 ChatGPT를 만들 수 있다”는 결론이었으면 좋았겠지만, 실측은 그렇게 말해주지 않았습니다. 대신 “조용하고, 전기 거의 안 먹고, 느리지만 꾸준한 야간 일꾼” 하나를 공짜로 얻을 수 있다는 게 이 실험의 정직한 결론입니다.

8직접 재보고 싶다면

재현은 어렵지 않습니다. 컴파일도 필요 없습니다.

  1. llama.cpp GitHub 릴리스에서 공식 CPU 프리빌드를 받습니다(이 글은 b10333 기준).
  2. Hugging Face에서 원하는 모델의 GGUF 양자화본을 내려받습니다. 램이 넉넉하면 Qwen3-30B-A3B 같은 활성 파라미터가 작은 MoE 모델부터 시도해 보세요.
  3. llama-bench -m 모델.gguf -t 물리코어수 를 실행합니다. pp512/tg128 두 숫자가 이 글의 표와 같은 지표입니다.
  4. 스레드 수를 물리코어의 절반, 물리코어, 논리 스레드 전체로 바꿔 보며 자기 CPU의 최적점을 찾습니다. 아마 물리코어 수 근처일 겁니다.

여러분의 서버에서는 몇 t/s가 나오는지, 이 글의 숫자와 비교해 보면 재미있을 겁니다. GPU 쪽 실측이 궁금하다면 RTX 5060 Ti 로컬 AI 벤치마크도 함께 보세요.

T

Treeru

웹 개발, IT 인프라, AI 솔루션 분야의 실무 인사이트를 공유합니다. 기업의 디지털 전환을 돕는 IT 파트너, Treeru입니다.

공유

관련 글

© 2026 TreeRU. All rights reserved.

본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.