SenseTime + NTU가 만든, 이미지 이해와 생성을 하나의 모델에서 처리하는 네이티브 멀티모달 모델. 비전 인코더(VE)·VAE를 둘 다 제거하고, 픽셀과 단어를 같은 표현 공간에서 다루는 NEO-Unify 아키텍처. 인포그래픽·교차 텍스트·이미지 편집 모두 한 모델로.
왜 이게 어려운 문제이고, 왜 새로운 접근이 필요했나.
2020년대 초반의 멀티모달 AI는 거의 모두 같은 패턴이었다 — 이해(understanding)용 모델과 생성(generation)용 모델을 따로 만들고, 어댑터로 이어 붙이는 식이다. 예를 들어 GPT-4V는 이미지를 "보고 설명"할 수는 있지만 직접 "그릴" 수는 없어서 DALL-E를 별도로 호출한다. 반대로 Stable Diffusion은 그림은 잘 그리지만 그림을 "이해"하지는 못한다.
이 분리를 없애려는 시도가 unified multimodal model(통합 멀티모달 모델)이다. 한 모델이 "이 그림 뭐야?"라는 질문에 답할 수도 있고, "이런 그림 그려줘"라는 요청에 직접 그림을 출력할 수도 있게 만드는 것. SenseNova-U1이 노리는 자리가 바로 거기다.
그런데 — 단순히 이해 모델과 생성 모델을 한 컨테이너에 묶기만 하면 통합이 아니다. 기존의 통합 시도(Chameleon, Show-o, Janus, Bagel 등)들도 결국 내부적으로는 비전 인코더(VE) + VAE + LLM을 짜깁기한 구조였다. SenseNova-U1은 여기서 한 발 더 나가, "VE도 VAE도 아예 없이 — 픽셀과 단어를 처음부터 같은 표현 공간에서 다루자"는 first principles 접근을 시도한다.
전체 글의 핵심 메시지.
기존 통합 모델은 — 이해용 인코더 + 생성용 디코더를 어댑터로 묶는 식이었다. 양쪽이 서로 다른 표현 공간을 쓰니까, 둘 사이를 번역하는 어댑터가 필연적으로 정보 손실을 만든다.
SenseNova-U1의 NEO-Unify는 "VE도 VAE도 없이 — 같은 트랜스포머가 픽셀도 단어도 같은 공간에서 처리"한다. 그 결과 인포그래픽처럼 텍스트와 그림이 빽빽한 이미지를 생성할 수 있고, 그림을 보고 이해한 다음 바로 편집된 새 그림을 출력하는 식의 작업이 한 모델에서 자연스럽게 나온다.
TrendShift 5위까지 올라온 맥락.
2026년 멀티모달 AI의 화두는 "separate-and-glue 시대를 끝낼 후보"다. 분리된 이해/생성 모델을 어댑터로 묶는 방식이 한계에 부딪히고 있다는 인식이 업계 전반에 깔려 있다. SenseNova-U1은 이 흐름에서 가장 과감한 제안 — VE·VAE를 둘 다 제거 — 을 들고 나온 오픈소스 후보다.
이해 모델(LLaVA류)과 생성 모델(SDXL류)을 따로 학습하고 어댑터로 연결하면 — 어댑터 학습 단계에서 의미와 픽셀 디테일 양쪽이 모두 깎인다. "그림을 보고 똑같이 다시 그려달라"고 하면 비슷한 그림이 나올 뿐, 같은 그림은 안 나온다.
이해도 생성도 같은 트랜스포머 백본의 hidden state에서 일어난다. "입력 픽셀 → 모델 표현 → 출력 픽셀"의 모든 단계가 학습 가능한 한 경로. NEO-Unify 블로그에 따르면 2B 크기에서 PSNR 31.56 / SSIM 0.85로 Flux VAE(32.65 / 0.91)에 근접 — 별도 VAE 없이도 픽셀 충실도가 잡힌다.
한 백본에 이해와 생성을 같이 학습시키면 두 손실 함수가 서로 끌어당겨서 어느 쪽도 SOTA가 안 된다는 게 통설이었다. 그래서 Chameleon 같은 초기 통합 모델도 어느 쪽에선가는 SOTA를 양보해야 했다.
Mixture of Transformers 구조로 — 같은 백본을 공유하되 모달리티별 전문가 파라미터를 분리. NEO-Unify 보고에 따르면 "낮은 데이터 비율과 손실 가중치로도 이해 성능은 유지되면서 생성은 더 빠르게 수렴" → 두 모달리티가 충돌이 아니라 공진화(co-evolve).
DALL-E·Midjourney·SDXL 모두 "한 문장 짧은 설명 → 한 장의 예술적 그림"은 잘하지만, 30줄짜리 표가 들어간 인포그래픽, 한자가 빽빽한 포스터, 수식이 들어간 다이어그램은 못 그린다. 글자가 깨지고, 표가 어그러지고, 레이아웃이 무너진다.
학습 데이터부터 인포그래픽·이력서·포스터·만화·발표 슬라이드를 의도적으로 포함. 공식 README의 데모를 보면 한자/영문이 섞인 가로 16:9 인포그래픽을 한 번에 생성한다. BizGenEval·IGenBench 같은 인포그래픽 벤치에서 오픈소스 SOTA를 주장.
"여행 일기 작성해줘 — 각 날짜마다 사진 한 장씩"이라고 요청하면 기존 시스템은 LLM → 이미지 모델로 따로따로 호출해야 한다. 일관된 캐릭터·스타일 유지가 어렵고, 텍스트와 그림이 따로 논다.
한 모델이 한 번의 forward로 텍스트 → 이미지 → 텍스트 → 이미지를 순서대로 생성. README의 예시 명령 examples/interleave/inference.py — "토마토 계란 볶음 만드는 법, 단계마다 그림 포함"이라고 입력하면 일러스트 튜토리얼이 한 흐름으로 나온다.
핵심 설계 패턴 — 왜 VE도 VAE도 빼는 게 가능한가.
먼저 큰 그림. 기존 통합 모델과 NEO-Unify의 흐름 차이를 보자.
입력 이미지를 CLIP 같은 인코더에 통과시키지 않고, raw 픽셀 패치를 직접 토큰화한다. 이것을 NEO-Unify에선 "near-lossless interface"라고 부르는데 — 사전학습된 인코더가 만든 "의미만 살아남은" 표현이 아니라 원본 픽셀 정보가 거의 그대로 보존된다는 뜻.
출력도 마찬가지. VAE latent로 가지 않고 픽셀 공간에서 직접 flow matching으로 생성한다. NEO-Unify 보고서는 2B 모델 기준 90K step 사전학습으로 PSNR 31.56을 찍었다 — Flux VAE의 32.65에 근접한 수치다.
같은 트랜스포머 백본(Qwen3 기반)을 이해와 생성이 공유하되, FFN(피드포워드) 레이어 일부를 모달리티별로 분리한다. 이해 토큰이 흘러올 때는 "understanding expert" FFN으로, 생성 토큰이 흘러올 때는 "generation expert" FFN으로 라우팅.
장점은 두 가지. ① attention 레이어는 공유되므로 모달리티 간 정보가 자연스럽게 섞임. ② FFN은 분리되어 모달리티별 특화 가능 → 손실 충돌 최소화. 결과: 이해 성능 유지 + 생성 빠른 수렴.
같은 백본에서 두 가지 종류의 손실을 동시에 흘려보낸다.
흥미로운 점은 한 모델이 한 step에서 이 두 목표를 같이 본다는 것. 텍스트 출력엔 logit + cross-entropy, 비전 출력엔 velocity prediction + MSE를 동시에 계산. MoT가 모달리티별로 라우팅하므로 가능한 구조다.
README와 학습 파이프라인을 정리하면 다음 5단계로 진행된다.
| 단계 | 이름 | 목적 |
|---|---|---|
| 1 | Understanding Warmup | 이해 경로만 먼저 학습. 시각 입력을 raw 픽셀로 받아 텍스트 출력하는 패턴 안정화 |
| 2 | Generation Pre-training | 생성 경로 사전학습. T2I(text-to-image) 대규모 데이터로 픽셀 flow matching 학습 |
| 3 | Unified Mid-training | 두 경로를 같은 백본에서 동시 학습 — MoT FFN이 모달리티별로 분화되는 핵심 단계 |
| 4 | Unified SFT | 고품질 지시 데이터로 지도학습 — interleaved generation·editing 등 복합 태스크 포함 |
| 5 | T2I RL | 강화학습으로 이미지 생성 품질 미세조정 — 선호도 데이터 기반 |
현재 공개된 모델은 SFT 4단계까지 완료한 SFT 모델과 5단계 RL까지 진행한 최종 모델 두 종류로 나뉜다. RL이 T2I에만 적용됐기 때문에 편집·추론·interleaved 영역에선 SFT 모델과 최종 모델 성능 차이가 크지 않다는 게 README의 솔직한 고백.
pyproject.toml과 deployment 문서에서 발췌.
pyproject.toml은 torch==2.8.0, torchvision==0.23.0을 정확히 핀(pin)한다. 사전학습 체크포인트가 비트-정확하게 재현되도록 — "동일 환경에서 학습된 모델은 동일 환경에서 추론"이라는 원칙. uv source가 PyTorch cu128 인덱스를 명시적으로 지정해서 uv sync 한 번에 환경 복원.
Hugging Face Transformers를 베이스로 NEO-Unify 모델 코드가 src/sensenova_u1/models/neo_unify/에 들어 있다. Qwen3 기반 백본을 가져와 MoT를 얹은 구조 — modeling_qwen3.py를 보면 attention은 그대로 두고 FFN을 모달리티별로 분기.
flash-attention 2.8.3 (CUDA 12.8용 cp311 wheel)로 attention을 가속. 없으면 torch SDPA로 자동 폴백해서 일반 사용자도 쓸 수 있게 했다. README 권장 추론 환경(LightLLM + LightX2V)에선 FA3 기반 hybrid-mask attention으로 prefill 2.4~3.2× 빠르다.
전통적 pip + venv 대신 uv(Astral의 차세대 Python 패키지 매니저)를 사용. uv sync 한 번으로 락파일(uv.lock) 기반의 완전 재현 환경을 구성. pip보다 10~100배 빠른 설치가 장점.
이해(VQA·텍스트 출력) 경로를 담당하는 LLM 추론 엔진. ModelTC가 만든 오픈소스로, vLLM 계열의 PagedAttention 같은 최적화를 적용해 처리량을 높인다. SenseNova-U1에선 텍스트 생성 부분만 LightLLM에 위임.
이미지 생성 경로 전용 추론 엔진. flow matching ODE solver, CFG, 멀티스텝 샘플링을 GPU에서 최적화. 이해 엔진과 생성 엔진을 분리(disaggregated)한 게 SenseNova-U1의 서빙 아키텍처 핵심 — 각 경로가 자체 병렬화 전략과 자원 예산을 가진다.
공식 이미지 lightx2v/lightllm_lightx2v:20260407를 docker pull 하면 LightLLM + LightX2V + SenseNova-U1이 한 컨테이너에 들어 있다. H100/H200 단일 노드에서 TP2 + CFG2 설정 시 2048×2048 이미지 한 장에 약 9초, step당 0.15초.
evaluation/easi/ 디렉토리에 EASI(Evaluation Agent for Synthetic Image) 벤치 코드를 서브모듈로 포함. T2I 품질을 자동으로 평가하는 에이전트 기반 벤치 — 사람이 일일이 보지 않아도 OneIG·LongText·CVTG·BizGenEval·IGenBench를 한 번에 돌릴 수 있다.
README의 차트에 따르면 SenseNova-U1은 8B/A3B 크기에서 — 이해 벤치에서 동급 LLaVA·InternVL과 어깨를 나란히, 생성 벤치에서 SD3·Flux와 비슷, 인포그래픽 전문 벤치에선 오픈소스 최고. 동급 상용 모델과 비슷한 성능을 더 작은 모델로 달성한 것이 강조 포인트.
주요 폴더와 파일의 역할.
처음 코드베이스를 열면 두 곳을 먼저 봐야 한다.
vqa, t2i, editing, interleave가 각각 독립 스크립트. 각 폴더 안에 inference.py가 있어서 한 줄 명령으로 돌려볼 수 있다. "먼저 vqa 돌려보고 → t2i 한 장 만들고 → editing 해보고 → interleave로 튜토리얼 생성" 순서가 학습 동선.
아키텍처를 직접 보고 싶을 때. modeling_qwen3.py가 핵심 — Qwen3 기반 백본에 MoT FFN과 flow matching head를 추가한 구조. ruff lint 제외 폴더로 지정돼 있어서 "손대지 말 것"이라는 시그널이지만, 읽고 이해하는 건 환영.
이 레포에서 무엇을 배울 수 있는가.
"인코더 없이 raw 픽셀을 직접 트랜스포머에 넣는다"는 발상은 한때 비효율적이라 여겨졌다. 이 레포는 그 통념을 깬다. docs/inference_infra.md와 NEO-Unify 블로그를 같이 읽으면 — 왜 이게 작동하는지, 어떤 트레이드오프가 있는지 감을 잡을 수 있다.
실습 아이디어: 작은 비전 트랜스포머(ViT) 코드에서 CLIP 인코더 부분을 제거하고 raw patch embedding만으로 분류 태스크가 학습되는지 실험해보기.
MoE는 익숙해도 MoT는 비교적 새로운 개념. src/sensenova_u1/models/neo_unify/modeling_qwen3.py에서 FFN 분기 로직을 직접 읽어보면 — "같은 attention, 다른 FFN"이라는 단순한 아이디어가 어떻게 구현됐는지 명확해진다.
실습 아이디어: 작은 LLM 한 개를 가져와 FFN 레이어를 두 개로 복제하고, 입력 토큰의 modality 플래그에 따라 라우팅하는 미니 MoT를 만들어보기.
SD 1.5/2.0 시대에 익숙해진 1000-step denoising 패러다임이, SD3·Flux·SenseNova-U1에선 50-step velocity prediction으로 바뀐다. README의 추론 명령에 --num_steps 50 --timestep_shift 3.0이 보이는데 — 이게 flow matching ODE 적분 설정이다.
실습 아이디어: Flow Matching 논문(Lipman et al., 2023)을 읽고 미니 MNIST 생성기를 250줄로 구현. Diffusion 버전과 학습 속도/품질 비교.
LightLLM + LightX2V로 두 추론 엔진을 분리하는 패턴은 최근 LLM 서빙 트렌드다. Prefill과 decode를 분리하는 vLLM의 disaggregated serving과 같은 맥락. docs/inference_infra.md가 왜 분리가 처리량에 유리한지 설명한다.
실습 아이디어: 단순 vLLM 서버 두 개를 띄우고, 하나는 텍스트 LLM, 하나는 임베딩 모델로 분담시키는 mini-disaggregated 서빙을 docker-compose로 구성.
pyproject.toml의 주석을 읽어보면 — flash-attn은 CUDA 버전별로 wheel이 다르므로 PyPI에서 못 받고 사용자가 직접 .whl을 설치하라고 명시. 없으면 SDPA로 폴백. "성능 최대화 vs 누구나 돌릴 수 있게"를 어떻게 양립시키는지 좋은 예시다.
전통적 ML 레포는 requirements.txt에 torch>=1.10 식으로 느슨하게 핀. 그러다 보니 "어제 되던 게 오늘 안 된다"가 일상. SenseNova-U1은 완전 핀(torch==2.8.0) + uv lockfile + cu128 인덱스 명시로 환경 드리프트를 차단.
실습 아이디어: 자기 프로젝트의 requirements.txt를 uv로 마이그레이션. uv init → uv add → uv sync 흐름을 익히면 ML 환경 관리가 한결 편해진다.
실제로 돌리려면 뭐가 필요한가.
| 항목 | 최소 | 권장 (8B 모델) | 권장 (production) |
|---|---|---|---|
| GPU | RTX 3090 (24GB) | A100 80GB | H100 / H200 |
| GPU 메모리 | ≥ 24GB | ≥ 40GB | ≥ 80GB |
| CUDA | 12.6 | 12.8 | 12.8 |
| Python | 3.11 | 3.11 | 3.11 |
| OS | Linux | Linux | Linux (Docker) |
| 디스크 | 50GB | 100GB | 200GB+ |
8B-MoT는 fp16 기준 16GB의 weights + KV cache + flow matching 중간 텐서를 더하면 실질적으로 24GB+ 가용 GPU 메모리가 필요. 3090(24GB)에서 동작 가능하지만 큰 해상도(2048×2048) 생성은 OOM 위험. A3B(MoE) 모델은 활성 파라미터만 3B 수준이므로 더 가볍게 돌아간다 — 메모리 한정 환경에선 A3B 우선.
로컬에 GPU가 없으면 https://unify.light-ai.top/ — 공식 무료 플레이그라운드. GPU 없이 브라우저에서 바로 인포그래픽 생성 가능. 대규모 실험은 클라우드 H100을 시간 단위로 빌리는 게 현실적이다.
난이도별 5단계.
설치 없이 — unify.light-ai.top에서 README 예제 프롬프트(SenseNova-U1 소개 인포그래픽)를 그대로 붙여넣고 결과 비교. "왜 일반 DALL-E와 결과가 다른가"를 글로 정리해보면 NEO-Unify의 차별점이 체감된다.
레포 클론 → uv sync → 가벼운 VQA 예제 실행. GPU가 없으면 --device cpu로 동작하는지 확인 (단, 매우 느림). 목적은 "의존성 핀과 lockfile이 실제로 어떻게 환경을 재현하는가"를 손으로 체험.
같은 모델로 "텍스트 → 이미지 생성 → 그 이미지를 다시 입력으로 편집" 흐름을 Python 스크립트 한 개로 묶어보기. 일반적인 분리형 파이프라인(SD + InstructPix2Pix)과 비교하면 — 모델 로딩 한 번으로 두 작업이 끝난다는 장점이 체감된다.
src/sensenova_u1/models/neo_unify/modeling_qwen3.py를 읽으며 — ① 어떤 시점에 modality flag가 결정되는가, ② FFN expert가 어떻게 선택되는가, ③ attention은 어떻게 두 모달리티를 섞는가를 주석으로 따라가며 정리. 결과를 자기 블로그에 "NEO-Unify 코드 리딩" 글로 정리하면 학습 강화.
"한 줄 주제 → 자동으로 인포그래픽 PNG"를 만드는 미니 서비스 구축. 1) GPT-4/Claude로 인포그래픽 구조(섹션·아이콘·배치)를 JSON으로 설계, 2) docs/prompt_enhancement.md의 베스트 프랙티스로 프롬프트 확장, 3) SenseNova-U1로 생성. 결과를 자기 Notion 페이지에 자동 게시까지 연결하면 실용 도구가 된다.
8주 코스로 구성.
① "Attention Is All You Need" 논문 + The Illustrated Transformer 블로그.
② CLIP 논문 + huggingface CLIP 사용 실습.
③ ViT(Vision Transformer) 논문 — "이미지를 patch로 잘라서 시퀀스로" 패턴 이해.
① DDPM 논문(Ho et al., 2020) + diffusers 라이브러리로 미니 생성기.
② Stable Diffusion 1.5 / SDXL 구조 분석 (UNet + VAE + Text Encoder).
③ Flow Matching 논문(Lipman et al., 2023) + SD3 기술보고서 — 패러다임 전환 이해.
① Chameleon(Meta, 2024) — early-fusion 통합 모델 원조.
② Show-o, Janus, Bagel — VE+VAE 기반 통합 모델 계보.
③ NEO-Unify(SenseNova, 2026) 블로그 정독 — 왜 VE/VAE를 빼는 게 가능한가.
① Mixtral 8x7B + Switch Transformer 논문 — MoE 기본기.
② DeepSeek-V2/V3 MoE 구조.
③ SenseNova-U1의 MoT 코드 직접 읽기 — "FFN만 분기"가 어떻게 충돌을 줄이는지.
① FlashAttention 2/3 논문.
② vLLM PagedAttention 블로그.
③ LightLLM + LightX2V 도커로 띄우고 처리량 측정 — "왜 disaggregated가 더 빠른가"를 직접 벤치.
SenseNova-U1 + Streamlit/Next.js로 인포그래픽 자동 생성 웹 도구. 6주차의 MoT 이해를 기반으로 — 한자/한글이 섞인 인포그래픽에서 텍스트 깨짐을 줄이는 프롬프트 패턴을 자체 데이터셋으로 정리.
레포 안에서 자주 만나는 용어 모음.
--cfg_scale 4.0 같은 인자로 제어. 값이 높으면 프롬프트 충실, 너무 높으면 부자연스러운 디테일.uv sync를 기본 환경 구성 명령으로 채택.github.com/OpenSenseNova/SenseNova-Skills.더 깊이 파고들 때 볼 자료.
github.com/OpenSenseNova/SenseNova-U1huggingface.co/blog/sensenova/neo-unify — 아키텍처 핵심 아이디어와 실험 결과unify.light-ai.topgithub.com/OpenSenseNova/SenseNova-Skillsgithub.com/ModelTC/lightllmgithub.com/ModelTC/lightx2vgithub.com/astral-sh/uvunify.light-ai.top에 들어가 README의 인포그래픽 프롬프트 한 개를 그대로 붙여넣고 결과를 받아본다. 같은 프롬프트를 DALL-E/Midjourney에도 넣어 비교.uv sync 시도. GPU가 있으면 examples/t2i/inference.py로 첫 생성. 없으면 examples/ 폴더의 코드만 읽어도 좋다.src/sensenova_u1/models/neo_unify/modeling_qwen3.py를 열고 MoT FFN 라우팅 부분을 주석을 달며 읽는다.