《GPU Mode》
L061
2025 · Inference silicon
Mid priority
transcript · failed
D-Matrix Corsair — Inference 전용 dataflow 칩
LLM inference 의 decode 단계는 memory-bound — 그래서 GPU 의 compute 90% 가 idle 이다. D-Matrix Corsair 는 이 자리를 정조준한 inference 전용 칩 — Digital In-Memory Compute (DIMC) 로 SRAM tile 안에서 GEMM 을 돌리고, 큰 on-chip SRAM 으로 KV cache 를 들고 있어 HBM 왕복을 거의 없앤다. 이 노트는 Corsair 의 architecture 와 GPU 와의 trade-off 를 정리한다.
Digital In-Memory Compute
SRAM-centric
inference-only
dataflow
PCIe Gen5
block FP
d-Matrix Aviator
D
Speaker
미상 (D-Matrix · 확인 필요)
Sudeep Bhoja / Sree Ganesan / 다른 공동창업자 후보
§ 01강의가 풀려는 문제· why a custom chip
GPU 가 inference 에서 비싸고 느린 이유 — 그리고 그 자리를 정조준한 칩의 모양
2024–25 년 시점에 LLM inference 비용이 production 의 budget 의 70%+. GPU 가 결정적으로 비효율인 영역이 — batch=1 (또는 작은 batch) decode. token 하나 만들 때마다 모델 전체 weight 를 HBM 에서 SRAM 으로 옮긴다. compute 는 거의 idle. 이 비효율을 정조준한 한 가지 답이 — inference 전용 dataflow 칩. D-Matrix 의 Corsair 가 그 길의 대표 사례.
강의 transcript 가 비어 있으므로 본 노트는 D-Matrix 공식 자료 (corsair product page, blog, ISSCC 논문 — 확인 필요) 와 vendor presentation 의 표준 자료 위에서 재구성. 강의 안에서 다룬 정확한 비중과 디테일은 영상 검증 필요.
강의의 frame
이 강의는 architectural overview — “GPU 가 아닌 다른 hardware 가 LLM inference 에 최적화되면 어떻게 생겼는가” 의 한 사례. 핵심 idea 는 compute 를 memory 옆으로 가져가는 것. SRAM tile 안에서 MAC 을 돌리면 weight 가 거의 안 움직인다 — decode 의 memory bandwidth 한계가 사라진다.
“GPU 가 메모리에 막혀 있을 때, hardware 가 할 수 있는 가장 큰 일은 — 메모리를 compute 옆으로 가져오는 것이다.”D-Matrix 자료 / 확인 필요
§ 02inference 전용의 동기· decode is memory-bound
왜 GPU 가 비싸냐 — decode 에서 90% 의 compute 가 놀고 있어서
LLM decode 의 산수를 다시 — 한 token 만들 때 model weight 를 한 번 read. 70B FP16 = 140 GB. H100 의 HBM bandwidth = 3.35 TB/s. 즉 한 token 의 memory time ≈ 42 ms. 이 동안 H100 의 989 TFLOPs 중 실제 사용량은 2 × 70B / 42 ms ≈ 3.3 TFLOPs = 0.3%. 99.7% 의 compute 가 idle.
FIG · H100 의 decode utilization70B · batch=1
HBM bandwidth
99% saturate
batch=1 에서 H100 의 700W 중 — Tensor Core 부분은 거의 안 켜지는데 HBM 과 control 회로는 다 도는 비대칭. $/token 비용이 GPU 의 가장 큰 약점이 되는 자리.
이 비효율이 GPU 의 본질적 design 의 결과다 — GPU 는 training 의 큰 batch · 큰 GEMM 에 최적화. inference decode 의 GEMV(=batch×1×d × d×d) 는 GPU 가 만들어진 워크로드가 아니다.
그래서 inference 전용 칩의 design space 가 열린다. GPU 와 다르게 만들어야 할 것들:
- weight 를 옮기지 않는다 — on-chip SRAM 에 모델을 통째로 둔다. HBM 거의 안 씀.
- compute 를 weight 옆에 — DIMC. 같은 SRAM tile 안에서 MAC.
- training 안 함 — backward / gradient / optimizer state 없음. 회로 단순.
- FP8 / INT8 / block FP 만 — high-precision FP32 안 쓰고, FP16 도 제한적.
대안 — 큰 batch 로 spread
batch 를 키우면 compute utilization 이 살아난다. batch=32, 70B → memory 시간 동안 64 토큰 동시 생성 → compute 21% 활용. 하지만 latency 가 올라가고 batch 를 채우려면 traffic 이 충분해야. 작은 enterprise / edge 에서는 batch=1 dominant.
D-Matrix 의 hypothesis — 대부분의 enterprise inference 는 작은 batch + 짧은 latency 가 SLO. 이 영역에서 GPU 가 dominant 가 아니다. 따라서 — 같은 작업을 더 적은 power, 더 적은 비용으로 도는 chip 이 자리를 가질 수 있다.
§ 03Corsair 아키텍처· chiplet · cards · servers
4 chiplet × 2 dies × 1 PCIe card — 큰 SRAM 을 여러 단계로 묶는다
Corsair 의 물리적 구성을 큰 그림으로. chiplet 이 base 단위. 한 chiplet 이 ~150 MB SRAM 을 들고, 그 안에 DIMC tile 이 grid 로 박혀 있다. 여러 chiplet 이 die 위에 모이고, 두 개의 die 가 PCIe Gen5 카드 한 장을 만든다 (확인 필요 — 정확한 갯수는 vendor 발표마다 다름).
CHIPLET
compute 단위
SRAM ~150 MB + DIMC tile array. 자기 안에서 layer 의 일부 GEMM 을 처리. chiplet 간은 high-speed interconnect (D2D).
DIE
chiplet 4개 묶음
4 chiplet 이 한 die 위에. 2.5D / 3D packaging. die 안 SRAM 합 ~600 MB.
CARD
2 die · PCIe Gen5
한 PCIe 카드에 2 die = 8 chiplet. SRAM 총 ~2 GB. ~600W TDP. (확인 필요)
SERVER
card 8 장 · 16 GB SRAM
표준 서버 1U/2U 에 카드 8장. 합 ~16 GB SRAM — 70B 모델 (~80GB FP16, ~20GB FP4 또는 INT4) 이 들어갈 수 있음 (확인 필요 — quantization 가정).
FIG · Corsair memory hierarchycompute 위치 표시
SRAM tile(DIMC 안)
~16 KB · 0.1 ns
SRAM bank
~150 MB · 1 ns
chip-wide SRAM
~600 MB · ns
card SRAM
~2 GB · 5 ns (D2D)
server SRAM
~16 GB · 50 ns (PCIe)
HBM (없음)
— DRAM 은 host 쪽만
전체 weight 가 SRAM 위에 살아 있다. 이게 HBM-less inference 의 핵심. DRAM 왕복이 없다 — 따라서 batch=1 decode 에서 압도적 power efficiency.
비교 기준 — H100 의 SRAM 은 SM 당 256 KB × 132 = ~34 MB. Corsair 의 server-wide SRAM 은 그 500배. 모델 전체가 SRAM 안에 사는 게 가능해진다.
§ 04DIMC· SRAM tile 위 MAC
Digital In-Memory Compute — weight 가 사는 SRAM 셀에서 곱이 일어난다
In-memory compute 는 두 갈래 — (a) analog IMC (analog charge / current 으로 곱 → ADC 로 디지털 화). (b) digital IMC (DIMC) — 디지털 곱셈을 SRAM bitcell 옆에 둔다. analog 의 정밀도 / 잡음 문제 없이 뮬티플라이.
D-Matrix 가 DIMC 를 선택한 이유:
- 정확도: analog IMC 는 ADC noise / process variation 에 민감. 학습된 모델의 quantization 정확도와 곱하면 누적 error 큼. DIMC 는 디지털이라 deterministic.
- scaling: digital 회로는 process node (3nm, 5nm) shrink 에 잘 따라간다. analog 는 그렇지 않다.
- tooling: digital IP 는 EDA 표준 flow. analog 는 customisation 부담 큼.
대신 DIMC 는 analog 만큼 dense 하지 않다 — 같은 면적에 곱셈기가 더 적게 들어간다. 그 trade-off 를 process node (4nm 또는 5nm 추정) 와 압도적 SRAM 양으로 보상.
DIMC tile 의 단순화 모델
한 SRAM bank 가 N×K weight matrix 를 들고 있다고 보자. input vector x (1×K) 가 들어오면 — bank 의 컨트롤러가 K 개 row 를 동시에 read 하고, 같은 bank 안의 MAC 회로가 N 개 dot-product 를 병렬로 수행. 결과 1×N output. weight 가 한 cycle 도 안 움직인다.
비교 — GPU 의 GEMV: weight (~10 GB) 를 HBM → L2 → L1 → SM register 로 옮긴 뒤 MAC. 옮기는 비용이 90%, 곱이 10%. DIMC 는 옮기는 비용 0%.
FIG · 비교 — GPU GEMV vs Corsair DIMC한 layer 의 weight load 시간
GPU H100
HBM → SM transit
~42 ms
Corsair DIMC
in-place compute
~5 ms
decode 의 critical path 가 weight transit 에서 MAC 자체로 옮겨감. 전체 latency 가 5~8× 빠르다 (vendor 자료 트렌드 기준 — 확인 필요).
§ 05NVIDIA 와 비교· H100 / B200 / spec
같은 70B 토큰 한 개를 만드는 데 — power 와 latency 의 비대칭
메트릭
H100 (배치 1)
B200 (배치 1)
Corsair (서버)
peak compute
989 TF (BF16)
2.25 PF (FP4)
~9.6 PF (block FP4)
memory
80 GB HBM3
192 GB HBM3e
2 GB SRAM/card · 16 GB/server
memory BW
3.35 TB/s
8 TB/s
~150 TB/s (SRAM)
batch=1 70B latency
~42 ms/token
~18 ms/token
~5 ms/token
power
~700W
~1000W
~600W (card) · 4.8 kW (8 cards)
tokens / W
low
중간
3~5×
training 가능
예
예
아니오
위 수치는 D-Matrix vendor 자료의 트렌드와 일반적 inference 산수의 재구성. 절대값은 quantization · model · workload 에 따라 변동 (확인 필요).
중요한 비대칭 — H100 / B200 은 training 과 inference 모두 가능한 general-purpose chip. Corsair 는 inference only. 그래서 직접 비교는 “전체 시스템 cost” 보다 “inference 단계 비용” 으로 봐야 의미가 있다.
§ 06채택 사례· enterprise inference
Corsair 가 정조준하는 자리 — enterprise · privacy · low-latency
D-Matrix 의 GTM 전략은 cloud hyperscaler 시장 (Google, Meta, Microsoft) 의 H100/B200 자리를 뺏는 것 이 아니다. 오히려 enterprise / on-prem / edge inference — 작은 batch, latency-sensitive, privacy-aware 워크로드를 정조준한다.
- enterprise on-prem: 자체 데이터로 LLM 을 돌리는 회사. cloud GPU 보다 같은 throughput 에 cost 1/3, power 1/3 이면 의미.
- realtime / edge: 자율주행, robotics, AR/VR. 작은 batch, 낮은 latency.
- government / regulated: 데이터 외부 안 나감. on-prem inference 의 전기료 / 발열 절약이 큼.
- fine-tuned 작은 모델 운영: 7B–70B 영역. 큰 cloud 는 비효율, 작은 chip 으로 충분.
D-Matrix 의 차별 포지션
다른 inference 칩들 (Groq, Cerebras WSE, SambaNova, Tenstorrent) 과의 차이 — Groq 은 throughput-first (한 토큰을 빨리), Cerebras 는 wafer-scale (메모리 가득), D-Matrix 는 cost/W per token 을 강조. 다른 dataflow 칩들과 같이 묶이지만 SRAM 양과 PCIe 폼팩터로 표준 server 에 그냥 꽂히는 deployability 를 강조.
§ 07SW 스택· Aviator
PyTorch / ONNX 모델을 그대로 받는다 — 컴파일러 + 런타임이 chip 위에 매핑
D-Matrix 의 SW stack 이름은 Aviator (확인 필요 — 자료 시점에 따라 변동). PyTorch / ONNX 형식의 모델을 입력으로 받아 — Corsair 위에서 dataflow 로 매핑한다. 사용자는 Hugging Face 모델 weight 와 tokenizer 만 들고 와도 batch inference 가 돌아간다.
FIG · Aviator compile pipelinePyTorch → Corsair binary
L0
PyTorch / HF
model checkpoint
L2
quantize
block FP / INT8
L3
layer placement
chiplet / die / card 매핑
L4
scheduler
dataflow + DMA
중요한 단계 — quantize 와 layer placement. 모델이 SRAM 에 들어가야 하므로 quantization 이 실질적으로 강제. 그리고 layer 가 카드 / 칩 사이에 걸치면 latency 가 비싸지므로 placement 가 중요.
- 지원 모델: Llama-2, Llama-3, Mistral, Mixtral, GPT-OSS-style 등 표준 transformer (확인 필요 — 모델 list 는 release 마다 갱신).
- 지원 quantization: block FP (D-Matrix 자체 포맷), INT8, FP8, FP4 (확인 필요 — Corsair 세대에 따라 차이).
- API: 일반적으로 OpenAI-compatible REST endpoint + native runtime API. vLLM-like batching scheduler 내장 (확인 필요).
§ 08한계· model size · training
모든 답이 아니다 — Corsair 가 못 하는 것들
solid 한 분석은 한계도 명시. Corsair 가 지금 시점에 못 하거나 약한 영역을 정리한다.
제약
왜
우회
매우 큰 모델
SRAM 16 GB / server. quantize 후 70B 까지가 한계. 400B+ 모델은 multi-server 분산 필요.
서버 cluster + low-latency interconnect (PCIe Gen5) — 확인 필요
training
backward / optimizer 회로 없음. inference only.
GPU cluster 에서 training, Corsair 에서 deploy
큰 batch
batch 키우면 GPU 의 compute 우위가 살아남. Corsair 의 강점은 작은 batch.
batch > 16 영역에서는 H100/B200 이 더 나을 수 있음
매우 긴 context
KV cache 가 SRAM 압박. 32K+ 에서 메모리 부족 가능.
KV offload (host DRAM) 또는 sliding/linear attn (확인 필요)
새 architecture 빠른 채택
SSM / linear-attn / Mamba 같은 새 op 가 컴파일러 지원 필요.
vendor 의 SDK update — 시간차 있음
multi-modal · vision
기본 transformer 위주. ViT / video / audio 은 별도 지원 (확인 필요).
vendor roadmap 의식해야
“같은 모델이라도 — batch 와 sequence 길이의 분포가 어디로 가느냐가 Corsair 의 sweet spot 안인지 밖인지 결정한다.”학습 노트
§ 09future road· next-gen Raptor
다음 세대 — 더 큰 SRAM · 더 작은 process · multi-card scale
D-Matrix 의 roadmap (공개된 자료 기준 — 확인 필요):
- Corsair (현행, 2024–25) — 4nm class. PCIe Gen5 카드. 8-card server 의 16 GB SRAM. 100B 클래스 모델 inference.
- Raptor (차세대, 2026 예상) — 더 큰 chiplet · 새 process node · 더 큰 SRAM. 또는 multi-server scale 의 표준 interconnect (확인 필요).
- SW — Aviator stack 의 vLLM / SGLang 호환성 확장. OpenAI API 호환 production server.
- 모델 지원 — MoE (Mixtral, DeepSeek) · Mamba / hybrid · multi-modal 확대.
- LP-grade — edge / robotics 용 작은 chip family 가능성 (확인 필요).
생태계의 신호
D-Matrix 가 2024 말 ~2025 초 시리즈 B+/C 로 큰 funding 을 받았다 (확인 필요). enterprise customer pilot 을 발표한 paper / blog 도 늘고 있다. inference silicon market 이 성장하면 — Corsair / Groq / Cerebras / Tenstorrent 가 각자 다른 niche 를 차지하는 게 자연스러운 시나리오.
§ 10기억할 메모와 자료· key takeaways · vendor docs
다시 열었을 때 빠르게 잡혀야 할 것
decode = memory-bound
batch=1 70B 에서 H100 의 compute 활용 0.3%. inference 전용 칩의 동기.
DIMC
Digital In-Memory Compute. SRAM bank 옆에 MAC. weight 가 안 움직임.
SRAM-centric
server-wide ~16 GB SRAM. HBM 없이 모델 통째로. quantize 강제.
chiplet → die → card → server
계층적 packaging. PCIe Gen5 카드 형태로 표준 서버에 꽂힘.
Aviator stack
PyTorch / ONNX 입력. quantize → placement → schedule → binary.
sweet spot
batch 작음 + latency 민감 + on-prem. cloud hyperscaler 와 별개 시장.
못 하는 것
training. 매우 큰 batch. 매우 긴 context. 새 op 빠른 채택.
vs GPU
batch=1 latency 5~8×, tokens/W 3~5× 우위 (확인 필요). batch 큰 영역 우위 약함.
Groq 비교 자료
groq.com · LPU 의 다른 dataflow inference 칩
손에 새기기 — 분석 시퀀스
- 자기 워크로드의 batch / latency 분포 측정 — production trace 에서 batch size 와 sequence length 의 histogram. Corsair sweet spot 인지 확인.
- roofline 분석 — 자기 모델의 GEMV 가 HBM bandwidth 의 몇 % 를 쓰는지. 90%+ 면 inference 칩으로 옮길 가치 큼.
- quantization 시뮬레이션 — INT8 / block FP4 로 자기 모델의 정확도 손실 측정. 큰 손실이면 Corsair-class 칩 부적합.
- cost model 비교 — H100 8-card server vs Corsair 8-card server 의 같은 throughput 가격 / 전기료 비교. 확인 필요한 vendor 자료 + 시장 가격.
- vendor pilot 신청 — D-Matrix dev kit / cloud 액세스가 있다면 직접 자기 모델 돌려보기.
- 다른 inference 칩들과 head-to-head — Groq, Cerebras, AWS Inferentia2/3, Google TPU v5e 의 같은 task 비교.
§ 11다른 강의로· connections
이 강의의 frame 이 다른 강의에서 어떻게 다시 등장하는지
§ 12열린 질문· open questions
transcript 가 비어 있어 직접 검증해야 할 것들
- 발표자 정확한 정체 — D-Matrix CTO / VP Engineering / 다른 lead engineer 후보. transcript 없어 확인 필요.
- Corsair 의 정확한 spec — chiplet 수, SRAM 양, PCIe Gen5 vs Gen4 — 본 노트의 수치는 vendor 자료의 일반적 트렌드 재구성. 정확한 release spec 은 D-Matrix 공식 문서 검증 필요.
- 실제 benchmark 수치 — 강의에서 H100 / B200 vs Corsair 의 specific benchmark (Llama-3-70B, batch=1, 입력 1K 출력 256) 가 어떻게 나왔는지.
- quantization 의 정확도 손실 — block FP 로 떨어졌을 때 자기 모델의 perplexity / downstream task 손실 — 강의에서 정량 수치가 있었는지.
- Aviator 의 OSS 지원 정도 — vLLM, SGLang 호환성 / native runtime 만 / docker container 형태 등의 제공 형태.
- cost 의 실제 비교 — cloud GPU 의 $/M-token vs Corsair 의 $/M-token. vendor 자료의 수치를 직접 검증.
- 특정 customer / production 사례 — 강의에서 case study 가 등장했는지. 어떤 산업에서 첫 채택이 일어났는지.
검증 메모
본 노트의 모든 수치 (latency, power, SRAM 양) 는 D-Matrix 의 공개 자료의 트렌드와 일반적 inference 산수의 재구성. vendor 자료는 best-case 시나리오를 강조하는 경향이 있으므로 — 자기 모델 / 자기 워크로드에서 직접 측정한 결과만 의사결정에 쓸 것.