15대 서버 임베딩 인프라 설계 — CPU 선택부터 아키텍처 분류까지

RAG 시스템이 확장되면 임베딩 연산이 병목이 됩니다. GPU를 붙이자니 비용이 크고, 아무 서버에나 올리자니 어떤 서버가 적합한지 기준이 없었습니다. 보유 중인 15대 서버에서 실제 임베딩 속도를 전수 측정하고, CPU 선택 기준, RAM·NVMe의 영향 여부, 서버별 배치 우선순위를 정리했습니다. 도구 소개가 아닌, 인프라 설계 관점의 기록입니다.

왜 임베딩 인프라를 설계했는가

로컬 LLM 서비스가 안정화되면서 다음 병목은 임베딩이었습니다. 사용자 질의를 벡터로 변환하고, 문서를 사전 인덱싱하고, 실시간 검색을 지원하려면 임베딩 서버가 안정적으로 응답해야 합니다.

초기에는 GPU 서버에 임베딩까지 올렸습니다. 하지만 GPU는 LLM 추론에 묶여 있어 임베딩 요청이 대기하는 경우가 생겼습니다. 반대로 유휴 CPU 서버가 여러 대 있었습니다.CPU 임베딩으로 전환하면 GPU를 LLM에 전담시키고, 임베딩은 여유 CPU 서버에 분산할 수 있습니다.그 전제로 “어떤 CPU가 임베딩에 얼마나 적합한가”를 측정했습니다.

임베딩에 GPU는 필요 없다

가장 먼저 확인하고 싶었던 것은 “CPU 임베딩이 실용적인가”입니다. LLM 추론과 비교해서 임베딩이 전체 응답 시간에서 차지하는 비중을 계산했습니다.

N100을 제외한 모든 서버에서 임베딩 레이턴시는 LLM 추론 대비 6% 미만이었습니다. 병목은 임베딩이 아니라 LLM 추론입니다. GPU를 임베딩에 투입하는 것은 자원 낭비입니다.CPU 임베딩으로 충분하며, GPU는 LLM 전담으로 유지하는 것이 옳습니다.

N100은 예외입니다. 481ms는 LLM 응답 대기 대비 최대 24%를 차지합니다. 이 경우 임베딩이 체감 가능한 병목이 됩니다. N100은 프록시나 경량 서비스 전용으로 운용하고, 임베딩 서버로는 배치하지 않기로 결정했습니다.

CPU 아키텍처별 성능 비교

15대 서버에 탑재된 CPU는 7종입니다. BGE-M3 기준 short text(30자) p50 레이턴시와 지속 처리량을 기준으로 정렬했습니다.

9950X3D — 압도적 1위

16코어 Zen 5 아키텍처의 9950X3D가 65.0ms, 148.7 items/s로 가장 빠릅니다. 2위 H255(70.9ms)와의 격차는 8.3%로 크지 않지만, 처리량은 49%나 높습니다. 배치 병렬 처리에서 코어 수의 이점이 더 크게 나타납니다. 현재 AI GPU 서버에 탑재되어 있어 임베딩과 LLM 추론을 동시에 처리 중입니다.

H255 — 균형 잡힌 2위

인텔 H255는 4대가 있으며, 4대 평균 70.9ms로 9950X3D와 큰 차이가 없습니다. 미니PC에 내장된 구성임에도 BGE-M3 기준 100 items/s에 근접하는 처리량을 보입니다. 9950X3D 다음으로 임베딩 전담 서버로 배치하기 적합한 후보입니다.

5825U — 범용 6대

Zen 3 기반 5825U가 6대로 가장 많습니다. 118ms는 H255 대비 66% 느리지만, 처리량 46/s는 단순 요청 처리에는 충분합니다. 한 대가 부족하면 여러 대에 분산하는 방식으로 운용합니다.

N100 — 임베딩 비권장

N100은 4코어 저전력 CPU로 481ms, 5.8 items/s를 기록했습니다. 2위 H255 대비 6.8배 느립니다. 경량 서비스나 리버스 프록시 역할에는 적합하지만, 임베딩 서버로는 부적합합니다.

RAM·NVMe는 성능에 영향 없다

서버마다 RAM 용량, 브랜드, NVMe 종류가 다릅니다. 이것이 임베딩 성능에 영향을 줄까요? 동일 CPU가 탑재된 서버들을 그룹으로 묶어 비교했습니다.

5825U 그룹 (6대)

H255 그룹 (4대)

이유는 명확합니다. 임베딩 추론은 모델 가중치가 CPU L3 캐시에 상주한 채로 반복 연산합니다. 추론 중 메모리 버스나 NVMe를 거의 사용하지 않기 때문에 RAM/NVMe 사양이 성능에 영향을 주지 않습니다.NVMe는 최초 모델 로딩 시간에만 관여합니다. 서버가 한 번 기동되면 이후 추론 속도와는 무관합니다.

실질적 결론: 임베딩 서버를 새로 구성할 때 RAM 브랜드나 NVMe 등급에 예산을 쓰지 않아도 됩니다.CPU 선택에 집중하면 됩니다.

텍스트 길이별 레이턴시 변화

임베딩 모델의 레이턴시는 입력 텍스트 길이에 비선형적으로 증가합니다. short(30자), medium(150자), long(500자) 세 구간을 측정했습니다.

9950X3D는 long 텍스트에서도 1.7배 증가로 가장 선형에 가깝습니다. 반면 N100은 500자에서 2,650ms로 5.5배 증가합니다. 문서 인덱싱처럼 긴 텍스트를 대량 처리하는 워크로드에서는 CPU 차이가 더욱 벌어집니다.

RAG 시스템 설계 시 참고사항: 사용자 질의 임베딩(short, 실시간)과 문서 인덱싱(long, 배치)을 분리하는 것이 좋습니다. 실시간 질의 처리에는 저레이턴시 서버를, 배치 인덱싱에는 처리량이 높은 서버를 배치합니다.

하이퍼스레딩의 함정

멀티스레드 임베딩에서 HT(하이퍼스레딩)를 활성화하면 어떻게 될까요? 논리 코어 수만큼 스레드를 늘리면 성능이 올라갈 것 같지만, 실제 결과는 반대였습니다.

9950X3D에서 논리 코어(32T)로 스레드를 늘리면 물리 코어(16T) 대비 22배 성능이 저하됩니다. 임베딩 연산은 각 스레드가 CPU 캐시와 연산 유닛을 집중적으로 사용하기 때문에, 물리 코어를 공유하는 HT 스레드는 서로 경쟁하며 처리량을 떨어뜨립니다.

설정 기준: 스레드 수 = 물리 코어 수.임베딩 서버를 배포할 때 OMP_NUM_THREADS나 torch.set_num_threads()를 물리 코어 수로 명시적으로 설정하는 것이 좋습니다. 기본값으로 논리 코어 수를 사용하면 성능이 역전됩니다.

# 물리 코어 수 확인 (HT 제외)
lscpu | grep "Core(s) per socket"

# 임베딩 서버 기동 시 스레드 수 명시
OMP_NUM_THREADS=8 python embedding_server.py

# Python 코드 내에서 설정
import torch
torch.set_num_threads(8)  # 물리 코어 수

온도와 쿨링 — 지속 부하에서도 안전한가

임베딩 서버는 24/7 지속 부하가 걸립니다. 온도가 임계치를 넘으면 서멀 스로틀링으로 성능이 저하됩니다. 30초 연속 임베딩 부하에서 온도 변화를 측정했습니다.

모든 서버에서 30초 지속 부하 후에도 서멀 스로틀링 임계치(보통 90~100°C)에 한참 미치지 않았습니다. 특히 5825U와 N100은 미니PC 내장 쿨링임에도 +5°C, +4°C 상승에 불과합니다. 이 계열 CPU의 TDP가 낮아 소형 쿨링으로도 충분합니다.

9950X3D는 유휴 시 58°C로 이미 높지만, 이는 GPU 서버와 같은 케이스에 있어 주변 온도가 높기 때문입니다. 부하 시 73°C로 여유가 있습니다. 단, 서버실 환경이 고온이라면 타워쿨러 이상의 쿨링을 권장합니다.

서버 분류 체계 — Tier 1/2/3

측정 데이터를 기반으로 임베딩 워크로드 적합성에 따라 서버를 3개 Tier로 분류했습니다.

임베딩 인프라 설계 체크리스트

이번 측정을 통해 도출한 임베딩 인프라 설계 원칙을 정리합니다.

임베딩 인프라 설계는 생각보다 단순합니다. CPU만 잘 고르면 되고, 나머지 변수는 영향이 없습니다.N100처럼 극단적으로 낮은 성능의 CPU만 피하면 대부분의 서버에서 LLM 파이프라인 병목 없이 임베딩을 처리할 수 있습니다.

벤치마크 도구 제작 과정과 스크립트 상세는 CPU 임베딩 벤치마크 도구 글을 참고하세요. 서버 전반 모니터링 체계는 Grafana + Prometheus 모니터링 글에서 다룹니다.