AMD 라이젠 X3D 프로세서에 탑재된 3D V 캐시는 3D 게임 성능을 대폭 올려주는 기능이라고 알려져 있습니다. 여기서 '기능이다'도 아니고 '기능이라고 알려져 있다'라고 썼다는 점에 주목해 주세요. X3D가 나온지 하루 이틀 된 것도 아니고, 그 동안 X3D의 우수함과 그 효능을 증명하는 벤치마크가 뻔히 다 나와 있는데 이렇게 쓴 의도가 무엇일까요? 글은 간결하게 쓸수록 좋다는 기본 소양조차 갖추지 못한 사람이라서? 아니면 제정 러시아 시절의 작가들처럼 글자 수대로 돈을 받으니까 조금이라도 분량을 늘리려고? 둘 다 아닙니다. X3D는 게임만을 위한 프로세서가 아니라서 저렇게 썼습니다. 

X3D의 본질에 대해 생각해 봅시다. 어떤 CPU 회사처럼 코드를 분석해 재구성해서 아키텍처에 맞춰주는, 좋게 말하면 최적화고 나쁘게 말하면 꼼수 아닌가 싶은 기능이 아니고요. 그냥 솔직하고 정직하게 캐시 용량을 늘린 것이 전부입니다. 물론 그 노력을 '캐시 용량을 늘린 것이 전부'라고 폄하해선 안 됩니다. 그 방법이 곧 기술력을 증명하고 있거든요. 다이에 포함된 캐시를 늘려서 수율을 떨어트리고 생산성을 낮추는 방법이 아니라, 대용량 캐시가 필요한 모델에만 캐시 다이를 적층해서 용량을 늘리는 선택지를 추가했고요. 2세대 3D V 캐시에서는 적층 방식을 바꿔 열 발산 문제를 해결해 기본 클럭을 더 높이고, 더 안정적으로 작동할 수 있도록 개선하기도 했습니다. 

다만 3D V 캐시 구조의 기술적인 분석이나, 대용량 캐시를 도입하면서 따라오는 생산 단가의 상승 같은 경제적인 부분을 떼어 놓고요. 3D V 캐시의 본질적인 부분만 바라보면 결국 CPU에 대용량 캐시를 더한 것입니다. 게임이라는 애플리케이션의 특성상, CPU 가까이에 위치한 대용량 캐시 메모리의 효과를 유독 크게 볼 뿐이며, 실제 게임 환경에서 그 우수성이 증명되서 3D V 캐시라면 곧 3D 게임을 떠올리게 된 것이지, 이게 오직 게임만을 위해서 탄생한 기능이라고 단정지어서는 안 됩니다. 대용량 캐시가 탑재된 CPU일수록 유리한 애플리케이션이 있다면, 3D V 캐시가 탑재된 CPU 역시도 당연히 유리하다고 봐도 될 것입니다. 그리고 그런 사례가 하나 있습니다. LLM의 RAG입니다. 

LLM는 뭐고 RAG는 뭔가요

(주제에 맞춰서 AI로 생성한 이미지입니다)

요새 유행인 AI에 관심이 많은 분들이라면 LLM(Large Language Model)이란 단어를 한 번쯤은 보셨을 겁니다. 말 그대로 대규모 언어 모델을 가리킵니다. 매개변수의 규모가 크고 합습된 데이터의 양이 많아 높은 성능을 보여주지요. AI를 사용하는 사람이 LLM에 질문하면 그 텍스트를 토큰으로 바꿔서 문맥을 파악해 대답할 단어들을 만들어 변환해 보여줍니다. 

다만 LLM은 학습된 데이터 안에서만 대답을 찾아서 보여줄 수 있습니다. 2026년 1월까지의 기글하드웨어를 싹싹 긁어서 학습한 LLM이라면 2026년 4월의 최신 뉴스나 리뷰에 나온 내용을 제대로 대답할 수가 없죠. 환각 가득한 헛소리나 늘어 놓던가요. 그래서 여기에서 나오는 것이 RAG(Retrieval-Augmented Generation)입니다. AI 사용자가 질문을 하면 외부에서 검색을 하고(벡터 DB 검색), 검색된 문서와 질문을 토대로 대답을 만들어 줍니다. 

(주제에 맞춰서 AI로 생성한 이미지입니다)

일반적으로 AI는 방대한 수의 병렬 코어가 탑재된 그래픽카드를 주로 사용한다고 알려져 있습니다. 하지만 모든 작업을 다 그래픽카드가 하는 건 아닙니다. 앞서 말한 벡터 검색처럼 사전 준비 작업의 상당수는 CPU가 처리하거든요. 다수의 검색 요청이 들어왔는데 CPU가 이를 제때 처리하지 못한다면, 전체 AI 처리 과정 중에서 상당한 병목 현상을 초래할 수도 있습니다. 

여기까지 보셨다면 AI 워크로드에서 CPU가 중요하다는 점은 이해가 되실 겁니다. 하지만 이 글의 주제는 '좋은 CPU를 쓰자'가 아니라 'X3D가 좋다'지요. 왜 X3D일까요? 그건 대용량 캐시 메모리가 HNSW(Hierarchical Navigable Small World) 검색 알고리즘에 유리하기 때문입니다. HNSW는 그래프 노드를 랜덤하게 탐색하면서 비슷한 문서를 찾습니다. PC 환경에서 그래픽카드의 GPU를 LLM 추론에 할당할 경우 HNSW 벡터 검색은 CPU에 할당하게 됩니다. 접근 속도가 빠르고 용량이 큰 대용량 캐시(3D V 캐시)가 있다면 HNSW 탐색 중 자주 참조되는 그래프 노드 데이터를 가져오기 위해 시스템 메모리까지 액세스하는 빈도가 줄어드니, 자연스레 성능이 오르게 됩니다. 

그래서 그걸 어떻게 확인하는데?

위에서 열심히 설명했지만 그래봤자 '이론적으로는 그렇다'는 주장에 불과하고요. 그게 정말 신빙성을 갖추려면 테스트를 해서 숫자로 보여줘야 되겠지요. 마침 이런 용도로 쓰기 위해 만들어진 벤치마크가 있습니다. x3d-rag-benchmark라고 하고요. 이름부터 X3D 시리즈 프로세서의 성능이 매우 잘 나올 것 같다는 분위기를 풍기고 있지만, 그렇다고 AMD에서 만든 공식 프로그램 같은 건 아니고 깃허브에 올라온 오픈소스 벤치마크입니다. https://github.com/sorrymannn/x3d-rag-benchmark

위 깃허브 페이지에 설치 방법이 나와 있는데요. 파이썬을 설치하고, Git을 설치하고, 벤치마크를 다운받고, 패키지를 깔끔하게 관리할 수 있도록 가상 환경에서 벤치마크를 실행하면 벡터 검색과 인덱스 구축 테스트를 진행하게 됩니다. 만약 여기에서 Concurrent RAG과 Data Feeding 테스트까지 더 하고 싶다면 지포스 그래픽카드를 장착해서 CUDA와 Ollama를 설치해야 합니다. 

리눅스에서 설치하는 게 깔끔하다고는 하는데 저같은 컴맹한테 그건 너무 어려운 과정이니 윈도우에서 테스트를 진행했습니다. 대신 윈도우를 클린 설치하고 업데이트를 마친 후 업데이트를 일시 정지하는 등, 계산에 영향을 줄 만한 요소들은 일체 배제했고요. CPU의 성능을 가늠하는 벤치마크지만 RAG 전체 테스트와 GPU를 활용한 데이터 임베딩을 위해 지포스 RTX 5080을 장착했습니다. 또 테스트 벡터를 유지하기 위해, 처음 생성한 캐시 파일 폴더를 다른 CPU 테스트에서도 계속해서 사용했습니다. 

x3d-rag-benchmark에서는 HNSW 알고리즘 기반으로 구성된 메타의 FAISS 벡터 검색 엔진을 사용해 위키피디아의 실제 문서를 임베딩해와(all-MiniLM-L6-v2) 테스트를 수행합니다. 데이터베이스 크기는 100K와 200K의 두 가지가 있으며, 배치 검색은 10번 반복을, RAG와 빌드는 5번 반복 측정해서 편차를 줄입니다. 첫 번째 토큰이 생성되는데 걸리는 시간인 TTFT는 당연히 빠를수록 좋고요. 나머지 모든 값은 클수록 좋습니다. 

자세히 보기

 

https://www.python.org/downloads/ 에 접속속해서 파이선 인스톨 매니저를 다운로드받습니다.

 

 

인스톨 파이선을 눌러주고요.

 

 

터미널이 열리면서 질문을 하는데 Open Installed apps now?, Add commands directory to your PATH now?, Install CPython now?에 모두 Y를 선택해 줍니다.

 

 

설치 후 파워쉘을 실행해 python --version 라고 쳤을 때 버전을 표시해 주면 파이썬의 설치가 정상적으로 끝난 것입니다. 

 

 

이제 git을 설치해야 합니다. https://git-scm.com/install/windows 에 접속해서 하나 받아야 하는데, 모를 때는 그냥 Click here to download라고 써진 걸 고르면 가장 대중적인 픽을 골라줍니다.

 

 

 

git의 설치는 다음다음다음다음설치 버튼만 누르면 됩니다. 따로 바꾸거나 확인할 게 없습니다.

 

 

이것도 파워쉘에서 git --version 이라고 쳤을 때 버전을 표시하면 성공적으로 설치된 것입니다. 

 

 

이제 cd ~/Desktop 로 바탕화면으로 이동하고, git clone https://github.com/sorrymannn/x3d-rag-benchmark 를 입력해 벤치마크 데이터를 다운로드받으면 바탕화면에 x3d-rag-benchmark 라는 폴더가 생깁니다. 파일을 받아야 하니까 시간이 좀 걸립니다.

 

여기서 벤치마크를 바로 실행해도 되지만, 저는 RAG 전체 테스트까지 하기로 마음 먹었으니 그래픽카드를 장착하고 CUDA와 Ollama를 설치하기로 했습니다. 먼저 NVIDIA 그래픽카드 드라이버를 설치해야 하는데 이건 기본중에 기본이니 넘어가고요.

 

 

https://developer.nvidia.com/cuda-downloads 에 접속해서 CUDA 툴킷을 받습니다. 운영체제와 아키텍처, 버전에 맞춰서 골라야 하는데 저는 윈도우, x86+64, 버전 11, exe(local)을 골랐습니다.

 

 

쿠다 설치는 다음 버튼만 계속 누르면 되니 어려울 건 없고요.

 

 

파워쉘에서 nvcc --version 라고 쳐서 쿠다 버전 정보가 나오면 된겁니다.

 

 

이제 Ollama를 받아야 합니다. https://ollama.com/download 에서 운영체제에 맞는 버전을 골라 받으세요. 

 

 

설치 후 Ollama가 실행이 됐네요.

 

 

파워쉘에서 ollama --version 로 설치가 잘 됐는지 확인

 

그럼 이제 ollama pull llama3.2로 RAG테스트용 모델을 다운로드받습니다. 

 

 

이제 테스트를 해 봅시다. 파워쉘에서 벤치마크가 저장된 폴더로 이동합니다. cd C:\Users\Test\Desktop\x3d-rag-benchmark 그리고 정책 에러가 뜰 수도 있으니 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned 를 돌려주고 python -m venv venv와 .\venv\Scripts\Activate 를 실행해서 가상 환경을 생성해 줍니다. 이래야 충돌이 안 나고 패키지 관리가 쉽다고 하더라고요.

 

 

테스트 실행 명령어는 python benchmark.py --output 이름.json 입니다. '이름.json'이라는 파일을 만들고 거기에 결과값을 저장하는 것이니 매번 다른 이름을 지정해 줄 필요가 있습니다.

X3D의 효과는 굉장했다

이 글은 'X3D가 RAG에서 효과가 좋더라'는 썰로 시작했습니다. 그러니 당연히 X3D의 유무를 비교할 수 있는 CPU를 골라야죠. 그래서 3D V 캐시가 없는 8코어 프로세서인 라이젠 7 9700X와 16코어 프로세서인 라이젠 9 9950X, 3D V 캐시가 있는 8코어 프로세서인 라이젠 7 9800X3D와 라이젠 7 9850X3D, 16코어 프로세서인 라이젠 9 9950X3D를 비교했습니다. 그리고 AMD CPU를 테스트하면 인텔 CPU도 비교를 해야죠. 인텔의 현 세대 플래그쉽인 코어 울트라 9 285K, 최신형 모델이자 일부 성능은 285K보다도 낫다는 평을 듣는 코어 울트라 7 270K 플러스를 테스트했습니다. 

100K와 200K의 두 가지로 나뉜 배치 검색은 CPU의 모든 코어를 사용해서 뽑아낸 1초당 벡터 검색량을 보여줍니다. 이 설명만 보면 인텔의 코어 울트라가 더 유리할 수도 있다고 생각할 수도 있지요. P코어와 E 코어를 섞었다고는 하지만 어쨌건 표면적인 코어 수가 더 많거든요. 물론 실제로는 그런 거 없고 그저 X3D가 들어간 모델이 압도적인 성능을 보여줍니다. 그 다음의 인덱스 빌드 시간 역시 마찬가지입니다. 초기 데이터를 구축하고 이를 갱신하는데 걸리는 시간을 의미하는데요. 여기에서도 3D V 캐시가 탑재된 모델들이 눈에 보일 정도의 큰 차이를 달성했습니다. 

Concurrent RAG Throughput부분에서도 3D V 캐시가 탑재된 CPU의 장점은 계속됩니다. 8개의 workers가 동시에 벡터 검색과 LLM 응답을 처리해내는 테스트로, 실제 사용 환경에 가까운 테스트 항목인데요. 여기에서는 1개의 CCD에 3D V 캐시를 적층한 라이젠 7 9800X3D와 라이젠 7 9850X3D가 우수한 성능을 보여 주었습니다. 다만 이 테스트에선 GPU 추론에 걸리는 시간이 훨신 큰 비중을 차지하기 위에서 테스트한 검색이나 빌드보다는 격차가 줄어드는 경향이 있습니다. TIFT도 마찬가지로 GPU의 영향이 크기에 CPU 사이에 차이가 크진 않지만, 그래도 AMD 라이젠 프로세서가 전반적으로 빠른 응답 속도를 보여주었습니다.  

자세히 보기

 

Batch Search 100K(QPS)
 

 

Batch Search 200K(QPS)
 

 

Index Build 100K(vec/s)
 

 

Index Build 200K(vec/s)

 

 

Throughput(req/s)
 

 

평균 TTFT(낮을수록 좋음)

물론 이번 테스트는 제한된 조건에서 이루어진 것이고, AI의 활용 방식과 방법이 다양한 만큼 테스트 조건에 따라서 다른 결과가 나올 수도 있습니다. 가령 라이젠 7 9700X의 경우 캐시 용량이 비슷한 코어 울트라 200 시리즈와 비교에서 벡터 검색량은 뒤쳐졌지만 RAG 응답은 더 좋은 결과를 보여주었고요. 평균 TTFT 시간은 3D V 캐시가 달린 것, 그렇지 않은 것을 불문하고 모든 라이젠 프로세서가 우수한 성적을 기록했습니다. 그러니 테스트 규모나 설정을 바꾼다면 이번 테스트와 다른 결과가 나올 수도 있을 것입니다. 

설령 그렇다 하더라도 3D V 캐시가 탑재된 프로세서의 성능은 분명 뛰어나며, 그 근거 역시 명확합니다. 본격적인 LLM 추론은 아직까진 GPU의 비중이 절대적이지만, RAG를 처리하는 과정 중에서는 CPU가 참여하는 부분 역시 무시할 수 없습니다. 벡터 검색, 인덱스 구축, 동시 처리 등의 분야에서는 이를 효율적으로 처리할 CPU의 아키텍처와 함께 자주 사용하는 대용량 데이터를 가까이에서 가져올 수 있는 대용량 캐시의 역할이 절대적입니다. 앞으로 RAG처럼 AI 처리에서 CPU의 활용처가 늘어난다면, 라이젠 9000X3D 시리즈는 더 이상 게이밍 전용 CPU가 아니라 AI에서도 탁월한 성능을 위한 CPU로 평가받게 될 겁니다.  

<저작권자(c) 기글하드웨어(https://gigglehd.com) 무단전재-재배포금지>

기글하드웨어 인기글