🧩 CPU

AMD 3D·이기종 Infinity Fabric

개요

AMD의 3D V-Cache는 CPU compute die 위에 추가 cache die를 수직으로 배치해, die 면적을 크게 넓히지 않고 특정 CCD의 cache capacity를 늘리는 패키징 방식이다. 이 방식에서 기본 CCD의 코어와 L3 cache, 추가 cache die, I/O die는 같은 package 안에 있어도 서로 다른 물리적 층과 전력·열 경계를 가진다. AMD Ryzen 7 7800X3D는 8코어와 96MB L3, Ryzen 9 7950X3D는 16코어와 128MB L3를 제품 사양으로 제시하며, 각각 package die count가 2와 3으로 표시된다.

여러 CCD를 쓰는 X3D 제품에서는 모든 compute resource가 같은 cache capacity와 frequency 특성을 갖지 않을 수 있다. 따라서 X3D를 단순히 전체 CPU의 L3가 커진 것으로만 읽으면 안 된다. 어느 코어가 cache-stacked CCD에 속하는지, standard CCD와의 동기화·coherence traffic이 어디에서 발생하는지, Infinity Fabric과 IOD가 remote access를 어떻게 운반하는지를 함께 봐야 한다. AMD가 공개하는 제품 사양은 총 cache와 package 구성을 보여주지만, SKU별 exact route·cache directory·queue·arbitration은 모두 공개하지 않으므로 이 문서는 공통 구조와 분석 모델을 구분한다.

핵심 개념

1. 3D V-Cache의 물리적 계층

3D V-Cache는 더 큰 단일 2D CCD와 다른 방식으로 cache capacity를 확장한다. 연산 logic가 있는 base CCD와 추가 cache die가 수직 연결되며, cache die는 코어를 실행하는 die가 아니라 cache capacity를 제공하는 계층으로 이해해야 한다. 실제 bonding, interconnect와 cache controller의 구현 세부는 제품 세대와 공개 자료에 따라 다르다.

계층	대표 역할	locality 관점	주의할 점
Base CCD	Zen core, private L1/L2와 기본 L3 slice	코어가 실행되고 local cache request를 생성하는 단위	X3D 여부와 관계없이 core·cache 경쟁이 존재함
Cache-stacked die	추가 L3 capacity 제공	같은 CCD의 cache hierarchy에 더 큰 working set을 수용할 여지	별도 compute core나 전체 CPU shared cache가 아님
X3D CCD	base CCD와 stacked cache를 결합한 locality group	cache hit 후보가 늘어 memory·remote fabric miss를 줄일 수 있음	cache capacity 증가가 모든 access의 latency 감소를 보장하지 않음
Standard CCD	수직 cache가 없는 일반 compute die	core와 base L3를 중심으로 local access 제공	X3D CCD와 cache capacity·열·frequency 정책이 다를 수 있음
IOD	memory controller, PCIe와 외부 I/O service	DRAM·device·socket의 경계	X3D cache를 대신하는 cache layer가 아님
Infinity Fabric	CCD, cache, IOD와 package/socket endpoint 사이 transaction 운반	request, data, coherence와 response의 물리적 경계	coherence protocol 자체나 단일 고정 bus가 아님

추가 cache가 같은 CCD의 주소 공간에 참여한다는 점과, 별도의 remote cache node라는 점을 구분해야 한다. 개념적으로는 core → local L3 hierarchy 안에 cache-stacked capacity가 추가되지만, 다른 CCD의 cache line이나 IOD의 memory service를 local로 바꾸지는 않는다.

2. 이기종 CCD의 의미

이 문서에서 heterogeneous는 ISA가 다른 big.LITTLE형 코어만을 뜻하지 않는다. 같은 Zen 계열 코어라도 CCD별로 stacked cache 유무, usable cache capacity, boost/frequency headroom, thermal condition과 preferred-core 특성이 다르면 fabric 관점에서 이기종 자원이 된다.

구분	X3D CCD	Standard CCD	시스템 영향
cache capacity	base L3 + stacked cache	base L3	working set과 memory miss 비율이 달라질 수 있음
compute	Zen core 실행	Zen core 실행	동일 ISA라도 주파수·전력 정책은 SKU별 확인 필요
physical stack	cache die가 base CCD 위에 연결	수직 cache die 없음	열 경로와 package 높이·조립 제약이 달라짐
shared data	local cache에 머물 확률을 높일 여지	remote 또는 DRAM으로 나갈 가능성이 상대적으로 커질 수 있음	thread와 data placement가 중요함
fabric traffic	cache capacity가 miss를 줄이면 외부 traffic 감소 가능	miss가 IF/IOD로 더 자주 나갈 수 있음	평균뿐 아니라 burst와 tail traffic을 측정해야 함
scheduling	cache-sensitive work에 적합할 수 있음	frequency-sensitive work에 적합할 수 있음	workload 특성과 OS/firmware 정책을 함께 확인

이 표는 모든 AMD X3D SKU의 정해진 동작 순서를 뜻하지 않는다. AMD Ryzen 9 9950X3D 공식 사양은 Zen 5, 16코어, 128MB L3와 package die count 3을 제시하고 2nd gen AMD 3D V-Cache를 명시한다. 그러나 total L3나 die count만으로 각 CCD의 stacked cache 배치, 내부 fabric route와 scheduler policy를 역산할 수는 없다.

3. Infinity Fabric이 담당하는 경계

3D stack의 수직 연결과 CCD·IOD 사이의 수평 연결은 서로 다른 문제다.

수직 cache path: base CCD가 cache hierarchy에서 추가 cache capacity를 조회한다.
CCD 내부 path: core, private cache와 shared L3 사이에서 local lookup과 coherence를 수행한다.
CCD-to-CCD path: 다른 CCD의 cache line, owner 또는 home에 접근한다.
CCD-to-IOD path: cache miss를 memory controller, PCIe 또는 외부 service로 보낸다.
socket/package path: 다른 socket, accelerator 또는 remote NUMA endpoint와 transaction을 교환한다.

따라서 X3D cache가 같은 CCD 안의 일부 miss를 흡수해도, remote CCD access의 IF hop과 IOD의 memory queue는 그대로 남는다. 같은 package라는 사실만으로 수직 cache access, 다른 CCD access와 DRAM access를 동일한 latency로 취급하지 않는다.

4. Cache capacity와 locality

추가 cache의 가장 직접적인 효과는 working set의 더 많은 부분을 cache hierarchy에 보관할 수 있다는 점이다. 그러나 capacity miss가 줄어드는 것과 hit latency가 줄어드는 것은 다른 효과다. cache tag/data lookup, cache contention, line state와 response path는 여전히 존재한다.

access 유형	대표 경로	3D cache의 영향	남는 비용
X3D CCD local hit	core → base L3/cache stack	DRAM 또는 remote CCD로 나갈 요청을 줄일 가능성	lookup, tag/data port, cache contention
standard CCD local hit	core → standard CCD L3	수직 cache를 사용하지 않는 local path	base L3 capacity와 local competition
다른 CCD cache hit	source CCD → IF/home → target CCD	source가 X3D여도 target CCD가 remote임	IF traversal, coherence와 response queue
memory miss	source CCD → IF → IOD → MC → DRAM	X3D hit이면 일부 miss를 줄일 수 있음	IOD queue, MC scheduling과 DRAM timing
write-sharing	source → home → owner/sharer	capacity보다 line ownership과 state가 중요	invalidate, acknowledgement와 migration

read-mostly workload에서는 X3D CCD의 larger cache가 유리할 수 있지만, 여러 코어가 같은 cache port와 fabric endpoint를 동시에 사용하면 contention이 생긴다. write-sharing workload는 cache capacity가 커도 line ownership 이동과 invalidate가 반복되므로, cache 크기만으로 성능을 예측하지 않는다.

5. 열·전력과 비대칭 frequency

수직 적층은 cache capacity를 늘리는 대신 열이 빠져나가는 경로, package 높이와 manufacturing test를 복잡하게 만든다. 특히 active compute die 위에 cache die가 놓이면 base CCD의 열 저항과 hotspot을 package·cooler 관점에서 함께 다뤄야 한다. 제품별 전력·온도·boost 정책은 공개 사양과 firmware에 따라 다르므로, 모든 X3D 제품에 같은 frequency penalty를 고정해서 쓰지 않는다.

이기종 CCD 시스템의 성능은 다음 세 정책의 결합으로 결정된다.

Placement: cache-sensitive thread와 working set을 어느 CCD에 둘 것인가?
Frequency: compute throughput이 중요한 thread를 어느 frequency headroom의 CCD에 둘 것인가?
Traffic: thread migration과 shared data가 CCD 간 coherence traffic을 얼마나 만드는가?

X3D CCD에 cache-sensitive workload를 배치하는 것이 항상 최선이라는 뜻도 아니다. working set이 cache에 들어가지 않거나 높은 single-thread frequency가 더 중요한 경우에는 standard CCD가 더 적합할 수 있다. 실제 선택은 benchmark, firmware topology와 OS scheduler 동작으로 검증한다.

6. Coherence와 cache visibility

3D V-Cache는 coherence protocol을 대체하지 않는다. base CCD와 cache-stacked die가 하나의 cache hierarchy로 동작하려면 tag, data, state, eviction과 fill이 일관된 규칙으로 처리되어야 한다. 다른 CCD가 같은 line을 읽거나 write ownership을 요구하면 Infinity Fabric은 request, data, invalidate, snoop과 acknowledgement를 운반한다.

개념적 transaction은 다음과 같이 쓸 수 있다.

request = {
    source_core,
    source_ccd,
    cache_level_or_stack,
    physical_address,
    read_or_write,
    home_or_coherence_service,
    target_ccd_or_iod,
    ordering_and_coherence_state
}

실제 home hash, probe filter, directory 위치와 data-forwarding policy는 SKU별로 공개 범위가 다르다. X3D cache가 있다는 사실만으로 line이 항상 stacked die에 있고, 모든 remote request가 같은 경로를 지난다고 가정하지 않는다.

비교/분석

1. Cache 확장 방식 비교

항목	큰 2D CCD	3D V-Cache 단일 CCD	이기종 3D CCD 조합
cache 확장	base die 면적과 배선 증가	cache die를 수직 추가	X3D CCD와 standard CCD를 package에 조합
compute 대칭성	비교적 단순한 동일 die 모델	한 CCD의 cache·열 특성이 다름	CCD별 cache·frequency·thermal 정책이 다름
local working set	base L3 용량에 제한	local capacity를 늘릴 여지	workload를 적합한 CCD에 placement해야 함
package 경계	주로 die 내부와 IOD	vertical link·bond와 열 경계 추가	vertical·horizontal·IOD 경계를 동시에 관리
remote access	CCD 수에 따른 IF 비용	다른 CCD·IOD 비용은 동일하게 존재	source/target CCD 조합에 따른 비대칭이 추가
software 관점	core/CCD affinity 중심	cache capacity와 thermal을 함께 고려	cache-sensitive와 frequency-sensitive placement를 구분

3D V-Cache는 모든 cache hierarchy를 3차원으로 만드는 기술이 아니다. 특정 cache capacity를 수직으로 더해 memory traffic을 줄일 수 있는 구조이며, 그 이득은 access pattern과 locality에 의존한다.

2. AMD 제품 사양을 읽는 법

제품 예시	AMD 공식 공개 값	이 문서에서의 해석
Ryzen 7 7800X3D	Zen 4, 8코어, 96MB L3, package die count 2, 5nm CCD와 6nm IOD	단일 compute CCD와 IOD가 있는 X3D package의 공개 사양 예시
Ryzen 9 7950X3D	Zen 4, 16코어, 128MB L3, package die count 3, 3D V-Cache	여러 compute die가 있는 X3D package의 total cache·die count 예시
Ryzen 9 9950X3D	Zen 5, 16코어, 128MB L3, package die count 3, 2nd gen 3D V-Cache	최신 client X3D 제품의 cache·package 공개 값 예시
EPYC 9004	Zen 4/Zen 4c, 최대 128코어, 12채널 DDR5 제품군	서버 chiplet·IOD 확장과 X3D client package를 직접 동일시하지 않기 위한 비교 기준

제품 페이지의 L3 Cache는 package 또는 processor가 제공하는 총량이며, 각 CCD의 usable cache, slice mapping, hit latency와 bandwidth를 직접 의미하지 않는다. 마찬가지로 Package Die Count는 die 수를 알려주지만 vertical stack의 exact bonding topology나 IF queue 구조를 공개하는 값은 아니다.

3. Workload별 선택 기준

workload	우선 배치 후보	핵심 이점	주의할 병목
큰 read-mostly working set	X3D CCD	cache capacity로 DRAM miss 감소 가능	L3 contention과 cache fill traffic
높은 single-thread compute	높은 boost headroom의 CCD	frequency와 core execution 활용	X3D thermal policy와 SKU별 비대칭
producer-consumer	같은 CCD 또는 같은 locality group	IF·coherence hop 감소	false sharing과 synchronization
write-sharing lock	owner와 sharer를 가까운 group에 고정	ownership traffic의 범위 제한	invalidate·acknowledgement와 line migration
streaming memory	모든 CCD와 channel에 분산	cache capacity 효과가 제한적일 수 있음	IOD, MC queue와 DRAM bandwidth
multi-socket NUMA	local CCD와 local memory	socket link traffic 감소	remote home, socket link와 page placement

4. 지연과 처리량 모델

제품 내부 cycle 수가 공개되지 않은 경우에는 access 경계를 다음처럼 나눈다.

L_x3d_local = L_core_miss
            + L_base_cache_lookup
            + L_stacked_cache_lookup
            + L_cache_contention
            + L_response

L_remote_or_memory = L_core_miss
                    + L_local_lookup
                    + L_home_or_coherence
                    + L_IF_forward
                    + L_remote_cache_or_IOD
                    + L_MC_and_DRAM_service
                    + L_response
                    + L_queue_retry

L_stacked_cache_lookup이 memory service를 피하게 만들 수 있어도, 모든 local access의 고정 latency가 된다는 뜻은 아니다. cache state, outstanding request, contention과 power state가 결과를 바꾼다. sustained payload bandwidth는 다음 공통 cut의 최솟값으로 분석할 수 있다.

B_sustained <= min(CCD injection capacity,
                    vertical cache service,
                    Infinity Fabric cut,
                    IOD and memory service capacity)

여러 CCD가 같은 IOD, response path 또는 package link를 공유하면 X3D CCD의 local hit 이득과 별개로 공통 cut이 전체 throughput을 제한할 수 있다. coherence control, request header, retry와 backpressure는 payload bandwidth에 포함해 따로 관측한다.

동작 원리

1단계: 코어가 local cache transaction을 만든다

코어가 L1과 L2에서 hit하지 않으면 cache controller가 physical address, read/write 종류, ordering과 coherence attribute를 포함한 transaction을 만든다. 요청은 먼저 source CCD의 queue와 cache fabric으로 들어간다. X3D 여부를 판단하기 전에 core stall, queue 대기와 local lookup을 별도로 측정해야 한다.

T0: L1/L2 miss 또는 write ownership 요구
T1: source CCD request queue 삽입
T2: base L3와 stacked cache lookup
T3: local hit 또는 remote/home route 생성

2단계: X3D cache hierarchy를 조회한다

X3D CCD의 local cache hierarchy에서 line과 필요한 permission을 찾으면 source CCD 안에서 응답할 수 있다. line이 base L3에 있는지 stacked capacity에 있는지는 제품 내부 구현에 따라 controller가 처리하며, 외부 software가 cache die를 별도의 NUMA node로 직접 관리하는 모델로 보지 않는다.

cache miss가 줄어드는 구조적 이점은 다음 조건에서 커진다.

working set이 base L3보다 크지만 추가 cache capacity에는 들어가는 경우
같은 데이터가 반복적으로 재사용되어 DRAM round trip을 피하는 경우
thread가 X3D CCD에 유지되어 remote CCD access가 늘지 않는 경우

반대로 streaming access, 높은 write-sharing과 cache capacity를 넘어선 working set에서는 3D stack의 이점이 제한될 수 있다.

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

local lookup이 실패하거나 ownership이 필요하면 address mapping과 coherence metadata가 home, remote owner, 다른 CCD 또는 IOD memory service를 선택한다.

destination = {
    source_ccd,
    home_or_coherence_agent,
    target_ccd_or_iod,
    memory_controller_or_io_endpoint,
    request_class,
    coherence_state
}

X3D CCD가 source라고 해서 destination이 반드시 stacked cache가 되는 것은 아니다. remote owner가 standard CCD에 있을 수 있고, line이 어느 cache에도 없으면 IOD와 DRAM으로 내려간다. 실제 route와 home hash는 공개 block diagram, firmware topology와 measurement를 함께 사용해 검증한다.

4단계: Infinity Fabric이 수평 경계를 운반한다

remote CCD, IOD 또는 socket service가 필요하면 request와 response가 제품별 Infinity Fabric path로 주입된다. 이 path는 data payload 외에도 coherence control, ordering, retry와 acknowledgement traffic을 운반한다. 수신 buffer가 부족하면 credit 또는 backpressure가 source CCD의 injection queue까지 전파된다.

확인할 항목은 다음과 같다.

X3D CCD와 standard CCD별 request injection stall
CCD-to-CCD와 CCD-to-IOD link의 방향별 utilization
remote cache, memory, coherence control과 response traffic 비율
IOD gateway, memory controller와 package link queue occupancy
corrected error, retry와 power-state transition

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

home/coherence service는 line state에 따라 local hit, remote owner forwarding, sharer invalidate 또는 memory read/write를 선택한다. remote owner가 최신 data를 가진 경우 data forwarding과 permission response가 필요하며, write ownership은 다른 sharer의 invalidate와 acknowledgement를 포함할 수 있다.

X3D local hit    -> source CCD response
standard local   -> standard CCD L3 response
remote owner     -> home -> owner data -> source CCD
memory miss      -> IOD -> MC -> DRAM -> IOD -> source CCD
I/O transaction  -> IOD -> device -> completion

3D stack은 local cache hit 후보를 늘릴 수 있지만, coherence state machine을 없애거나 다른 CCD의 write-sharing 비용을 제거하지 않는다. payload가 작아도 invalidate와 ownership acknowledgement가 많으면 IF queue와 tail latency가 커질 수 있다.

6단계: 응답을 수렴하고 배치를 검증한다

data 또는 acknowledgement가 request ID와 ordering rule에 따라 source core로 돌아오면 cache state와 replacement metadata가 갱신된다. 이기종 CCD의 배치 효과는 다음 실험을 같은 frequency, SMT, BIOS determinism과 background load에서 비교해야 한다.

X3D CCD와 standard CCD의 동일 working set
base L3에 들어가는 working set과 stacked cache까지 필요한 working set
같은 CCD의 local access와 다른 CCD의 remote cache access
read-mostly, write-sharing, lock contention과 streaming
local memory와 remote NUMA memory
CPU-only와 PCIe/DMA concurrent workload

평균 latency만으로 cache-stacked CCD의 이득을 결론 내리지 않는다. p50/p95/p99, L3 miss, memory bandwidth, IF/IOD utilization, queue occupancy, core frequency와 temperature를 함께 기록한다.

장단점

장점	단점 및 주의점
수직 cache die로 compute die 면적을 크게 늘리지 않고 cache capacity를 확장할 수 있음	package bonding, test, height와 열 경로가 복잡해짐
큰 read-mostly working set의 DRAM miss를 줄일 여지가 있음	cache capacity가 latency와 application throughput을 자동으로 보장하지 않음
X3D CCD와 standard CCD를 workload별로 활용할 수 있음	CCD별 cache·frequency·thermal 특성이 달라 scheduling이 복잡함
local cache hit이 늘면 IOD와 IF의 일부 payload traffic을 줄일 수 있음	remote CCD, coherence와 IOD traffic은 여전히 fabric을 사용함
작은 compute die와 cache die를 조합해 제품 variant를 만들 수 있음	SKU별 exact stack topology, cache mapping과 policy가 공개되지 않을 수 있음
package-level cache locality와 chiplet 확장을 함께 활용할 수 있음	thread migration과 shared data placement가 비대칭 비용을 만들 수 있음

선택과 검증 기준

3D V-Cache를 전체 CPU가 하나의 거대한 shared L3를 갖는 것으로 표현하지 않는다.
X3D CCD, standard CCD, IOD와 Infinity Fabric을 서로 다른 physical/functional boundary로 나눈다.
total L3 Cache와 Package Die Count를 per-CCD cache mapping이나 exact route로 역산하지 않는다.
cache-sensitive, frequency-sensitive, write-sharing과 streaming workload를 분리해 측정한다.
같은 CCD local hit, 다른 CCD remote cache, local DRAM과 remote NUMA access를 별도 실험으로 만든다.
package temperature, core frequency, power state와 scheduler placement를 latency 측정과 함께 기록한다.
X3D cache capacity의 이득과 Infinity Fabric/IOD common-cut의 병목을 별도로 분석한다.
내부 directory, home hash, queue depth, bonding topology와 fixed cycle은 공식 근거나 silicon measurement 없이 단정하지 않는다.
평균 throughput보다 saturation point, response queue와 p95/p99를 확인한다.

핵심 정리

AMD 3D V-Cache는 base CCD 위에 추가 cache die를 쌓아 특정 locality group의 cache capacity를 늘리는 패키징 방식이며, 전체 CPU를 하나의 균일한 L3로 만들지는 않는다.
X3D CCD와 standard CCD는 같은 ISA를 실행해도 cache capacity, 열 조건, frequency headroom과 scheduling 적합성이 달라질 수 있다.
Infinity Fabric은 수직 cache lookup을 대체하는 단일 경로가 아니라 CCD·IOD·socket 사이의 request, data, coherence와 response를 운반하는 계층이다.
추가 cache의 효과는 read-mostly working set과 local placement에서 커질 수 있지만, write-sharing, streaming, remote CCD와 IOD common cut의 비용은 남는다.
제품 사양의 total L3와 die count만으로 exact stack topology를 추정하지 말고, cache miss, IF/IOD queue, frequency, temperature와 p95/p99를 함께 측정해야 한다.