FlashAttention과 PagedAttention 차이

모델은 입력 토큰이 서로 참고할 정보를 어텐션으로 계산해요. 입력이 길수록 중간 결과를 GPU⁶ 메모리에 쓰고 다시 읽는 이동이 많아져요. FlashAttention은 입력을 작은 타일로 계산하고 중간 결과를 큰 배열에 반복 기록하지 않아 데이터 이동을 줄여요.

입력 전체를 어텐션 계산에 사용하면서 중간 결과의 저장과 이동을 줄이는 방식이에요. 긴 입력에서 첫 토큰까지 오래 걸린다면 모델 로딩 시간과 프리필 시간을 나누어 기록하고, 실행 로그에서 FlashAttention 커널이 선택됐는지 확인해요.

서버에 길이가 다른 요청이 들어오면 각 대화는 입력과 지금까지 생성한 토큰의 상태를 KV 캐시에 보관해요. PagedAttention은 이 캐시를 같은 크기의 블록으로 관리하고 요청마다 필요한 만큼 배정한 뒤 완료되면 회수해요. 큰 연속 메모리를 요청별로 미리 잡아둘 때 생길 수 있는 빈 공간을 줄이는 목적이에요.

요청 A가 이어지는 동안 짧은 B가 끝나면 B의 블록을 회수해 C에 배정할 수 있어요. A의 대화에 필요한 상태는 A가 끝날 때까지 유지해요. 같은 GPU 메모리 안에서 요청별 공간을 효율적으로 나눠 쓰는 거예요.

동시 요청이나 문서 길이가 늘면 활성 캐시도 필요해요. 입력 프리필이 실행 중인 디코드⁷와 GPU 자원을 나누면 토큰 간격이 길어질 수 있고, 긴 프리필을 나누어 스케줄링하는 지원 여부는 런타임⁸마다 달라요. 캐시를 더 효율적으로 배치해도 실제 상태를 담을 물리 메모리는 필요해요.

FlashAttention은 어텐션 계산 중 데이터가 메모리를 오가는 방식을 바꾸고, PagedAttention은 각 요청의 KV 캐시를 블록에 배정하는 방식이에요. 같은 런타임이 모두 지원하면 프리필 계산과 요청 메모리 관리를 함께 최적화할 수 있어요. 긴 코드 입력에서 프리필이 느린 문제와 팀 요청이 겹칠 때 캐시 공간이 부족한 문제는 각각 다른 조건을 확인해요.

지원 여부는 GPU·모델 구조·양자화⁹·앱 버전에 따라 달라지고, 런타임이 자동으로 경로를 고를 수도 있어요. 메뉴에 옵션 이름이 보이는지만으로 적용됐다고 보지 말고 로그에서 실제 커널과 캐시 경로를 확인해요. 강제 설정을 시험하기 전 정상 실행되는 기본값을 기록해 둬요.

개인용으로 짧은 함수 하나를 물으면 동시 캐시 상태가 적어 PagedAttention의 서버 메모리 배치 이점이 작을 수 있어요. FlashAttention도 프리필과 한 토큰씩 만드는 디코드에서 효과가 같다고 볼 수 없어요. 첫 토큰 대기와 생성 중 토큰 간격을 분리해 기록해요.

팀 서버는 한 요청의 기준 결과를 만든 뒤 긴 코드 분석 중 짧은 질문과 다른 분석을 겹쳐 보내요. 첫 토큰, 생성 구간, 피크 메모리, 요청별 지연, 전체 처리량¹⁰을 기록하면 커널 계산과 캐시 관리 중 어떤 변화가 사용자에게 도움이 됐는지 볼 수 있어요.

런타임이 허용하는 옵션을 한 번에 하나씩 시험하고 로그에서 실제 적용을 확인해요. 사용자 조정 옵션이 없으면 임의로 넣지 말고 자동 선택 여부를 로그에서 살펴요. 입력 계산이 병목일 때 FlashAttention 경로를, 겹치는 요청의 캐시 배치가 문제일 때 PagedAttention 지원을 확인해요.