# 10년 된 Xeon이면 충분하다 > Clean Markdown view of GeekNews topic #30096. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30096](https://news.hada.io/topic?id=30096) - GeekNews Markdown: [https://news.hada.io/topic/30096.md](https://news.hada.io/topic/30096.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-02T09:54:38+09:00 - Updated: 2026-06-02T09:54:38+09:00 - Original source: [point.free](https://point.free/blog/gemma-4-on-a-2016-xeon/) - Points: 5 - Comments: 2 ## Topic Body - **Gemma 4 26B-A4B**를 2016년형 단일 Intel Xeon E5-2620 v4, DDR3 128GB, GPU 없는 서버에서 `ik_llama.cpp` 최적화로 읽기 속도 수준까지 실행함 - LLM 디코더 패스는 연산보다 **메모리 대역폭**이 병목이며, CPU는 다음 가중치를 RAM에서 캐시로 가져오길 기다리는 시간이 커짐 - `--spec-type mtp`, `--cpu-moe`, `--merge-up-gate-experts`, `--run-time-repack` 등은 **MTP 추측 디코딩**, MoE 라우팅, 캐시 친화적 메모리 배치로 DDR3 환경의 병목을 줄임 - 로그 기준 전체 메모리 요구량은 **82,355MiB**이며, 전체 262K 컨텍스트에서 가중치 약 25GB보다 KV 캐시 약 56GB가 더 큼 - `ollama` 같은 블랙박스 도구는 필요한 모델 지원과 세부 조정 노브가 부족하며, 오래된 하드웨어에서는 추론 엔진과 메모리 구조를 깊게 이해해야 성능을 끌어낼 수 있음 --- ### 실행 환경과 핵심 병목 - 테스트 서버는 재활용 장비이며, 사양은 Intel Xeon E5-2620 v4 @ 2.10GHz, 8코어 16스레드, AVX2, 20MiB L3 캐시, 2MiB L2, 128GB DDR3, GPU 없음 - 이 CPU는 AVX-512, AVX-VNNI, BF16을 지원하지 않고, 통합 GPU도 없음 - LLM 추론에서 토큰을 하나씩 생성하는 디코더 패스는 주로 연산량이 아니라 메모리 대역폭에 묶임 - 다음 토큰을 계산하려면 모델의 학습 지식이 담긴 가중치를 RAM에서 CPU 캐시와 코어로 계속 옮겨야 하며, 프로세서는 행렬 계산보다 다음 가중치 이동을 기다리는 시간이 커짐 - 이런 “메모리 벽(memory wall)”은 Xeon뿐 아니라 H100 같은 고성능 장비에서도 중요한 성능 장벽으로 작동함 ### 블랙박스 도구 대신 필요한 실행 노브 - 단순히 DDR3·무GPU 환경에서 `llama-cli`를 실행하면 매우 느리고, 일반 GPU 사용 사례에 맞춘 최적화 때문에 많은 개선 여지가 남음 - `ollama`는 필요한 모델 지원이 없을 수 있고, 실행 성능을 제대로 끌어올릴 만큼 충분한 세부 설정을 노출하지 않음 - 실제 실행은 `ik_llama.cpp`가 노출하는 다수의 플래그를 조합해야 가능함 - 핵심 플래그 묶음은 다음과 같음 ```bash --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune -sm graph -smgs -sas -mea 256 --split-mode-f32 -t 8 --parallel 8 --cpu-moe --merge-up-gate-experts --flash-attn on --mla-use 3 --mlock --run-time-repack --no-kv-offload ``` ### 추측 디코딩과 MoE 최적화 - `--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune`는 26B 검증기(verifier)를 이전에 만든 작은 MTP 드래프터와 함께 사용함 - `--draft-max 3`는 드래프트당 최대 3토큰, `--draft-p-min 0.0`은 모든 확률 수용, `--spec-autotune`은 워크로드에 맞춰 체인 길이를 조정함 - 긴 추론 체인을 생성할 때 사용자에게 최종 답변만 짧게 보이더라도, 숨겨진 사고 토큰마다 전체 디코더 패스가 필요함 - CPU에서는 검증기 가중치를 캐시로 스트리밍하는 비용이 크고, 작은 드래프터의 활성 레이어는 L3 캐시에 잘 맞기 때문에 추측 디코딩의 이점이 더 강해짐 - Gemma 4 26B-A4B는 128개 전문가 중 토큰당 8개가 활성화되는 MoE 구조이며, 전체 약 25.2B 파라미터 중 활성 파라미터는 약 3.8B임 - `--cpu-moe`는 CPU 캐시 계층에 맞춰 라우팅을 조정하고, 128개 전문가 사이를 계속 오가며 캐시를 비우고 DDR3에서 다시 가져오는 캐시 스래싱을 줄이도록 동작함 - `--merge-up-gate-experts`는 전문가 내부의 up projection과 gate projection을 하나의 행렬 곱으로 융합하며, 로그에는 `fused_up_gate = 1`로 확인됨 - `-t 8`은 물리 코어 8개에 맞춘 설정이며, 메모리 병목 워크로드에서 16개 SMT 스레드를 모두 쓰는 것은 처리량보다 스케줄링 비용을 늘릴 수 있음 ### 메모리 고정, 재배치, 그래프 분할 - `--run-time-repack`은 추론 직전 가중치 행렬을 CPU 캐시 레이아웃에 맞게 재구성하며, 로그에는 `Repacked 265 tensors`로 나타남 - 이 설정은 시작 시 몇 초의 비용을 들여 RAM 안의 숫자 테이블을 CPU가 더 잘 읽을 수 있는 형태로 재배치하고, 실제 텍스트 생성 중 메모리 대역폭을 최대한 활용하게 함 - `--mlock`은 모델을 RAM에 고정해 운영체제가 디스크로 스왑하지 못하게 하는 설정임 - 커널의 memlock 제한이 충분하지 않으면 `failed to mlock 27628376064-byte buffer`와 `Try increasing RLIMIT_MEMLOCK` 경고가 나오며, 이는 LLM 자체 문제가 아니라 기본 `ulimit` 설정 문제임 - `--no-kv-offload`는 GPU가 없는 환경에서 KV 캐시를 GPU로 옮기려는 탐색을 건너뛰고, 시스템 RAM에 유지하게 함 - `-sm graph`는 계산 그래프를 세로로 나눠 여러 처리 장치나 메모리 영역이 같은 레이어의 다른 부분을 동시에 계산하도록 하는 그래프 분할을 시도함 - 이번 실행에서는 `Split mode 'graph' is not supported for Gemma4 external MTP` 로그와 함께 레이어 분할로 안전하게 낮춰짐 - `-sas`는 물리 CPU 소켓 또는 NUMA 노드 간 워크로드 분할을 지시하고, `--split-mode-f32`는 분할 후 다시 결합되는 중간 지점에 32비트 부동소수점 정밀도를 쓰게 함 ### Attention, 메모리 사용량, 결론 - [ikawrakow](https://github.com/ikawrakow)는 CPU에서 Flash Attention을 처리하는 커스텀 커널을 작성해, 무거운 컨텍스트 처리에서 GPU 없이 동작하게 함 - `--flash-attn on`은 attention softmax와 행렬 곱을 융합해 전체 N×N attention 행렬을 RAM에 물리적으로 쓰지 않고, 작은 청크 단위로 캐시 안에서 계산하고 소비하게 함 - `--mla-use 3`은 Multi-Head Latent Attention을 활성화해 KV 캐시의 Key와 Value를 더 작은 잠재 표현으로 압축함 - 로그에는 `flash_attn = 1`, `fused_moe = 1`, `fused_up_gate = 1`이 표시되어 해당 최적화가 실제로 적용됨 - 메모리 로그 기준 전체 레이어 합계는 81,607.46MiB이고, 모델 텐서와 캐시에 필요한 메모리는 82,355MiB임 - 전체 262K 컨텍스트에서 가중치는 약 25GB, KV 캐시는 약 56GB로, KV 캐시가 모델보다 큼 - 이 설정은 25B 파라미터 MoE를 로드하고 MTP 드래프터로 추측 디코딩을 수행해, 2016년형 Xeon과 DDR3, GPU 없는 서버에서 읽기 속도로 텍스트를 생성함 - 결론은 최신 오픈 가중치 AI의 로컬 실행 병목이 실리콘만이 아니라 추론 엔진의 동작과 메모리 구조를 이해하는 데 있으며, 올바른 포크, 보정된 양자화, 메모리 아키텍처 이해가 있으면 오래된 서버에서도 실행 가능하다는 것임 ## Comments ### Comment 58784 - Author: neo - Created: 2026-06-02T09:54:39+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48353348) - 새 **Gemma 4 Drafter** 모델을 실행할 방법이 부족하고, 주류 도구들이 성능 조절 지점을 숨긴다는 답답함 때문에 글을 썼음 결국 GPU 없이 단일 Xeon E5-2620 v4와 128GB DDR3 RAM만 있는 오래된 재활용 서버에서 최신 26B MoE 모델을 읽기 속도로 돌리는 데 성공함 글 끝에 양자화 모델도 링크했지만, 언급한 **ik_llama-cpp** 포크를 쓰지 않으면 실행되지 않을 것이고 자세한 내용은 다른 글을 봐야 함 머신러닝 엔지니어는 아니고 서버도 Nix 캐시 역할로 바쁘지만, 질문이 있으면 가능한 범위에서 답할 수 있음 - 메모리 대역폭에 묶인 작업이라면 SMT가 오히려 전형적으로 유용한 경우 아닌지 궁금함 한 스레드가 DDR3를 기다리는 동안 다른 스레드가 실행될 수 있기 때문임 또한 `--cpu-moe` 설명도 이해가 잘 안 됨. 전문가 하나가 약 4.0GiB 파라미터를 갖고 있는데, L3 캐시가 20MiB뿐이라면 전문가 순서를 최적화해도 파라미터를 유의미하게 캐시하지 못할 것 같음 다른 사람들이 말했듯 Intel Xeon E5-2xxx v4 중 일부만 DDR3를 지원했고, Intel 자료상 **E5-2620 v4**는 그중 하나가 아님 - 정말 실용적으로 훌륭한 성과임. 비슷한 Dell T7610 워크스테이션에서도 비슷하거나 더 나은 성능이 나올지 궁금함 듀얼 Xeon과 128GB DDR3 구성이고, CPU는 총 24코어/48스레드의 2 × Xeon E5-2697 v2라 코어 수는 더 좋지만 실제 차이는 크지 않을 수도 있음 먼지만 쌓이고 있는 장비인데, **읽기 속도 Gemma**라면 꽤 기대됨 - 2년 전에 Amazon에서 리퍼 **2× E5-2690v4** 서버, 128GB RAM, Dell T7810을 500달러 미만에 샀음 Amazon에서 “chia farming”을 검색하되 chia seeds는 지나치면 됨 지금은 같은 장비가 2.5배쯤 비싸졌지만, 현세대 DDR5 머신보다는 훨씬 저렴함 [https://www.amazon.com/dp/B095TRGCSX]() - 정말 DDR3가 맞는지 의문임. 집에 **E5 v4** 장비가 두 대 있는데 둘 다 DDR4라서, 혹시 2011-3 소켓이 DDR3와 DDR4를 모두 지원하는 건지 헷갈림 - 이 구성은 내 상황에 딱 맞아 보임 `Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz`, 온라인 CPU 0-31, 128GB RAM 구성임 DIMM 슬롯이 8개면 실제로도 메모리 대역폭이 더 좋아지는지 궁금함. 지금 이 불쌍한 장비는 YouTube 시청용으로만 쓰이고 있음 - 아직 거기까지는 아니지만, 지금의 거품이 끝나는 명백한 종착점은 **로컬 하드웨어와 기기에서 돌아가는 공개 모델**이 대부분의 용도에 “충분히 좋음”이 되는 것임 그렇게 되면 현재 기술 업계에서 벌어지는 일이 완전히 무너질 수 있음 - 나에게도 이미 그런 일이 생김. CoPilot 가격 변경을 계기로 구독을 취소하고, VRAM 안에서만 도는 **로컬 코딩 모델**을 설치했음 정말 막힐 때는 Claude API를 부르겠지만, 필요의 80%는 더 멍청한 로컬 모델로 처리할 수 있을 듯함 프로그래밍 언어와 기법은 크게 바뀌지 않으니 최소 5년은 쓸 수 있길 기대하고, 같은 VRAM에 더 똑똑한 모델을 넣도록 최적화되면 그때 업그레이드하면 됨 이 방향이 마음에 듦 - Amazon 입장에서는 공개 모델을 돌리고 실행 비용에 가까운 가격으로 시간 단위를 파는 게 유리하지 않을까 싶음 하지 않는 이유를 추측하자면, 현재 AI 연구소들이 모델을 큰 손실로 팔고 있어서 Amazon이 저마진 컴퓨팅을 쓰기엔 다른 고마진 상품보다 매력이 낮기 때문일 수 있음 현재 상태가 무너지기 위해 꼭 로컬 실행까지 갈 필요는 없을지도 모름. AI 연구소들의 공짜 돈 활주로가 끝나고 실제 실행 비용보다 높은 가격으로 팔아야 하면, 컴퓨팅을 가진 누구든 **공개 모델 서비스**를 범용 가격으로 더 싸게 제공할 유인이 생김 - OpenAI와 Anthropic은 궁극적으로 AI 회사라기보다 **컴퓨팅 인프라 사업**에 가까움 모두가 모델을 갖고 실행할 능력을 갖게 될 것이고, 그래서 GPU 부족이 이들에게 유리하게 작용함 - 새로 탄생한 조 단위 가치 회사들에게는 최악의 시나리오임 이들의 희망은 기업과 중소기업이 모든 업무 프로세스를 클라우드로 옮기고, 직원들이 토큰을 최대한 많이 쓰도록 경쟁하는 데 달려 있음 - 완전히 무너진다고까지 말하진 않겠지만, 그 방향으로 가는 건 분명함 “충분히 좋은” 모델에 프라이버시와 장기 비용 절감이 붙으면 매력적임 역설적으로 코딩 에이전트용 범용 실행 환경이 좋아질수록 Claude 같은 서비스의 해자는 줄어듦. 몇 달 전 최전선 모델을 일부 공개 모델이 얼마나 빨리 따라잡았는지 믿기 어려울 정도임 - 글도 좋고 기술적으로도 인상적임. 빌드 파이프라인을 이해하고 로컬에서 실행할 수 있어야 한다는 데 동의함 다만 전기요금에 따라 경제성이 없을 수 있음. 오래된 서버는 에너지 효율이 낮고, 예전 Xeon 서버는 부하 시 200W쯤 먹을 거라 생각했는데, 같은 모델은 OpenRouter에서 100만 토큰당 0.1/0.3달러, 76토큰/초, 262k 문맥으로 제공됨 게다가 이런 서버는 시끄러움. 다만 200W 추정은 너무 높았던 것 같고, 예전에 쓰던 구형 Xeon 서버들이 전기를 많이 먹었지만 정확한 모델은 기억나지 않음 - **2620v4**는 전기를 빨아먹는 괴물이 아님. 서버 보드에 따라 다르지만 서버가 꼭 그렇지도 않음 서버는 대체로 시끄럽지만 그것도 구성에 따라 달라짐. 이런 칩을 기반으로 한 저가 호스팅이 많고, 생각보다 전력 효율이 좋음 - 부하 시 **85W**에 더 가까울 것임. 저가형 쿨러에서도 매우 조용하고, 온도도 50°C를 좀처럼 넘지 않음 - 1U나 2U에 넣으려면 필요한 정압을 만들기 위해 고속 팬이 필요해서 이런 서버가 시끄러운 것임 비슷한 구성을 4U 케이스와 느린 120mm 팬으로 돌리면 괜찮음 - 다른 사람들도 이걸 깨닫는 걸 보니 반가움. 2012년식 Xeon과 16~24GB RAM 컨테이너에서 **Gemma 26B-A4B Q4**를 돌리고 있고, 대략 8~12토큰/초가 나옴 큰 문맥이나 GPU 실행과 비교할 수는 없고, llama.cpp의 이미지 디코더도 GPU보다 훨씬 느리지만 작은 자동화 작업이나 일반 상식 질문에는 괜찮음. 읽으면서 따라갈 수 있을 정도라 기다림이 덜함 구성은 OpenBLAS와 OpenMP를 켠 `llama.cpp` 빌드, `OPENBLAS_NUM_THREADS=4`, `OMP_NUM_THREADS=4`, `unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL`, `q8_0` 캐시, 8192 문맥 같은 설정임 CPU별로 AVX2 같은 최적화를 찾아봐야 하고, MTP는 잠깐 써봤지만 성능 향상은 없었음. 캐시·문맥 배치 크기를 조절하거나 Q2까지 낮출 수도 있고, 스레드 과다 할당은 피하는 게 좋음. 기본값이나 `llama-bench`부터 시도하는 편을 권함 - 지금 **프랑켄슈타인 시스템**을 만들고 있음. 중국산 DDR3 X99 보드, 12코어 Xeon v3, 32GB 1866MT/s RAM, 1080 Ti 구성임 테스트 중에는 11GB VRAM에 완전히 들어가는 `gemma4:e4b-it-q4_K_M`을 돌렸고 50토큰/초를 넘겼음. 그 정도 작은 모델은 코딩에는 유용하지 않지만 다른 용도는 있을 수 있음 Wake-on-Use를 만들어 개인 ChatGPT처럼 쓰고 싶음. Pi를 프록시로 두고 Wake-on-LAN 스크립트를 호출하는 식이 가능할지도 모르겠고, 언젠가 재미있는 주말 프로젝트가 될 듯함 항상 켜두는 LLM은 12GB 2060에 절반도 못 올리는 dense `Gemma4:31b`인데 매우 느리지만 품질은 좋고, 자동 큐 처리 용도라 출력만 바라보고 있지는 않음. 2060이 하나 더 있지만 둘 다 꽂으면 PC가 POST를 못 함 - llama와 로컬 컴퓨팅 얘기로, 며칠 전 **Georgi Gerganov**가 Mac M2 Ultra나 RTX 5090에서 로컬로 Qwen3.6 27B를 돌려 llama.cpp 개발을 보조하고 있다고 트윗했음 - 한동안 Mac Studio Pro를 고민하다가 결국 이 길로 왔음. **HP Z620** 헤드리스 머신에 192GB ECC RAM, 듀얼 Xeon E5-2680 v2, Optane AIC, 10GB VRAM P102-100 두 장, Debian 12.6이 올라간 최소 부팅 SSD, Pascal 카드를 지원하는 고정된 구버전 CUDA를 구성함 지하실에서 AMT/meshcommander로 원격 사용하고, `llama.cpp`와 프런트엔드를 띄운 뒤 로컬 네트워크로 접속함. Talkie, Qwen 3.6 27b, medgemma를 만져보고 있고, 적절한 양자화를 고르면 GGUF 성능은 전반적으로 괜찮았음 총비용은 500달러 미만이었지만 작년에 eBay에서 산 서버라 지금은 다를 수 있음 앞으로 **삼진법 LLM**이 꽃피면 이 오래된 하드웨어가 사실 지식이 꽉 찬 고밀도 모델을 호스팅할 수 있길 기대함. GPU RAM보다 커서 Optane으로 넘쳐도 괜찮고, 속도보다 일반 사실 지식이 중요함 최종 계획은 설정 후 지하실 Faraday 쓰레기통에 보관해, 세상이 무너졌을 때 “문명 재건”용 오라클로 남겨두는 것임. 물론 그런 상황에서는 전력이 문제겠지만, 이 하드웨어가 이렇게 싸고 최신 AI가 실용적인 순간이 많다면 시도할 만함 - AI 발전에서 가장 흥미로운 건 AGI나 특정 AI 유니콘의 최신 모델이 아니라, **로컬에서 무엇을 돌릴 수 있느냐**임 6년 전에는 고사양 게이밍 PC에서 재미는 있지만 별 쓸모없는 모델을 돌렸는데, 지금은 M5 노트북에서 그보다 100배 나은 걸 돌릴 수 있음 시장이 메모리 부족에 반응하고 Apple silicon 발전이 같은 속도로 계속된다면, 6년 뒤 로컬에서 돌릴 수 있는 것은 매우 흥미롭거나 무서울 것임 이것이 AI 회사들의 밸류에이션에 무엇을 의미하는지도 모르겠음. 예전에 행사에서 그 회사 직원에게 비슷한 질문을 했더니 답하지 않고 칵테일을 가지러 가버렸음 - 말하면 안 되는 것들이 있음. AI 모델 사업에는 지속적이고 방어하기 쉬운 기술 우위인 **해자**가 없고, 단기 우위만 있음 AI 사업은 오래된 공장처럼 자본집약적임. 데이터센터는 비싸고, 모델은 전기를 많이 먹고, 내부 하드웨어는 3~4년마다 교체해야 함 더 작고 특화된 모델이 아래에서 마진을 갉아먹음. 전사, 음성, 이미지 감지에는 거대 모델이 필요 없음 전통적 소프트웨어 사업처럼 높은 마진을 기대할 이유가 없고, AI의 이익은 대부분 소비자에게 감. 다만 Microsoft, Google, Amazon, Meta 같은 몇몇 거대 기업은 규모의 경제로 비용 우위를 노릴 수 있음 - 소비자 하드웨어에서 로컬로 돌릴 수 있는 수준은 꽤 잘 발전하고 있음 5080 같은 최상급은 아니지만 괜찮은 게이밍 GPU만 있어도 2025년 초 최첨단보다 나은 로컬 모델을 돌릴 수 있음 원하는 작업에 따라 모델을 바꿔야 할 수 있고, 하나로 다 되는 초거대 모델은 아직 데이터센터 영역임 - 결국 **편의성**의 문제임. Wikipedia부터 소셜 미디어, 이메일, 비디오 서버까지 많은 것을 로컬에서 돌릴 수 있음 하지만 정규직에 아이 둘이 있는 대부분의 사람은 패치하고 유지보수할 시간과 에너지가 없음. 시스템은 계속 복잡해지고 버그도 늘어남. 자유와 편의 사이의 오래된 절충임 - AI 회사 밸류에이션에는 아마 별 영향이 없을 것임 대부분의 사용자는 LLM이 무엇인지, 어떻게 실행되는지 모름. 많은 LLM 사용자는 직장에서 제공하는 것을 기본으로 쓰고, 조금 더 능숙한 사용자도 OpenAI나 Anthropic 구독료를 내는 데 괜찮아 보임 로컬 LLM을 선호하는 작지만 헌신적인 공개 가중치 모델 사용자층은 생기겠지만, 나머지는 큰 공급자에게서 소비할 가능성이 큼. 오늘날 운영체제 선택처럼 소수의 Linux 사용자와 대다수의 Windows, macOS, Chrome 사용자 구도와 비슷할 수 있음 - 소프트웨어, 특히 게임에서는 항상 그랬음 5~6년 된 게임은 훨씬 싸게 살 수 있고 평범한 하드웨어에서도 돌릴 수 있음. 하지만 업계가 5년 동안 가만히 있지는 않아서, 더 나은 하드웨어가 필요한 새 소프트웨어가 계속 나옴 - 원글 작성자가 댓글에서 밝힌 결과는 약 **12토큰/초**임 이 하드웨어에서 가능하리라 생각한 것보다 훨씬 인상적인 노력이지만, 만족스러운 대화형 세션에 필요한 수준에는 아직 꽤 모자람 - 특히 이런 작은 모델은 OpenRouter 같은 플랫폼에서 정말 싸고 빠름 최첨단 모델보다 100~500배 저렴한 경우가 많고, 토큰/초도 2~5배 빠른 경우가 있음 - 그 결과를 찾는 데 너무 오래 걸렸음. SSD에서도 모델을 돌릴 수 있다는 걸 생각하면 느린 RAM에서 실행 가능한 건 놀랍지 않음 - 대화형으로 아주 나쁘지는 않음: [https://mikeveerman.github.io/tokenspeed/?rate=12&mode=text]() 백그라운드 용도라면 충분히 괜찮을 것임 - 종이와 연필, 공학용 계산기로도 RSA 암호화를 할 수는 있음 작동은 하지만 진지한 작업에 쓸 처리량은 아님 - **E5-2620 v4**는 훌륭함. 10년째 쓰고 있고, 업그레이드하려다 현재 가격을 보고 멈췄음 64GB DDR4에 RX 9060 XT 16GB를 붙였는데 게임도 여전히 빠르게 돌아감. DOOM The Dark Ages에서는 CPU가 약간 병목일 수 있지만 60fps라 문제 없음 가벼운 LLM을 GPU에서 돌리는 건 당연한 선택이고, CPU에서도 튜닝하면 괜찮게 돌릴 수 있다는 게 멋짐 한 달 전에 2667 v4를 30달러에 샀고 성능 향상이 꽤 있을 것 같지만 아직 필요가 없었음. 글처럼 LLM 쪽으로 밀어붙인다면 2667이 조금 더 빠른 RAM을 처리할 수 있어서 업그레이드할 듯함 - 듀얼 **E5 2667-v4**, 256GB DDR4, Z640, 1080 Ti 구성인데 2025년 상반기에 SSD를 제외한 부품을 모두 합쳐 500달러 미만에 구했음 중고 시장에서 찾을 수 있는 것들에 아직도 꽤 놀람 RAM과 GPU 가격이 이렇게 폭등할 줄 몰랐는데 우연히 타이밍이 좋았음. eBay에서 300달러 안팎의 3080을 잡고 1080 Ti를 팔까도 생각하지만, 그 외에는 훌륭한 업그레이드였음 전기는 Coca Cola처럼 빨아먹지만 워크스테이션으로는 훌륭하게 동작해서, 고장 날 때까지 몰아붙일 생각임 - CPU를 10년 쓰는 건 정말 길게 느껴짐 예전에는 열로 인한 손상이 5~7년쯤 지나면 CPU를 죽인다고 생각했는데, 그게 틀린 가정인지 궁금함. 요즘 CPU가 예전보다 훨씬 강하고 튼튼한 건지도 모르겠음 - 구형 Xeon 최적화와 관련해 최근 비슷한 글이 있었음 “High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440” [https://news.ycombinator.com/item?id=47320244]() - 의외로 **Itanium**도 LLM에 꽤 잘 맞는 듯함: [https://medium.com/@tglozar/running-llama-inference-on-intel...]() 생각해보면 그럴 만함 ### Comment 58808 - Author: cronex - Created: 2026-06-02T13:11:56+09:00 - Points: 1 - Parent comment: 58784 - Depth: 1 내용이 재밌네요. 구형 제온 시스템이 있는데 한번 시도해봐야겠습니다.