🧩 CPU

AMD CCX와 Infinity Fabric

개요

AMD의 CCX(Core Complex)는 여러 Zen 코어와 공유 캐시를 묶는 논리적 locality 단위다. 다만 CCX의 코어 수와 공유 L3 범위는 Zen 세대에 따라 바뀐다. Zen과 Zen+에서는 4코어 CCX 두 개가 8코어 die를 구성했고, Zen 2에서는 CCD 안에 4코어 CCX 두 개가 배치되었다. Zen 3부터는 8코어가 하나의 unified complex와 32MB L3를 공유하는 방향으로 바뀌어, 같은 CCD 안의 core-to-core 및 core-to-cache 경로가 단순해졌다.

Infinity Fabric은 CCX라는 블록 자체가 아니라, 코어·캐시·CCD·I/O die·메모리·다른 소켓 또는 가속기를 연결하는 AMD의 인터커넥트 계열이다. 따라서 "CCX 사이의 버스"로만 이해하면 안 된다. 같은 CCD 안의 cache access, CCD와 IOD 사이의 메모리 요청, 소켓 사이의 coherent traffic은 서로 다른 물리 경계와 지연을 가질 수 있지만, 모두 제품별 Infinity Fabric 계층을 통해 조정된다.

이 문서는 공개된 AMD Zen·EPYC 자료를 바탕으로 세대별 grouping과 패키지 경로를 분리해 설명한다. AMD는 제품별 exact route, buffer, arbitration, link width와 cache directory 구현을 모두 공개하지 않으므로, 고정 cycle 수나 모든 Ryzen·EPYC에 같은 topology가 적용된다고 일반화하지 않는다.

핵심 개념

1. CCX, CCD, IOD와 Infinity Fabric

용어를 같은 계층의 부품으로 취급하면 Zen 2 이후의 칩렛 구조를 잘못 해석하게 된다.

용어	역할	locality 관점	주의할 점
CCX	Zen 코어와 공유 L3를 묶는 core complex	공유 L3와 코어 간 접근의 기본 단위	코어 수와 L3 용량은 세대별로 다름
CCD	CPU 코어와 L2/L3를 담는 compute die	여러 코어가 같은 die와 cache fabric을 공유	Zen 2의 CCD는 두 CCX, Zen 3 이후는 unified complex 모델로 설명되는 경우가 많음
IOD	메모리 컨트롤러, PCIe와 외부 링크 등 I/O 기능을 수용하는 die	CCD 밖의 메모리·I/O 접근 경계	제품과 세대에 따라 기능 배치가 다름
Infinity Fabric	die 내부·die 간·소켓 간 트랜잭션 운반과 제어	hop, queue, link와 protocol 경계를 포함	하나의 고정 bus나 단일 속도 규격이 아님
Data Fabric	coherent data와 주소·응답 traffic을 처리하는 fabric 기능 계층	cache, memory와 I/O transaction의 경로	구현 명칭과 관측 범위는 제품별로 다를 수 있음
Control/management fabric	전원, 초기화, 상태와 관리 트래픽을 운반	성능 data path와 다른 control 경로	공개 자료가 없는 내부 세부를 고정 모델로 쓰지 않음

CCX는 무엇을 함께 캐시하고 가까이 처리하는가를 설명하는 단위이고, Infinity Fabric은 그 단위들이 어떻게 서로 통신하는가를 설명하는 계층이다. CCD도 topology 이름이 아니라 die 경계를 나타내는 packaging·compute 단위다. 예를 들어 Zen 2 EPYC에서는 여러 CCD가 중앙 IOD에 연결되는 hub-and-spoke 모델로 설명할 수 있지만, 이것이 모든 AMD 제품의 유일한 Infinity Fabric 배치라는 뜻은 아니다.

2. Zen 세대에 따른 CCX의 변화

세대	대표 grouping	공유 L3의 공개된 대표 구성	Infinity Fabric 관점
Zen / Zen+	4코어 CCX, 8코어 Zeppelin die에서는 CCX 두 개	CCX당 8MB	die 안의 CCX와 메모리·I/O 경계를 연결하는 fabric이 CCX 간 locality 차이를 만든다
Zen 2	CCD당 4코어 CCX 두 개, 최대 8코어	CCX당 16MB, CCD당 32MB	CCD와 별도 IOD 사이의 링크가 메모리·I/O 및 다른 CCD 접근의 중심 경로가 된다
Zen 3	CCD당 최대 8코어 unified complex	8코어가 32MB L3를 공유하는 모델	같은 CCD 안의 과거 CCX 경계가 사라져 core-to-core locality가 개선된다
Zen 4	일반 Zen 4 CCD당 최대 8코어	CCD당 32MB L3가 대표 구성	최대 96코어 Genoa와 12채널 DDR5 같은 서버 규모에서 CCD-IOD locality가 중요하다
Zen 4c / Zen 5c	밀도 최적화 compute complex	제품별 cache 구성과 코어 수를 확인해야 함	코어 밀도와 전력 목표가 달라 같은 cache·frequency 모델을 재사용하면 안 됨
Zen 5	표준·dense compute die 조합	제품 SKU와 variant에 따라 다름	최신 EPYC에서도 chiplet과 I/O 분리의 이점은 유지되지만 exact fabric은 제품별로 확인해야 함

Zen 2의 "CCD당 32MB L3"는 16MB L3를 가진 4코어 CCX 두 개의 합이다. 한 CCX의 cache가 다른 CCX에서 바로 동일한 locality로 보인다는 뜻은 아니다. Zen 3의 unified complex는 8코어가 하나의 32MB L3에 직접 접근하는 구조적 변화를 의미하므로, 단순히 총 L3 용량만 비교해서는 세대 차이를 설명할 수 없다.

3. Infinity Fabric의 연결 범위

Infinity Fabric의 기능을 한 층으로 그리지 말고 물리적 경계별로 나눠야 한다.

Core·cache fabric: 코어의 L1/L2 miss와 L3 lookup, coherence request를 같은 CCD 안에서 운반한다.
CCD-to-IOD fabric: compute die의 memory request와 I/O request를 IOD의 memory controller, PCIe 또는 다른 service endpoint로 전달한다.
CCD-to-CCD 경로: remote L3, owner cache 또는 다른 CCD의 home에 접근한다. Zen 2 EPYC의 hub-and-spoke 설명에서는 이런 traffic이 IOD를 경유하는 경로가 기본 분석 모델이며, direct CCD link라고 일반화하지 않는다.
Socket-to-socket fabric: 다중 소켓 EPYC에서 remote memory와 cache-coherent request를 다른 소켓으로 전달한다. 이 경계는 on-package hop과 다른 NUMA 비용을 만든다.
Accelerator/package fabric: 일부 AMD 제품에서는 GPU 또는 accelerator와의 package link가 Infinity Fabric 계열 이름으로 설명된다. CPU cache coherence 여부와 link의 peak bandwidth는 제품별로 따로 확인해야 한다.

4. Locality의 네 단계

동일한 cache-line access라도 source와 home의 물리적 거리가 다르면 결과가 달라진다.

access 범위	주요 경로	일반적인 비용 요인	software 관점
동일 CCX/complex	core → local L3 → core	tag lookup, local arbitration, shared-cache 경쟁	thread 간 공유 데이터 배치에 유리
동일 CCD	core → CCD cache fabric → 다른 core 또는 L3	core-to-core route, cache state 처리	Zen 3 unified complex에서 이전 CCX 경계보다 단순
다른 CCD, 같은 socket	source CCD → IF → IOD 또는 package fabric → destination CCD	link hop, IOD queue, remote L3/home, response path	CPU affinity와 cache sharing을 함께 고려
다른 socket	local CCD/IOD → socket link → remote IOD/CCD	socket link, remote home, NUMA와 queueing	`numactl`, ACPI distance와 memory placement가 중요

locality가 낮아질수록 지연이 단조롭게 증가한다고 단정할 수는 없다. local L3가 바쁘고 remote L3가 유휴 상태일 수도 있으며, address hash가 home을 고르게 분산할 수도 있다. 반대로 여러 코어가 한 IOD, memory controller 또는 response path를 공유하면 평균 hop이 짧아도 tail latency가 커질 수 있다.

5. Fabric, coherence와 memory의 경계

Infinity Fabric은 cache-coherence protocol과 동일한 개념이 아니다. coherence controller가 line의 state, owner와 sharer를 관리하고, fabric은 그 판단에 필요한 request, snoop, invalidate, data forwarding과 acknowledgement를 운반한다. AMD 제품의 구체적인 directory와 probe filter 동작은 세대·제품별 공개 범위가 다르므로, MOESI state 이름만 보고 fabric path를 복원할 수 없다.

메모리 요청은 보통 다음과 같은 계층을 지난다.

core miss
  -> local L2 / L3 lookup
  -> home 또는 coherence service 선택
  -> Infinity Fabric을 통한 remote CCD 또는 IOD 전송
  -> memory controller / PCIe service
  -> data와 coherence response 반환

여기서 home은 주소와 coherence 정책에 따라 transaction을 조정하는 위치이고, data owner와 항상 같은 위치라는 보장은 없다. 따라서 CCD -> IOD -> DRAM이라는 경로는 memory miss의 개념 모델이지, 모든 cache hit·remote owner 경로의 완전한 설명은 아니다.

6. Clock, link와 유효 대역폭

Infinity Fabric의 성능은 "Infinity Fabric 속도" 하나로 표현할 수 없다. 링크 폭, 전송 횟수, fabric clock, power state, protocol overhead와 queueing을 함께 봐야 한다.

raw link capacity = link width × transfers per cycle × link frequency
effective payload = raw capacity × protocol efficiency

client Ryzen에서 자주 쓰이는 FCLK, UCLK, MCLK는 각각 fabric, memory controller와 memory clock을 분석하는 기준이다. 1:1 또는 2:1 동작은 특정 client generation과 memory setting에 종속되며, 모든 EPYC server fabric에 같은 tuning rule을 적용할 수 없다. 실제 측정에서는 memory data rate와 fabric clock을 분리해 기록해야 한다.

AMD는 공식 Zen 자료에서 Ryzen 3000의 Zen 2 Infinity Fabric bandwidth를 512-bit로 소개한다. 이 수치는 해당 client 설계의 공개 수치이므로, EPYC를 포함한 모든 세대와 제품의 link width 또는 sustained bandwidth로 일반화하지 않는다.

유효 bandwidth는 다음 항목으로 줄어든다.

request header, response와 coherence control traffic
link encoding, credit 또는 ready/backpressure
router·IOD·memory-controller queue
retry, error correction과 power-state transition
data가 아닌 snoop, invalidate, ownership acknowledgement

따라서 공개된 peak link rate를 곧바로 DRAM sustained bandwidth 또는 application throughput으로 읽으면 안 된다. EPYC 7002의 8채널 DDR4와 128 PCIe 4.0 lanes 같은 platform bandwidth도 CCD-to-IOD fabric, memory scheduling과 workload locality를 통과한 end-to-end 결과와 구분해야 한다.

비교/분석

1. CCX grouping과 package topology 비교

항목	Zen 1/Zen+	Zen 2	Zen 3 이후 unified CCD
기본 cache group	4코어 CCX	4코어 CCX	CCD당 최대 8코어 unified complex
CCD/die 해석	초기 die 안에 여러 CCX	CCD 안에 CCX 두 개	한 CCD의 코어가 하나의 큰 L3 group을 공유
L3 locality	CCX 경계가 명확	두 CCX 사이에 추가 locality 경계	CCD 내부 core-to-cache 경계가 단순해짐
다른 CCD 접근	die 또는 package fabric	별도 IOD를 중심으로 분석	IOD와 package fabric 경계는 여전히 존재
강점	작은 cache group, 모듈식 확장	compute와 I/O 공정 분리, 코어 수 확장	공유 데이터가 많은 workload의 CCD 내부 locality 개선
주의점	CCX 간 latency 차이	CCX·CCD·IOD 세 경계를 분리해야 함	unified L3가 remote CCD latency를 없애지는 않음

2. AMD fabric과 다른 CPU interconnect의 분석 단위

비교 축	AMD CCX + Infinity Fabric	Ring	2D Mesh
무엇을 먼저 설명하는가	cache grouping과 계층형 package fabric	ring stop 순회와 segment 경쟁	router grid와 link 병렬성
locality의 핵심	CCX/CCD/IOD/socket 경계	source-stop와 home slice 거리	Manhattan hop와 home agent 위치
확장 방식	CCD와 IOD chiplet 조합	stop, lane 또는 ring segment 추가	stop과 router grid 확장
대표 병목	IOD, remote CCD, socket link, memory service	ring segment, bridge, home slice	link hotspot, router queue, central cut
소프트웨어 영향	CCD/NUMA affinity와 memory placement	LLC slice locality	LLC/CHA와 mesh locality
고정 수치 해석	제품별 IF width·clock·route 필요	세대별 ring topology 필요	SKU별 stop·route·VC 필요

이 표는 Infinity Fabric이 Ring이나 Mesh보다 항상 빠르다는 뜻이 아니다. Ring과 Mesh는 주로 on-die topology를 분류하는 반면, Infinity Fabric은 core complex, die-to-die, socket link와 protocol 계층을 함께 묶는 AMD 제품군의 이름이다. AMD 제품 내부에도 local cache fabric과 package link의 topology가 동시에 존재할 수 있다.

3. Workload별 예상 병목

workload	주로 보는 locality	예상 병목	관측할 지표
private-cache friendly compute	동일 CCX 또는 CCD	local L3 capacity와 core 경쟁	L2/L3 miss, core-to-core latency
shared read-mostly data	동일 CCD와 remote CCD	remote L3/home 및 response path	local/remote access ratio, p99 latency
write-sharing lock 구조	여러 core와 coherence home	ownership, invalidate와 acknowledgement	coherence message 수, line migration
streaming memory	여러 CCD → IOD → MC	memory-controller queue와 DRAM timing	MC occupancy, read/write bandwidth, queue time
PCIe/DMA와 CPU 동시 부하	CCD → IOD	I/O egress와 fabric QoS	IOD traffic, DMA interference, tail latency
다중 소켓 NUMA workload	remote socket	socket link와 remote memory service	NUMA placement, remote ratio, socket-link utilization

4. 지연 모델과 성능 해석

단일 cache miss의 개념적 지연은 다음과 같이 분해할 수 있다.

L_total = L_core_detection
        + L_local_cache_lookup
        + L_home_or_coherence
        + L_IF_forward
        + L_remote_L3_or_memory_service
        + L_response_IF
        + L_queue_retry

여기서 L_IF_forward만 낮춰도 L_total이 반드시 낮아지지는 않는다. remote L3 또는 DRAM service가 지배적일 수 있고, IOD queue가 가득 차면 source CCD의 injection도 막힌다. 반대로 Zen 3의 unified L3는 같은 CCD 안의 일부 core-to-core 경로를 줄일 수 있지만, 다른 CCD나 socket까지 같은 latency를 제공하지 않는다.

Infinity Fabric을 측정할 때는 다음 네 경계를 고정해야 한다.

Network-only: link와 fabric traversal만 측정하는가?
Cache transaction: L2 miss부터 L3 또는 owner response까지 포함하는가?
Memory transaction: IOD, memory-controller queue와 DRAM service까지 포함하는가?
Application outcome: OS scheduling, NUMA placement와 synchronization wait까지 포함하는가?

경계를 섞으면 Zen 2의 CCX penalty, Zen 3의 unified L3 이득, memory clock 변경 효과를 서로 잘못 비교하게 된다.

동작 원리

1단계: Core가 요청을 생성한다

코어가 L1과 L2에서 cache miss를 감지하면 cache controller는 physical address, read/write 종류, ordering과 coherence attribute를 가진 transaction을 만든다. 요청은 우선 local cache complex의 queue에 들어간다. 이 시점의 대기와 Infinity Fabric에 첫 flit을 주입하기까지의 대기를 분리해야 한다.

2단계: Local CCX 또는 unified CCD가 lookup한다

Zen 2에서는 요청 core가 속한 CCX의 L3가 첫 번째 중요한 locality 경계다. 다른 CCX의 L3에 line이 있거나 home이 그쪽이면 같은 CCD 안에서도 추가 cache-fabric 경로와 coherence 처리가 필요하다. Zen 3 이후에는 8코어 unified complex가 하나의 32MB L3 group을 공유하는 구조로 설명되므로, 이 경계가 이전보다 단순해진다.

L1 miss
  -> L2 lookup
  -> local CCX 또는 unified CCD L3 lookup
  -> hit이면 data 반환
  -> miss이면 home/coherence route 생성

3단계: Home과 목적지 경로를 선택한다

주소 mapping과 coherence metadata는 line의 home, sharer와 owner를 결정하는 데 사용된다. 제품별 hash와 directory 구현은 공개 범위가 제한되므로, 코어 번호만으로 home CCD를 추정하지 않는다. 개념적으로 destination은 다음 정보를 포함한다.

destination = {
    home_or_directory,
    source_ccd,
    target_ccd_or_iod,
    request_class,
    coherence_state
}

remote CCD 접근은 Zen 2 EPYC의 중앙 IOD 모델에서 IOD를 경유하는 path로 분석하는 것이 안전하다. 다른 client·server 제품에서 direct 또는 다른 hierarchy가 있을 수 있으므로, 이 모델을 AMD 전체의 고정 배선으로 표현하지 않는다.

4단계: Infinity Fabric이 request를 운반한다

fabric의 arbitration은 local injection과 in-flight traffic, request와 response, data와 control class 사이의 경쟁을 조정한다. 구현별로 credit, ready/backpressure, priority 또는 age 정책이 결합될 수 있다. 다음 IOD·CCD·socket link의 buffer가 부족하면 backpressure가 source 방향으로 전파된다.

이 단계에서 확인할 항목은 다음과 같다.

source CCD와 target home 사이의 modeled hop 또는 link traversal
link와 gateway의 busy cycle 및 방향별 utilization
input/output queue occupancy와 credit stall
data, snoop, invalidate, acknowledgement의 traffic 비율
retry, error correction과 power-state transition

5단계: Coherence 또는 memory service가 실행된다

home/coherence agent는 line 상태에 따라 다음 중 하나를 선택한다.

local 또는 remote L3에 data와 permission이 있으면 해당 cache 경로에서 반환한다.
다른 CCD의 owner가 최신 line을 가진 경우 owner cache에 data forwarding 또는 ownership request를 보낸다.
line이 cache hierarchy에 없으면 IOD의 memory controller로 DRAM read/write를 전달한다.
write ownership을 얻어야 하면 필요한 sharer에 invalidate와 acknowledgement를 발행한다.
필수 response를 수집한 뒤 source core에 data와 새 coherence 상태를 반환한다.

data payload가 작아도 write-sharing에서는 invalidate와 ownership control traffic이 fabric을 점유할 수 있다. 반대로 streaming read에서는 coherence보다 IOD·memory controller와 DRAM timing이 병목이 될 수 있다. 두 workload를 같은 "Infinity Fabric latency"로 묶어 말하지 않는다.

6단계: IOD와 메모리·I/O 경계를 통과한다

memory miss가 IOD에 도착하면 memory controller가 channel, rank, bank와 row/column service를 스케줄한다. PCIe request는 I/O endpoint로 향하며, CPU cache coherence와 device ordering의 경계를 함께 처리한다. IOD는 여러 CCD의 요청이 모이는 fan-in 지점이므로, CCD 수와 코어 수가 늘어도 IOD service capacity가 그대로면 end-to-end bandwidth는 증가하지 않는다.

same-socket memory path
  = source CCD
  + Infinity Fabric traversal
  + IOD queue
  + memory-controller scheduling
  + DRAM service
  + response traversal

7단계: Response를 반환하고 locality를 관측한다

data 또는 coherence acknowledgement가 source complex로 돌아오면 request ID와 ordering rule에 따라 transaction을 완료한다. 운영·성능 분석에서는 lscpu -e, numactl --hardware, Linux perf, AMD uProf와 firmware topology 정보를 사용해 CPU affinity와 NUMA 배치를 확인할 수 있다. 다만 일반 OS 도구가 내부 IF queue와 exact route를 모두 노출한다고 기대해서는 안 된다.

최소 실험군은 다음과 같다.

동일 complex의 private/shared cache access
동일 CCD와 다른 CCD의 controlled address access
local memory와 remote NUMA memory 비교
read-mostly, write-sharing과 lock contention
CPU와 DMA/PCIe 동시 부하
uniform memory stream과 single-controller hotspot

각 실험에서 평균 latency뿐 아니라 p95/p99, local/remote 비율, memory-controller queue, per-link 또는 per-socket utilization과 전력 상태를 함께 기록해야 한다.

장단점

장점	단점 및 주의점
작은 compute die를 반복 조합해 코어 수와 제품 SKU를 확장하기 쉬움	CCD·IOD·socket 경계가 늘어 locality와 지연 분포가 비균일해짐
코어와 I/O를 서로 다른 공정·die로 분리할 수 있음	die-to-die link, IOD와 protocol의 전력·검증 비용이 추가됨
Zen 3 unified complex가 같은 CCD 안의 shared-data locality를 개선함	unified L3가 remote CCD·remote memory 비용을 없애지는 않음
여러 CCD와 memory controller를 병렬로 사용할 수 있음	IOD, memory controller, socket link가 fan-in 병목이 될 수 있음
fabric에 coherence, flow control, error와 power 관리 경계를 통합할 수 있음	exact route, queue와 arbitration이 공개되지 않아 성능 원인 분리가 어려움
EPYC에서 높은 코어 수·메모리 채널·I/O 확장을 지원	NUMA placement와 CPU affinity를 무시하면 remote access가 증가함
3D V-Cache와 dense compute variant 같은 제품 변형을 조합할 수 있음	cache capacity, frequency, thermal budget이 SKU마다 달라 단순 비교가 위험함

선택과 검증 기준

공유 데이터와 동기화가 같은 CCD 안에서 주로 발생하면 unified L3 locality와 core placement를 먼저 확인한다.
코어 수가 큰 server에서는 CCD-to-IOD link, IOD queue, memory-controller service와 NUMA distance를 함께 측정한다.
Infinity Fabric bandwidth를 비교할 때 link width·frequency·방향성·protocol overhead와 측정 경계를 명시한다.
Zen 2의 4코어 CCX 경계와 Zen 3의 unified 8코어 complex를 같은 cache locality 모델로 취급하지 않는다.
CCD 간 요청을 direct link로 단정하지 말고, 해당 제품의 공개 block diagram과 측정 결과로 IOD 경로를 확인한다.
AMD 공식 자료의 최대 코어 수나 memory channel 수를 fabric의 sustained application throughput으로 바꾸어 쓰지 않는다.
local/remote memory, read-sharing, write-sharing과 DMA interference를 별도 workload로 검증한다.

핵심 정리

CCX는 코어와 공유 L3를 묶는 cache locality 단위이고, CCD는 compute die이며, Infinity Fabric은 이 블록과 IOD·메모리·소켓을 연결하는 계층형 interconnect다.
Zen 2는 CCD당 4코어 CCX 두 개와 별도 IOD 구조가 핵심이며, Zen 3는 CCD 안의 8코어 unified complex와 32MB L3 공유로 locality 경계를 단순화했다.
같은 CCD, 다른 CCD, 다른 socket의 access는 서로 다른 IF·IOD·NUMA 경계를 가지므로 총 L3 용량이나 peak link rate만으로 latency를 판단할 수 없다.
성능 분석은 local cache lookup, home/coherence, IF traversal, IOD·memory service, response와 queue/retry를 분리하고 read-sharing·write-sharing·streaming workload를 별도로 측정해야 한다.
AMD 제품별 exact route, cache directory, link 폭과 arbitration은 공개 범위가 제한되므로, 세대별 공식 사실과 일반적인 hub-and-spoke 분석 모델을 명확히 구분해야 한다.