SenseNova-U1.5-8B-MoT 리뷰

그림을 만드는 것과 고치는 것을 한 모델이 다 한다는 물건을 찾고 있었습니다. 저희는 지금 만드는 쪽과 고치는 쪽에 서로 다른 모델을 쓰는데, 그때마다 24GB짜리 카드에 이걸 올렸다 저걸 올렸다 합니다.

SenseNova-U1.5-8B-MoT가 그렇다고 해서 열어봤습니다. 이름에 8B가 붙어 있으니 bf16¹이면 16GB쯤이겠거니 했어요.

받기 전에 model.safetensors.index.json부터 열어봤습니다. 여기 total_size가 적혀 있습니다.

total_size = 35,065,708,928 — 35.07GB / 32.66GiB

model.safetensors.index.json 의 텐서 1,116개 이름을 짝지어 본 것입니다.

텐서 이름을 세어보니 가중치가 두 벌이었습니다

index 파일에는 텐서가 1,116개 들어 있어요. 이름을 훑는데 같은 게 두 번씩 보였습니다.

q_proj.weight 옆에 q_proj_mot_gen.weight가 있고, mlp.gate_proj.weight 옆에 mlp_mot_gen.gate_proj.weight가 있습니다. layernorm까지 두 벌입니다. layer² 42개 전부 그렇습니다.

config.json의 값으로 한 갈래만 세봤습니다. hidden 4096, intermediate 12288, KV head 8개.

• layer 하나: 192,937,984개
• layer 42개: 8,103,395,328개 → 8.10B

이름의 8B가 여기서 나온 겁니다. 한 갈래만 센 숫자입니다. 두 갈래에 embedding과 lm_head를 더하면 17.45B이고 bf16으로 34.90GB입니다. 실제 파일 35.07GB와 0.16GB 차이인데 vision 쪽과 fm head, norm이 그 몫입니다.

계산해놓고 저장소 README를 더 내려보니 이렇게 적어뒀더군요.

SenseNova-U1-8B-MoT의 8B-MoT는 이해 파라미터 약 8B 와 생성 파라미터 약 8B를 뜻합니다.

숨긴 건 아니었습니다. 다만 모델 카드에는 이 문장이 없고 파일 크기도 안 적혀 있습니다.

MoT는 이해용 한 벌, 생성용 한 벌

같은 모양의 갈래가 두 벌 있고 같은 길 위에 나란히 놓입니다. 하나는 이해용, 하나는 생성용입니다.

MoT가 뭔지는 모델 카드에 안 나옵니다. NEO-unify³ 블로그에 풀어놨더군요. Mixture-of-Transformer입니다.

MoE⁴와 헷갈리기 쉬운데 다릅니다. MoE는 여러 조각 중 몇 개만 골라 켜서 계산량을 줄이는 구조예요. MoT는 이해용 한 벌과 생성용 한 벌을 통째로 따로 두고 둘 다 씁니다. 줄이는 게 아니라 늘리는 쪽이에요.

블로그에는 왜 이렇게 했는지도 적혀 있었습니다. 두 갈래를 같은 데이터로 함께 학습시켰더니 데이터 비율과 손실 가중치가 낮아도 이해는 안정적으로 유지되고 생성은 더 빨리 수렴했다고 합니다. 한 벌에 두 일을 시키면 서로 싸우는데, 두 벌로 나눠두니 충돌이 거의 없었다는 겁니다.

VAE를 없앴다는 대목이 제일 재미있었습니다

보통 그림 모델은 이미지를 이렇게 눌렀다가 다시 폅니다. NEO-unify는 이 단계를 아예 없앴습니다.

보통 그림 만드는 모델은 VAE⁵를 씁니다. 이미지를 작게 눌러 뒀다가 다시 펴는 부품이에요. 저희가 쓰는 것들도 그렇습니다.

NEO-unify는 그걸 없앴다고 합니다. 보는 쪽 encoder도, 만드는 쪽 VAE도 안 쓰고 픽셀을 곧장 다룬다고요. 그러면 눌렀다 펴는 과정에서 잃는 게 없으니 좋을 것 같은데, 대신 잘 안 될 수도 있잖아요. 그래서 숫자를 찾아봤습니다.

MS COCO 2017에서 이미지를 다시 만들어낸 값입니다.

• NEO-unify (2B), 사전 학습 90K 스텝: PSNR⁶ 31.56 · SSIM 0.85
• Flux VAE: 32.65 · 0.91

졌습니다. 다만 상대는 그 일만 하려고 따로 학습된 부품이고, 이쪽은 encoder 없이 통째로 배운 모델이에요. 그 차이를 생각하면 1.09 차이는 꽤 붙은 편이라고 봅니다.

편집도 재봤는데, 이해 갈래를 얼려둔 채로 ImgEdit에서 3.32점이 나왔다고 합니다. 이해 쪽을 안 건드려도 생성 갈래만으로 편집이 됐다는 뜻입니다.

24GB 카드용 스위치가 이미 달려 있었습니다

파일은 35GB, 카드는 24GB입니다. 11GB가 모자라서 그냥은 안 들어갑니다.

저희 관심사는 이겁니다. 3090은 24GB인데 파일은 35GB입니다. 6GB 모자라서 고생한 적이 있는데 여기는 11GB가 모자랍니다.

저장소를 뒤져보니 --vram_mode라는 게 있더군요.

• full — 전부 GPU에 올림. VRAM 넉넉할 때
• fast — 미리 가져다 두고 생성 layer를 예산 안에서 붙잡아 둠. 24GB급 GPU 권장
• low — layer마다 CPU와 GPU 사이를 오감. VRAM 최소
• balanced — 미리 가져오기를 계산과 겹침. 빠듯한데 속도도 원할 때

fast는 VRAM의 90%를 예산으로 잡고 여유 2GiB, 활성값 예비 4GiB를 둡니다. 24GB에서 대략 예산 19.4GB에 나머지가 여유인 셈입니다.

여기에 Q8 GGUF⁷가 21.2GB로 나와 있습니다. 커뮤니티에서 만든 것이고 9월 1일에 올라왔습니다. 저장소는 Q4 GGUF에 balanced를 묶는 게 10~12GB급 카드에 권장이라고 적어뒀습니다.

그러니까 24GB에서 35GB 모델을 돌리는 방법이 이미 문서에 있습니다. 저희가 전에 손으로 해결하려던 걸 만든 쪽에서 스위치로 만들어둔 겁니다.

이야기하는 사람이 거의 없습니다

해커뉴스 글 네 개가 1점, 2점, 3점, 4점이었습니다. 댓글은 다 합쳐 두 개입니다.

찾다가 이상했던 게 이겁니다. 해커뉴스에 관련 글이 네 개 올라왔는데 점수가 1점, 2점, 3점, 4점이었어요. 댓글은 다 합쳐 두 개입니다.

NEO-unify 블로그는 추천 180개를 받았는데 댓글이 여섯 개입니다. 그중 하나가 stablellama의 질문이었어요.

여러 캐릭터를 섞으면서 서로 번지지 않게, 각자의 고유한 특징을 지키게 하는 건 지금 모델들로는 아주 어렵습니다. NEO-unify가 여기서 유리할 거라고 보시나요?

답이 안 달렸습니다. 저도 궁금한 질문이라 좀 아쉬웠어요.

허깅페이스 내려받기는 7,807회, 좋아요 211개입니다. 조용한 편이지만 아무도 안 쓰는 건 아니에요.

저희한테 쓸모가 있나

써볼 만하다고 봅니다. 이유가 둘입니다.

첫째, 만드는 모델과 고치는 모델을 바꿔 끼우는 일이 없어집니다. 지금은 배너를 만들고 문구를 고치려면 다른 모델을 올려야 하는데, 카드에 35GB짜리 하나만 올려두면 되는 그림이라면 왕복이 사라집니다.

둘째, --vram_mode fast가 24GB를 콕 집어 적어뒀습니다. 만든 쪽이 우리 크기의 카드를 염두에 두고 만들었다는 뜻입니다.

다만 저장소가 스스로 적어둔 한계가 저희 일과 정면으로 겹칩니다. 작은 얼굴과 손이 불안정하고, 빽빽하고 작은 글자에 오류가 나고, 제약이 많은 레이아웃에서 개수와 정렬이 어긋날 수 있다고 합니다. 저희가 만드는 게 대개 글자 들어간 배너라서 하필 그쪽입니다.

받아서 돌려봐야 알 것 같습니다. 105GB짜리를 받는 것보다는 나은 조건이라 이건 한번 해보려고 합니다.