LLaDA2.2: 레벤슈타인(Levenshtein) 편집 기법을 도입하여 에이전트 작업을 지원하는 확산 언어 모델(Diffusion LM)

9bow · 7월 30, 2026, 9:30오후

LLaDA2.2 소개

지우개도 없고 끼워 넣기도 없는 편집기

글을 고쳐 쓸 때 우리는 단어를 다른 단어로 바꾸기도 하고, 군더더기를 통째로 지우기도 하고, 빠뜨린 괄호를 중간에 끼워 넣기도 합니다. 그런데 만약 편집기가 "같은 칸에 다른 글자를 덮어쓰기"만 허용하고 지우기와 끼워 넣기를 막아 둔다면, 고칠 수 있는 오류의 종류는 크게 줄어들 것입니다.

이 논문은 확산 언어 모델(diffusion language model, dLLM)이 겪는 바로 그 제약을 푸는 연구입니다. Ant Group의 Inclusion AI 팀이 공개한 LLaDA2.2 는 확산 모델의 병렬 디코딩 과정에 삭제(DELETE)와 삽입(INSERT) 연산을 추가하여, 고정 길이 치환만 가능하던 기존 편집 메커니즘을 레벤슈타인 편집(Levenshtein Editing) 으로 확장합니다. 목표는 명확합니다. 확산 언어 모델을 여러 턴에 걸친 긴 호흡의 에이전트(agent) 작업에 실제로 쓸 수 있게 만드는 것입니다.

확산 언어 모델은 왜 빠른가, 그리고 왜 에이전트에서 무너지는가

오늘날 대부분의 대규모 언어 모델은 자기회귀(Autoregressive, AR) 방식으로 동작합니다. 토큰을 하나 만들고, 그것을 다시 입력에 붙여 다음 토큰을 만들고, 이 과정을 반복합니다. 품질은 좋지만 생성 길이에 비례해 순차적인 지연(latency)이 쌓인다는 구조적 한계가 있습니다.

확산 언어 모델은 이 지연 병목을 정면으로 공격합니다. 텍스트 전체(또는 일정 크기의 블록)를 마스킹된 상태에서 시작해, 여러 위치의 토큰을 동시에 복원(denoising)해 나가는 방식입니다. 한 스텝에서 여러 토큰이 확정되므로 이론적으로 훨씬 빠릅니다. 실제로 이 시리즈의 이전 모델인 LLaDA2.0은 확산 언어 모델을 처음으로 100\text{B} 파라미터 규모까지 끌어올렸고, LLaDA2.0-flash-CAP은 초당 535 토큰의 디코딩 속도를 기록했습니다.

문제는 이 병렬성이 곧 약점이 된다는 점입니다. 같은 블록 안의 토큰들은 서로를 순차적으로 참조하지 못한 채 동시에 결정됩니다. 마치 여러 사람이 서로 상의하지 않고 같은 문장의 빈칸을 동시에 채우는 것과 같아서, n-gram이 반복되거나 JSON 괄호가 어긋나거나 도구 호출(tool call)의 경계가 뒤섞이는 일이 생깁니다.

이 결함을 완화하기 위해 직전 버전인 LLaDA2.1은 토큰 대 토큰(Token-to-Token, T2T) 편집 을 도입했습니다. 복원이 진행되는 중에도 이미 확정한 각 위치의 토큰을 다시 들여다보고 필요하면 다른 토큰으로 바꾸는, 편집 가능한 복원 과정입니다. 하지만 T2T 편집은 keep(유지)과 substitute(치환) 두 가지 연산만 지원합니다. 즉 출력 길이가 고정 됩니다. 중복된 구절을 지울 수도 없고, 빠뜨린 인자를 중간에 끼워 넣을 수도 없습니다. 앞서 말한 "덮어쓰기만 되는 편집기"가 바로 이것입니다.

논문이 짚은 두 가지 도전 과제

연구팀은 복잡한 도구 사용 환경에서 확산 언어 모델이 실패하는 원인을 두 가지로 정리합니다.

Challenge I: 구조적 경직성과 추론 경로 붕괴. 같은 블록 안의 토큰들이 명시적인 순차 조건화 없이 디코딩되면서 n-gram 반복, 형식이 깨진 JSON, 모호한 도구 호출 경계가 자주 발생합니다. 그리고 이 오류들은 고치기가 어렵습니다. LLaDA2.1의 일대일 치환이 출력 길이를 고정해 토큰을 넣거나 빼는 것 자체를 막아 두기 때문입니다. 여기에 더해 임의 순서 복원(arbitrary-order denoising)은 추론 다양성 자체를 깎아냅니다. 확신이 높은 쉬운 위치부터 먼저 확정하고 불확실한 분기 토큰을 뒤로 미루다 보면, 그 사이에 채워진 주변 문맥이 결정적인 선택을 미리 확정해 버려 다른 추론 경로가 잘려 나갑니다. 논문은 이 현상을 해 공간 붕괴(solution-space collapse)라 부르며, 임의 순서가 추론 잠재력을 어떻게 제한하는지 분석한 연구를 근거로 인용합니다.

Challenge II: 오류 누적이 장기 궤적을 무너뜨린다. 에이전트는 한 번 답하고 끝나지 않습니다. 여러 턴에 걸쳐 도구를 호출하고 환경 피드백을 받아 자기 행동을 교정하는 폐루프(closed loop)를 돕니다. 이 구조에서 초기 스텝의 잘못된 출력은 단순히 "품질이 조금 나쁜 문장"으로 끝나지 않고, 다음 블록의 복원 과정에 하드 제약(hard constraint)으로 편입 됩니다. 즉 오류가 작업 상태 자체를 오염시키고, 목표 표류(goal drift)와 연쇄 실패로 번집니다. 자기회귀 모델은 이전 문맥을 암묵적으로 조건화하며 이상 징후를 만나면 스스로 방향을 틀 수 있지만, 블록 확산 모델은 구조적으로 이런 자가 교정에 취약합니다. 최근의 실증 분석 역시 현재의 확산 언어 모델이 장기 인과 계획이 필요한 에이전트 작업에서 신뢰하기 어렵다는 점을 확인했습니다.

LLaDA2.2가 제안하는 세 개의 축

LLaDA2.2는 이 두 과제를 세 갈래로 나누어 공격합니다.

MoE 확산 모델을 위한 효율적인 인프라: 컨텍스트 윈도우를 128\text{K} 토큰으로 확장하고, MoE(Mixture-of-Experts) 블록 확산의 추론 비용을 억제하는 블록 라우팅(Block Routing)을 도입합니다.
레벤슈타인 편집 패러다임: DELETE 와 INSERT 편집 제어 토큰을 추가하여 병렬 디코딩 중에 시퀀스의 길이와 위치를 바꿀 수 있게 합니다.
환경 인지 에이전트 강화학습 시스템: 편집 결정을 환경 보상으로 최적화하는 L-EBPO를 제안합니다.

이번에 공개된 모델은 비임베딩 파라미터 100\text{B} 규모의 MoE 확산 모델인 LLaDA2.2-flash 한 종입니다. 미리 결론을 말하면, LLaDA2.2-flash는 7 개 에이전트 벤치마크 평균 53.83 점으로 자기회귀 베이스라인인 Ling-2.6-flash의 55.74 점에 1.91 점 차로 근접했고, τ²-Bench와 PinchBench, MCP-Atlas에서는 오히려 앞섰습니다. 그러면서 11 개 워크로드 평균 디코딩 처리량은 1.64\times 빨랐습니다.

128K 컨텍스트와 블록 라우팅: 확산 MoE를 위한 인프라

에이전트 작업은 본질적으로 컨텍스트를 먹는 작업입니다. 저장소 전체를 읽고, 수십 번의 도구 호출 기록을 누적하고, 그 위에서 다음 행동을 결정해야 합니다. 아무리 좋은 편집 메커니즘이 있어도 컨텍스트가 8\text{K} 에서 끊긴다면 쓸모가 없습니다. 그래서 LLaDA2.2는 편집 이야기를 꺼내기 전에 인프라부터 손봅니다.

점진적 롱 컨텍스트 확장

LLaDA2.2는 LLaDA2.1 베이스 모델에서 출발해 별도의 지속 사전학습(Continued Pre-Training, CPT) 단계를 거칩니다. 이 단계의 목표는 두 가지입니다. 하나는 컨텍스트 확장, 다른 하나는 라우팅 전환입니다.

컨텍스트 확장은 한 번에 이루어지지 않습니다. 8\text{K} 짜리 LLaDA2.1 베이스 모델을 먼저 64\text{K} 길이에서 300\text{B} 토큰만큼 학습시키고, 그다음 128\text{K} 길이에서 다시 200\text{B} 토큰을 학습시킵니다. 짧은 문맥에서 아주 긴 문맥으로 급격히 넘어가면 모델이 위치 표현과 어텐션(attention) 패턴, 블록 확산 복원 거동을 한꺼번에 재조정해야 하는데, 단계를 나누면 이 적응이 완만해집니다.

데이터 구성에도 의도가 담겨 있습니다. 롱 컨텍스트 데이터는 장문 문서와 저장소 단위 코드가 주를 이루며, 특히 유효 길이가 64\text{K} 에서 128\text{K} 사이에 들어오는 예제를 중심으로 모았습니다. 또한 문서 인지 패킹(document-aware packing)과 어텐션 경계를 유지해서, 서로 무관한 문서들이 확산 학습 과정에서 엉뚱한 양방향 의존성을 만들지 않도록 막았습니다. 확산 모델은 자기회귀 모델과 달리 블록 내부에서 양방향 어텐션을 쓰기 때문에 이 처리가 특히 중요합니다.

에이전트 데이터, 즉 긴 소프트웨어 엔지니어링 문맥과 도구 사용 기록, 브라우징 궤적은 마지막 128\text{K} 단계에서만 투입됩니다. 모델이 안정적인 롱 컨텍스트 거동을 이미 확보한 뒤에 에이전트 감독을 얹는 순서입니다. 그 결과 최종 모델은 추론 시점의 외삽(extrapolation)에 기대지 않고 네이티브 128\text{K} 컨텍스트를 지원합니다.

MoE 블록 확산을 위한 블록 라우팅

두 번째 변경이 이 논문에서 시스템 관점으로 가장 흥미로운 부분입니다.

일반적인 MoE 트랜스포머에서는 각 토큰이 독립적으로 상위 k 개 전문가(expert)를 고릅니다. 자기회귀 디코딩에서는 이게 자연스럽습니다. 한 스텝에서 처리하는 새 토큰이 몇 개 되지 않으니까요. 그런데 블록 확산 디코딩에서는 한 스텝이 블록 하나, 보통 32 개 또는 64 개 토큰을 통째로 처리합니다. 모든 토큰이 자유롭게 라우팅하면 한 블록이 건드리는 전문가 집합은 모든 토큰 선택의 합집합 이 됩니다. 블록 크기 B 와 전체 전문가 수 E 에 대해, 활성 전문가 규모가 자기회귀의 k 개에서 최대 \min(Bk, E) 개까지 부풀어 오릅니다.

이건 단순한 계산량 문제가 아니라 시스템 병목입니다. 전문가 집합이 크고 입력에 따라 매번 달라지면 HBM 트래픽이 늘고, 전문가 가중치 재사용률이 떨어지며, 전문가 병렬(expert parallelism) 환경에서 디스패치와 컴바인 통신 비용이 커집니다. 롱 컨텍스트 추론이나 제한된 디바이스 배포처럼 전문가 워킹셋의 예측 가능성이 처리량과 지연, 첫 토큰까지의 시간(TTFT)에 직결되는 상황일수록 이 문제가 두드러집니다.

연구팀의 해법은 관찰에서 출발합니다. LLaDA2 시리즈 MoE 확산 모델을 들여다보니, 토큰 단위 라우팅은 겉보기에 분산되어 있지만 한 블록 안에서 전문가 선호는 매우 집중 되어 있었습니다. 소수의 전문가가 라우팅 트래픽 대부분을 차지한 것입니다. 그렇다면 고정 용량의 블록 단위 전문가 풀이 블록 확산 추론에 자연스럽게 들어맞습니다.

블록 라우팅 은 라우팅 단위를 확산 생성 단위와 일치시킵니다. 각 토큰이 전문가 집합을 마음대로 넓히도록 두는 대신, 먼저 블록 수준에서 전문가 승인(admission)을 수행하고, 그다음 승인된 풀 안에서만 토큰별 라우팅을 적용합니다. 블록 크기 B 의 블록에서 토큰 i 의 라우팅 점수 벡터를 s_i 라 할 때, 블록 수준 승인 점수는 토큰 레이싱(token racing) 전략으로 계산합니다.

g_j = \max_{i \in \{1, \ldots, B\}} s_{i,j}, \quad j = 1, \ldots, E

각 토큰이 자신이 강하게 선호하는 전문가를 후보로 지명할 기회를 한 번씩 갖는 규칙입니다. 그 뒤 블록은 g 기준 상위 C 개 전문가를 승인해 고정 용량 풀 \mathcal{P} 를 만들고, 토큰별 상위 k 선택은 오직 \mathcal{P} 안에서만 수행하며 풀 밖의 점수는 마스킹합니다. 기본 설정은 E = 256 개 라우팅 전문가에 대해 C = 48 입니다.

이 설계의 이점은 예측 가능성입니다. 모든 블록이 O(C) 라는 전문가 워킹셋 상한을 갖게 되어 메모리 계획과 전문가 병렬 실행이 훨씬 수월해집니다. 동시에 승인된 풀 안에서는 여전히 토큰별 상위 k 선택이 일어나므로, 라우팅이 "블록당 하나의 결정"으로 뭉개지지 않고 토큰 수준 전문화가 보존됩니다. 논문은 지속 사전학습 이후 블록 라우팅으로 전환해도 모델 품질 저하가 거의 없었다고 보고합니다.

레벤슈타인 편집: 확산 디코딩에 지우개와 끼워 넣기를 더하다

인프라가 준비되었으니 이제 이 논문의 이름값을 하는 부분입니다.

네 가지 편집 연산

레벤슈타인 거리(Levenshtein distance)는 두 문자열을 같게 만드는 데 필요한 최소 편집 횟수를 재는 고전적인 지표로, 치환과 삭제, 삽입을 모두 편집 연산으로 인정합니다. LLaDA2.2는 이 발상을 확산 복원 과정에 그대로 옮겨, keep, substitute, delete, insert 네 가지 연산을 지원합니다. DELETE 와 INSERT 는 어휘집에 추가된 두 개의 편집 제어 토큰(edit-control token) 으로 구현됩니다. 위치 i 에서 DELETE 는 현재 토큰 x_i 를 제거하고, INSERT 는 x_i 바로 앞에 새로운 편집 가능 위치를 만듭니다.

삽입과 삭제로 시퀀스 길이를 동적으로 바꾸는 아이디어 자체는 Insertion Transformer나 Levenshtein Transformer 같은 편집 기반 시퀀스 생성 연구에서 이미 다뤄졌습니다. LLaDA2.2의 기여는 이를 대규모 MoE 확산 언어 모델의 복원 루프 안에 통합하고, 학습 레이블을 자동으로 만들어내는 절차를 붙였다는 데 있습니다.

아래 그림은 앞서 본 프레임워크 그림의 오른쪽 절반을 확대한 것으로, 이 과정을 한눈에 보여줍니다. 병렬 디코딩이 만들어낸 초안이 No man step step in the the river twice 라고 해봅시다. 세 번째 자리에는 ever 가 와야 하는데 step 이 들어갔고, the 가 두 번 반복되었으며, river 앞에 있어야 할 same 이 통째로 빠져 있습니다. 병렬 복원에서 흔히 나오는 전형적인 결함들입니다.

레벤슈타인 편집은 스텝 t 에서 각 위치에 편집 레이블을 붙입니다. 세 번째 step 에는 [SUBS], 중복된 두 번째 the 에는 [DEL], river 자리에는 [INST], 나머지는 모두 [KEEP] 입니다. 스텝 t+1 이 되면 초안은 No man ever step in the [MASK] river twice 로 바뀝니다. 삭제로 한 자리가 빠지고 삽입으로 한 자리가 생겨 길이는 그대로지만, 시퀀스의 정렬 자체가 재배치 되었습니다. 마지막으로 새로 생긴 [MASK] 가 same 으로 채워지면서 문장이 완성됩니다.

이 짧은 예시만 놓고 보면 T2T 편집으로도 같은 결과에 닿을 수 있습니다. 세 번째 자리를 ever 로, 일곱 번째 자리를 same 으로 치환하면 그만이니까요. 레벤슈타인 편집이 결정적으로 달라지는 지점은 초안과 목표의 정렬 자체가 밀렸을 때 입니다.

예를 들어 도구 호출 인자 하나가 통째로 중복 생성되어 그 뒤의 내용이 전부 한 칸씩 밀렸다고 해봅시다. 치환만 가능하다면 밀린 자리를 하나하나 전부 다시 써야 하고, 그 각각을 모델이 독립적으로 맞춰야 합니다. 반면 DELETE 하나면 뒤 토큰이 전부 제자리로 당겨지면서 한 번에 해결됩니다. 논문이 고정 길이 치환 메커니즘을 "에이전트 워크플로우의 결정적 병목"이라 부른 이유가 여기에 있습니다. 중복 제거와 누락 보충은 도구 호출과 코드 편집에서 가장 흔한 결함인데, 정확히 그 두 가지가 치환만으로는 감당하기 어려운 유형입니다.

LCS로 편집 레이블을 만들어내는 방법

편집을 배우려면 "이 위치에서 무슨 연산을 했어야 하는가"라는 정답 레이블이 필요합니다. 문제는 그런 레이블이 데이터에 붙어 있지 않다는 것입니다. 연구팀은 이를 최장 공통 부분 수열(Longest Common Subsequence, LCS) 정렬 로 자동 유도합니다.

블록 안의 유효한 초안(draft) 토큰 시퀀스를 x, 목표(target) 시퀀스를 y 라 하고 각각의 길이를 m, n 이라 합시다. 블록 구현에서는 m = n \le B 입니다. 두 시퀀스의 LCS를 계산하고 그 매칭 지점들을 앵커(anchor)로 삼으면, 다음과 같은 연산 레이블 열을 얻습니다.

\mathbf{a} = (a_1, \ldots, a_m) \in \{K, S, D, I\}^m

규칙은 이렇습니다. 매칭된 앵커는 삽입 위치로 쓰이는 경우를 제외하면 keep 레이블이 됩니다. 앵커 앞의 각 간격(gap)에 대해서는, 정렬된 위치는 substitute, 초안 쪽에 남는 잉여 위치는 delete, 목표 쪽에 남는 간격은 뒤따르는 앵커에 insert 레이블 하나를 할당합니다. 여기서 중요한 절제가 하나 들어갑니다. 한 편집 라운드에서 한 간격에 할당되는 insert 레이블은 최대 하나 이며, 더 채워야 할 위치는 이후 라운드에서 순차적으로 만들어집니다. 마지막 앵커 뒤의 초안 위치는 모두 delete, 앵커가 하나도 없으면 전 위치가 delete 입니다.

최종 감독 레이블은 다음과 같이 정리됩니다.

\ell_i = \begin{cases} y_{\sigma(i)} & \text{if } a_i \in \{K, S\} \\ \text{DELETE} & \text{if } a_i = D \\ \text{INSERT} & \text{if } a_i = I \end{cases}

여기서 \sigma(i) 는 keep 또는 substitute 연산에 배정된 목표 인덱스입니다. 편집 초기 단계에서 [MASK] 는 LCS 상에서 어떤 목표 토큰과도 매칭될 수 있으며, 역추적 과정에서 선택된 마스크 위치는 목표 인덱스를 가장 가까운 실현 가능한 위치로 조정한 뒤 레이블을 받습니다. 첫 학습 라운드는 평범한 목표 토큰 감독을 쓰고, 이후 편집 라운드부터는 갱신된 초안으로부터 LCS 레이블을 매번 다시 계산합니다.

블록 길이는 어떻게 고정되는가

삽입과 삭제를 허용하면 블록 길이가 들쭉날쭉해질 것 같지만, 구현은 블록 길이를 고정합니다. 편집은 각 블록의 m 개 유효 위치에 독립적으로 적용됩니다. delete 는 x_i 를 제거하고 뒤의 토큰들을 왼쪽으로 당기고, insert 는 x_i 를 ([\text{MASK}], x_i) 로 확장해 이후 복원 라운드가 새 슬롯을 채우도록 합니다. 그 결과를 [MASK] 토큰으로 패딩하거나 꼬리에서 잘라내어 다시 m 개 위치로 되돌립니다.

즉 텐서 모양은 그대로 두면서 시퀀스의 내용과 정렬만 바꾸는 방식입니다. 고정된 블록 크기를 전제로 메모리와 커널을 잡아 두는 추론 엔진 입장에서는, 길이가 매 라운드 달라지는 편집보다 훨씬 다루기 쉬운 형태입니다. 가변 길이 편집의 효과를 얻으면서 실행 경로는 건드리지 않는, 실용적인 타협인 셈입니다.

물론 대가는 있습니다. 한 편집 라운드가 만들어낼 수 있는 변화량이 블록 크기 안으로 제한되므로, 크게 어긋난 초안은 한 번에 고쳐지지 않습니다. 앞서 본 "한 간격에 insert 는 최대 하나" 규칙과 짝을 이루어, 큰 수정은 여러 라운드에 걸쳐 조금씩 이루어집니다. 사람이 원고를 한 번에 완성하지 않고 여러 번 훑으며 다듬는 것과 비슷하게, 편집을 점진적이고 국소적인 연산으로 묶어 두는 설계입니다.

L-EBPO: 환경 피드백으로 편집 결정을 학습하다

지도 미세조정(Supervised Fine-Tuning, SFT)만으로는 절반입니다. 편집의 문법 은 배울 수 있지만, "이 상황에서 지우는 게 이득인가"라는 전략 은 배우기 어렵습니다. 그래서 LLaDA2.2는 강화학습(Reinforcement Learning) 단계를 붙입니다.

2단 제어 계층과 확장된 행동 공간

연구팀은 에이전트 강화학습 문제를 2단 제어 계층으로 정식화합니다. 바깥 층은 에이전트 상호작용 라운드에 걸친 궤적 수준 결정을 다루고(LLaDA2.1이 도입한 EBPO가 담당), 안쪽 층은 한 생성 스텝 안에서 DELETE 와 INSERT 를 언제 어디에 적용할지를 다룹니다.

L-EBPO(Levenshtein Editing ELBO-based Block-level Policy Optimization) 는 이 두 층을 하나의 확장된 행동 공간으로 통합합니다.

\mathcal{A} = \mathcal{V} \cup \{ \text{DELETE}, \text{INSERT} \}

어휘집 \mathcal{V} 에 두 편집 제어 토큰을 더한 것이 곧 행동 공간입니다. 이렇게 두면 토큰 예측과 편집 결정이 하나의 공통 목적 함수 아래에서 함께 최적화됩니다. 적응된 로그 비율(log-ratio)은 다음 형태를 취합니다.

\log \rho(y|x) \approx \sum_{n=1}^{N} w_n \sum_{b=1}^{B} \left( \log p_\theta(a_b \mid z_n, x; M) - \log p_{\theta_{old}}(a_b \mid z_n, x; M) \right), \quad a_b \in \mathcal{A}^{L_B}

여기서 a_b 는 블록 b 의 행동 벡터로, 토큰 예측과 레벤슈타인 편집 결정을 모두 담습니다.

기술적으로 까다로운 지점이 하나 있습니다. DELETE 와 INSERT 는 일시적(transient) 인 토큰이라는 것입니다. 디코딩 중에는 존재하지만 최종 출력 시퀀스에는 남지 않습니다. 그래서 가능도(likelihood)를 추정하려면 사라진 편집 흔적을 복원해야 합니다. 연구팀은 앞서 설명한 레벤슈타인 편집 알고리즘을 그대로 활용해, 노이즈가 섞인 롤아웃(rollout)을 원래 행동 시퀀스와 정렬시켜 각 노이즈 수준마다 최적 편집 레이블을 유도합니다. 이렇게 해야 그래디언트 신호가 구조적 결정까지 흘러 들어갑니다.

멀티턴 궤적의 어텐션 마스킹에도 별도의 처리가 필요합니다. 하나의 확산 블록 안에 모델 출력과 도구 응답이 여러 턴 섞여 있으면, 블록 내부 풀 어텐션 때문에 정보 누출이 생길 수 있습니다. 그래서 첫 번째 턴을 제외한 나머지 턴은 모두 마스킹합니다.

에이전트 학습 환경

에이전트 강화학습은 알고리즘만큼이나 인프라 싸움입니다. LLaDA2.2의 학습 파이프라인은 다양한 작업 하네스(harness)와 격리된 실행 환경 위에 세워집니다. 학습 워커와 롤아웃 워커는 대규모 사후 학습용 통합 강화학습 시스템인 ASystem이 함께 조율하고, 롤아웃 생성은 SGLang이 담당하며, 실행 환경은 AKernel이 관리하는 대규모 샌드박스 클러스터로 제공됩니다.

보상 신호는 전적으로 에이전트 롤아웃 중 수집된 환경 피드백에서 나오며, 세 가지 요소를 더해 구성합니다. 도구 호출 실행의 정확성, 출력 형식의 유효성, 그리고 전체 작업 완수 여부입니다. 학습 벽시계 시간을 줄이기 위해 롤아웃 수집과 샌드박스 서빙, 환경 실행, 정책 최적화가 분산 워커에서 동시에 진행되는 비동기 학습 방식을 채택했습니다.

실험 결과 및 성능 분석

평가 구성

평가 스위트는 총 17 개 벤치마크로, 7 개의 에이전트 벤치마크와 10 개의 일반 벤치마크로 나뉩니다.

에이전트 쪽에는 저장소 단위 소프트웨어 엔지니어링 벤치마크 세 가지, 즉 SWE-bench Verified와 SWE-bench Pro, SWE-bench Multilingual이 들어갑니다. 여기에 멀티턴 도구-에이전트-사용자 상호작용을 보는 τ²-Bench, 자율 에이전시를 보는 Claw-Eval, 대화형 도구 사용을 보는 PinchBench와 MCP-Atlas가 더해집니다.

일반 벤치마크는 수학(AIME 2026, OlympiadBench), 코딩(LiveCodeBench), 지시 따르기(IFBench, Multi-IF), 추론(KOR-Bench), 과학 질의응답(GPQA-Diamond), 롱 컨텍스트 이해(LongBench v2), 함수 호출(BFCL v3/v4)을 아우릅니다.

비교 대상은 같은 Ant Group 계열의 자기회귀 모델인 Ling-2.6-flash입니다. LLaDA2.2-flash의 SWE-bench 계열은 Claude Code 스캐폴드로 평가했고, 모든 점수는 5 회 실행의 산술 평균입니다. 일반 벤치마크에서는 전작 LLaDA2.1-flash도 함께 비교합니다.

에이전트 벤치마크: 도구 사용에서는 대등, 저장소 수리에서는 열세

벤치마크	Ling-2.6-flash (AR)	LLaDA2.2-flash (dLLM)
평균	55.74	53.83
SWE-bench Verified	61.20	49.28
SWE-bench Pro	31.88	30.10
SWE-bench Multilingual	33.73	25.00
τ²-Bench	76.36	80.33
Claw-Eval	64.56	64.22
PinchBench	81.30	81.66
MCP-Atlas	41.12	46.21

결과는 명확하게 갈립니다. 대화형 도구 사용 계열에서 LLaDA2.2-flash는 자기회귀 베이스라인을 앞섭니다. τ²-Bench에서 80.33 점으로 3.97 점 앞섰고, MCP-Atlas에서는 46.21 점으로 5.09 점 앞섰습니다. PinchBench도 근소하게 앞서고 Claw-Eval은 사실상 동률입니다.

반면 저장소 단위 소프트웨어 엔지니어링 에서는 뚜렷하게 밀립니다. SWE-bench Verified에서 11.92 점, SWE-bench Multilingual에서 8.73 점 뒤처집니다. 다만 논문은 SWE-bench Verified 비교에 대해 신중할 것을 당부합니다. Ling-2.6-flash의 점수는 OpenHands 스캐폴드로 측정된 기술 보고서 수치인 반면 LLaDA2.2-flash는 Claude Code 스캐폴드를 썼기 때문에, 스캐폴드가 다른 상태의 비교라는 것입니다.

여기서 읽어야 할 신호는 무엇일까요. 도구 호출 한 번, 대화 한 턴처럼 비교적 짧은 호흡에서 구조를 맞추는 일 은 레벤슈타인 편집이 잘 처리합니다. 하지만 수십 번의 파일 탐색과 패치 시도가 누적되는 저장소 수리처럼 긴 호흡의 인과 계획 에서는 여전히 자기회귀 모델의 순차적 조건화가 우위에 있습니다.

일반 벤치마크: 롱 컨텍스트에서 나타난 반전

분류	벤치마크	Ling-2.6-flash	LLaDA2.1-flash	LLaDA2.2-flash
평균		65.90	59.23	56.81
함수 호출	BFCL v4	66.81	41.04	60.78
함수 호출	BFCL v3	76.05	75.61	67.17
수학	AIME 2026	73.65	74.01	62.24
수학	OlympiadBench	79.59	76.59	74.48
코딩	LiveCodeBench	60.96	45.37	44.77
지시 따르기	IFBench	57.40	37.07	30.20
지시 따르기	Multi-IF	74.80	76.41	73.67
추론	KOR-Bench	66.48	65.12	60.96
지식	GPQA-Diamond	60.35	67.30	48.67
롱 컨텍스트	LongBench v2	42.94	33.80	45.13

일반 능력에서는 격차가 큽니다. 평균 56.81 점으로 Ling-2.6-flash의 65.90 점에 9.09 점 뒤지고, 전작인 LLaDA2.1-flash의 59.23 점보다도 낮습니다.

다만 두 가지 항목은 주목할 만합니다. 하나는 LongBench v2 입니다. 45.13 점으로 자기회귀 베이스라인(42.94 점)을 앞섰을 뿐 아니라, LLaDA2.1-flash의 33.80 점 대비 11.33 점이나 뛰어올랐습니다. 컨텍스트 윈도우를 128\text{K} 로 확장한 노력이 정확히 겨냥한 지점에서 결실을 맺은 셈입니다. 다른 하나는 BFCL v4 로, LLaDA2.1-flash의 41.04 점에서 60.78 점으로 19.74 점 상승했습니다. 함수 호출은 전형적인 구조화 출력 과제이므로, 레벤슈타인 편집이 형식 오류를 실제로 고쳐냈다고 읽을 수 있습니다. 다만 Ling-2.6-flash의 66.81 점에는 여전히 미치지 못하며, 논문도 BFCL을 격차가 남은 항목으로 함께 꼽습니다.

반대로 IFBench(30.20 점 대 57.40 점), GPQA-Diamond(48.67 점 대 60.35 점), LiveCodeBench(44.77 점 대 60.96 점), AIME 2026(62.24 점 대 73.65 점)에서는 격차가 큽니다. GPQA-Diamond는 전작 LLaDA2.1-flash(67.30 점)보다도 18.63 점 낮은데, 에이전트 데이터에 무게를 실은 학습이 지식 집약적 추론 능력을 희생시켰을 가능성을 시사합니다. 논문 스스로도 이 항목들을 향후 개선 우선순위로 명시합니다.

레벤슈타인 편집이 실제로 기여했는가

성능 표만 보면 "그래서 레벤슈타인 편집이 얼마나 기여한 것인가"라는 질문이 남습니다. 연구팀은 이를 격리해서 측정했습니다. 동일한 LLaDA2.2 베이스 모델을 동일한 SWE 궤적으로 미세조정하되, 레벤슈타인 편집 활성화 여부만 바꾼 것입니다.

결과는 SWE-bench Verified 기준 35.8 점에서 44.4 점으로, 절대 8.6 점 상승입니다. 상대적으로는 24\% 에 가까운 개선입니다. 삽입과 삭제를 허용하는 것만으로 저장소 단위 소프트웨어 엔지니어링 성능이 이만큼 오른다는 것은, 앞서 지적한 "고정 길이 치환의 한계"가 실제로 병목이었음을 뒷받침합니다.

흥미로운 지점은 이 44.4 점이 최종 모델의 49.28 점보다 낮다는 것입니다. 이 실험은 동일한 SWE 궤적만으로 미세조정한 SFT 단계를 떼어내 측정한 값이므로, 최종 모델과의 4.88 점 차이는 L-EBPO 강화학습을 포함한 나머지 사후 학습 과정에서 나온 몫입니다.

추론 처리량: 확산 모델의 본령

분류	벤치마크	Ling-2.6-flash (BF16)	LLaDA2.2-flash (BF16)	LLaDA2.2-flash (FP8)
에이전트	SWE-bench Verified	303.20	519.00	601.50
에이전트	SWE-bench Pro	283.40	485.30	578.60
에이전트	SWE-bench Multilingual	200.60	459.50	535.70
에이전트	τ²-Bench	334.90	592.80	705.30
함수 호출	BFCL-v4	331.50	703.82	846.60
수학	AIME 2026	351.24	514.10	588.50
코딩	LiveCodeBench	354.90	599.00	721.30
지시 따르기	IFBench	327.24	473.40	566.50
추론	KOR-Bench	352.75	452.10	550.00
지식	GPQA-Diamond	324.55	337.60	408.80
롱 컨텍스트	LongBench-v2	145.50	281.20	320.80

처리량은 확산 언어 모델이 존재하는 이유입니다. 11 개 워크로드 전부에서 LLaDA2.2-flash가 더 빨랐고, 평균 1.64\times 의 속도 향상을 기록했습니다. 참고로 비교 대상인 Ling-2.6-flash는 다중 토큰 예측(Multi-Token Prediction, MTP)을 4 개 드래프트 토큰으로 활성화한 상태입니다. 즉 자기회귀 쪽도 속도 최적화를 켜 둔 상태의 비교입니다.

격차가 가장 큰 곳이 의미심장합니다. SWE-bench Multilingual에서 2.29\times, BFCL-v4에서 2.12\times, τ²-Bench에서 1.77\times 로, 에이전트 및 도구 사용 워크로드에서 특히 벌어집니다. LongBench-v2에서도 145.50 TPS 대 281.20 TPS로 거의 두 배입니다. 반면 GPQA-Diamond는 324.55 TPS 대 337.60 TPS로 거의 차이가 없는데, 짧고 어려운 추론 문제에서는 병렬 복원의 이점이 크지 않다는 뜻으로 읽힙니다.

BF16에서 FP8로 양자화하면 평균 처리량이 추가로 18.6\% 오릅니다. BFCL-v4에서는 846.60 TPS까지 올라가는데, 이는 Ling-2.6-flash 대비 2.55\times 에 해당합니다.

정리하면 품질에서 1.91 점을 내주는 대신 속도에서 1.64\times 를 얻는 거래입니다. 지연이 사용자 경험을 좌우하는 대화형 에이전트라면 충분히 매력적인 교환비입니다.

한계점 및 향후 연구 방향

논문의 한계 서술은 이례적으로 솔직합니다. 연구팀 스스로 "여전히 초기 단계"라고 못 박으며 세 가지 미해결 문제를 제시합니다.

블록 확산 디코딩의 국소적 비일관성

블록 확산 모델은 엄격하게 구조화된 출력 생성에서 여전히 강한 자기회귀 모델에 뒤처집니다. 한 복원 스텝 안에서 여러 위치가 병렬로 예측되므로, 이후 정제 스텝이 오기 전까지는 서로를 조건화할 수 없습니다. 이 지연된 의존성이 중첩 JSON 생성이나 복잡한 SQL 합성, 다중 인자 도구 호출처럼 순서에 민감한 작업에서 국소적 일관성을 약화시킵니다. 구분자 불일치, 필드 어긋남, 모호한 경계 같은 오류가 여기서 나옵니다.

레벤슈타인 편집은 이런 오류를 사후에 수리 할 수 있게 해주지만, 자기회귀 디코딩의 토큰 단위 접두사 제약을 완전히 대체하지는 못하며 문법적 유효성을 보장하지도 않습니다. 수리는 예방이 아니라는, 담백한 인정입니다.

비대칭적 편집 학습

두 편집 제어 토큰의 학습 난이도가 같지 않다는 관찰이 특히 흥미롭습니다. DELETE 는 대개 국소적으로 눈에 보이는 중복 에 대응합니다. 같은 구절이 두 번 나오면 하나를 지우면 되니 판단이 쉽습니다. 반면 INSERT 는 모델이 (1) 누락을 감지하고, (2) 어디에 새 내용이 필요한지 판정하고, (3) 삽입된 위치를 이후 정제 스텝과 조율해야 합니다. 세 단계 모두를 요구하므로 훨씬 어렵습니다.

그 결과 반복을 제거하는 일은 쉽지만 빠진 내용이나 구조적 결손을 메우는 일은 어렵다 는 비대칭이 생깁니다. 그리고 고쳐지지 않은 오류는 문맥에 편입되어 시간에 따라 복리로 누적되며 목표 표류를 일으킵니다. 국소 편집만으로는 장기 호흡의 오류 누적을 없앨 수 없다는 것이 연구팀의 결론입니다.

강화학습 효율과 MoE 학습-추론 불일치

확산 언어 모델의 생성 궤적은 블록 단위 복원과 편집 결정이 여러 라운드 겹쳐 있어, 정확한 시퀀스 수준 가능도를 효율적으로 계산하기 어렵습니다. LLaDA2.1이 도입한 EBPO는 이를 우회하려고 ELBO(Evidence Lower Bound) 기반 근사를 정책 비율 추정의 대리 지표로 씁니다. L-EBPO도 같은 접근을 이어받아 레벤슈타인 편집이 포함된 궤적으로 확장한 것입니다.

여기에는 두 종류의 학습-추론 불일치가 남아 있습니다. 하나는 학습 시의 ELBO 기반 가능도 추정과 추론 시의 신뢰도 기반 디코딩 사이의 간극이고, 다른 하나는 MoE 전문가 라우팅이 학습과 추론에서 다르게 동작하는 문제입니다. EBPO 자체의 학습 효율과 최적화 안정성도 과제로 남아 있습니다.

더 넓게 보면 확산 언어 모델의 핵심 학습 패러다임 자체가 아직 미개척입니다. 일반 코퍼스와 에이전트 코퍼스 사이의 데이터 혼합 비율과 커리큘럼 설계에 정답이 없습니다. 에이전트 데이터가 지나치면 범용 기초 능력이 깎이고, 감독이 부족하면 도구 사용 숙련도와 장기 실행 능력이 제약됩니다. 이번 결과에서 GPQA-Diamond가 전작보다 크게 떨어진 것이 이 딜레마의 구체적인 사례로 보입니다. MOPD(Multi-Teacher On-Policy Distillation) 같은 기법을 확산 언어 모델로 확장하는 문제도 아직 열려 있습니다.

앞으로 열려 있는 연구 전선

연구팀은 세 가지 연구 전선을 제시합니다.

첫째, 편집에 디코딩과 동시에 검증하는(verify-while-decode) 목적 함수를 통합하여 이미 생성된 토큰과의 일관성을 계속 확인하는 방향입니다. I-DLM의 내성적(introspective) 모델링 관점과 맞닿아 있습니다.

둘째, 이산적인 마스크-편집 전이를 넘어서는 연속 확산 패러다임입니다. 셋째, 블록 확산 안에서 이루어지는 온라인 정렬(online alignment)로, 분산이 낮은 가능도 추정과 더 표적화된 탐색, 더 세밀한 크레딧 할당이 핵심 과제입니다.

이 연구가 남기는 것

LLaDA2.2는 확산 언어 모델이 자기회귀 모델을 이겼다고 주장하지 않습니다. 오히려 표를 보면 일반 능력에서 9 점 넘게 뒤처지고, 저장소 수리에서는 두 자릿수 격차가 납니다. 그럼에도 이 연구가 의미 있는 이유는, 확산 언어 모델을 에이전트 워크로드에서 "쓸 수 없는 것"에서 "선택지"로 옮겨 놓았다는 데 있습니다.

대화형 도구 사용 벤치마크 세 곳에서 자기회귀 베이스라인을 앞서면서 1.64\times 빠르다는 것은, 지연에 민감하고 도구 호출이 잦은 워크로드에서는 이미 실용적인 대안이 존재한다는 뜻입니다. 그리고 그 열쇠가 더 큰 모델이나 더 많은 데이터가 아니라 "지울 수 있고 끼워 넣을 수 있게 만드는 것" 이라는 단순한 편집 능력의 확장이었다는 점이, 이 논문에서 가장 오래 남는 대목입니다.

LLaDA2.2-flash 사용 방법

LLaDA2.2-flash는 Apache License 2.0으로 공개되어 있으며 Hugging Face에서 바로 내려받을 수 있습니다. 모델 사양은 MoE 확산 언어 모델로 비임베딩 파라미터 100\text{B}, 레이어 32 개, 어텐션 헤드 32 개, RoPE 위치 인코딩, 어휘 크기 157{,}184 입니다.

transformers 로 바로 실행할 수 있습니다.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_path = "inclusionAI/LLaDA2.2-flash"

model = AutoModelForCausalLM.from_pretrained(
    model_path,
    trust_remote_code=True,
    device_map="auto",
)
model = model.to(torch.bfloat16)
model.eval()

tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True)

prompt = """Calculate 1+5-28*0.5-200=?"""
input_ids = tokenizer.apply_chat_template(
    [{"role": "user", "content": prompt}],
    add_generation_prompt=True,
    tokenize=True,
    return_tensors="pt",
).input_ids

generated_tokens = model.generate(
    inputs=input_ids,
    eos_early_stop=True,
    gen_length=512,
    block_length=32,
    threshold=0.5,
    editing_threshold=0.0,
    temperature=0.0,
)

print(tokenizer.decode(generated_tokens[0], skip_special_tokens=True))

모델 카드가 권장하는 설정은 다음과 같습니다.

샘플링 파라미터: block_length=32, temperature=0.0, top_p=None, top_k=None 을 안정적인 기본값으로 시작합니다.
복원 임계값: threshold, editing_threshold, max_post_steps 를 애플리케이션이 요구하는 속도와 품질의 균형에 맞춰 조정합니다. 임계값을 낮추면 추론 속도가 빨라지지만 반복이 늘거나 출력이 불안정해질 수 있습니다.
롱 컨텍스트 에이전트 워크로드: 긴 문맥의 도구 사용과 멀티턴 에이전트 애플리케이션에는 SGLang을 서빙 백엔드로 쓸 것을 권장합니다. 128\text{K} 컨텍스트와 MoE 확산 추론 요구사항에 맞게 서빙 스택을 구성해야 합니다.

참고로 벤치마크 평가에 사용한 설정은 위 권장값과 조금 다릅니다. 모델 카드에 따르면 모든 벤치마크에서 128\text{K} 컨텍스트에 temperature=1.0, block_length=32, threshold=0.5, editing_threshold=0.0 을 썼습니다. 즉 표에 실린 점수는 탐욕적 디코딩이 아니라 온도 1.0 에서 5 회 실행한 평균입니다. SGLang 배포 지원은 준비 중이라고 안내되어 있습니다.

LLaDA2.2: Enabling Agentic Diffusion Language Models via Levenshtein Editing 기술 보고서

LLaDA2.1: Speeding Up Text Diffusion via Token Editing 논문

LLaDA2.0: Scaling Up Diffusion Language Models to 100B 논문

LLaDA2.X GitHub 저장소

LLaDA2.2-flash (Hugging Face)

Large Language Diffusion Models (LLaDA) 논문

The Bitter Lesson of Diffusion Language Models for Agentic Workflows 논문

Power Up Diffusion LLMs: Day-0 Support for LLaDA 2.0 (SGLang) 블로그

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~