AWS 환경에서 프로덕션-레디 확산 언어 모델(DLM) 검증하기

확산 언어 모델(Diffusion Language Model, 이하 DLM)은 일반적인 자기회귀(Autoregressive, 이하 AR) 모델과 다른 방식으로 텍스트를 생성하는 언어 모델입니다. 최근 AR 모델과 동일한 사이즈의 DLM 모델들이 공개되고 있으며, 벤치마크 결과에서 AR보다 낮은 응답 지연(latency)을 보이며 주목을 받고 있습니다. 다만 AR과 완벽히 동일한 구조의 모델이 아니기 때문에 워크로드에서 모델을 변경하기 앞서 검증을 통해 기존 워크로드의 응답 품질에 영향이 가지 않는지 확인해야 합니다. 즉, 지연시간 이점만으로 프로덕션에 새 모델을 사용할 수 있을지는 쉽게 판단할 수 없습니다.

본 글은 AWS 위에서 DLM을 서빙하거나 DLM을 기존 에이전틱 워크로드에 도입하기 위해 평가 게이트를 구축하려는 고객을 대상으로 합니다. 특히 AR 모델에 비해 응답 정확도가 떨어진다는 평가를 받는 DLM 모델을 서빙할 때 고려해야 하는 부분과 모델 응답을 채점하고 통과/탈락을 판정하는 평가 게이트에 대해 다룹니다.

이를 위해 게임 NPC 대화 워크로드를 상정하고 테스트했으며, 약 45개 엔티티로 구성된 게임 세계관에서 NPC가 플레이어의 질문(세계관 사실 질문, 거짓 전제로 유도하는 함정 질문, 여러 NPC를 교차 참조하는 질문, 멀티턴 대화 등)에 캐릭터를 유지한 채 사실에 맞게 답하도록 만드는 과정에서의 개선들을 소개합니다.

이 워크로드는 작은 모델, 외부 지식 주입, 실시간 대화라는 조건을 모두 포함하므로, 세부 임계값을 제외한 설계 원칙은 게임 도메인뿐만 아니라 다른 도메인에도 그대로 적용됩니다. 이 글에서 다루는 핵심 질문은 세 가지입니다:

1. DLM이란 무엇이고, AR과 무엇이 다른가.
2. 작은 모델에 세계 지식을 주입할 때, 데이터를 어떻게 저장하고 검색(retrieve)해야 하는가.
3. 모델 응답을 어떤 기준으로 통과/탈락시킬 것인가. 즉 평가 게이트(Evaluation Gate)를 어떻게 설계하는가.

1. DLM이란 무엇인가

우리가 알고 있는 대부분의 LLM은 자기회귀(AR) 방식입니다. 토큰을 왼쪽에서 오른쪽으로 한 번에 하나씩 순차적으로 생성하며, 새 토큰을 생성할 때 기존 토큰들을 참조하게 됩니다. 따라서 한 사용자의 총 응답 지연은 대체로 인풋 토큰 처리 시간 + (생성할 토큰 수 × 토큰당 생성 시간)으로 정해집니다.

앞의 지연시간은 프리필(Prefill) 과정이 중요한 역할을 하고 뒤의 지연시간은 디코드(Decode) 과정이 중요한 역할을 합니다. 우리는 이 각각의 지연 시간을 TTFT(Time-To-First-Token) 혹은 ITL(Inter-Token-Latency)로 측정하기도 합니다. 이때 프리필 단계에서는 연산 능력에 묶이게 되고(compute-bound), 디코딩 단계에서 연산 능력이 아니라 메모리 대역폭에 묶여 있게 됩니다(memory-bound).

즉, 토큰을 생성하는 동안 연산 능력이 잘 활용되지 못하는 상황들이 발생하고 잉여 연산 능력이 단일 사용자의 지연을 줄이는 데에는 쓰이지 못하게 됩니다. 따라서 이런 연산 능력을 꾸준히 활용하고자 프리필과 디코딩을 배치 형식으로 스케줄링하는 방식을 사용하거나 아예 프리필과 디코드를 분리하는 프리필-디코드 분리(Prefill-Decode Disaggregation)와 같은 아키텍처들이 활발하게 연구 및 채택되고 있습니다.

DLM은 AR 모델과 다른 방식을 사용합니다. 본 글에서 사용한 DiffusionGemma를 예로 들면, 토큰을 하나씩 만드는 대신 고정 길이의 토큰 묶음(캔버스/canvas)을 한꺼번에 병렬로 생성한 뒤, 여러 번의 디노이징(denoising, 노이즈를 제거하며 정답에 가깝게 만드는 과정) 패스로 캔버스를 다듬게 됩니다. 즉, 노이즈로 채워진 자리의 토큰을 문맥에 맞는 토큰으로 바꿔 가며 문장을 다듬게 됩니다. 이 작업은 연산 능력에 영향을 많이 받기 때문에 AR 모델과 다르게 병목이 메모리 대역폭에서 연산으로 옮겨가고(compute-bound), 단일 사용자의 응답 지연이 낮아집니다. 또한 캔버스 전체를 양방향(bidirectional)으로 보며 정제하므로, 생성 도중 스스로 오류를 고치기도 합니다.

다만 엄밀히 말하면, 글을 작성하는 시기에 프로덕션 레벨에서 언급되고 있는 DLM은 순수한 비자기회귀(non-autoregressive) 모델이라기보다는 AR과 확산 모델의 하이브리드에 가깝습니다. DiffusionGemma는 캔버스(기본 256 토큰) 한 블록을 병렬 확산으로 완성한 뒤 그 결과를 KV 캐시에 확정하고, 다음 블록을 위해 새 캔버스를 시작합니다. 블록 안에서는 확산으로, 블록과 블록 사이에서는 자기회귀로 동작하는 것입니다. 이렇게 확산을 통한 속도와 AR을 통한 순차적 안정성을 함께 취합니다.

그림 1. DiffusionGemma의 구조. 출처: DiffusionGemma: The Developer Guide

표 1. AR과 DLM의 생성 방식 비교

그림 1에서 본 DiffusionGemma처럼 실제 토큰 위에서 직접 작업하는 방식을 이산(discrete) DLM이라고 합니다. DLM은 이산 DLM을 포함해 크게 두 가지로 분류됩니다. 또다른 DLM인 연속(continuous) DLM은 토큰을 연속적인 표현(토큰 임베딩이나 학습된 잠재공간)으로 바꾼 뒤 그 공간에서 디노이징하고, 다시 토큰으로 바꿉니다. 쉽게 말해 이산 방식은 단어를 직접 고쳐 쓰는 쪽이고, 연속 방식은 의미 공간에서 다듬은 뒤 단어로 옮기는 쪽입니다. 현 시점까지 프로덕션 레벨의 DLM 연구 결과나 모델은 대부분 이산 DLM에서 나왔습니다. 연속 DLM과의 성능 차이가 언어의 본질적인 이산성 때문인지, 아니면 아직 충분히 탐구되지 않은 설계 선택 때문인지는 여전히 열린 질문입니다. 그렇지만 엔비디아의 연구나 MIT의 연구를 보면 연속 DLM도 충분히 이산 DLM과 경쟁할만큼 혹은 그 이상의 효율을 보여줄 수 있으리라 보며 활발히 연구되고 있음을 확인할 수 있습니다.

DLM은 이처럼 빠르게 변화하고 연구되고 있어서, 어떤 DLM을 선택하더라도 더 적은 스텝과 더 적은 사이즈의 모델로 같은 품질을 내는 새로운 모델이 곧 등장할 가능성이 높습니다. 따라서 특정 모델에 고착되기보다, 모델을 갈아끼울 수 있는 데이터 파이프라인 혹은 하네스(harness)와 평가 게이트를 먼저 갖추는 것이 필요합니다.

2. 작은 모델에 사실을 주입하기

DLM이든 AR이든, 모델은 그 안에 세계의 사실을 모두 담을 수 없습니다. 특정 도메인(게임 세계관, 사내 지식, 제품 카탈로그 등)에서 정확하게 답하게 하려면, 여전히 외부 지식을 검색(retrieve)해서 프롬프트에 함께 넣어 주어야 합니다. 이렇게 외부 지식을 검색해 모델 입력에 보강하는 방식을 검색 증강 생성(RAG, Retrieval-Augmented Generation)이라고 하며 최근에는 에이전틱 서치와 같은 방법을 통해 컨텍스트를 증강하기도 합니다. 언뜻 들으면 서로 다른 방법 같지만, 둘 모두 데이터 혹은 사실을 어떻게 구조화해 저장하고 어떻게 검색하느냐를 중요하게 생각합니다.

본 글에서 다루는 실험에서는 지식을 엔티티와 관계의 그래프로 저장하고 검색하는 그래프 기반 RAG를 사용했습니다. GraphRAG는 일관성을 유지하기에 탁월하고, 그래프 구조가 캐릭터 중심의 세계관을 표현하기 좋아 게임/미디어 워크로드에서 많이 고려되는 방법 중 하나입니다. GraphRAG와 관련된 자세한 내용은 본 글에서 다루지 않으며, 다른 AWS 블로그를 참고하시는 것을 권장드립니다.

데이터를 저장하고 검색하는 과정에서 개선은 총 세 가지에서 나왔습니다.

• 타입(type)이 있는 그래프: 사실을 자유로운 텍스트가 아니라 정해진 요소(역할, 소속, 위치, 상태 등)로 구분해 저장하고, 자주 발생하는 오해(예: 닮은 두 인물을 혼동)를 별도의 정정용 데이터로 관리.
• 하이브리드 검색: 그래프 기반의 엔티티 기반 검색과 벡터 유사도 검사를 함께 사용. 캐릭터의 핵심 정체성 사실은 랭킹에서 밀려나지 않도록 항상 포함.
• 적절한 검색: 검색된 데이터가 많다고 꼭 정확한 답변을 하지 않음. 오히려 검색된 데이터가 너무 많은 경우, 중요한 사실(fact)을 놓치는 경우가 발생. 검색을 통한 사실 신호 밀도를 높여, 모델이 봐야 할 사실에 집중하도록 함.

특히 초기에는 단순한 방식으로 데이터를 구조화하고 저장했는데 결국 검색에도 영향을 미쳐 응답 퀄리티를 떨어뜨리는 현상도 나타났습니다. 초기 구성은 “주어-관계-목적어” 형태의 단순한 트리플(triple)로 저장했고 이를 검색해서 프롬프트에 그대로 넣었습니다. 시나리오당 53개의 사실이 들어갔고, 그중 실제로 답에 필요한 신호는 오직 6%였음을 발견했습니다.

예를 들어 “정우”라는 NPC를 보겠습니다. 두 방식의 차이는 다음과 같습니다.

표 2. 단순 트리플과 타입 그래프 저장 방식 비교 (NPC 정우 예시)

왼쪽은 모델이 직책, 종족, 저주 관계를 무관한 트리플 더미 속에서 일일이 골라내야 합니다. 오른쪽은 한 엔티티의 핵심 요소들이 구분되어 저장되며, 자주 나오는 오해도 데이터로 따로 올려 둡니다.

표 3. 데이터 구조화에 따른 주입 사실 수와 신호 밀도

추가로 DLM 관점에서 한 가지 관찰이 있습니다. 노이즈가 많은 초기 방식에서는 DLM의 사실 정밀도가 AR보다 최대 10%가량 낮았는데, 적절한 검색을 통해 사실을 밀도 있게 주입받자 그 격차가 사라졌습니다. 또한 환각을 일으키거나 함정 질문에서 함정에 빠지는 일이 유의미한 수치로 감소했습니다. 이처럼 단순히 모델 레벨의 성능을 중요하게 평가하기보다는 데이터 파이프라인의 품질 개선을 통해 모델의 단점을 유의미하게 가릴 수 있을지를 평가해야 합니다.

3. 실험 설계

DLM과 AR의 차이를 확인하기 위한 실험이기 때문에 다음의 환경들을 동일하게 구성했습니다.

• 동일한 백본 모델 (DiffusionGemma와 Gemma4) 기반과 사이즈. 전체 260억 파라미터 중 토큰당 약 40억 개만 활성화하는 Mixture-of-Experts(MoE) 구조(26B-A4B)를 양쪽에 동일하게 사용.
• 동일한 양자화. NVFP4(NVIDIA의 4비트 부동소수점 형식으로, 모델 가중치를 압축해 메모리와 추론 비용을 줄임)를 양쪽에 적용.
• 동일한 서빙 스택. 오픈소스 LLM 추론 엔진 vLLM을 사용하고, 모델을 여러 GPU로 쪼개지 않는 단일 가속기 구성으로 실행.
• 동일한 인스턴스 (g7e.2xlarge)
• 동일한 GraphRAG 컨텍스트, 동일한 구조화 프롬프트.

이렇게 하면 유일하게 다른 변수는 모델 내 구조만 남게 됩니다. 평가는 게임 NPC 대화 워크로드를 기준으로, 단일턴 50개 시나리오(일반 사실, 함정 질문, 심화 세계관, 성격 반영, 교차 참조 카테고리)와 멀티턴 14개 시나리오로 구성했습니다.

그림 2. 평가 게이트 전체 아키텍처

이 실험의 실행 환경은 Amazon SageMaker AI의 학습 작업(Training Job)으로 구성했습니다. 모델을 학습시키는 것이 목적은 아니지만, 필요한 시간 동안만 GPU를 띄워 생성을 수행하고 끝나면 자원을 회수하는 일회성 GPU 실행 수단으로 Training Job이 적합했기 때문입니다. 그림 2가 전체 파이프라인을 보여줍니다. 컨테이너 이미지는 Amazon ECR에서 가져오고, 실험에 사용할 모델 가중치는 Amazon S3에서 로드하며, 생성은 g7e.2xlarge 인스턴스 위에서 vLLM으로 수행합니다. g7e.2xlarge를 선택한 이유는 양자화 형식에 있습니다. NVFP4는 NVIDIA Blackwell 세대 GPU에서 가속되는데, g7e.2xlarge가 Blackwell GPU를 제공하므로 여러 GPU로 쪼개지 않는 단일 가속기 구성으로 NVFP4 가속 요건을 충족할 수 있었습니다. AR과 DLM 모델로부터 생성된 응답은 Amazon S3로 내보냅니다. 이후 평가 단계에서는 Amazon Lambda 또는 Amazon Bedrock AgentCore Runtime 위에서 이 응답을 읽어 Amazon Bedrock의 Claude Sonnet으로 채점(LLM as a judge)한 뒤, 평가 결과를 다시 S3에 저장합니다. 채점 방식과 평가 게이트의 구체적인 설계는 4장에서 자세히 다룹니다.

4. 평가 게이트(Evaluation Gate)

평가 게이트는 모델에서 생성한 응답을 채점하고 통과/탈락을 판정합니다. 모델 비교의 신뢰성은 모델 자체가 아니라 이 평가 게이트에서 결정됩니다.

4.1 비즈니스 목표에서부터 게이트를 설계하기

평가 게이트(Evaluation Gate)는 점수가 높으면 통과시키는 장치가 아니라, 비즈니스 목표를 만족하는 최소 조건의 집합입니다. 실시간 대화 워크로드라면 “사실 정밀도가 일정 수준 이상이면서, 꼬리 지연이 임계 안이고, 멀티턴에서 페르소나가 유지될 것” 같은 것들이 통과 조건이 됩니다. 임계값은 벤치마크 관행이 아니라 내 워크로드에서 허용할 수 있는 한계에서 도출되어야 합니다. 예를 들어 지연 시간 p95 임계값은 “실시간 대화에서 응답이 특정 시간 이상 끊기면 몰입이 깨진다”는 제품 판단에서 출발해 정하고, 사실 정밀도 하한은 “NPC가 세계관 사실을 틀리면 플레이어 신뢰가 깨진다”는 기준에서 정합니다. 같은 수치라도 의료, 금융처럼 오류 비용이 큰 도메인이라면 지연 시간을 조금 손해보더라도 정확도의 임계를 더 높게 잡아야 합니다.

즉, 평가 게이트는 비즈니스 목표에서 출발해야 합니다. 만약 워크로드의 비즈니스 목표를 임계값으로 표현할 수 없다면, 해당 AI/ML 또는 에이전틱 워크로드를 설계하는 목적 자체를 먼저 점검할 필요가 있습니다. 목표가 정의되지 않으면 통과/탈락 기준을 세울 수 없고, 기준이 없으면 모델을 프로덕션에 적용할 근거도 확보할 수 없습니다.

본 실험에서 사용한 게이트의 예시는 다음과 같습니다. 해당 요소들을 참고하되, 임계값은 도메인마다 달라야 합니다.

표 4. 평가 게이트 항목과 임계값 예시

4.2 채점 모델과 신뢰구간 판정

채점에는 Amazon Bedrock의 Claude Sonnet 4.6과 코드 기반의 결정론적인 방법을 사용했습니다. Sonnet을 선택한 이유는 비용-효율 때문입니다. 같은 응답을 여러 번 채점하거나 검증해야 하는 여러 시나리오가 증가하기 시작하면 채점 호출 수가 빠르게 늘어나 평가만으로도 비용에 부담이 갈 수 있는데, Opus는 토큰당 비용이 훨씬 높아 Sonnet을 사용하게 되었습니다. 이 채점 작업에서 Sonnet을 사용하는 것으로 품질이 충분하다고 판단했습니다. 또한 단순히 LLM만 판단의 주체로 사용하지 않고, 결정론적으로 판단할 수 있는 부분들은 코드를 통해 검증해 신뢰성을 높이고 LLM 호출 비용을 줄이고자 했습니다.

LLM으로 응답을 채점하면 채점 결과 혹은 점수가 균일하지 않을 수도 있습니다. 따라서 단일 점수가 아니라 신뢰구간(반복 측정을 통해 얻은 참값이 들어갈 범위)이 임계값을 완전히 넘을 때만 통과 판정을 내리는 것이 안전합니다. 일부 지표의 경우, 비율 지표는 Wilson 구간, 평균 지표는 부트스트랩(bootstrap, 표본을 반복 재추출해 구간을 추정하는 통계 기법)을 통해 구간을 계산했습니다. 또한 채점 노이즈 자체를 줄이기 위해 같은 응답을 여러 번 호출을 통해 재채점해 합치는 방식을 적용해 채점 편차를 낮췄습니다.

4.3 Raw Response를 검토하기

집계 점수는 정리된 결과를 보여주기 때문에 보기 좋지만 집계 결과만으로 단순히 성공, 실패를 판단하는 것은 좋은 방법이 아닙니다. 특히 LLM을 판단의 주체(LLM as a judge)로 사용하고 있다면, 이 점수는 무엇을 고쳐야 할지 알려주지 않습니다. 본 실험에서 의미 있는 개선은 모델의 원본 응답(raw response)을 사람이 직접 읽고 확인하는 과정(HITL, Human-in-the-Loop)에서 나왔습니다. 실제 응답을 검토하면 점수만으로는 보이지 않는 패턴이 드러나기도 합니다. 채점기가 페르소나의 말투를 사실 오류로 오인하거나, 정답을 다른 표현으로 답한 경우를 오답으로 처리하거나, 반대로 오답을 정답으로 처리한 경우가 있을 수 있습니다.

따라서 평가 게이트는 한 번 만들고 끝나는 정적 산출물이 아니라, 다음과 같은 루프를 통해 지속적으로 교정되는 시스템으로 운영해야 합니다.

1. 게이트를 실행한다.
2. 통과/탈락 결과와 함께 탈락하거나 경계선에 있는 케이스의 원본 응답을 사람이 검토한다.
3. 점수와 사람의 판단이 어긋나는 지점을 찾는다.
4. 채점 기준, 임계값, 테스트 시나리오 추가를 통해 평가게이트를 교정한다.
5. 다시 실행한다.

5. 결과

아래 수치는 테스트를 위해 게임 NPC 대화 워크로드 기반으로 측정한 결과입니다. 매 테스트마다 단일턴 50개와 멀티턴 14개를 서로 다른 난수 시드로 3회 반복해 비교했습니다. 같은 환경에서 AR과 DLM의 비교를 진행했으며, 다양한 개선을 통해 변화하는 것을 볼 수 있습니다.

5.1 사실 정밀도와 환각

사실 정밀도는 모델을 교체하지 않고 데이터 파이프라인을 개선하는 과정에서 단계적으로 향상되었습니다. 초기 단순 트리플 기반의 저신호 컨텍스트에서는 DLM이 AR보다 최대 10% 정도 낮았으나, 데이터 저장과 조회 방식을 개선하자 AR(0.983)과 DLM(0.975)의 사실 정밀도가 가까워졌고, 그래프 데이터를 추가로 보강한 DLM은 0.984까지 올라 95% 게이트(신뢰구간 하한 ≥ 0.95)를 통과했습니다. 특히 이 과정에서 환각이 눈에 띄게 감소(18%에서 3%)하는 것을 볼 수 있었습니다.

표 5. 데이터 파이프라인 단계별 사실 정밀도와 환각 (AR, DLM)

위 단계별 궤적은 모델을 고정한 채 데이터 파이프라인을 개선하며 DLM의 변화를 추적한 것으로, 데이터 보강 시점 기준 AR(0.985)와 DLM(0.984)로 두 모델의 사실 정밀도는 통계적으로 동률에 가깝습니다. 초기 저신호 컨텍스트에서 나타난 DLM 성능의 문제는 모델의 본질적 한계가 아니라 데이터 파이프라인의 품질 문제였으며, 데이터 저장 방식과 검색 방식 개선을 통해 점진적으로 사실 정밀도가 높아진 것을 확인할 수 있습니다.

5.2 지연 시간

표 6. AR과 DLM의 응답 지연 시간 (P50/p95)

DLM은 중앙값(P50)뿐 아니라 꼬리 지연(p95)에서도 일관되게 빨랐으며, 약 3.5배의 지연 시간 이점을 보였습니다. 실시간 상호작용 워크로드라면 이는 중요한 차이입니다. 실제로 표4의 지연 시간 게이트(p50 < 1s, p95 < 2s)에 대입하면, AR은 p50 1509ms, p95 2324ms로 두 임계값을 모두 초과해 게이트를 탈락하는 반면, DLM은 p50 421ms, p95 629ms로 두 기준을 모두 여유 있게 통과합니다. 다만 앞에서 설명했듯 이 이점은 compute-bound 특성, 즉 더 많은 연산 자원을 소비하는 대가로 얻어집니다. 다중 사용자 처리량이 목표라면 이 트레이드오프는 다르게 계산되어야 할 수 있으며 직접적인 부하 테스트를 통해 각 워크로드에서 확인하는 것이 필요합니다.

5.3 평가 교정

DLM의 최종 사실 정밀도 0.984는 숫자만 보면 충분히 높아 보여 더 확인하지 않아도 될 것처럼 보입니다. 그러나 점수를 깎은 소수의 응답을 직접 읽어 보면, 성격이 다른 문제들이 섞여 있었습니다. 예를 들어, 채점기 자체의 오판으로 보이는 경우도 있었습니다. 게임 세계관에서 악당의 봉인과 관련된 오래된 역사와 현재 역사가 있었는데, 한 응답은 원조 봉인 영웅을 정확히 나열하고 후대 영웅을 올바르게 제외했으나 채점기는 “후대 영웅 A를 빠뜨렸다”며 감점했습니다. 이 경우라면 응답이 아니라 채점한 점수가 틀린 쪽에 가깝고 사실 정밀도는 더 올라갈 수 있게 됩니다.

집계 점수만 봤다면 이 응답은 실패로 남았겠지만, 원본을 읽으면 오히려 정답에 가깝습니다. 즉 점수에는 실제로는 진짜 모델 응답의 오류 혹은 채점기 오판이 함께 섞여 있을 수 있습니다. 높은 점수에 안심하지 말고 사람이 직접 점수에 따라 응답을 직접 분류하거나 혹은 반대로 임계점의 점수를 가지고 통과한 경우가 있는지 확인하고 평가 루프를 교정해야 합니다.

5.4 그 외 게이트 결과

본문에서는 AR과 DLM의 차이가 가장 두드러지는 사실 정밀도와 지연 시간에 초점을 맞췄으나, 표4에서 정의한 나머지 게이트 항목도 함께 측정했습니다. DLM 기준으로 검색 정확도(엔티티 커버리지)는 약 0.91로 게이트 기준(90% 이상)을 충족했고, 페르소나 일관성 4.9점, 자연스러움 4.8점(각 5점 만점), 멀티턴 통과율은 100%를 기록했습니다. 즉 사실 정밀도, 환각, 지연을 포함한 6개 게이트 항목 전체가 통과 조건을 만족했습니다.

6. 엔지니어링 교훈

특정 도메인을 넘어, 모델 교체를 고려하거나 평가 게이트를 구축하는 경우에 공통으로 적용되는 교훈입니다.

• 모델 문제인가? 혹은 하네스의 문제인가? : 모델의 구조상 문제 혹은 파라미터 설정 문제일 수도 있지만 모델 서빙을 둘러싼 스택이 더 정교해져야 할 수도 있습니다.
• 모델 교체 전, 우리가 적절히 검증했는지 검토한다 : 모델 교체를 통해 우리가 얻고 싶은 것은 무엇인지, 혹은 적절한 검증 기준을 통해 확인했는지 생각해봐야 합니다.
• 측정 저하와 품질 저하를 분리한다. : 측정이 잘못됐는지 혹은 실제 응답이 잘못됐는지를 분리할 수 있어야 정확한 개선이 가능합니다.
• 평가게이트는 지속적으로 교정 및 운영되어야 하는 시스템이다.

7. 결론

DLM은 실질적인 지연 시간 이점을 제공하며, 환경에 따라 AR과 같은 수준에 도달할 수 있습니다. 다만 이 이점은 연산 자원의 비용을 동반하게 됩니다. 이런 상황에서 DLM과 AR 모두 프로덕션 적용의 조건은 동일합니다. 달성하려는 목표가 정의되어 있고, 그 목표를 측정할 수 있으며, 측정이 비즈니스 목표를 정확히 반영하는 것입니다. 모델 선택 혹은 교체는 그 이후의 문제입니다. 끝으로 DLM과 관련해서 앞으로 주목해야 할 요소들 세 가지를 소개하며 본 글을 마무리합니다.

첫째, 선택한 DLM은 우리 워크로드에 따라 더 나은 모델로 교체할 수 있으므로, 특정 모델에 종속되지 않는 데이터 파이프라인과 평가 게이트를 설계하는 것이 필요합니다. 특히 연속 확산 모델에 대한 연구들이 지속되고 있기 때문에 추후 모델의 변화를 살펴볼 필요가 있습니다. 그렇지만 모델이 바뀌더라도 비즈니스 목표 기반의 파이프라인이 필요하다는 점은 여전히 바뀌지 않는다는 것을 기억해야 합니다.

둘째, DLM의 “단일 사용자 저지연, 연산 집중적”이라는 특성은 클라우드/플랫폼 레벨의 서빙에서도 충분한 이점이 될 수 있지만 단일 사용자 지연이 지배적인 환경, 예컨대 온디바이스에서 유리할 가능성이 높습니다. 다만 실제 적합성은 비즈니스 목표와 워크로드의 처리량/지연 목표에 따라 검증 후 판단해야 합니다.

마지막으로, DiffusionGemma의 경우 파인 튜닝을 통해 성능을 개선한 예제(스도쿠)와 방법, 결과가 모두 공개되어 있습니다. 이를 통해 디노이징 스텝을 줄이고 정답률도 약 0~1%대에서 80%까지 끌어올렸기 때문에 특정 문제를 풀어야 하는 경우라면 적용해 볼 수 있을 것으로 생각됩니다. 이 경우 앞에서 소개한 SageMaker Training Job을 활용할 수 있습니다.