본문으로 건너뛰기

© 2026 Molayo

GeekNews헤드라인2026. 06. 02. 10:04

10년 된 Xeon이면 충분하다

요약

10년 된 Intel Xeon 서버 환경에서 Gemma 4 모델을 효율적으로 실행하기 위한 하드웨어 최적화 전략을 다룹니다. 메모리 대역폭 병목을 해결하기 위해 추측 디코딩(Speculative Decoding)과 MoE 라우팅 최적화, 런타임 재패킹 기술을 활용하는 방법을 설명합니다.

핵심 포인트

  • LLM 추론의 핵심 병목은 연산 성능보다 메모리 대역폭임
  • 추측 디코딩을 통해 디코더 패스 횟수를 줄여 성능 향상 가능
  • MoE 모델의 경우 CPU 캐시 계층에 맞춘 라우팅 최적화가 필수적임
  • 런타임 재패킹으로 CPU 캐시 미스를 최소화하는 레이아웃 구성 필요

공개 가중치 AI의 접근성은 최신 GPU뿐 아니라 재활용 서버, 추론 엔진, 메모리 구조 이해에도 크게 좌우됨

2016년 Xeon 서버에서 Gemma 4 실행하기

하드웨어 조건과 병목

테스트 장비는 Intel Xeon E5-2620 v4 @ 2.10GHz, 물리 8코어/16스레드, AVX2 지원, AVX-512·AVX-VNNI·BF16 미지원, L3 20MiB, 총 L2 2MiB, 128GB DDR3 메모리, GPU 없음으로 구성됨

LLM 추론의 디코더 단계는 다음 토큰을 만들 때마다 모델 가중치를 RAM에서 CPU 캐시로 계속 가져와야 하므로, 순수 연산 성능보다 메모리 대역폭이 병목이 됨

ChatGPT 같은 도구에서 텍스트가 단어별로 흘러나오는 과정은 출력 토큰을 하나씩 생성하는 디코더 패스이며, 숨겨진 긴 추론 체인이 있어도 각 토큰마다 같은 디코더 패스가 필요함

이 병목은 Xeon뿐 아니라 H100에서도 중요한 성능 장벽으로 작용하는 메모리 장벽이며, DDR3 기반 CPU-only 환경에서는 더 크게 드러남

일반 llama-cli, ollama, 표준 llama-cpp 방식만으로는 이 환경에서 충분한 최적화 노출과 모델 지원을 얻기 어려워, ik_llama.cpp의 세부 플래그를 직접 조합해야 함

실행 명령과 핵심 최적화

전체 실행 구성

실제 실행은 gemma-4-26B-A4B-it-Q8_0.gguf 검증기와 MTP 드래프터 GGUF를 함께 쓰고, --spec-type mtp, --cpu-moe, --flash-attn on, --mlock, --run-time-repack 같은 플래그를 한 번에 적용함

블랙박스 도구에서는 이런 명령줄을 확인하기 어렵고, 오래된 하드웨어에서는 각 플래그의 역할을 이해해야 성능을 끌어낼 수 있음

일부 플래그는 적용되지 않거나 엔진이 조용히 우회할 수 있어 로그 확인이 필수임

추측 디코딩

--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune은 26B 검증기와 작은 MTP 드래프터를 묶어 최대 3개 토큰을 초안으로 만들고, 워크로드에 맞춰 체인 길이를 자동 조정함

추측 디코딩은 메모리 대역폭에 묶인 디코더 패스 수를 줄이는 소프트웨어적 우회로로 작동함

CPU에서는 작은 드래프터의 활성 계층이 L3 캐시에 들어갈 수 있고, 검증기는 캐시를 훨씬 넘어서므로 드래프터에 추가 연산을 쓰는 비용이 상대적으로 작음

CPU 환경에서는 검증기 가중치를 캐시로 계속 스트리밍하는 비용이 커, 추측 디코딩의 효과가 GPU보다 더 강하게 나타날 수 있음

CPU와 MoE 라우팅

Gemma 4 26B-A4B는 128개 전문가 중 토큰당 8개가 활성화되며, 전체 약 25.2B 파라미터 중 약 3.8B 활성 파라미터를 사용함

--cpu-moe는 CPU 캐시 계층에 맞춰 MoE 라우팅을 조정해, 128개 전문가 사이를 계속 이동하며 캐시를 비우고 DDR3에서 다시 가져오는 캐시 스래싱을 줄이도록 설계됨

--merge-up-gate-experts는 전문가 내부의 두 projection을 하나의 행렬 곱으로 합쳐 메모리 버스를 여러 번 오가는 비용을 줄이며, 로그의 fused_up_gate = 1로 적용 여부를 확인할 수 있음

-t 8은 물리 코어 수와 맞춘 설정이며, 이 작업은 DDR3 대기 시간이 병목이므로 16개 SMT 스레드까지 늘리면 처리량보다 스케줄링 비용이 커질 수 있음

--parallel 8은 병렬 실행 설정과 함께 물리 코어 중심의 CPU 활용을 맞추는 구성으로 쓰임

메모리 고정, 재패킹, KV 캐시

런타임 재패킹

--run-time-repack은 추론 직전에 가중치 행렬을 CPU 캐시 레이아웃에 맞게 메모리에서 재구성함

로그에는 Repacked 265 tensors가 출력되어 265개 텐서가 재배치됐음을 확인할 수 있음

일반 레이아웃의 가중치 행렬을 그대로 읽으면 CPU가 데이터를 어색한 조각 단위로 가져와 캐시 미스가 발생할 수 있음

시작 시 약간의 시간을 들여 메모리 배치를 바꾸는 대신, 실제 텍스트 생성 단계에서 메모리 대역폭을 최대한 쓰도록 만드는 최적화임

mlock과 스왑 방지

--mlock은 모델을 물리 RAM에 고정해 운영체제가 디스크로 스왑하지 못하게 하는 설정임

AI 가중치 27GB가 디스크로 스왑되면 다시 읽는 동안 생성 속도가 사실상 멈출 수 있음

로그에 failed to mlock 27628376064-byte buffer와 Try increasing RLIMIT_MEMLOCK ('ulimit -l' as root)가 나오면, 플래그 문제가 아니라 커널의 memlock 제한이 27GB 버퍼를 고정하기에 낮은 상태임

이는 LLM 고유의 문제가 아니라 기본 ulimit 설정에서 생기는 운영체제 제한이며, 블랙박스 도구는 해당 최적화를 요청하지 않는 방식으로 문제를 감출 수 있음

KV 캐시 배치

--no-kv-offload는 엔진이 KV 캐시를 GPU로 옮기려 하지 않도록 하는 설정임

KV 캐시는 현재 대화 문맥을 저장하는 단기 기억 역할을 하며, 새 토큰마다 전체 프롬프트를 다시 읽지 않게 해줌

일반적으로 AI 엔진은 읽기·쓰기가 잦은 KV 캐시를 더 빠른 GPU 메모리로 오프로드하려 하지만, 이 구성에는 GPU가 없으므로 하드웨어 버스 검색과 오류 가능성을 줄이는 편이 나음

이 설정은 KV 캐시를 가중치와 함께 시스템 RAM에 유지하도록 명시함

그래프 분할과 Attention 최적화

그래프 레이아웃

-sm graph -smgs -sas -mea 256 --split-mode-f32는 계산 그래프를 메모리 영역에 어떻게 배치하고 분할할지 제어하는 설정임

-sm graph는 계산 그래프를 수직으로 나눠 여러 프로세서나 메모리 영역이 같은 계층의 서로 다른 부분을 동시에 계산하는 방식을 목표로 함

기본 또는 대체 방식인 레이어 분할은 모델을 계층 단위로 나눠, 한 프로세서가 앞 계층을 계산한 뒤 다음 프로세서로 넘기는 구조라 일부 하드웨어가 대기할 수 있음

이번 실행 로그에는 Split mode 'graph' is not supported for Gemma4 external MTP => changing split mode to 'layer'가 출력되어, Gemma4 외부 MTP 구성에서는 그래프 분할이 지원되지 않아 레이어 분할로 안전하게 내려감

MTP는 네트워크 끝단의 수학적 연결을 더 복잡하게 만들기 때문에, 이 엔진은 아직 MTP 아키텍처를 안전하게 그래프 분할하지 못하는 상태임

-sas는 여러 물리 CPU 소켓 또는 NUMA 노드가 있는 서버에서 워크로드 분할 방식을 지정하는 플래그이며, 단일 CPU 시스템에서도 향후 다중 CPU 구성의 벤치마크 후보가 됨

--split-mode-f32는 분할된 계산 결과를 다시 합칠 때 중간 연결 지점에 32비트 부동소수점 정밀도를 사용해 반올림 오류로 인한 품질 저하를 막는 설정임

새 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과 1624GB RAM 컨테이너에서 Gemma 26B-A4B Q4를 돌리고 있고, 대략 812토큰/초가 나옴
큰 문맥이나 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 같은 플랫폼에서 정말 싸고 빠름
최첨단 모델보다 100500배 저렴한 경우가 많고, 토큰/초도 25배 빠른 경우가 있음

그 결과를 찾는 데 너무 오래 걸렸음. SSD에서도 모델을 돌릴 수 있다는 걸 생각하면 느린 RAM에서 실행 가능한 건 놀랍지 않음

종이와 연필, 공학용 계산기로도 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가 예전보다 훨씬 강하고 튼튼한 건지도 모르겠음

AI 자동 생성 콘텐츠

본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0