NPU에서 LLM Decode가 왜 다르게 보이는가

Sources: 무엇을 기준으로 삼았는가

이 글은 /Users/USER/Documents/NPU_LLM_Decode_Research_20260605. 에 있는 deep-research 패키지를 바탕으로 작성했습니다. 가장 중요한 근거는 1차 자료입니다. ATOM과 vLLM-RBLN 동작은 RBLN docs와 whitepaper를, GPU 실행 모델은 NVIDIA 문서를, Decode arithmetic intensity와 dataflow 원리는 논문을 기준으로 삼았습니다.

경계: 공개 자료만으로 RBLN ATOM의 모든 microarchitecture 세부사항을 알 수는 없습니다. 이 글에서 "schedule이 원한다" 또는 "그럴듯한 mapping"이라고 말하는 부분은 공개된 memory/compiler/runtime 사실을 바탕으로 한 해석입니다. 공개되지 않은 내부 구현을 단정하는 설명은 아닙니다.

Mental model: 작은 live vector, 거대한 static weights, 계속 커지는 dynamic cache

Decode에서는 각 request가 한 번에 token 하나씩만 새로 만듭니다. 이 token의 hidden vector를 x_t라고 부르겠습니다. Model weights는 크고, 대부분 고정되어 있습니다. 반대로 KV cache는 크면서도 동적입니다. sequence length가 늘어날수록 커지고, request가 들어오거나 끝나거나 prefix를 공유하면서 물리적 배치도 바뀝니다. output과 partial sum은 임시 값입니다. 아주 짧은 순간에는 중요하지만, 계산이 끝나면 다음 layer의 input으로 넘어갑니다.

이 그림 하나가 하드웨어 관점의 대부분을 설명합니다. GPU는 이렇게 묻습니다. memory가 도착하는 동안 machine을 놀리지 않을 만큼 parallel work를 충분히 던질 수 있는가? NPU는 조금 다르게 묻습니다. graph를 미리 잘 배치해서 data movement를 예측 가능하게 만들고, local하게 유지하고, compute와 겹칠 수 있는가? 둘 다 locality를 중요하게 봅니다. 차이는 locality를 runtime cache와 scheduler가 얼마나 동적으로 찾아내는지, 아니면 compiler와 runtime이 실행 전에 얼마나 정리해 두는지에 있습니다.

End-to-end lifecycle: token 하나는 data-movement program이다

하나의 예시를 계속 사용하겠습니다. request req_A가 128개 prompt token에 대한 Prefill을 막 끝냈다고 합시다. 이제 tok_129를 Decode합니다. 현재 hidden state는 x_129이고, cache에는 token 0부터 128까지의 block이 이미 들어 있습니다.

이 lifecycle에서 숨어 있는 비용은 곱셈 그 자체가 아닙니다. operand가 이미 연산 유닛 옆에 있다면 multiplication은 싸게 처리됩니다. 진짜 비용은 operand delivery입니다. 필요한 byte를 필요한 시점에 필요한 위치로 옮기고, 쓸모 있는 reuse를 다 뽑아내기 전까지 비싼 memory로 되돌려 쓰지 않는 것이 핵심입니다.

Prefill과 Decode가 왜 다른 실행 방식을 요구하는가

vLLM report는 이 차이를 아주 간단한 계산으로 설명합니다. BF16 matrix-vector product인 y = W x에서는 accelerator가 대략 2mn FLOPs를 수행하고, 동시에 weight를 대략 2mn bytes 읽습니다. 그래서 arithmetic intensity는 대략 1 FLOP/byte 수준입니다 [5]. 반면 batch size가 b인 matrix-matrix product Y = W X에서는 같은 weight tile을 b개의 vector에 재사용할 수 있으므로, intensity가 b에 비례해 올라갑니다 [5].

WaferLLM도 spatial/local-memory 관점에서 같은 구분을 합니다. Prefill과 Decode는 서로 다른 전략이 필요하며, 특히 GEMV가 지배적인 Decode에서는 배치 방식도 달라져야 한다고 봅니다 [6]. 이것이 ATOM이 WaferLLM과 같은 방식을 구현한다는 뜻은 아닙니다. 다만 넓은 architecture 관점에서 교훈은 같습니다. Decode는 "작아진 Prefill"이 아니라, 다른 dataflow 문제입니다.

Tensor shape 정리: layer 하나에서 실제로 무엇이 움직이는가

꼬리 질문에 답하려면 tensor shape를 구체적으로 잡고 있어야 합니다. Llama 계열 decoder layer를 생각해 보겠습니다. hidden size는 H, query head 수는 n_q, KV head 수는 n_kv, head dimension은 d_h, MLP intermediate size는 I, prompt length는 T, decode batch는 B라고 하겠습니다. Prefill에서는 B * T개의 token vector가 layer를 지나갑니다. Decode에서는 live token matrix가 B x H 정도로 얇아집니다.

이 표는 "Decode가 왜 다른가?"라는 질문에 정확히 답하기 위한 기준입니다. transformer layer 자체가 바뀐 것이 아닙니다. 같은 layer가 다른 shape로 실행될 뿐입니다. Prefill은 token dimension이 두껍고, Decode는 live token dimension이 얇은 대신 cache dimension이 계속 커집니다. NPU compiler/runtime은 이 둘을 함께 schedule해야 합니다. weights 위의 regular graph와 KV 위의 dynamic state structure를 동시에 다루는 셈입니다.

Decode roofline 계산: 왜 peak TOPS부터 묻는 것은 부족한가

Decode를 설명할 때 roofline식 bound를 들면 방어력이 좋아집니다. BF16 matrix-vector product y = W x에서 shape가 m x n인 matrix는 대략 2mn FLOPs가 필요합니다. 그런데 BF16 weights를 읽는 데에도 activation, output, metadata, cache traffic을 제외하고 대략 2mn bytes가 필요합니다. 그래서 weight traffic만 보더라도 arithmetic intensity가 약 1 FLOP / byte가 됩니다 [5].

b개의 token vector가 있는 Y = W X에서는 같은 weight byte가 b개의 vector에 쓰입니다. 단순 계산으로 intensity는 대략 b FLOPs / byte가 됩니다 [5]. 그래서 Prefill은 compute-friendly한 GEMM에 가까워지고, Decode는 bandwidth와 locality limit에 더 빨리 부딪힙니다.

그래서 "GPU가 좋은가, NPU가 좋은가"를 단순한 우열 문제로 말하면 곤란합니다. GPU는 거대한 bandwidth와 유연한 kernel 생태계를 가집니다. 추론용 NPU는 off-chip bandwidth가 더 낮을 수 있지만, compiler가 만든 local movement와 특정 serving shape에서의 power efficiency를 강점으로 삼을 수 있습니다. 공정한 비교는 실제 batch size, context length, cache hit rate, model size에서 tokens/s/W가 얼마나 나오는지를 보는 것입니다.

GPU versus NPU: 제어 방식의 차이

CUDA는 GPU를 유연한 SIMT 실행 모델로 보여 줍니다. grid, block, thread, warp, register, global memory, cache, shared memory가 그 기본 단위입니다 [9]. H100급 GPU는 여기에 매우 큰 memory bandwidth와 Tensor Core throughput까지 갖습니다 [10]. 보통의 성능 질문은 kernel이 충분한 parallel work와 memory coalescing을 드러내서 이 유연성을 실제 성능으로 바꿀 수 있는가입니다.

RBLN ATOM의 공개 architecture는 다른 쪽에 무게를 둡니다. Neural Engine, local SRAM, shared SRAM, NoC, DMA command, task manager, 그리고 실행 전에 SRAM placement와 dependency를 계획하는 compiler가 핵심입니다 [1], [2], [3]. parallelism을 덜 중요하게 본다는 뜻은 아닙니다. model graph의 일부로 data movement를 더 명시적으로 schedule한다는 뜻에 가깝습니다.

ATOM memory 계층: byte는 어디에 머물러야 하는가

RBLN architecture 문서에 따르면 ATOM의 각 Neural Engine은 4 MB local SRAM을 갖고, 모든 Neural Engine이 32 MB global SRAM을 공유하며, device에는 16 GB off-chip GDDR6가 있습니다 [1]. ATOM whitepaper도 RBLN-CA12에 대해 64 MB on-chip SRAM, 8개 Neural Engine, 16 GB GDDR6, 256 GB/s memory bandwidth를 제시합니다 [2]. 이 숫자는 단순한 스펙 나열이 아닙니다. 어떤 object를 compute 가까이에 staging해야 하고, 어떤 object를 stream해야 하는지 알려 주는 단서입니다.

흔한 실수는 16 GB GDDR6만 "accelerator memory"라고 보고 SRAM을 보너스처럼 생각하는 것입니다. Decode에서 SRAM은 schedule의 작업대입니다. x_t, W_tile, psum, local attention fragment가 만나는 장소입니다. GDDR6는 on-chip에 올릴 수 없는 큰 static/dynamic object가 머무는 곳입니다.

Linear layer walkthrough: 진짜 질문은 stationarity다

Decode projection y = W x_t를 보겠습니다. 핵심 질문은 하드웨어가 곱셈을 할 수 있는가가 아닙니다. 당연히 할 수 있습니다. 진짜 질문은 어떤 object를 stationary하게 둘지, 어떤 object를 stream할지, final output이 나오기 전까지 partial sum을 어디에 둘지입니다.

for out_tile in output_tiles:
    psum = local_sram.zeros(out_tile)

    for k_tile in reduction_tiles:
        W_tile = dma_gddr6_to_sram(W[out_tile, k_tile])
        x_tile = local_view(x_t[k_tile])
        psum += neural_engine_mac(W_tile, x_tile)

    y[out_tile] = reduce_and_write(psum)

의미: accelerator가 W 전체를 on-chip에 올리려는 것은 아닙니다. 가까이에 들어온 tile을 최대한 쓸모 있게 쓰고, final output을 쓸 수밖에 없는 순간까지 psum을 local에 유지하려는 것입니다.

예시: x_t가 여러 output row에서 재사용된다면, 이를 off-chip memory에서 반복해서 가져오는 것은 낭비입니다. psum을 tile마다 spill하면, 아직 final도 아닌 값 때문에 extra traffic을 냅니다.

흔한 오해: "activation stationary"나 "output stationary"는 구호가 아닙니다. 어떤 byte는 멈춰 두고, 어떤 byte는 그 주변으로 흘려보낼지에 대한 구체적인 선택입니다.

Attention path: Decode는 old state를 읽고 new state를 쓴다

linear projection 이야기는 weight traffic을 설명해 줍니다. Attention은 여기에 두 번째 압력을 더합니다. 바로 persistent KV state입니다. token t에서 layer는 q_t, k_t, v_t를 만듭니다. 새 k_t와 v_t는 cache에 append되어야 합니다. 그 다음 q_t가 cached K[0:t], V[0:t] 위에서 attention을 수행합니다. weights와 달리 이 cache는 compile-time에 주소가 깔끔하게 정해진 고정 tensor가 아닙니다. request history에 따라 달라집니다.

Attention을 구체적으로 설명하려면, 보통 "attention을 실행한다" 한마디로 합쳐 버리는 memory action을 나눠 봐야 합니다. 첫째, 현재 token을 Q/K/V로 projection합니다. 둘째, 이 request의 기존 KV block 위치를 찾습니다. 셋째, tiled working set으로 attention score와 value accumulation을 수행합니다. 넷째, 새 K/V vector를 cache에 씁니다. 세 번째는 tiling을 이야기할 만큼 compute-heavy합니다. 두 번째와 네 번째는 serving-state 문제입니다.

linear layer와 비슷한 점이 보입니다. partial sum은 spill하지 않는 편이 좋고, tile은 on-chip에 있는 동안 최대한 쓸모 있게 써야 합니다. 하지만 attention에는 한 가지 twist가 있습니다. sequence dimension이 token마다 커지므로, context length가 길어질수록 cache read가 비싸집니다. 그래서 long-context Decode는 SRAM tiling, cache layout, request scheduling이 합쳐진 문제가 됩니다.

Compiler도 architecture의 일부다

RBLN compiler 자료는 memory allocation, SRAM use, dependency management가 compile time에 처리된다고 설명합니다 [3]. Optimum RBLN의 Llama 문서는 conversion 과정에서 Hugging Face checkpoint weights를 optimized RBLN graph로 옮기고, 그 graph를 compile한다고 말합니다 [13]. vLLM-RBLN은 같은 물리적 압력을 드러내는 설정을 노출합니다. max_model_len, block_size, prefix_block_size, decoder_batch_sizes, RBLN device placement가 그 예입니다 [12].

중요한 점은 dynamic serving이 사라지는 것이 아니라는 사실입니다. request length와 batch 구성은 계속 바뀝니다. 다만 runtime은 이 dynamism을 compiled system이 감당할 수 있는 shape로 표현하려고 합니다. 눈에 보이는 예가 decoder_batch_sizes입니다. RBLN은 여러 decoder graph를 compile해 두고, in-flight request 수에 맞는 가장 작은 graph를 선택할 수 있습니다 [12]. 하나의 완전히 generic한 kernel path와는 꽤 다른 방식입니다.

KV cache: regular graph와 irregular serving이 만나는 곳

KV cache는 이 이야기에서 가장 까다로운 부분입니다. model graph는 규칙적이지만 serving state는 그렇지 않습니다. request length는 서로 다르고, 끝난 request는 block을 반환합니다. shared prefix가 있으면 이전 cache를 재사용할 수도 있습니다. physical memory block이 연속적이지 않아도 attention은 logical sequence를 순서대로 읽어야 합니다.

RBLN LLM-serving whitepaper는 중요한 단서를 줍니다. RBLN의 PagedAttention path는 vLLM block table과 호환되고, block table을 kernel 안으로 넘기며, dynamic DMA를 사용해 Command Processor가 address를 즉석에서 평가하고 arbitrary DRAM location에 접근할 수 있게 합니다 [4]. 이것이 타협점입니다. high-level execution은 compiled/SRAM-aware하게 유지하되, 정말 동적인 구조인 KV cache에는 controlled dynamic address path를 허용하는 것입니다.

Serving loop: batching과 graph variant가 왜 중요한가

Decode token 하나도 이미 memory program입니다. 실제 serving은 그 바깥에 또 하나의 loop를 붙입니다. request가 들어오고, Prefill이 실행되고, request가 Decode로 넘어오고, 일부는 끝나고, 새 request가 합류합니다. 그래서 live Decode batch는 iteration마다 바뀝니다. NPU는 batch가 영원히 하나의 고정 숫자라고 가정할 수 없습니다. 동시에 compiler-planned accelerator는 무제한의 shape 자유도도 원하지 않습니다.

RBLN-specific 단서는 decoder_batch_sizes입니다. vLLM-RBLN 문서는 listed batch size마다 decoder graph 하나를 compile하고, in-flight request 수에 맞는 가장 작은 decoder graph를 선택한다고 설명합니다 [12]. 이것이 "controlled dynamism"의 좋은 예입니다. serving workload는 dynamic하지만, hardware-facing shape는 작은 수의 precompiled option으로 bucket됩니다.

이 주제는 과제에 잘 맞습니다. architecture를 RBLN SDK, vLLM 기반 LLM inference, compilation, serving, benchmarking과 바로 연결하기 때문입니다. 단순히 "NPU에는 SRAM이 있다"라고 말하는 것이 아닙니다. 실제 serving stack이 irregular LLM request를 추론용 NPU가 실행할 수 있는 shape와 block movement로 어떻게 바꾸는지를 설명하는 것입니다.

흔한 함정: 그럴듯하지만 얕은 설명들

선발 안내문은 원리를 이해했는지, 그리고 자기 언어로 설명할 수 있는지를 본다고 말합니다. 발표 자료와 면접에서 아래 표현들은 피하는 편이 좋습니다.

작은 trace: ATOM-style NPU에서 token 129가 지나가는 길

위 mental model을 하나의 구체적인 trace로 압축해 보겠습니다. 이것은 정확한 RBLN execution dump가 아닙니다. 공개 architecture가 시사하는 source-grounded 실행 모양입니다.

5장 발표로 압축하기

제출 PDF는 정확히 5장이어야 합니다. 주제 내용 4장, 그리고 NPU에 올려보고 싶은 model 1장입니다. 발표 자료가 이 문서 전체를 억지로 압축할 필요는 없습니다. 이 문서는 백업 지식으로 두고, 발표에서는 하나의 흐름만 깨끗하게 보여 주면 됩니다. Decode는 data-movement 문제이고, ATOM-style NPU는 SRAM-aware compiled execution과 controlled KV-cache dynamism으로 이 문제를 다룬다.

Deck discipline: title slide, agenda slide, generic NPU intro는 넣지 않습니다. 앞의 4장은 각각 claim 하나, 구체적인 diagram 하나, 질문을 받아도 방어할 수 있는 문장 하나로 구성하는 편이 좋습니다.

연습 질문: 진짜로 이해했는지 확인하기

아래 질문이 편하게 느껴지면 mental model이 어느 정도 자리 잡은 것입니다. 애매하다면 용어를 외우기보다 diagram으로 다시 돌아가 보세요.

References

전체 citation registry와 evidence ledger는 이 HTML 파일 옆의 sources.jsonl, evidence.jsonl에 있습니다. 아래는 이 walkthrough에서 인용한 sources입니다.