논문이 제시한 기기와 해상도에서는 가능합니다. Mobile-O는 경량 VLM과 선형 Diffusion Transformer를 하나로 합쳐 iPhone 17 Pro에서 512×512 이미지를 약 3초에 생성했지만, 이 수치를 모든 휴대전화의 보장값으로 볼 수는 없습니다.
논문과 프로젝트 페이지는 이미지 질문에 답하는 이해 기능과 텍스트로 이미지를 만드는 생성 기능을 단일 온디바이스 모델에 넣는 방법을 설명합니다. 핵심은 두 모델을 단순히 붙이는 것이 아니라, 이해 모델이 가진 중간 표현을 생성 모델이 적은 비용으로 쓰게 하는 연결부입니다.
Mobile Conditioning Projector, 즉 MCP는 VLM의 여러 레이어에 있는 hidden state를 가중 결합해 DiT의 조건 신호로 바꿉니다. 중간 query token을 별도로 만들지 않고 depthwise separable convolution과 channel attention을 사용해 계산량을 낮춥니다.
VLM은 이미지의 대상과 관계를 언어 공간에서 이해하고, 경량 DiT와 VAE는 그 정보를 이미지로 만듭니다. MCP는 이해에서 얻은 표현을 버렸다가 다시 계산하지 않게 연결합니다. 이 구조가 중요한 이유는 모델 두 개의 기능을 갖는 것보다 모바일 NPU가 처리할 수 있는 연산 형태로 결합하는 데 있습니다.
MCP가 유용한지는 연결부의 파라미터 수만으로 판단하기 어렵습니다. VLM의 여러 레이어를 읽는 과정에서 중간 텐서를 오래 보관하면 peak memory가 늘 수 있고, 연산자가 목표 NPU에서 지원되지 않으면 CPU나 GPU로 넘어가 지연이 커질 수 있습니다. 논문의 연산량 감소와 실제 앱의 메모리 이동 비용을 분리해 측정해야 합니다.
어느 VLM 레이어를 얼마나 섞는지도 생성 결과에 영향을 줄 수 있습니다. 낮은 레이어는 질감과 위치 정보를 더 보존하고 높은 레이어는 의미 관계를 더 압축할 수 있으므로, 한쪽에 치우치면 이미지 구도나 프롬프트 충실도가 달라질 수 있습니다. MCP를 제거한 조건, 마지막 레이어만 쓰는 조건, 여러 레이어를 결합한 조건을 같은 DiT에서 비교하면 연결 구조 자체의 기여를 좁힐 수 있습니다.
이해와 생성을 한 앱에서 번갈아 쓰면 공통 VLM 표현과 배포 파일을 재사용할 가능성이 있습니다. 사용자가 사진을 물어본 뒤 그 내용을 바탕으로 새 이미지를 만드는 흐름에서는 두 기능 사이의 문맥도 자연스럽게 연결할 수 있습니다. 하지만 생성만 쓰는 앱이라면 이해 모듈의 저장, 메모리 비용이 불필요할 수 있고, 이해만 필요한 앱이라면 DiT와 VAE가 배포 부담이 됩니다.
비교할 때는 통합 모델과 별도 경량 VLM, 생성 모델을 같은 품질 목표에서 재야 합니다. 앱 설치 용량, 첫 로딩 시간, 두 기능을 연속 실행할 때의 peak memory, 한 기능만 사용할 때 남는 자원을 기록합니다. “모델 하나”라는 이름이 런타임에서 항상 더 작고 빠르다는 뜻은 아닙니다.
후처리 학습에는 생성 프롬프트, 이미지, 질문, 답변으로 이뤄진 quadruplet을 사용합니다. 같은 이미지에서 텍스트-이미지 생성 손실과 이미지-텍스트 이해 손실을 동시에 계산해 두 능력의 표현이 멀어지지 않도록 합니다.
원문은 수십억 개가 아닌 수백만 개 규모의 샘플로 학습했다고 설명합니다. 이미지 편집 결과는 ShareGPT4V의 46,000개 편집 샘플로 파인튜닝한 Mobile-O-0.5B에서 제시합니다.
이 데이터 효율은 매력적이지만, 좁은 편집 데이터에서 좋은 사례가 나왔다는 사실과 임의의 도메인에서 안정적으로 편집한다는 주장은 구분해야 합니다.
공동 학습에서는 한 능력을 높이는 손실이 다른 능력의 표현을 바꿀 수 있습니다. 생성 손실 비중을 키웠을 때 이미지 질문 정확도가 떨어지는지, 이해 손실을 키웠을 때 프롬프트를 따르는 생성이 약해지는지 확인해야 합니다. 총손실만 내려갔다고 두 작업이 모두 개선됐다고 말할 수는 없습니다.
quadruplet의 질문과 생성 프롬프트가 같은 이미지에서 너무 비슷한 속성을 반복하면 공유 표현의 이득이 과대평가될 수 있습니다. 질문에는 없지만 생성에 필요한 관계, 생성 프롬프트에는 없지만 이해해야 할 세부를 포함한 평가가 필요합니다. 학습에 본 이미지와 비슷한 편집뿐 아니라 새로운 대상, 구도, 문구에서 두 기능이 함께 유지되는지도 분리해 봅니다.
이미지 편집은 원본 보존과 요청 변화라는 두 목표를 동시에 봐야 합니다. 편집 결과가 선명해도 사람이나 물체의 정체성이 바뀔 수 있고, 원본을 잘 보존해도 요청한 변화가 약할 수 있습니다. 편집 샘플 수만 인용하기보다 작업 유형별 충실도와 보존 실패를 기록해야 실제 앱 범위를 정할 수 있습니다.
연구는 GenEval 생성 점수 74%를 보고하고, 일곱 이해 벤치마크 평균에서 비교 모델보다 5.1~15.3% 높은 결과를 제시합니다. 속도는 Show-O와 JanusFlow 등 비교 조건에서 6배에서 11배 빠르다고 설명합니다.
이 숫자들은 동일한 평가 설정 안에서의 상대 결과입니다. 모델 변환 방식, 정밀도, NPU 지원 연산, 발열 상태가 달라지면 모바일 지연도 달라집니다. 특히 3초는 iPhone 17 Pro에서 512×512 한 장을 생성한 데모 조건이며, 연속 생성의 배터리와 열 안정성을 뜻하지 않습니다.
첫 실행과 반복 실행도 다릅니다. 처음에는 모델 파일 로딩과 그래프 컴파일, 메모리 할당이 포함될 수 있고 이후 생성은 캐시 덕분에 빨라질 수 있습니다. 반대로 연속 실행에서는 발열로 클록이 낮아져 뒤쪽 생성이 느려질 수 있으므로 차가운 상태의 첫 장, 워밍업 뒤 한 장, 여러 장 연속 생성의 지연을 나눕니다.
생성 점수와 이해 평균은 서로 다른 평가이므로 한 숫자로 통합 모델의 우열을 정하면 안 됩니다. 제품이 사진 질의응답과 이미지 생성을 모두 사용한다면 각 기능의 최소 품질선을 정하고 한쪽이 크게 약해지지 않는 모델을 선택해야 합니다. 특정 벤치마크 평균이 높아도 앱에서 자주 묻는 텍스트 인식, 작은 물체와 공간 관계가 약할 수 있습니다.
모바일 배포에서는 연구 모델을 기기 런타임 형식으로 변환하고 더 낮은 정밀도로 양자화할 가능성이 큽니다. 이 과정은 파일 크기와 지연을 줄일 수 있지만 VLM의 작은 텍스트 인식, MCP 조건, DiT의 색과 구도 표현에 서로 다른 영향을 줄 수 있습니다. 데스크톱 원본 모델 점수를 모바일 변환본의 점수로 대신해서는 안 됩니다.
정밀도별로 이해 정확도, 생성 충실도, peak memory와 지연을 같은 장치에서 비교합니다. 지원되지 않는 연산 때문에 일부 레이어만 높은 정밀도로 남았는지, CPU fallback이 생겼는지도 프로파일에서 확인합니다. 양자화 후 두 능력 중 하나만 크게 나빠지면 통합 모델의 공유 표현이 특정 수치 오차에 민감한지 살펴야 합니다.
Mobile-O를 검토한다면 기능을 한 점수로 합치지 말고 다음을 따로 확인해야 합니다.
온디바이스 실행은 서버 호출을 줄이고 입력을 기기에 둘 가능성을 제공하지만, 자동으로 인프라 비용이 0이 되거나 개인정보 보호가 완성되는 것은 아닙니다. 앱 업데이트, 모델 배포, 저장 공간과 전력 비용은 남습니다. Mobile-O의 실제 의미는 거대한 통합 모델을 축소한 데만 있지 않고, 이해 표현을 생성 조건으로 재사용하는 연결 구조를 모바일 제약 안에서 보였다는 데 있습니다.
개인정보 흐름은 추론 위치 외에도 입력 저장, 생성 기록, 진단 로그와 클라우드 백업을 포함합니다. 모델이 기기에서 돌아가도 사진이 분석 로그나 운영체제 백업으로 외부에 나갈 수 있으므로 네트워크를 끈 상태의 기능, 파일 보존 위치와 삭제 절차를 확인합니다. 모델 업데이트를 받는 통신과 사용자 입력을 보내는 통신도 구분해 설명해야 합니다.
배터리 평가는 한 장의 소비 전력보다 실제 세션을 기준으로 봅니다. 사진 질문을 여러 번 한 뒤 편집, 생성을 이어 가는 흐름에서 배터리 감소, 표면 온도, 메모리 압박과 앱 종료를 기록합니다. 백그라운드로 내려갔다 돌아왔을 때 모델을 다시 로드하는 시간과 운영체제가 메모리를 회수했을 때의 복구도 사용자 경험에 포함됩니다.
최종 결정은 “휴대전화에서 실행됐다”가 아니라 목표 기기 범위에서 품질과 반응 시간이 유지되는지에 달려 있습니다. 최신 고급 기기 한 종에서만 가능한지, 지원 기기마다 다른 모델 크기나 서버 fallback이 필요한지 정하고, fallback 시 데이터 경계가 어떻게 바뀌는지도 사용자에게 알려야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.