Introduction

모바일 LLM 백그라운드 작업을 하면 실제로 사용자 앱만 심하게 느려진다

저자들은 백그라운드에서 LLM을 실행한 상태로 25개 인기 앱을 하나씩 사용해 보았다.

그런데 동시에 실행 중인 LLM은 거의 느려지지 않았다.

즉, 자원을 공평하게 나눠 갖는 것이 아니라, 화면 앱은 큰 손해를 보는데, 백그라운드 LLM은 거의 손해를 보지 않는 비대칭 간섭이 발생한다!

병목은 연산량이 아니라 공유 메모리 대역폭이다

처음에는 NPU가 LLM을 실행하면서 CPU나 GPU 연산 능력을 빼앗는 것처럼 보일 수 있다.

하지만 저자들의 분석 결과, 원인은 공유 DRAM의 메모리 대역폭 경쟁이다.

모바일 SoC는 일반적으로 CPU, GPU, NPU가 같은 DRAM을 사용하는 UMA, Unified Memory Architecture 구조다.

따라서 NPU가 모델 가중치를 읽기 위해 메모리 트래픽을 많이 발생시키면, CPU와 GPU의 화면 렌더링용 메모리 요청이 밀린다.

단순히 LLM을 느리게 만들면 되지 않는 이유

그렇다면 NPU의 속도를 낮추거나 잠깐씩 쉬게 하면 될 것 같지만, 실제 모바일 SoC에서는 세 가지 문제가 있다.

• 메모리 경쟁을 빠르게 감지하기 어렵다
  • NPU가 정확히 얼마나 메모리 대역폭을 쓰는지 실시간으로 보여주는 하드웨어 카운터가 부족하다.
  • 소프트웨어로 직접 측정하려 하면 측정 자체가 CPU와 메모리를 사용해서 오버헤드가 커진다.

• LLM 실행을 자주 중단하기 어렵다
  • 모바일 NPU는 효율을 위해 미리 컴파일된 static computation graph를 실행한다.
  • 그래프가 한번 시작되면 보통 끝날 때까지 중단할 수 없으므로, 화면 렌더링이 갑자기 바빠져도 즉시 멈추기 어렵다.

• 기존 throttling은 비효율적이다
  • NPU 주파수를 낮추거나 일정 시간 sleep시키는 방식은 메모리 사용량을 줄일 수는 있다.
  • 하지만 그동안 LLM 추론도 거의 진행되지 않기 때문에, 화면 성능을 지키려면 LLM 성능을 크게 희생해야 하는 단순한 trade-off

Background

Interference and Analysis

3.1 Quantifying Interference

백그라운드 LLM이 foreground 앱에 얼마나 큰 간섭을 일으키는가?

LLM과 앱을 동시에 실행하면 앱의 화면 품질과 CPU·GPU 성능은 크게 떨어지지만, 정작 LLM 추론 속도는 거의 떨어지지 않는다.

결과

• foreground 앱의 화면이 크게 버벅임
  • 25개 앱 전체를 합친 aggregate jank rate는 153% 증가 (2.53배)
  • Discord는 LLM과 함께 실행했을 때 Native 대비 거의 18배의 jank rate

• 가벼운 앱도 큰 피해를 본다
  • 앱 자체의 연산량이 작더라도 화면 렌더링 deadline에 민감하면 LLM의 자원 간섭을 크게 체감할 수 있다.
  • Discord처럼 Native 상태에서 잘 최적화된 앱이 오히려 normalized jank에서 매우 큰 증가를 보인 이유도 이와 연결된다.

• CPU·GPU 최고 성능도 크게 떨어진다 (오른쪽 figure)
  • Native 상태를 1.0으로 놓았을 때 대부분 약 0.5~0.6 수준까지 떨어진다.
  • 최신 Snapdragon 8 Elite가 실질적으로 2~3년 전 하드웨어 수준의 성능을 보이는 것과 비슷하다!

• 그런데 LLM은 거의 느려지지 않는다
  • Prefill throughput: 1.01% 감소
  • Decode throughput: 1.64% 감소

• systemic priority inversion
  • 두 작업이 자원을 공평하게 나눠 가지는 상황이 아니다. (asymmetric interference)
  • 실제로 더 긴급한 UI가 밀리고, 덜 긴급한 백그라운드 LLM이 자원을 우선적으로 공급받는 상황이다.
  • 왜 하필 NPU가 이기는가? → 3.3에서 계속

3.2 Physical Attribution: Bandwidth

백그라운드 LLM 때문에 앱이 느려지는 원인 확인

1. Compute 지표: 거의 변화 없음

• IPC, CPU utilization, GPU utilization은 대부분 1.0 근처다.

• 즉, LLM이 NPU에서 실행된다고 해서 CPU나 GPU의 연산 코어가 꽉 차는 것은 아니다.

• 주파수(core frequency)도 비정상적으로 떨어지지 않아 발열에 의한 throttling도 주요 원인이 아니다. (그래프에는 없고 설명으로 따로 측정했다고 함.

2. Cache 지표: 뚜렷한 악화 없음

• LLC miss, L2 cache miss, TLB miss 역시 Native와 크게 다르지 않다.

• NPU가 캐시를 오염시켜 CPU/GPU 데이터를 밀어내는 cache contention도 핵심 원인은 아니다.

3. Unified Memory 지표: 3~4배 악화

• CPU memory stall cycles, LLC miss latency, GPU memory stall

• CPU와 GPU가 메모리를 요청한 뒤 기다리는 시간이 크게 증가했다는 뜻이다.

Foreground 앱이 느려지는 원인은 연산 코어나 캐시 부족이 아니라, NPU가 공유 메모리 대역폭을 과도하게 차지해 CPU와 GPU의 메모리 접근 지연이 증가하기 때문이다.

3.3 Architectural Root Cause Analysis

왜 모바일 시스템이 NPU의 과도한 메모리 사용을 제어하지 못하는가?

1. OS가 NPU 트래픽을 제대로 보거나 제한할 수 없다

• CPU의 메모리 stall은 모니터링하지만, NPU 트래픽은 기존 관리 시스템에서 빠져 있는 경우가 많다.

• CPU에는 MPAM 같은 대역폭 분배 기능이 있지만 NPU에는 적용되지 않아, 혼잡을 발견하더라도 NPU에 대역폭 제한을 걸기 어렵다.

2. 하드웨어가 NPU 메모리 요청을 우선 처리한다

• NPU는 전용에 가까운 고우선순위 메모리 경로를 사용하며, 화면 출력처럼 긴급한 작업과 비슷한 높은 우선순위를 받는다. 반면 CPU와 GPU는 대역폭·발열 정책의 제약을 받는다.

• 또한 UI는 120Hz 기준 약 8.3ms 안에 처리돼야 하는데, 메모리 대역폭 제어기가 반응하는 데 약 64ms가 걸려 짧은 렌더링 간섭을 막기에는 너무 느리다. Table 1은 이런 CPU/GPU와 NPU의 차이를 정리한다.

3. 원래 카메라와 영상 처리를 위한 설계다

• 모바일 칩은 원래 NPU나 ISP 같은 가속기를 카메라·영상 처리에 사용했다. 4K 영상 촬영은 프레임 하나라도 늦으면 영상이 손상되므로, 하드웨어가 이 가속기들의 메모리 요청을 높은 우선순위로 처리하도록 설계됐다.

• 문제는 하드웨어가 긴급한 카메라 작업과 중요도가 낮은 백그라운드 LLM을 구분하지 못한다는 것이다. 그래서 LLM도 카메라와 같은 우선권을 물려받아 UI를 밀어낸다.

NPU는 메모리 접근 우선권은 높은데, OS가 관찰하거나 제한할 수단은 부족하다.

이 구조를 상용 스마트폰에서 바꾸기 어렵기 때문에, 저자들은 하드웨어 정책에 의존하지 않고 LLM 스스로 대역폭을 양보하는 소프트웨어 방식이 필요하다고 결론낸다.

SERENO Design

5.1 Elastic Speculative Decoding

1. Preemptible Draft Execution

• 기존에는 draft model도 하나의 큰 static graph로 실행돼 중간에 멈추기 어렵다.

• SERENO는 draft model을 Transformer layer 단위의 작은 subgraph로 컴파일한다.

• 각 subgraph는 1ms 미만으로 실행되므로, subgraph 경계마다 중단 여부를 결정할 수 있다.

plainCopy code

Draft layer → Draft layer → Draft layer ↑ 여기서 즉시 중단 가능

• 메모리 경쟁이 감지되면 남은 draft 작업을 버리고, 지금까지 만든 후보만 가지고 verification으로 넘어간다.

• Draft 결과는 아직 tentative한 후보라서 버려도 이미 확정된 토큰이나 최종 정확성은 손상되지 않는다.

• 또한 dynamic operator로 바꾸지 않고 static graph를 유지하므로 NPU 효율도 보존한다.

2. N-gram Filling

• Draft를 일찍 중단하면 verification batch를 채울 후보 토큰이 부족해져 처리량이 떨어질 수 있다.

• SERENO는 빈 자리를 저비용 N-gram 후보로 채운다.

plainCopy code

Verification batch 크기: 9 Neural draft 후보: [A][B][C] N-gram 후보 추가: [D][E][F][G][H][I]

• N-gram 후보도 target model이 모두 검증하므로, 잘못된 후보는 거절되고 출력 정확성에는 영향이 없다.

• 후보 품질을 높이기 위해 다음 정보를 활용한다.
  • 검증을 통과한 출력: 높은 신뢰도
  • prompt에 등장한 토큰
  • 이전에 거절된 draft sequence: 낮은 가중치로 재활용

• 자주 틀리는 패턴은 제거하고, 짧은 2-gram보다 긴 문맥이 일치한 후보에 더 높은 가중치를 준다.

• 즉, N-gram Filling은 대역폭을 줄이는 기능이라기보다 draft 중단으로 잃은 처리량을 보상하는 기능

3. Selective Batching

SERENO는 batch 크기가 서로 다른 verification graph를 미리 컴파일해 둔다.

• 메모리 경쟁 정도에 따라 적절한 graph를 선택한다.
  • 경쟁이 적음 → 작은 batch → 후보를 덜 기다리고 빠르게 verification
  • 경쟁이 심함 → 큰 batch → 한 번의 target-model weight 읽기로 더 많은 후보를 병렬 처리해 평균 대역폭 압력을 낮춤

• 논문에서 batch 1의 대역폭 요구량을 1.0으로 두면, batch가 커질수록 8/16/32에서 각각 약 0.82/0.79/0.74로 감소한다.

• 다만 큰 batch가 항상 빠른 것은 아니다. 더 많은 후보를 준비해야 하고, 한번 시작한 verification graph가 더 오래 실행되는 긴 atomic burst가 될 수 있기 때문이다.

draft를 빠르게 끊을 수 있게 만들고, 끊어서 부족해진 후보는 N-gram으로 보충하며, verification batch 크기를 바꿔 메모리 대역폭과 지연을 조절하는 설계

5.2 Endogenous Contention Sensing

별도의 하드웨어 카운터나 메모리 측정 프로그램 없이, LLM 자신의 실행 시간을 이용해 메모리 경쟁을 감지하는 방법

Draft model의 subgraph도 NPU SRAM과 DRAM 사이에서 많은 데이터를 전송하므로, 경쟁이 발생하면 실행 시간이 느려진다.

별도의 probe를 실행하는 대신 원래 수행하던 LLM 연산 자체를 메모리 지연 측정기로 사용한다. 그래서 endogenous, 즉 시스템 내부에서 자연스럽게 얻는 신호라고 부른다.

왜 Draft subgraph를 사용하는가

메모리를 많이 사용하고, 실행 시간이 1ms보다 짧으며, 반복적으로 실행되기 때문에 메모리 경쟁을 빠르게 관찰하기 좋다. 별도 메모리 접근을 발생시키지 않아 측정 오버헤드도 거의 없다.

Calibration

문제는 Transformer layer마다 원래 실행 시간이 다르다는 점이다. 컴파일러의 graph fusion, 메모리 정렬, tensor tiling 차이 때문에 subgraph별 실행 시간이 최대 37% 정도 차이날 수 있다.

따라서 SERENO는 경쟁이 없는 환경에서 각 subgraph의 정상 실행 시간 ($T_{\text{baseline}}$)을 한 번 미리 측정한다.

실행 중에는 다음 Contention Score를 계산한다.

$CS=\frac{T_{\text{actual}}-T_{\text{baseline}}}{T_{\text{baseline}}}$

예를 들어 평소 0.8ms 걸리던 subgraph가 1.0ms 걸렸다면,

$CS=\frac{1.0-0.8}{0.8}=0.25$

즉, 평소보다 25% 느려졌으므로 메모리 경쟁이 증가했다고 판단한다.

예측이 아니라 반응형 감지

SERENO는 사용자의 다음 터치나 앱 렌더링을 미리 예측하지 않는다. 앱마다 동작이 다르고 사용자 입력은 불규칙해서 예측 모델이 놓치거나, 지나치게 보수적으로 LLM을 제한할 수 있기 때문이다.

대신 subgraph 실행 시간이 실제로 증가하는 순간을 sub-millisecond 단위로 관찰하고 바로 반응한다.

신뢰성

이 Contention Score는 실제 CPU가 경험한 DRAM 지연 지표인 Stall Cycles per LLC Miss와 약 (R=0.86)의 높은 상관관계를 보였다.

정리하면, SERENO는 “내 draft layer가 평소보다 느려졌는가?”를 관찰해 공유 메모리가 혼잡한지를 추정한다. 별도 하드웨어 지원 없이 빠르고 거의 공짜로 contention을 감지하는 것이 핵심이다.

5.3 Bandwidth Controller

5.2에서 계산한 Contention Score를 보고, LLM이 메모리 대역폭을 얼마나 양보할지 결정하는 부분

1. Draft Preemption — 즉각적인 대응

   Draft는 batch 1로 실행돼 메모리 집약도가 가장 높다. 경쟁이 감지되면 남은 draft를 바로 중단하고 verification으로 넘어가 대역폭을 즉시 내놓는다.

2. Selective Batching — 큰 단위 조절

   Verification에서 경쟁이 약하면 작은 batch를 사용하고, 경쟁이 심하면 평균 대역폭 요구량이 낮은 큰 batch graph를 선택한다.

3. Micro-sleeps — 미세 조절

   Verification subgraph 사이에 1~2ms 정도의 짧은 sleep을 넣어 메모리 사용 duty cycle을 세밀하게 낮춘다. 실행 중인 NPU graph 내부를 멈추는 것은 아니다.

PI Controller

얼마나 강하게 양보할지는 PI controller가 결정한다.

$e(t)=C{S}_{\text{measured}}-C{S}_{\text{target}}$

• 측정한 contention이 목표보다 높으면 양보 강도를 키운다.

• P 항은 현재 혼잡에 즉시 반응한다.

• I 항은 혼잡이 계속 누적될 때 제어 강도를 높인다.

Derivative 항은 사용하지 않는다. 모바일 실행 시간에는 scheduling jitter 같은 잡음이 있어, D 항이 이를 증폭하면 제어가 흔들릴 수 있기 때문이다.

Draft 단계에서는 작은 혼잡만 감지돼도 빠르게 preemption한다. Verification 단계에서는 PI 출력에 따라 batch 크기와 micro-sleep 시간을 점진적으로 조절한다. 일시적인 지연 한 번에 과민 반응하지 않도록, 여러 번 연속으로 기준을 넘었을 때 중단하는 hysteresis도 사용한다.

LLM이 굶지 않게 하는 장치

Foreground를 계속 우선하면 LLM이 거의 진행하지 못할 수 있다. 그래서 Token Bucket으로 최소 처리량을 보호한다.

• 처리량이 충분하면 정상적으로 QoS 제어

• 처리량이 부족해지면 contention 기준을 완화해 덜 양보

• 계속 부족하면 잠시 QoS 제어를 끄고 일반 speculative decoding으로 복귀

즉, UI를 보호하면서도 background LLM이 완전히 starvation되는 것은 막는다.

contention 정도를 PI controller로 판단하고, draft 중단·batch 변경·짧은 sleep을 단계적으로 조합해 필요한 만큼만 대역폭을 양보하는 것

Evaluation

7.1 Experimental Setup

7.2 End-to-End Effectiveness

Comparison with SOTA frameworks (a), (b)

Comparison with scheduling strategies (c), (d)

일반 speculative decoding은 처리량이 19.84 tokens/s로 가장 빠르지만, Social jank가 15.38%로 높다.

SERENO는 처리량을 16.0 tokens/s로 조금 양보하면서 jank를 8.14%까지 낮춘다.

반면 단순한 방식은 좋지 않았다.

• Freq-Limit: 6.74 tokens/s, jank 18.55%

• Chunk-Sleep: 대역폭은 양보하지만 sleep 중 추론 진행이 없어 비효율적

System peak performance

Gaming 상황에서 제어되지 않은 LLM 추론은 CPU·GPU benchmark 성능을 Native의 약 51%까지 떨어뜨린다.

• SERENO Balanced: 약 73%까지 회복, 10.56 tokens/s

• SERENO UI-First: 약 84%까지 회복

• GPU 점수는 Native의 92%까지 회복

MNN도 foreground 성능은 잘 보호하지만 처리량이 2.25 tokens/s에 불과하고, SERENO UI-First는 5.25 tokens/s를 유지한다.

Latency

512-token prefill과 128-token decode 요청에서 PowerServe: 11.25초, SERENO: 10.21초

SERENO의 prefill은 작은 batch 때문에 느리지만, speculative decoding으로 decode가 빨라져 전체 latency는 오히려 9% 낮다.

Sporadic workload evaluation

알림 요약이나 스마트 답장처럼 LLM이 잠깐씩 실행되는 (Sporadic) 상황도 평가했다.

SERENO의 jank는 전체 구간에서 0.72~1.16%였고, PowerServe의 1.64~2.51%보다 대략 절반 수준

7.3 Mechanism Analysis

SERENO의 센서와 controller가 실제로 의도대로 작동하는지 확인

실제 메모리 병목을 줄였는가?

저자들은 CPU가 체감하는 DRAM 지연의 proxy로 CPLM(Stall Cycles per LLC Miss)을 사용한다.

값이 클수록 LLC miss 후 메모리를 더 오래 기다렸다는 뜻이다.

SERENO는 uncontrolled PowerServe보다 CPLM을 42% 감소시켰다. 즉, 단순히 jank 지표만 좋아진 게 아니라 원인인 공유 메모리 혼잡 자체를 실제로 완화했다.

Contention Score가 믿을 만한가?

Draft subgraph 실행 시간으로 계산한 Contention Score와 실제 CPLM을 비교했다.

• 표본: 약 125,060개

• Pearson correlation: ($R\approx 0.86$)

즉, draft 실행이 평소보다 느려지는 정도가 실제 메모리 stall과 강하게 연결된다. 별도 하드웨어 카운터 없이도 메모리 혼잡을 꽤 정확히 감지한다는 의미다.

Controller가 상황에 맞게 동작하는가?

일반 workload에서는 Draft가 전체 시간의 약 35~40%를 차지한다.

반면 강한 UI-First 정책인 Gaming-B에서는:

• Draft: 20.1%까지 감소

• 저대역폭·큰 batch verification: 6.6% → 41.7%

• Micro-sleep: 1.0% → 6.9%

즉, 경쟁이 심해지면 controller가 실제로 고대역폭 Draft 감소 → 저대역폭 verification 증가 → micro-sleep 증가 형태로 실행 모드를 바꾼다. 고정 throttling이 아니라 측정된 혼잡에 따라 단계적으로 적응한다는 결과다.

Speculative acceptance가 낮아진 이유

SERENO의 후보 토큰 acceptance rate는 18.9%로, 일반 speculative decoding의 30.4%보다 낮다.

• Foreground가 바쁘면 draft를 빨리 중단하고

• 대역폭 효율이 높은 큰 verification batch를 사용하기 때문

후보 rejection은 많아지지만 N-gram Filling이 처리량 손실을 일부 보상한다.

모든 후보는 target model이 최종 검증하므로 정확성은 변하지 않는다.

7.4 Ablation Study

Component ablation

• Draft Preemption이 가장 큰 효과를 낸다. Jank를 8.5%에서 4.5%로 약 47% 감소시켜, 빠르게 draft를 끊는 것이 foreground 보호의 핵심임을 보여준다.

• Selective Batching과 Micro-Sleep은 verification 단계의 남은 메모리 burst를 줄여 jank를 Native 3.0%에 가깝게 만든다. 하지만 이 제어들 때문에 처리량이 감소한다.

• N-gram Filling은 대역폭 제어 기능이 아니라, 감소한 처리량을 12.9 → 15.6 tokens/s로 회복하는 보상 기능이다.

N-gram filling ablation

N-gram 자체의 개선 기법도 별도로 실험했는데, 최종적으로 처리량을 14.42 → 18.06 tokens/s로 높여 preemption 때문에 손실된 속도의 약 25.2%를 회복했다.

7.5 System Analysis

Energy efficiency

CPU 기반	1.81 tokens/J
Chunk-Sleep	2.07 tokens/J
일반 Speculative	3.78 tokens/J
SERENO	3.52 tokens/J

SERENO는 일반 speculative decoding보다는 약 7% 낮지만, 단순 sleep이나 CPU 방식보다 훨씬 효율적

NPU를 느린 주파수로 오래 실행하기보다, 높은 성능으로 유효한 작업을 빨리 수행한 뒤 양보하는 race-to-sleep 방식이기 때문이다.

Hardware generality

Snapdragon 8 Gen 3에서도 Tools와 Social workload의 jank를 약 59~62% 감소시켜 8 Elite와 비슷한 효과를 보였다.
구형 칩에서는 게임 병목이 메모리 대역폭보다 CPU/GPU 연산 부족으로 바뀔 수 있기 때문이다. SERENO는 대역폭 문제를 해결하는 시스템이므로 compute-bound 상황에는 효과가 제한된다.

Task and model robustness

ShareGPT, GSM8K, HumanEval에서 실험한 결과

처리량: 15.89~17.16 tokens/s, Jank: 7.45~8.12%로 비교적 안정적이었다.

논문은 모든 후보를 target model이 검증하므로 lossless라고 보고, 별도의 출력 정확도 평가는 하지 않았다.

다만 모델 평가는 Llama 계열 dense Transformer 중심이라는 범위 제한은 있다.

System overhead

• CPU 사용량: 단일 코어 기준 약 4.7% 증가

• 추가 메모리: 0.86GB, 약 19% 증가

• SERENO 전용 static graph: 70MB 미만

추가 메모리 대부분은 SERENO controller 자체가 아니라 speculative decoding에 필요한 1B draft model의 가중치 때문이다.

Related Work

Efficient On-Device LLM Inference

기존 연구는 주로 다음을 통해 LLM 자체를 빠르게 만드는 데 집중했다.

• 양자화와 sparsity로 모델 크기·연산량 감소

• CPU·GPU·NPU를 효율적으로 활용하는 추론 프레임워크

• 모바일 NPU용 연산 최적화

하지만 대부분 LLM이 하드웨어를 독점적으로 사용한다고 가정해, foreground 앱과 동시에 실행될 때의 자원 경쟁은 고려하지 않았다.

SERENO는 이런 추론 엔진을 대체하기보다, 그 위에 붙어서 멀티태스킹 QoS를 관리하는 control plane에 가깝다.

Speculative decoding

기존 speculative decoding 연구는 작은 모델의 후보를 큰 모델이 검증해 decode 속도를 높이는 것이 목적

SERENO의 차이는 speculative decoding을 가속 기법 → 중간에 멈출 수 있는 자원 스케줄링 기법으로 재해석했다는 점이다.

논문은 비슷한 원리를 early exit에도 적용해, 혼잡할 때 얕은 경로를 선택하는 식으로 확장할 수 있다고 본다.

Limitation & Future Work

이건 논문에 명시한게 아닌 내 생각이다.

3.2 Physical Attribution: Bandwidth에서

Foreground 앱이 느려지는 원인은 연산 코어나 캐시 부족이 아니라, NPU가 공유 메모리 대역폭을 과도하게 차지해 CPU와 GPU의 메모리 접근 지연이 증가하기 때문이라고 언급했다.

그래서 SERENO는 메모리 대역폭 contention을 대상으로 한다.

하지만, 구형 SoC의 gaming workload에서는 병목이 메모리 대역폭보다 CPU/GPU compute로 바뀌면서 효과가 감소했다.

최근 모바일 LLM 분석에서도 모델 단계와 runtime에 따라 CPU·GPU·NPU의 상대 성능과 에너지 효율이 달라지고, NPU가 항상 최선의 backend는 아니라는 결과가 보고되고 있다.

https://arxiv.org/abs/2607.05475v1

“The optimal execution backend depends fundamentally on the inference phase.”

→ compute-bound인 prefill에서는 NPU가 강하지만, memory-bound인 decode에서는 CPU가 더 빠른 phase split을 관찰했다. NPU는 크고 고정된 shape의 작업에 적합하지만, decode는 작고 동적인 kernel을 반복하기 때문에 구조적으로 잘 맞지 않는다!

“A complex scheduling problem requiring both intra-backend calibration and cross-backend coordination.”

→ 모바일 LLM 최적화는 단순히 좋은 kernel을 만드는 문제가 아니라, backend 내부의 frequency·thread·sleep 조정 + CPU·GPU·NPU 사이의 실행 분배를 함께 고려하는 scheduling 문제다!

https://arxiv.org/abs/2605.27435v1

“Adopt stage-aware backend selection.”

→ 이 논문은 아예 design guideline으로 prefill과 decode에 서로 다른 backend를 배정해야 한다고 제안한다. 해당 구현에서는 CPU가 prefill에서 1.27–1.62배 빠르고, decode 핵심 GEMV 연산에서는 NPU가 유리하다!

두 연구가 제시하는 최적 backend가 서로 다르다

→ 특정 phase에 항상 적합한 backend가 존재하지 않음을 보여준다. 최적 backend는 SoC뿐만 아니라 runtime, kernel implementation, quantization, operator coverage, context length 등에 따라 달라질 수 있다.

→ backend 선택을 LLM 단독 처리량만으로 결정해서는 안 된다.

Foreground application의 현재 병목에 따라서 동일한 backend가 서로 다른 간섭을 발생시킬 수 있다!

• CPU-bound foreground → CPU 기반 LLM 실행 회피

• GPU-bound foreground → GPU offloading 회피

• Memory-bound foreground → backend 변경만으로는 불충분 (SERENO 사용)

• Thermal/power pressure → 에너지 효율을 고려한 backend 및 실행 강도 조절

SERENO는 하나의 주요 병목 현상 하에서 하나의 백엔드를 제어한다.
앞으로는 동적으로 변화하는 병목 현상 하에서 이기종 백엔드를 선택하고 제어해야 한다!

게임+LLM 타겟

위에서 말했듯이, Game에서는 Memory bound가 아니기 때문에 CPU/GPU 같은 compute bound 문제를 해결해야한다.

• 최근 배틀 그라운드 등 게임에서 npc와 함께 플레이 하는 서비스를 선보이고 있다.

• 아직은 서버 Side로 진행중인데, 서버에서 모델을 유저 개개인에 대해 돌리려면 컴퓨팅/리소스/네트워크 병목 등 한계가 있다.

• 그리고 무엇보다, 개인적인 대화 내용이 서버로 넘어가기 때문에 사용자가 꺼려할 수 있다.

• On-device 또는 hybrid LLM execution은 이러한 문제를 줄일 수 있지만, 게임은 엄격한 frame deadline을 가지므로 백그라운드 LLM이 foreground 성능을 저하시켜서는 안 된다.

• 게임의 dominant bottleneck은 장면과 실행 단계에 따라 동적으로 변할 수 있다.
  • CPU-bound: game logic, physics, simulation
  • GPU-bound: rendering and shader execution
  • Memory-bound: asset streaming and unified-memory contention
  • Thermal-bound: sustained gaming and LLM execution

따라서 고정된 backend나 memory-only control보다, 현재 게임 병목과 LLM inference phase를 함께 고려하는 runtime adaptation이 필요하다.

RAG-based Gaming Agent

RAG 기반 Gaming Agent는 NPC의 기억, 퀘스트 상태, 월드 정보와 같은 게임 지식을 실시간으로 검색해 LLM 응답에 반영할 수 있다.

이때 embedding 생성, vector index 삽입, 요약·정리 작업이 추가 자원을 사용한다.

하지만 이런 memory update는 매번 즉시 수행할 필요가 없다. 전투처럼 foreground 부하가 높은 구간에서는 미루고, 메뉴·로딩 화면이나 자원 여유가 있는 시점에 batch로 처리할 수 있다.

따라서 향후에는 frame SLO를 지키면서 RAG memory update를 자원 여유 구간에 opportunistically 배치하는 방식으로 고려해보면 재밌을 것 같다.