파이프라인 병렬화는 모델의 층이 비슷할수록 다루기 쉽다. 층을 고르게 나눠 stage에 배치하고, 여러 microbatch를 흘려보내면서 한 stage의 통신을 다른 계산과 겹치면 된다. Qwen3-Next는 이 전제를 깨뜨린다. 선형 attention 층 세 개 뒤에 full attention 층 하나가 오고, 모든 층 뒤에는 sparse mixture-of-experts(MoE)가 붙는다. 층 조합마다 연산과 통신의 비율이 달라서 단독 실행 시간의 합이 같은 stage도 중첩 후에는 속도가 달라진다.

Alibaba Cloud가 OSDI 2026에 공개한 Tessera는 Qwen3와 Qwen3-Next 사전학습에 사용한 파이프라인 프레임워크다[1]. 소규모 시제품의 최고값이 아니다. Hopper GPU 4,096장부터 12,288장까지 다섯 프로덕션 작업에서 기존 내부 시스템보다 처리량이 20~33% 늘었다. 1조 매개변수 Qwen3 작업에서는 model FLOP utilization(MFU)이 39%에 도달했다. 수치도 크지만, 이 논문의 핵심은 파이프라인의 일정과 구간 나누기를 따로 최적화할 수 없다는 설명에 있다.

층 수는 같은데 stage가 달라지는 이유

sparse MoE 학습은 token을 expert로 보내고 되받는 All-to-All 통신을 수행한다. 다른 microbatch의 행렬곱을 옆에 배치하면 전송 시간 일부를 가릴 수 있다. 문제는 어떤 연산끼리 같은 실행 구간에서 만나는지에 따라 감춰지는 비율이 달라진다는 점이다. Tessera의 실측에서는 층 조합에 따른 중첩 이득이 3배까지 벌어졌다. 층 개수를 세거나 각 연산의 단독 시간을 더하는 방식은 stage의 실제 비용을 잘못 계산한다.

의존 관계는 양방향이다. 층을 어떻게 나누느냐에 따라 가능한 중첩 조합이 정해지고, 좋은 구간 나누기를 고르려면 그 조합을 실제로 실행한 시간이 필요하다. 기존에는 새 모델 구조가 나올 때마다 전문가가 이 관계를 몇 주 동안 손으로 맞췄다고 저자들은 설명한다. GPU가 1만 장을 넘으면 실행 중의 변화도 커진다. 매 iteration에서 expert로 가는 token 수가 달라지면서 정적 계획이 정확히 예측할 수 없는 짧은 유휴 구간이 생긴다.

서로 다른 MoE 층에서 층 개수만 세어서는 안 되는 이유. a, Qwen3-Next는 선형 attention과 full attention을 섞고 각 층 뒤에 sparse MoE 통신을 수행한다. b, 단독 실행 비용이 같은 stage도 통신 중첩 뒤에는 노출되는 시간이 달라져 병목이 된다. c, Tessera는 각 조합을 먼저 실측해 구간을 나누고, routing 변동에는 실행 중 대응한다. 이 글을 위해 새로 만든 도판.

일정을 실측하고, 나눈 뒤, 남은 빈틈을 채운다

Tessera는 층을 expert dispatch, 행렬곱, 결과 combine 같은 작은 task로 분해한다. 중첩 scheduler는 두 chunk 사이에서 의존성을 지키는 실행 순서를 찾고, 목표 GPU에서 전체 소요 시간을 측정한다. 단순한 분석 모델에만 의존하지 않는 이유가 있다. GPU 자원 경합과 kernel 동작 때문에 개별 task 시간을 합한 값보다 중첩한 상태의 실측값이 더 정확했기 때문이다.

partitioner는 이 중첩 후 비용을 사용해 stage를 맞춘다. 가능한 조합의 일정을 먼저 만들고 측정한 다음, 실제 병렬 실행 시간을 기준으로 층 경계를 고른다. Dynamic Bubble Optimizer는 학습 중 routing metadata를 보고 곧 생길 빈 구간을 예측해 미룰 수 있는 task를 옮겨 넣는다. 각 expert-parallel group 안에서 독립적으로 동작하므로 GPU 수가 늘어도 하나의 중앙 제어기가 병목이 되지 않는다.

세 기능은 맡은 범위가 다르다. scheduler는 무엇을 겹칠지 정하고, partitioner는 모델 chunk를 어디에 놓을지 정한다. 동적 최적화기는 확률적인 routing 변화가 남긴 여유를 회수한다. 이를 모두 뭉뚱그려 파이프라인 최적화라고 부르면 어느 조건에서 어떤 이득이 사라지는지 알기 어렵다.

최고값 하나보다 중요한 다섯 작업

프로덕션 평가는 중형부터 1조 매개변수까지 Qwen3와 Qwen3-Next를 포함한다. GPU 8,192장의 Qwen3-L은 MFU가 29.7%에서 36.3%로 올라 처리량이 22.0% 늘었다. 같은 규모의 Qwen3-XL은 32.0%에서 39.0%로, GPU 4,096장의 Qwen3-Next-M은 16.7%에서 20.0%로 개선됐다. 가장 큰 GPU 12,288장 Qwen3-Next-XL은 15.9%에서 21.1%로 올라 처리량 이득이 32.8%였다. 별도의 GPU 256장 통제 실험에서는 공개 recipe를 사용한 Megatron-Core MoE보다 MFU가 최대 1.24배 높았다[3]. 서로 다른 평가 조건의 수치를 하나로 섞어 읽으면 안 된다.

한 프로덕션 기록에서는 기능별 기여도도 보인다. Tessera의 정적 계획을 적용하자 처리량이 약 13% 늘었고, 이 중 약 9%가 stage 균형 개선에서 나왔다. 이후 동적 빈 구간 채우기를 켜자 Qwen3-XL의 MFU가 39.0%에 도달했다. 또 다른 GPU 6,144장 작업에서는 동적 기능만으로 파이프라인 유휴 시간이 641 ms 줄고 처리량이 3.4% 증가했다.

Tessera가 프로덕션에서 측정한 결과. a, 다섯 작업의 기존 MFU와 Tessera MFU를 함께 표시했다. b, 처리량 이득은 20.0~32.8%이며 Megatron-Core 대비 1.24배는 별도의 GPU 256장 통제 실험이다. c, GPU 8,192장 대형 작업은 expert 통신의 73%를 감췄지만 연산량이 작은 작업은 26%만 감췄다. 이 글을 위해 새로 만든 도판.

겹쳐 놓을 연산이 부족하면 통신은 남는다

중첩은 통신 옆에 충분한 유효 연산이 있어야 작동한다. GPU 8,192장의 1조 매개변수 Qwen3-Next 작업에서는 expert-parallel 통신의 73%를 감춰 전체 iteration 시간 중 노출된 비중을 8.3%로 줄였다. 반면 GPU 5,120장의 중형 작업은 expert 하나가 수행하는 행렬곱이 짧아서 26%만 감췄고, 노출된 expert 통신이 iteration의 38.9%를 차지했다. 소프트웨어가 틀린 것이 아니라 전송 시간을 덮을 만큼 긴 계산 구간이 없었다.

유리한 작업에도 개선 여지는 남는다. 노출된 expert 통신과 파이프라인 유휴 시간을 더하면 iteration의 17%다. 시작과 끝의 warmup·cooldown 구간에는 동시에 실행할 microbatch가 적어 구조적인 빈틈이 생긴다. Tessera는 통신을 없애는 시스템이 아니라, 달라진 모델 구조를 따라갈 수 있는 계획기를 보여 준다.

여기서 얻을 수 있는 더 큰 결론은 모델 구조가 클러스터 scheduling의 일부가 됐다는 점이다. 선형 attention, full attention, sparse expert는 알고리즘 선택이지만 GPU 1만 장에서는 어느 통신을 숨길지, 어느 stage가 병목이 될지, 설치한 연산 자원을 얼마나 쓸지가 이 선택에 의해 정해진다. 동일한 Transformer 블록만 가정한 학습 프레임워크는 이미 지나가고 있는 모델 세대를 최적화한다.

GPU 수 다음에 적어야 할 숫자

대규모 학습을 소개할 때는 모델 크기와 GPU 수를 먼저 적는다. Tessera는 이 두 값만으로는 설치한 연산 자원이 왜 유효 토큰으로 바뀌지 못했는지 설명할 수 없음을 보여 준다. 같은 GPU와 같은 병렬화 규모를 사용해도 모델 구조가 통신을 덮을 연산 구간을 얼마나 제공하느냐에 따라 처리량이 크게 달라진다. 앞으로의 용량 보고에는 최소한 연산 중첩 뒤의 스테이지 불균형, 집합 통신별로 드러난 통신 비율, 동적 보정 뒤에도 남은 파이프라인 유휴 시간을 함께 기록할 필요가 있다. MFU가 전체 손실의 크기를 말한다면 이 세 값은 다음 최적화 비용을 어디에 써야 하는지 알려 준다.

Qwen3-Next-XL의 32.8% 개선을 큰 작업일수록 Tessera가 더 유리하다는 법칙으로 읽어서도 안 된다. 가장 큰 작업은 기존 MFU가 가장 낮았고, 어텐션과 MoE가 섞이는 방식도 특정하다. 다른 모델에 결과를 옮기려면 층 조합을 실측한 뒤 스테이지 비용과 통신을 덮을 연산 구간이 논문의 사례와 비슷한지 확인해야 한다. GPU 수는 평가 규모이지 개선 원인을 설명하는 변수가 아니다.

하드웨어와 소프트웨어의 경계도 여기서 드러난다. 노출된 전문가 통신이 38.9%인 GPU 5,120장 사례에는 더 빠른 패브릭이 도움이 되지만, 대역폭만으로 잘못 나눈 스테이지를 고칠 수는 없다. 반대로 계획기가 좋아도 전문가 행렬곱이 짧으면 긴 전송을 덮지 못한다. 모델 설계자는 전문가 크기, 라우팅 균형, 어텐션 순서가 품질뿐 아니라 집합 통신 비용도 바꾼다는 정보를 받아야 한다. Tessera의 오래 남을 가치는 이 비용을 수 주짜리 학습을 시작하기 전에 측정 가능한 값으로 만든 데 있다.

기능별 결과를 보면 최적화 순서도 정할 수 있다. 먼저 모든 마이크로배치에 반복해서 부담을 주는 지속적인 스테이지 불균형을 없애야 한다. 그다음 순간적인 라우팅 변화가 만든 빈 구간을 회수하고, 두 작업 뒤에도 남은 노출 시간을 패브릭 문제로 분류한다. 이 순서를 지키면 스케줄링 문제를 네트워크 증설의 성과로 잘못 설명하거나, 옆에 덮을 연산이 없는 통신까지 스케줄러의 실패로 판단하는 일을 줄일 수 있다. 모델이나 커널이 바뀔 때는 중첩 후 비용표, 선택한 분할, 남은 통신 장부를 함께 다시 만드는 회귀 시험이 필요하다.

논문이 충분히 비용에 넣지 않은 문제는 프로파일의 유효 기간이다. 커널 버전, 배치 모양, 라우팅 분포, GPU 펌웨어가 바뀌면 모델 그래프가 같아도 중첩 결과는 달라질 수 있다. 프로파일을 너무 늦게 갱신하면 나쁜 계획을 유지하고, 너무 자주 하면 귀한 클러스터 시간을 쓴다. 실제 시스템은 프로파일이 예측한 스테이지 시간과 관측값의 오차를 기록하고, 오차가 지속될 때만 재계획을 실행하며, 프로파일링 비용도 처리량 이득에서 빼야 한다. 이 수명주기 관리가 없으면 중첩을 고려한 계획도 배포 첫날에만 정확한 정적 설정이 될 수 있다.

출처와 저작권 안내

이 글은 Silicon & Systems가 작성한 편집 요약이다. 인용 논문의 주장과 결과를 우리 표현으로 다시 썼다. 원문의 문장, 표, 도판은 옮기지 않았으며 두 도판은 보고된 수치를 바탕으로 새로 만들었다. OSDI 2026 논문의 저작권은 원저자에게 있으며, USENIX가 발표 페이지에서 원문을 공개한다. 저작권 (c) 2026 원저자.