Multi-Stream LLM, 프롬프트와 사고와 입출력을 분리해서 병렬로 돌린다

무슨 논문인가

arXiv에 "Multi-Stream LLMs"라는 제목의 새 논문이 올라왔어요. 핵심 아이디어를 한 줄로 요약하면, 지금 우리가 쓰는 LLM은 프롬프트 처리, 추론(thinking), 입출력(I/O)을 한 줄로 줄 세워서 처리하는데, 이걸 여러 "스트림"으로 쪼개서 병렬로 진행시키자는 거예요.

좀 더 풀어서 설명하면 이래요. 지금 ChatGPT나 Claude 같은 모델에 질문을 던지면 안에서 대략 이런 순서로 일이 진행됩니다. 먼저 입력 프롬프트를 처리하고(이걸 prefill이라고 해요), 그다음 토큰을 한 개씩 생성하면서 답을 만들고(decoding), 추론 모델이라면 그 사이에 "생각하는 단계(thinking)"가 끼어들고, 도구를 호출해야 하면 그 결과를 기다렸다가 다시 이어서 생성합니다. 이게 다 순차적으로 일어나요.

무엇이 문제인가

순차 처리의 가장 큰 문제는 GPU가 노는 시간이 많다는 거예요. 예를 들어 모델이 외부 API를 호출해서 결과를 기다리는 동안, 또는 사용자가 다음 메시지를 입력하는 동안, 비싼 H100 GPU는 그냥 대기 상태로 있거든요. 추론 모델의 경우엔 더 심해요. 사용자에게 보여줄 최종 답을 만들기 전에 "생각하는 토큰"을 수천 개씩 뽑는데, 그동안 사용자는 화면을 멍하니 보고 있어야 합니다.

또 다른 문제는 컨텍스트가 한 덩어리로 묶여 있다는 거예요. 시스템 프롬프트, 사용자 입력, 모델의 사고 과정, 도구 결과가 다 같은 시퀀스에 들어가서 어텐션 계산의 부담이 같이 커집니다. 16만, 100만 토큰 컨텍스트로 가면 이게 메모리 병목이 되거든요.

Multi-Stream의 핵심 아이디어

논문은 이 세 가지(프롬프트, 사고, I/O)를 별도의 스트림으로 분리합니다. 각 스트림이 자기 페이스로 동시에 진행되고, 필요할 때만 동기화하는 구조예요. 비유하자면, 지금 LLM이 "한 사람이 듣고-생각하고-말하는 걸 순서대로 하는 모놀로그"라면, Multi-Stream LLM은 "여러 사람이 동시에 일하면서 필요할 때 회의실에서 만나는 팀" 같은 느낌이에요.

구체적으로는 이런 식이에요. 프롬프트 스트림은 사용자 입력이 들어오는 대로 계속 인코딩하면서 KV 캐시를 늘려갑니다. 사고 스트림은 그 KV 캐시를 참조해서 추론을 진행하는데, 사용자가 추가 메시지를 입력하더라도 그걸 끊지 않고 옆에서 통합해요. I/O 스트림은 도구 호출이나 외부 API와의 통신을 비동기로 처리합니다. 세 스트림이 같은 모델 가중치를 공유하지만, 별도의 어텐션 마스크와 캐시 영역을 갖는 게 핵심 기법이에요.

이걸 가능하게 하는 기술적 트릭은 어텐션의 블록별 분리예요. 트랜스포머 어텐션을 계산할 때 어떤 토큰이 어떤 토큰을 볼 수 있는지를 정의하는 마스크가 있는데, 이걸 스트림별로 다르게 설정해서 "사고 스트림은 프롬프트 스트림을 참조할 수 있지만 그 반대는 아니다" 같은 관계를 만들 수 있거든요.

기존 접근과 뭐가 다른가

비교 대상으로 몇 가지가 있어요. Speculative Decoding(추측 디코딩)은 작은 모델이 토큰을 미리 뽑고 큰 모델이 검증하는 방식인데, 여전히 한 줄짜리 생성이에요. Continuous Batching은 여러 요청을 묶어서 처리하지만, 하나의 요청 안에서의 순서는 그대로예요. OpenAI o1, Claude의 extended thinking 같은 추론 모델은 "생각하는 시간"을 잘 활용하지만, 그동안 다른 작업은 멈춰 있죠.

Multi-Stream은 한 요청 안에서의 병렬화라는 점에서 결이 달라요. 특히 에이전트(agent) 시나리오에서 강해요. 에이전트가 도구를 5번 호출하면서 그 사이사이에 생각하는 패턴이 일반적인데, 지금 구조에선 도구 호출 응답이 올 때까지 GPU가 놀거든요. Multi-Stream이라면 그 시간에 다른 가능성을 미리 탐색해두거나, 들어올 가능성이 높은 후속 도구 호출의 컨텍스트를 미리 처리해둘 수 있어요.

한국 개발자에게 시사하는 것

첫째, LLM 추론 인프라를 직접 운영하는 팀에게는 흥미로운 최적화 방향이에요. vLLM, SGLang, TensorRT-LLM 같은 추론 엔진들이 이런 아키텍처를 어떻게 흡수할지 지켜볼 만합니다. 같은 GPU로 더 많은 동시 사용자를 받을 수 있다는 건 단가에 직결되거든요.

둘째, 에이전트 시스템을 만드는 분들에게 영감이 됩니다. 지금 LangGraph, AutoGen 같은 프레임워크는 외부에서 워크플로우를 짜는 방식인데, 모델 내부에서 이미 병렬성이 지원된다면 에이전트 설계 패턴 자체가 바뀔 수 있어요. "여러 추론 경로를 동시에 탐색하면서 부분 결과를 스트리밍"하는 UX가 자연스러워지는 거죠.

셋째, 사용자 경험 관점에서요. 챗봇이 "생각 중..."이라고 멈춰 있는 시간이 줄어들고, 사용자가 메시지를 추가해도 모델이 이미 진행하던 생각을 버리지 않고 자연스럽게 흡수하는 경험이 가능해집니다. 진짜 사람과 대화하는 것에 한 발 가까워지는 거예요.