같은 맥락에서 여러 판단을 빠르게 처리하는 Flide

배경과 문제

결정 모델은 긴 대화나 에이전트 기록을 읽고, 다음에 무엇을 할지 또는 어느 경로로 요청을 보낼지 판단한다. 일반 챗봇처럼 설명문을 길게 생성하기보다 주어진 선택지의 확률을 출력한다. 이런 판단이 에이전트의 매 단계에서 반복되면 짧은 지연도 누적된다. 확률이 정해진 임계값을 넘는지에 따라 행동을 바꾸는 서비스에서는 처리 속도와 출력의 수치적 안정성이 함께 중요하다.

요청 하나를 나무로 생각하면 이해하기 쉽다. 모든 질문이 읽는 기사나 대화가 줄기이고 질문들이 가지다. 각 질문은 줄기와 자기 질문의 앞부분만 읽어야 한다. 앞서 나열된 다른 질문까지 읽으면 원래의 독립 질문과 다른 문제가 된다. Flide의 목표는 이 독립성을 유지하면서 공통 계산은 공유하고, 여러 가지를 한꺼번에 GPU에 실행하는 것이다.

기존 접근의 한계

vLLM과 SGLang 같은 생성용 엔진에서는 질문마다 프롬프트를 만들고 토큰화하고 시퀀스를 관리한다. 접두부 캐시가 공통 계산 일부를 줄여도 질문별 실행·복원 비용은 남는다. 특히 하이브리드 모델의 순환 상태를 블록 경계에서만 복원하면 경계 뒤의 꼬리를 다시 계산해야 한다. 다만 모든 기존 엔진이 공유 문맥 전체를 매번 계산한다는 뜻은 아니다. 원문에서도 전체 어텐션을 쓰는 Gemma 4의 vLLM은 공유 상태를 한 번 계산한다고 구분한다.

질문을 한 시퀀스에 이어 붙이는 SGLang의 다중 항목 점수화(MIS)는 공유 계산을 늘리지만 구분 토큰이 실제 모델 입력에 들어간다. 이 때문에 독립 질문의 확률과 달라질 수 있다. 어텐션 마스크로 읽을 토큰을 나누더라도, Gated DeltaNet처럼 과거 정보를 하나의 순환 상태에 접는 층은 별도로 분기해야 한다. 서버 부하에 따른 배치 변화가 부동소수점 합산 순서를 바꾸는 문제도 논리적 질문 분리와는 별개로 남는다.

연구방법을 단계별로

첫째, 요청과 질문의 소속을 GPU 메타데이터로 표현하고 토큰은 평평한 스트림에 모은다. 질문의 위치 번호는 공유 문맥 다음부터 이어져 독립 실행과 같은 위치 정보를 쓴다. ForkAttention은 각 토큰이 같은 요청의 줄기와 자기 가지의 현재·이전 토큰만 읽게 한다. 앞쪽에 놓인 다른 질문이나 다른 요청은 보이지 않는다. 토큰을 붙이는 물리적 배치와 실제 읽기 관계를 분리한 것이다.

둘째, Gated DeltaNet 층에서는 먼저 모든 요청의 공유 문맥을 처리해 마지막 순환 상태와 합성곱 창을 저장한다. 다음 호출에서 질문들을 함께 계산하되 각 질문이 자기 요청의 저장 상태에서 시작한다. 이 두 단계가 어텐션 마스크만으로 처리할 수 없는 순환 층의 분기를 구현한다. 명제와 부록의 증명은 정확한 산술에서 독립 프롬프트와 같은 함수를 계산한다는 내용이며, 실제 저정밀 연산의 모든 비트가 자동으로 같다는 정리는 아니다.

셋째, 스트림 용량별 CUDA 그래프를 준비해 반복적인 GPU 커널 실행 요청 비용을 줄인다. 매 라운드의 질문 수와 길이는 장치 버퍼의 값으로 바뀌므로 동적인 요청도 이미 준비한 그래프에 넣을 수 있다. 패딩은 스트림 꼬리에만 둔다. 큰 라운드는 요청 경계에서 나눠 실행하고, 단일 요청이 최대 그래프에 들어가지 않으면 그래프 없는 경로를 쓴다. 마지막 층에서는 모든 토큰의 키·값은 유지하되 출력에 필요한 질문 끝 토큰을 중심으로 후속 계산하는 선택적 판독도 적용한다.

넷째, 에이전트 기록이 늘어날 때는 이전 문맥의 내부 위치에 저장한 체크포인트를 재사용한다. 그 위치까지 토큰이 일치해야 재개할 수 있으며, 순환 상태·합성곱 창·어텐션의 KV 캐시를 함께 보관한다. 바뀔 수 있는 꼬리는 체크포인트 뒤에 남겨 새 토큰과 함께 계산한다. 선택적인 배치 불변 모드는 합산 순서와 질문별 계산 경계를 고정해 부하 변화에 따른 비트 차이도 줄인다. 이 모드는 별도 성능 비용이 있는 선택 사항이다.

결과와 숫자의 의미

주요 실험은 NVIDIA H200 한 대에서 Qwen3.5와 Gemma 4의 여러 크기를 bfloat16으로 실행했다. RACE·QuALITY·MultiRC·Decision Index에서 여섯 워크로드를 만들고, 단독 요청의 중앙 지연 시간과 여러 클라이언트가 계속 요청하는 처리량을 구분했다. 모델과 워크로드가 같아도 동시 요청 수가 다르면 비교할 수치가 달라진다. 엔진은 차례로 시작하고 각 부하 단계 전에 접두부 캐시를 비웠으며, 요청 사본끼리 공유 상태를 재사용하지 못하도록 별도 태그를 넣었다.

표 3의 최대 9.5배는 Qwen3.5-0.8B의 QuALITY 전체 질문에서 확인할 수 있다. 단독 요청 지연은 vLLM 362ms, SGLang 359ms, Flide 37.7ms다. 같은 워크로드의 클라이언트 8개 처리량은 각각 초당 4.5·4.6·39.1요청으로, 최고 비교군 대비 8.5배다. 긴 문맥에 여러 질문이 붙을수록 이점이 컸다. 질문 하나인 작은 모델의 최대 지연 개선은 3.2배였지만 큰 모델에서는 비교군과 비슷하거나 조금 느린 셀도 있어 최대치를 일반화할 수 없다.

표 4는 정답률과 기준 출력 일치도를 따로 보여준다. Qwen3.5 네 크기의 평균에서 Flide의 최상위 답은 모든 워크로드에서 float32 기준과 가장 자주 일치했다. 실제 문제 정답률은 각 셀에서 vLLM과 1.2퍼센트포인트 이내였으며 항상 더 높은 것은 아니다. 클라이언트 한 개에서 64개로 바꿀 때 최상위 답이 달라진 비율의 최대치는 Flide 0.2%, SGLang 1.7%, vLLM 3.2%였다. 이는 부하 변화의 안정성이지 오답률이 아니다.

구분 토큰의 영향은 또 다른 검사다. Qwen3.5-4B에서 MIS의 float32 기준 대비 총 변동 거리 중앙값은 Flide의 약 12배였다. 확률 0.5를 넘는지에 따른 판정 뒤집힘은 시험한 설정에서 MIS 최대 29%, Flide 최대 2.3%였다. 이 수치를 일반적인 문제 오답률로 읽으면 안 된다. SWE-agent의 공개 실행 기록을 재생한 별도 실험에서는 Flide가 가장 강한 비교군보다 초당 4.4~7.2배 많은 단계를 처리했다. 실제 코딩 과제의 완료율이 높아졌다는 결과는 아니다.

구체적인 예시

한 RACE 지문에 네 객관식 질문이 있다면 네 질문의 공통 지문 처리를 공유하되 답끼리 영향을 주지 않아야 한다. 표 3의 Qwen3.5-0.8B에서 전체 질문 요청의 지연은 vLLM 47.3ms, SGLang 31.0ms, Flide 7.2ms였다. Flide는 지문을 읽은 상태에서 네 가지를 만들고 함께 실행한다. 비교 엔진의 캐시가 일부 계산을 줄이더라도 질문마다 남는 토큰화·복원·스케줄링 비용까지 같은 정도로 없애지는 못한다.

에이전트가 저장소를 살펴보고 도구 결과를 기록하는 경우, 다음 판단에는 이전 기록과 새 기록이 함께 필요하다. Flide는 일치하는 이전 접두부에서 재개하고 새 기록과 변경된 꼬리를 계산한다. 표 7의 Qwen3.5-4B에서 기록 길이 구간에 따른 단계 지연은 4천 토큰 미만 22.4ms, 1만2천 토큰 초과 36.1ms였다. 기록이 늘어도 공짜가 되거나 시간이 완전히 일정한 것은 아니지만, 매 단계 전체를 다시 처리하는 부담을 줄이는 원리를 보여준다.

한계와 오해하기 쉬운 점

정확 산술의 동등성, float32 기준과의 근접성, 실제 문제의 정답률은 서로 다른 주장이다. 기본 모드에서는 커널과 타일 모양에 따라 반올림 차이가 생긴다. 부록 표 12의 선택적 배치 불변 모드는 시험한 여섯 모델·여섯 워크로드에서 부하에 따른 비트 일치를 보였지만 클라이언트 64개에서 처리량이 최대 10% 줄었다. 같은 실행 환경에서의 부하 불변성을 다른 하드웨어·소프트웨어 사이의 보편적 재현성으로 확대해서는 안 된다.

주요 성능 수치는 한 GPU와 정해진 모델·데이터셋의 결과다. Flide와 vLLM은 같은 프롬프트를 쓰지만 SGLang과 vllm-jev는 자기 템플릿을 사용하므로 정확도 비교에 입력 표현의 차이도 있다. 다중 항목 점수화는 CUDA 그래프를 끈 설정이다. 이런 조건을 생략하면 엔진 설계 자체의 차이와 주변 실행 환경의 차이를 구분하기 어렵다.

이 엔진의 중심은 공유 문맥에서 선택지 확률을 얻는 결정 요청이다. 임의의 긴 자유 생성 대화, 여러 GPU 분산 서비스, 모든 모델에서 같은 가속을 검증한 논문은 아니다. 질문 수가 적거나 모델 계산이 대부분인 요청에서는 이점이 작다. 여기서는 공개 원문과 표를 대조했으며 엔진을 설치해 저자의 속도 결과를 독립 재현한 것은 아니다.

실제로 어떻게 활용할까

적용 가능성을 검토할 때는 같은 상태를 읽는 판단이 여러 개 있는지부터 살펴볼 수 있다. 가상의 고객 지원 예라면 한 대화에서 담당 부서·긴급도·정책 위반 여부를 따로 판단하는 구조가 해당한다. 이를 한 요청의 독립된 질문들로 묶을 수 있다면 공유 계산의 이점을 시험할 수 있다. 이는 논문의 기법을 설명하는 사용 예이며 실제 고객 지원 성능 측정은 아니다.

확률 임계값으로 행동을 선택하는 서비스라면 지연과 처리량뿐 아니라 기존 엔진 대비 확률 분포, 임계값 부근의 판정 변화, 부하 변화의 재현성을 함께 비교해야 한다. 에이전트 기록에서는 접두부가 실제로 일치하는지와 체크포인트 보관 비용도 확인할 항목이다. 배치 불변 모드를 켤지는 비트 재현성의 필요와 처리량 손실을 같은 요청 집합에서 측정해 정할 수 있다.