Executive Summary
2026년 6월, 허깅페이스 공동창업자 토마스 울프가 짧은 트윗을 올렸다. 100개가 넘는 AI 에이전트가 일주일 동안 공개 협업으로 Gemma 4의 vLLM 추론 속도를 5배 끌어올렸다는 내용이다. 화제가 된 지점은 "AI가 협업했다"였지만, 정작 눈여겨볼 대목은 따로 있다. 에이전트들이 신약을 찾거나 데이터를 분석한 것이 아니라, AI를 돌리는 인프라 자체, 즉 추론 엔진의 커널을 고쳤다는 사실이다. 외부 과제를 푸는 도구였던 AI가 자기를 돌리는 시스템을 직접 손보는 자리로 올라섰다.
5배라는 숫자는 마법이 아니라 진단 가능한 엔지니어링의 결과다. Gemma 4는 표준 어텐션 커널이 비활성화되는 구조라 vLLM이 느린 우회 경로로 떨어졌고, 그 탓에 일부 GPU에서 같은 체급 모델 대비 14배 가까이 느린 9 tok/s까지 내려갔다는 보고가 있었다. 비정상적으로 낮아진 출발선을 정상으로 되돌리는 것만으로도 5배는 기술적으로 설명된다. 다만 트윗은 "but"에서 잘렸고, 그 뒤에는 거의 확실히 조건과 한계가 있다.
우리가 보는 핵심은 그 "but" 뒤다. 에이전트 100개가 동시에 패치를 쏟아낼 때, 무엇을 채택하고 무엇을 버릴지 가려내는 검증과 큐레이션이 5배를 떠받친 보이지 않는 인프라였다. AI가 AI를 고치는 시대의 진짜 병목은 연산이 아니라 데이터 품질이다. 이 글은 그 5배를 해체하고, 잘린 트윗 너머의 진짜 병목을 따라간다.
편집자의 노트. AI와 데이터의 경계에서 무엇이 성능을 만드는가, 페블러스는 늘 그 질문에 관심이 간다. 이 글은 "AI가 사람을 대체했다"는 식의 과장을 따르지 않는다. 울프의 실험은 사람과 에이전트가 함께 참여한 오픈 협업이며, 5배의 측정 조건은 트윗이 잘려 공개되지 않았다. 그래서 모든 수치는 1차 출처(vLLM 이슈 트래커, 공식 블로그, 논문)에서 다시 확인했고, 단정 대신 "기술적으로 설명 가능하다"는 표현을 썼다.
주요 수치
네 숫자가 이 글의 뼈대다. 끌어올린 폭과 그 뒤에 숨은 비용을 함께 보여준다.
5×
최종 추론 속도 향상
일주일 공개 협업의 결과(측정 조건 미공개)
9 → 60~100
tok/s 회복폭
우회 커널 정상화로 되돌릴 수 있는 구간
100+ / 1주
참여 에이전트 / 협업 기간
공개 메시지보드 기반 집단 협업
+58~285%
멀티에이전트 토큰 오버헤드
협업 구조에 따라 늘어나는 숨은 비용
무슨 일이 있었나 — 100개 에이전트의 일주일
시작은 한 줄짜리 트윗이었다. 허깅페이스 공동창업자이자 최고과학책임자인 토마스 울프가 "지금 가장 흥미로운 에이전트 행동 중 하나는 멀티에이전트 협업"이라며, 100개가 넘는 에이전트가 일주일간 공개 협업으로 vLLM에서 Gemma 4의 추론 속도를 5배 개선했다고 적었다. 그리고 문장은 "but"에서 끊겼다. 무엇이 한계였는지, 어떤 조건에서 5배였는지는 그 뒤에 있었을 텐데, 공개된 트윗은 거기까지였다.
이 실험의 무대는 구글과 허깅페이스가 함께 연 Fast Gemma Challenge였다. 참가자들이 공유 메시지보드에서 서로의 최적화 시도를 보고, 베끼고, 덧붙이며 경쟁 겸 협업을 벌이는 형식이다. 사람만의 대회가 아니라 코딩 에이전트가 대거 참여했고, 그 과정과 결과가 공개 대시보드에 그대로 쌓였다. "오픈 협업"이라는 말은 사람과 에이전트가 한 보드 위에서 함께 움직였다는 뜻이다. AI가 인간을 밀어낸 사건이 아니다.
그래서 표면의 화제성("AI 100개가 협업했다")보다 한 겹 아래를 봐야 한다. 기존의 유명한 멀티에이전트 사례는 거의 전부 에이전트가 외부 과제를 수행하는 구조였다. 신약 후보를 탐색하거나, 고객 문의를 처리하거나, 산업 데이터를 운영하는 식이다. 이번 실험은 방향이 반대다. 에이전트가 자기들이 돌아가는 토대, 곧 추론 엔진의 커널을 고쳤다. AI 시스템이 스스로를 반복 개선하는 메타 레벨로 한 발 들어선 장면이다.
한 줄로 줄이면 이렇다. 오픈 커뮤니티형 집단 에이전트가 처음으로, 대규모로, 그리고 기계가 즉시 채점할 수 있는 방식으로 AI 인프라 자체를 직접 개선했다. "더 빠른가?"라는 질문은 사람의 해석을 기다리지 않는다. 그래서 이 작업은 에이전트 협업에 유난히 잘 맞는 종류였다.
출처 주석: 트윗 원문은 "5x ... but"에서 잘려 있어, 본문은 5배의 측정 조건을 단정하지 않는다. Fast Gemma Challenge의 사람+에이전트 협업 구조, 공유 메시지보드, A10G 환경의 100+ TPS 기록 등은 허깅페이스 대시보드와 구글·허깅페이스 공식 자료로 교차 확인했다.
5배는 어떻게 가능했나 — 병목 해부
5배라는 숫자를 보면 새 알고리즘을 떠올리기 쉽다. 그러나 이 경우엔 정반대였다. 출발선이 비정상적으로 낮았기 때문에, 그 출발선을 정상으로 되돌린 것만으로 큰 배수가 나왔다. 핵심은 Gemma 4라는 모델의 고유한 구조에 있다.
2.1왜 하필 느렸나
Gemma 4는 로컬 어텐션과 글로벌 어텐션을 5대 1로 섞은 하이브리드 구조에, 어텐션 헤드의 차원(head_dim)이 256과 512로 표준에서 벗어나 있다. 문제는 vLLM이 기본으로 쓰는 빠른 FlashAttention 커널이 이 비표준 차원을 지원하지 않는다는 점이다. 지원되지 않으면 엔진은 느린 우회 경로(Triton fallback)로 떨어진다. 그 결과 RTX 4090에서 약 9 tok/s가 보고됐는데, 같은 체급의 Llama 3.2 3B가 100 tok/s를 넘긴 것과 비교하면 14배 가까이 느린 셈이다(vLLM Issue #38887).
다시 말해 에이전트들이 발견한 것은 새로운 수학이 아니라 "모델과 커널 사이의 어긋남을 메우는 작업"이었다. 이 병목 하나만 풀어도 9 tok/s가 60~100 tok/s대로 회복되니, 5배는 단일 레버만으로도 충분히 설명된다. 물론 실제 대회에서는 여러 최적화가 함께 쌓였다. 아래는 추론 속도를 끌어올리는 대표 레버들을 누적해서 본 것이다.
기준선 — Triton 우회 경로에 갇힌 상태. 9 tok/s.
커널 정상화 — 비표준 head_dim을 지원하는 어텐션 경로 복구. 가장 큰 단일 레버.
PagedAttention · 연속 배치 — 메모리 단편화를 줄이고 요청을 끊김 없이 묶어 처리량을 키운다.
FP8 · NVFP4 양자화 — 정밀도를 낮춰 연산·대역폭을 절약(품질 검증이 전제).
MTP(다중 토큰 예측) — 초안 토큰을 미리 생성해 가속. 실측 1.7~2.66배(구글은 공식 최대 3배 주장), 수락률 약 96.5%.
torch.compile — 그래프 컴파일로 커널 호출 오버헤드를 줄여 마무리.
한 가지 단서를 분명히 해 둔다. 위 배수들은 각각 다른 조건에서 측정된 값이라 단순 곱셈으로 합치면 안 된다. 레버는 서로 겹치고 상한도 있다. 그러나 방향은 또렷하다. 커널 정상화가 가장 크게 작동했고, 나머지는 그 위에 얹혔다. 5배는 여러 개의 작은 마법이 아니라, 진단 가능한 어긋남 하나를 제대로 메운 결과에 가깝다.
"AI가 AI를 고친다"는 이미 와 있다
울프의 실험을 일회성 화제로 보면 본질을 놓친다. 에이전트가 GPU 커널을 자율적으로 최적화하는 흐름은 이미 여러 연구·제품에서 누적돼 왔다. 울프 실험은 그 패러다임의 가장 큰 규모 버전, 즉 100개가 넘는 에이전트가 일주일간 공개로 달려든 사례일 뿐이다. 아래 표는 최근 1~2년의 대표 선례를 모은 것이다.
| 사례 | 성과 | 특징 |
|---|---|---|
| KernelSkill | KernelBench L1 5.44× | 멀티에이전트 GPU 커널 최적화 |
| MiniMax M3 | 자율 FP8 GEMM 9.4× | 24시간·147회 제출·인간 개입 0 |
| Cursor × NVIDIA | B200 235커널 geomean 1.38× | 실제 프로덕션 커널 대상 |
| ISO-Bench | 실제 vLLM 과제 46.2% 자율 개선 | 코딩 에이전트 벤치마크 |
숫자들 사이에서 한 가지 공통된 교훈이 떠오른다. 결과를 가른 변수는 모델의 크기가 아니라 검증 루프와 끈기였다. ISO-Bench의 주된 실패 유형은 "의도는 좋았으나 실행이 틀린(Good Intent, Bad Execution)" 경우였다. MiniMax M3는 30회 안에 정체되는 다른 모델들과 달리 147번째 제출에서 최고 성능을 냈다. 시도하고, 채점하고, 다시 고치는 과정을 끈질기게 반복한 쪽이 이겼다는 뜻이다.
그래서 진짜 자산은 모델 한 덩어리가 아니라, 시도-검증-재시도의 이력 데이터다. 어떤 변경이 속도를 올렸고 어떤 변경이 조용히 품질을 떨어뜨렸는지, 그 궤적 전체가 다음 최적화를 가르치는 신호가 된다.
"but" 뒤에 숨은 것 — 진짜 병목
잘린 트윗의 "but" 뒤에는 거의 확실히 한계와 조건이 있었다. 그 한계는 두 층으로 나뉜다. 하나는 결과 자체의 재현성 문제이고, 다른 하나는 멀티에이전트라는 방식 자체의 비용이다.
4.1결과는 어디까지 재현됐나
최적 성능은 최신 Blackwell GPU에서 재현됐다. 그 밖의 환경에서는 14배 저하가 그대로 남기도 했다. 게다가 정밀도를 낮추는 과정에서 조용한 품질 저하가 따라왔다. FP8 블록 양자화는 출력 분포가 비정상적으로 치우치는 logit saturation 버그(Issue #39407)를, 큰 프리필(prefill)은 엔진이 멈춰 버리는 행(hang) 현상(Issue #39914)을 동반했다. 속도를 얻는 대신 어딘가에서 정확도나 안정성을 잃을 수 있었다는 의미다.
4.2에이전트를 많이 붙이면 좋아질까
멀티에이전트 자체도 공짜가 아니다. 협업을 위해 주고받는 토큰이 늘면서 오버헤드가 독립형 구성에서 +58%, 중앙집중형에서 +285%까지 보고됐다. 구글 리서치는 잘못 구성된 멀티에이전트가 단일 에이전트보다 39~70% 낮은 성능을 낼 수 있음을 지적했고, 업계 집계로는 프로덕션 성공률이 약 23%, 권장 팀 규모는 3~5개에 그친다. "많이 붙일수록 좋아진다"는 직관은 자주 틀린다.
그런데 같은 멀티에이전트가 특정 조건에서는 분명히 빛난다. 작업이 잘게 쪼개지고, 병렬로 돌릴 수 있고, 결과를 기계가 즉시 채점할 수 있을 때다. 커널 최적화가 바로 그 스위트 스팟이다. 갈림길은 에이전트 수가 아니라 협업을 어떻게 짜느냐에 있다. 구조를 잘 설계하면 오버헤드가 절감으로 뒤집히기도 한다. MARS 같은 협업 프레임워크는 같은 정확도를 내면서 토큰과 시간을 절반으로 줄였다고 보고됐다. 분해 가능한 과제에서는 Finance-Agent가 +80.8%, 5개 에이전트 앙상블이 HumanEval에서 89%를 기록했다. 아래 대조표가 그 갈림을 보여준다.
| 구분 | 멀티에이전트가 불리할 때 | 멀티에이전트가 유리할 때 |
|---|---|---|
| 작업 성격 | 분해·검증이 모호한 일반 추론 | 분해·병렬·기계 검증 가능 |
| 대표 수치 | 오버헤드 +58~285%, 성능 39~70%↓ | Finance-Agent +80.8%, HumanEval 89% |
| 권장 팀 규모 | 20개 이상은 지속 저성능 | 3~5개, 성공률 약 23% |
그래서 5배의 진짜 병목은 연산이 아니었다. 100개 에이전트가 동시에 던진 패치 가운데 무엇을 살리고 무엇을 버릴지, 어떤 변경이 logit saturation처럼 겉보기엔 멀쩡한 채로 품질을 깎아내리는지 가려내는 일, 곧 검증과 큐레이션이 병목이었다. 다른 말로 데이터 품질이다.
5배가 바꾸는 것 — 추론 경제학과 Physical AI
추론 속도가 5배가 되면 무엇이 달라질까. 두 곳에서 임계값이 움직인다. 하나는 돈, 하나는 물리다.
5.1추론 경제학
추론 단가는 가파르게 떨어져 왔다. 같은 성능을 내는 토큰의 가격이 2022년 약 100만 토큰당 20달러에서 2026년 0.40달러 수준으로, 대략 50배 낮아졌다(Epoch AI 기준, 연 약 10배). 이제 추론은 AI 컴퓨팅 비용의 약 67%를 차지하고, 2026년 추론 시장 규모는 기관별로 59억~227억 달러까지 추정이 갈릴 만큼 빠르게 커지는 중이다. 단가가 한 번 더 5배 내려가면, 지금은 수지가 안 맞던 실시간·대량 추론 서비스가 손익분기를 넘는다.
5.2엣지와 로봇의 문턱
물리 쪽 변화는 더 직접적이다. 로봇이나 드론의 실시간 제어는 초당 100~1,000 토큰을 요구하는데, 현재 엣지 칩은 10~30 토큰에 머문다. 10배에서 100배의 격차다. 추론 5배는 이 격차를 메우는 핵심 레버 중 하나이고, 활성 파라미터가 작은 Gemma 4 MoE(활성 약 3.8B)에 다중 토큰 예측을 더한 조합이 엣지 진입의 유력 후보로 거론된다.
▲ 엣지 추론 임계값 격차. 막대는 상대 규모를 단순화한 도식이다(로그 스케일 아님).
정리하면, 추론 5배는 단순한 벤치마크 자랑이 아니다. 비용을 낮춰 더 많은 서비스를 가능하게 하고, 물리적 처리량을 끌어올려 로봇과 엣지의 진입 문턱을 낮추는 레버다. 그리고 그 레버를 안전하게 당기려면, 속도를 위해 무엇을 양보했는지를 데이터 수준에서 추적할 수 있어야 한다.
페블러스가 주목하는 이유
이 실험은 페블러스가 다루는 세 축과 정면으로 만난다. 화제는 "에이전트 100개"였지만, 우리가 보는 자리는 그 에이전트들이 만들어 낸 산출물의 품질을 누가 가려내느냐다.
6.1비즈니스·기술 연결
100개 에이전트가 쏟아낸 최적화 패치와 실험 로그, 실패한 시도는 그 자체로 "어떤 변경이 속도를 올리는가"를 가르치는 다음 세대의 학습 신호다. 무엇을 채택하고 무엇을 버릴지 판단하는 일이 곧 데이터 큐레이션이다. 추론 5배는 엣지에서 로봇·드론 실시간 제어의 임계값에 다가서게 하는 직접 레버이고(Physical AI), 에이전트가 던진 커밋 중 무엇이 조용히 품질을 떨어뜨리는지 자동으로 진단·필터링하는 일은 DataClinic의 자연스러운 확장이다.
6.2데이터 품질 관점
멀티에이전트 협업의 성패는 모델 크기가 아니라 생성물의 품질 관리에서 갈린다. ISO-Bench의 "의도는 좋으나 실행이 틀린" 실패, FP8 logit saturation 버그, 성능 역설(39~70% 하락)은 모두 겉보기엔 그럴듯하지만 실제로는 열화된 산출물의 문제다. 학습·최적화 파이프라인에 들어오는 데이터, 곧 패치·체크포인트·합성 신호의 품질이 모델 내부 표현과 최종 성능을 직접 좌우한다.
6.3고객·파트너 실무 함의
기업이 멀티에이전트를 도입할 때 ROI를 가르는 변수는 분명하다. 첫째, 작업이 분해·검증 가능한가. 둘째, 팀 규모를 3~5개 안에서 관리하는가. 셋째, 시도-검증-재시도 이력을 자산으로 보존하는가. "에이전트를 많이 붙이면 좋아진다"는 막연한 기대는 토큰 오버헤드와 성능 역설로 되돌아온다.
AI가 AI를 고치는 시대에 페블러스의 자리는 집단 에이전트 협업의 데이터 품질 레이어다. 에이전트가 만든 코드·패치·실험 데이터를 검증·큐레이션하고, 조용한 품질 저하를 진단하며, 채택 가능한 신호와 노이즈를 분리하는 역할. 연산과 모델은 빠르게 상품화되지만(단가 50배 하락), "무엇이 좋은 데이터인가"를 가려내는 판단은 상품화되지 않는다. 이 실험은 바로 그 판단이 5배라는 결과를 만든 숨은 동력이었음을 보여 준다.
참고문헌
이 글이 인용한 학술 논문, vLLM·구글의 기술 문서와 이슈, 업계·벤치마크 자료를 출처별로 묶었다. 5배의 측정 조건은 트윗이 잘려 미공개이므로, 본문의 수치는 모두 1차 출처에서 다시 확인했다.
학술 (arXiv)
- 1.(2026). KernelSkill: Multi-Agent GPU Kernel Optimization. arXiv:2603.10085. (KernelBench L1 5.44×)
- 2.(2026). ISO-Bench: Coding Agents Optimizing vLLM/SGLang. arXiv:2602.19594.
- 3.(2025). Comparative Analysis of LLM Inference Serving: vLLM and HuggingFace TGI. arXiv:2511.17593.
- 4.(2025). MARS: Efficient Multi-Agent Collaboration for LLM Reasoning. arXiv:2509.20502.
- 5.(2026). COLT: Lightweight Multi-LLM Collaboration through Shared MCTS. arXiv:2602.01935.
기술 문서 · 이슈 · 공식 블로그
- 6.vLLM GitHub Issue #38887 — Gemma 4 E4B ~9 tok/s, Triton fallback.
- 7.vLLM GitHub Issue #39407 — Gemma 4 31B FP8_BLOCK logit saturation bug.
- 8.vLLM GitHub Issue #39914 — Gemma 4 engine hang during large prefill.
- 9.vLLM GitHub Issue #39749 — Q2 2026 Roadmap.
- 10.Google (2026). Accelerating Gemma 4: faster inference with MTP drafters (블로그).
- 11.Red Hat Developer (2026-04). Speculative decoding in vLLM.
- 12.Hugging Face. Fast Gemma Challenge dashboard.
- 13.vLLM Blog. 2024 Retrospective and 2025 Vision · Performance update / v0.6.0 (vllm.ai, 2024-09-05).
업계 · 벤치마크 · 데이터
- 14.Latent Space AINews (2026-06-25~27). Thomas Wolf, 100+ agents top tweet (1차 출처).
- 15.Epoch AI. LLM inference price decline (10–50×/year since 2022).
- 16.Allen Kuo, Medium (2026). Gemma 4 on vLLM vs Ollama: 96 GB Blackwell benchmarks.
- 17.Spheron Blog (2026). vLLM vs TensorRT-LLM vs SGLang H100 benchmarks / GPU cost per token.
- 18.Cursor × NVIDIA (2026). Blackwell B200 multi-agent kernel optimization · MiniMax M3 (2026-06). Autonomous FP8 GEMM kernel optimization on Hopper.