당신이 아주 거대하고 복잡한 비디오 게임을 컴퓨터에서 실행하려고 한다고 상상해 보세요. 하지만 당신은 하드웨어를 직접 만지는 것을 허용하지 않는 매우 엄격하고 보안을 중시하는 관리자를 통해서만 게임을 실행해야 합니다. 이것이 바로 웹 브라우저 내에서 인공지능(특히 거대 언어 모델, 즉 LLM)을 실행하는 세계입니다. 이 모델들은 이야기를 쓰고, 수학 문제를 풀고, 대화를 나누는 챗봇의 두뇌 역할을 합니다. 개발자들은 이 모델들을 슈퍼컴퓨터 없이도 당신의 노트북이나 스마트폰에서 빠르게 실행하기 위해 WebGPU라는 특별한 도구를 사용합니다. WebGPU를 당신의 브로커가 컴퓨터의 그래픽 카드(보통 비디오 게임을 렌더링하는 부분)와 대화할 수 있게 해주는 '만능 통역사'라고 생각하면 됩니다. 이를 통해 AI를 위한 무거운 수학 연산을 수행할 수 있습니다.

하지만 문제가 하나 있습니다. 과거에 개발자들이 AI 모델을 더 빠르게 만들기 위해 노력했을 때, 그들은 개별적인 수학 단계(이를 "커널"이라고 부릅니다)를 더 효율적으로 만드는 데 집중했습니다. 이는 마치 자동차의 엔진을 더 정교하게 닦는 것과 같습니다. 하지만 이 논문은 다른 질문을 던집니다. "만약 자동차 자체는 멀쩡한데, 운전자가 차에 타고 내리는 데 너무 많은 시간을 쓰고 있다면 어떨까?" 브라우저의 세계에서는 매 수학 단계마다 브라우저에서 그래픽 카드로 작업을 시작하라는 요청인 "디스패치(dispatch)"를 보내야 합니다. 이 거대한 미스터리는 바로: 우리가 실제로 수학 계산을 하는 시간 대비, 이러한 요청을 보내는 데 얼마나 많은 시간이 낭비되고 있는가 하는 점이었습니다. 이 문제를 이해하는 것은 매우 중요합니다. 왜냐하면 만약 컴퓨터에게 일을 시키기 위해 요청을 보내는 데 너무 많은 시간을 낭비한다면, 아무리 똑똑한 수학 계산을 하더라도 챗봇은 느리고 답답하게 느껴질 것이기 때문입니다.

"스톱 앤 고(Stop-and-Go)" 교통 체증

이 논문의 연구자는 모두가 이러한 AI 요청의 속도를 측정하는 방식을 완전히 잘못 알고 있었다는 사실을 발견했습니다. 당신이 배달 기사가 택배를 전달하는 시간을 측정한다고 상상해 보세요. 만약 기사가 창고를 떠나서 집으로 운전해 가고, 택배를 내려놓고, 다시 다음 물건을 가지러 창고로 돌아오는 시간까지 모두 포함해서 시간을 잰다면, 당신은 전체 왕복 시간을 측정하는 것입니다. 하지만 실제 AI의 세계에서 기사는 매번 택배 하나를 배달할 때마다 창고로 돌아가지 않습니다. 한 번에 한 꾸러미를 통째로 내려놓고, 마지막에 딱 한 번만 창고로 돌아갑니다.

논문은 이전의 측정 방식들이 모든 패키지에 대해 이 전체 왕복 시간을 측정했던 것과 같았음을 보여줍니다. 그들은 요청을 보내는 시간(디스패치)과 컴퓨터가 "알았어, 다 했어"라고 말할 때까지 기다리는 시간(동기화)을 혼동했습니다. 이 "대기 시간"은 엄청나게 큰데, 약 450 마이크로초의 일시 정지와 같습니다. 연구자들이 모든 단계에 이 대기 시간을 더했을 때, 그들은 요청을 보내는 비용이 실제보다 약 20배나 더 높다고 생각했습니다.

저자는 "순차적 디스패치(sequential-dispatch)"라는 새로운 방법을 사용하여, 중간의 긴 대기 시간 없이 오직 요청을 보내는 행위 자체만을 측정하는 방법을 알아냈습니다. 그 결과 실제 비용은 훨씬 낮다는 것을 밝혀냈습니다. 일부 시스템(Vulkan)에서는 24~36 마이크로초, 다른 시스템(Metal)에서는 32~71 마이크로초 사이였습니다. 흥로하게도, 이 비용은 컴퓨터가 "float32" 또는 "float16" 숫자(두 가지 다른 소수점 저장 방식)를 사용하는 것과 관계없이 동일했습니다. 이는 지연 시간이 수학적 계산 때문이 아니라 브라우저의 규칙 때문에 발생한다는 것을 증명합니다.

진짜 병목 현상: 너무 많은 멈춤

단일 요청의 실제 비용을 파악한 후, 팀은 다음과 같은 질문을 던졌습니다. "이것이 실제로 중요한가?" 이를 알아내기 위해 그들은 통제된 실험을 수행했습니다. 표준 AI 모델을 가져와서 구성 방식을 변경했습니다. 텍스트의 단어 하나를 처리하기 위해 그래픽 카드에 876개의 작은 요청을 보내는 대신, 몇몇 단계들을 "퓨즈(fuse, 결합)"하여 그래픽 카드가 564개의 요청만 받도록 만들었습니다.

여기서 핵심은, 그들이 요청 내부의 수학 계산을 더 빠르게 만든 것이 아니라는 점입니다. 그들은 코드를 더 똑똑하게 만들거나 메모리를 적게 사용하도록 수정하지 않았습니다. 단지 브라우저가 그래픽 카드의 문을 두드려야 하는 횟수를 줄였을 뿐입니다.

결과는 어떠했을까요? AI는 53% 더 빨라졌습니다. 첫 번째 단어를 생성하는 데 걸리는 시간이 71.4 ms에서 41.6 ms로 단축되었습니다.

이 실험은 가장 흔한 설정(단어 하나씩 처리하는 "배치 사이즈 1")에서, 가장 큰 문제는 수학이 너무 느리거나 메모리가 부족한 것이 아님을 입증했습니다. 문제는 단순히 "문을 너무 많이 두드리는 것"이었습니다. 저자는 더 나은 수학 코드나 적은 메모리 사용량이 속도 향상의 이유가 아니라는 점을 명시적으로 배제했습니다. 바뀐 것은 오직 디스패치의 횟수뿐이었습니다.

이것이 미래에 의미하는 바

논문은 결론적으로, 브라우저에서 AI 챗봇을 원활하게 실행하고 싶다면 모든 개별 수학 단계를 완벽하게 만드는 데 집중할 것이 아니라, 이 단계들을 하나로 묶는 데 집중해야 한다고 말합니다. 이는 마치 배달 트럭을 더 빨리 도착하게 하려면 운전자가 더 빨리 뛰게 만드는 것이 아니라, 한 번에 더 큰 상자를 들고 가게 하여 이동 횟수를 줄여야 한다는 것을 깨닫는 것과 같습니다.

저자는 해결책이 "디스패치 분산(dispatch amortization)"에 있다고 제안합니다. 이는 어려운 말로, "노크"의 비용을 여러 작업에 분산시켜서 지연 시간이 영향을 덜 미치도록 해야 한다는 뜻입니다. 저자는 이것이 AI를 실행하는 소프트웨어뿐만 아니라, 잠재적으로 WebGPU의 규칙 자체의 변화를 요구할 수도 있다고 지적합니다. 예를 들어, 브라우저가 매 단계를 일일이 확인하는 대신 "명령 그래프(command graph, 미리 계획된 경로)"를 받아들일 수 있도록 하는 방식입니다.

이러한 결과는 특정 하드웨어(NVIDIA RTX 5090 등)와 특정 AI 실행 방식에 기반하고 있지만, 메시지는 명확합니다. 현재 브라우저에서 AI를 더 빠르게 만드는 비결은 더 빠른 엔진이 아니라, 더 적은 횟수의 멈춤입니다.