InternVL-U 4B가 일부 생성, 편집 평가에서 더 큰 모델보다 나을 수는 있지만, 모든 이해, 추론 과제에서 14B를 대체한다고 볼 수는 없습니다.
논문 2603.09877은 이해, 추론, 생성, 편집을 한 Model에서 다루되 시각 표현을 하나의 가중치 공간에 억지로 합치지 않습니다. 이해를 담당하는 MLLM과 생성을 담당하는 MMDiT Head를 분리하고 Text Reasoning을 두 모듈 사이의 계획으로 사용합니다. Parameter 수보다 책임 분리가 핵심인 설계입니다.
Image에서 Chart 수치를 읽는 표현은 의미 구분에 강해야 하고, Image를 그리는 표현은 Texture와 Pixel 구조를 복원해야 합니다. 같은 Latent와 Objective에 두 역할을 몰아넣으면 한 Task를 개선할 때 다른 Task가 약해질 수 있습니다.
InternVL-U는 MLLM이 Image와 Text를 이해하고 Reasoning하도록 두고, MMDiT 기반 Head가 실제 생성을 담당합니다. Modular한 경계가 있으면 각 부분의 입력과 출력을 따로 평가할 수 있습니다. 반대로 두 Module을 연결하는 Projector와 학습 정렬이 잘못되면 의미는 맞지만 Image에 반영되지 않는 새로운 실패가 생깁니다.
복잡한 Text Rendering이나 과학적 편집 요청에서 바로 Pixel로 가지 않고, 먼저 무엇을 어디에 어떻게 바꿀지 Text로 계획합니다. 이 중간 표현은 사용자의 의도와 생성 조건을 연결하는 역할을 합니다.
Chain-of-Thought가 길거나 그럴듯하다고 Image가 정확해지는 것은 아닙니다. 잘못된 계획은 생성 Head에 더 명시적으로 전달될 수 있고, 최종 Image가 계획을 지켰는지 별도 검증이 필요합니다. 계획 내용, 편집 Mask, 결과 Image를 나란히 비교할 수 있어야 Reasoning 단계가 실제로 기여했는지 알 수 있습니다.
원문은 InternVL-U가 Parameter가 세 배 이상 큰 14B 계열 Model보다 생성과 편집 Task에서 일관되게 좋은 결과를 보였다고 설명합니다. 이는 해당 Benchmark와 학습 데이터의 비교이며 Model 크기만으로 전체 성능 순위를 정하는 근거는 아닙니다.
고밀도 합성 데이터는 Text Rendering과 추론 기반 편집의 간극을 줄이는 데 기여합니다. 그러나 합성 데이터의 문구, Layout, Style 분포가 실제 사용자 요청과 다르면 성능이 이동할 수 있습니다. 이해, 생성, 편집, Text 정확도와 안전성을 각각 분리해 비교해야 합니다.
원문 표는 약 10~12GB와 소비자 GPU 사용 가능성을 제시하지만, Parameter 수만으로 Peak VRAM을 확정할 수 없습니다. Weight Precision, Image Resolution, Diffusion Step, KV Cache, Batch, MLLM과 MMDiT를 동시에 올리는지에 따라 달라집니다. 연속 편집에서는 중간 Tensor와 Cache가 누적될 수도 있습니다.
vLLM 같은 Text Serving Engine과 Generation Head의 호환도 자동으로 주어지지 않습니다. Cold Start, Module별 Loading, 한 요청이 이해에서 생성으로 넘어갈 때의 Scheduling을 측정해야 합니다. 작은 Model이라는 장점은 실제 Checkpoint와 Runtime이 특정 Hardware에서 안정적으로 동작할 때 의미가 있습니다.
하나의 Test Set에서 다음 흐름을 따로 측정합니다.
먼저 필요한 기능 하나를 기존 Pipeline과 비교하고, 통합으로 줄어든 운영 복잡도가 품질 손해보다 큰지 봅니다. Paper ID 2603.09877의 의미는 “4B가 14B를 박살냈다”는 구호보다 서로 충돌하는 시각 역할을 분리하면서 하나의 사용자 흐름으로 묶는 방법을 제시했다는 데 있습니다.
MLLM이 “왼쪽 표의 제목만 바꾼다”는 계획을 올바르게 만들었어도 생성 헤드가 대상 영역을 잘못 찾을 수 있습니다. 반대로 최종 이미지는 그럴듯하지만 계획에 없던 배경이나 객체를 함께 바꿀 수 있습니다. 이해 오류, 계획 오류, 모듈 전달 오류, 생성 오류를 분리해야 어느 부분을 개선할지 알 수 있습니다.
같은 입력에서 정답 계획을 사람이 제공한 조건과 모델 계획을 사용한 조건을 비교할 수 있습니다. 정답 계획에서도 이미지가 틀리면 생성, 연결 쪽이 병목이고, 정답 계획에서는 성공하지만 모델 계획에서 실패하면 이해, 추론이 병목입니다. 두 모듈을 통합했다는 사실만으로 끝단 오류의 원인이 하나가 되는 것은 아닙니다.
편집 요청은 바꿀 영역과 바꾸지 말아야 할 영역을 함께 정의합니다. 대상 객체의 색을 바꾸면서 얼굴, 배경 글자, 구도와 조명이 얼마나 유지됐는지 봅니다. 마스크가 제공되지 않는 자연어 편집이라면 모델이 선택한 영역과 사람이 의도한 영역의 차이도 평가해야 합니다.
연속 편집에서는 첫 결과를 다시 입력으로 넣을 때 품질과 정체성이 누적해서 무너질 수 있습니다. 한 번의 편집, 세 번의 연속 편집, 원본으로 되돌리는 요청을 나눠 시험합니다. 생성 품질 평균이 높아도 보존해야 할 영역을 자주 바꾸면 실제 편집 도구로 쓰기 어렵습니다.
같은 프롬프트와 이미지, 해상도, 생성 횟수, 평가 기준을 사용합니다. 큰 모델은 이해에 강하고 작은 통합 모델은 생성에 강할 수 있으므로 종합 순위보다 작업별 표를 만듭니다. 두 모델의 학습 데이터와 추론 단계가 다르다면 파라미터 수만으로 효율을 설명하지 않습니다.
비용 비교에는 모델 파일 크기 외에 이미지 인코딩, reasoning token, diffusion step, 동시 요청 처리량을 포함합니다. 작은 모델이 요청당 단계가 많아 전체 지연은 길 수 있고, 반대로 모듈을 한 서비스로 묶어 데이터 이동을 줄일 수도 있습니다. 실제 워크플로의 끝단 시간과 최대 메모리가 판단 기준입니다.
한 이미지에 질문하고 그 답을 바탕으로 즉시 편집하는 흐름은 이해와 생성이 자주 오가므로 통합의 이점이 있을 수 있습니다. 반면 읽기 전용 문서 QA나 대량 이미지 생성처럼 한 기능만 쓰는 업무에서는 전문 모델이 더 단순할 수 있습니다. 필요한 기능 수보다 기능 사이의 전달 오류와 운영 비용이 줄어드는지를 봐야 합니다.
라우팅 실험으로 이해만 필요한 요청, 생성만 필요한 요청, 두 기능을 이어야 하는 요청을 나눕니다. 사용하지 않는 모듈까지 항상 메모리에 올리는지와 요청별 로딩 비용을 확인합니다. 통합 체크포인트 하나가 배포 구성까지 하나로 만든다고 가정하면 안 됩니다.
먼저 이해, 생성, 편집의 독립 기준선을 만듭니다. 다음으로 사람이 만든 올바른 계획을 넣어 모듈 연결을 확인하고, 마지막에 모델이 직접 계획하는 끝단 흐름을 평가합니다. 각 단계에서 오류 사례와 VRAM, 지연을 저장하면 통합으로 새로 생긴 실패를 찾을 수 있습니다.
자체 데이터에는 작은 글자, 표, 여러 객체, 바꾸지 말아야 할 영역과 반복 편집을 포함합니다. 공개 체크포인트와 실행 코드가 실제로 제공하는 기능과 라이선스를 확인한 뒤 필요한 한 기능부터 비교합니다. 모든 기능을 한 번에 도입하는 것보다 병목을 확인하며 범위를 넓히는 편이 안전합니다.
그렇게 볼 수 없습니다. 원문의 우위는 특정 생성, 편집 평가 조건에서 보고된 것이며 이해, 추론, 안전성과 실제 사용자 작업은 과제별로 다시 비교해야 합니다.
보장되지 않습니다. 계획이 생성 헤드에 잘 전달되지 않거나 최종 이미지가 좌표, 문자열을 지키지 않을 수 있으므로 계획과 결과를 별도로 평가해야 합니다.
항상 그렇지는 않습니다. 정밀도, 해상도, diffusion step, KV cache, batch와 두 모듈의 동시 로딩 방식에 따라 최대 VRAM이 달라집니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.