SSM 직관

마지막 수정:

ssmmambamodelsequence

SSM은 State Space Model의 약자다.

한 문장으로 말하면:

sequence의 과거를 고정 크기 state에 압축해 두고,
새 token을 볼 때마다 그 state를 갱신하는 모델이다.

Transformer attention은 현재 token이 과거 token들의 표현을 직접 다시 본다. 그래서 decode에서는 과거 token의 K/V를 cache로 들고 있어야 한다.

SSM은 질문을 다르게 던진다.

과거 token 전체를 계속 들고 있을 필요가 있을까?
지금까지의 과거를 하나의 state로 요약해 갱신할 수는 없을까?

기본 그림

SSM의 계산은 recurrent하게 볼 수 있다.

state_{t-1} + input_t -> state_t -> output_t

여기서 중요한 점은 state_t의 크기가 sequence length에 직접 비례하지 않는다는 것이다. token이 길어져도 state의 모양은 모델이 정한 차원 안에 머문다.

이 관점은 Transformer의 KV cache와 다르다.

Transformer:
past token 수가 늘면 KV cache도 늘어난다.

SSM:
past token 수가 늘어도 recurrent state 크기는 고정된다.

왜 LLM에서 다시 중요해졌나

긴 context에서 Transformer attention은 과거 token을 직접 참조하기 때문에 cache memory와 memory bandwidth가 커진다. SSM은 고정 크기 state를 통해 sequence를 처리하므로 long-context 효율성의 후보가 된다.

하지만 이것이 “SSM은 모든 문제가 사라진다”는 뜻은 아니다.

SSM은 KV cache 문제를 없애는 대신, 다음 질문을 만든다.

state를 어디에 저장할 것인가?
prefill에서 state를 어떻게 빠르게 계산할 것인가?
decode에서 state를 어떻게 갱신할 것인가?
batch 안의 여러 request state를 어떻게 관리할 것인가?

이 질문들이 Mamba, selective state update, vLLM의 Mamba cache로 이어진다.

연결

확인

  • SSM에서 state는 무엇을 대신하는가?
  • SSM state가 sequence length와 직접 같이 커지지 않는다는 말은 무슨 뜻인가?
  • SSM이 KV cache 문제를 없앤다고만 말하면 부족한 이유는 무엇인가?