Jev-Omni란? 사진·음성·영상에서 답을 고르는 로컬 AI

집 안의 카메라가 현관을 찍고 있다고 해봅시다. 자동화에 필요한 것은 ‘문이 열림’, ‘문이 닫힘’, ‘사진으로 판단하기 어려움’ 중 하나입니다. 화면에 무슨 물건이 있는지 유창하게 설명해도, 프로그램은 마지막에 그 셋 중 하나를 골라야 합니다. Jev-Omni는 그 선택 자체를 결과로 받으려는 접근입니다.

반대로 ‘왜 그런 판단을 했는지 설명해줘’나 ‘이 사진으로 광고 이미지를 만들어줘’는 다른 작업입니다. Jev-Omni는 설명문을 쓰거나 이미지·영상을 생성하는 모델이 아닙니다. 반복해서 같은 종류의 질문을 처리하는 분류기, 혹은 어떤 도구를 다음에 호출할지 정하는 보조 모델로 보는 편이 용도에 가깝습니다.

로컬 JEV형 구현 중에는 Qwen이 다음에 출력할 후보 토큰¹의 점수를 바로 읽는 방식이 있습니다. Jev-Omni는 Gemma 4 12B IT 기반 모델에 별도로 학습한 분류 헤드를 붙입니다. 공개 코드는 입력을 처리한 뒤 마지막 위치의 내부 표현을 이 헤드에 전달하고, 선택지 점수를 확률로 바꿉니다. 길게 토큰을 이어 쓰는 디코딩 루프는 없습니다.

출력은 prediction, prediction_index, confidence, probabilities입니다. 가장 높은 확률의 선택지만 쓰거나 전체 확률을 남겨 나중에 검토할 수 있습니다. options에는 서로 다른 문구를 넣는 것이 좋습니다.

결과가 선택지 문구를 키로 쓰는 사전이므로 같은 문구를 중복하면 결과 해석이 꼬일 수 있습니다. 한 번의 predict 호출은 질문 하나를 처리하므로, 여러 질문을 무료로 동시에 해결한다고 생각하면 안 됩니다.

사진은 흐림 여부나 정해진 물건의 존재를 분류하는 식으로 시작할 수 있습니다. 음성은 짧은 구간에 특정 소리가 있었는지, 영상은 여러 장면에서 상태가 바뀌었는지 확인하는 실험에 쓸 수 있습니다. 이것은 가능한 활용 예이지, 이 프로젝트가 모든 용도에서 정확도를 검증했다는 뜻은 아닙니다. 실제 파일과 사람이 매긴 정답을 함께 준비해야 내 작업에 맞는지 알 수 있습니다.

공개 헬퍼의 음성 경로는 ffmpeg로 앞부분 최대 30초를 잘라 처리합니다. 영상은 기본 16프레임²을 골라 이미지로 전달하며 영상의 오디오 트랙을 함께 듣는 경로는 아닙니다. 긴 영상에서 아주 잠깐 일어난 사건은 선택된 프레임 사이로 빠질 수 있습니다. ‘영상 지원’과 ‘영상의 모든 순간을 확인’은 구분해야 합니다.

평소 12B 모델을 4비트로 실행했다면 몇 GB면 충분하다고 느낄 수 있습니다. 하지만 공개 Jev-Omni 체크포인트³는 그런 배포 형태가 아닙니다.

텍스트 가중치 인덱스만 약 47.63GB이고, 기본 로더는 이를 FP32⁴로 CUDA⁵에 올립니다. 모델 카드도 런타임 여유를 제외하고 약 50GB를 안내합니다.

따라서 24GB RTX 3090·4090이나 32GB RTX 5090에서 기본 예제를 그대로 실행한다고 보장할 수 없습니다.

더 중요한 것은 초기 로딩의 피크입니다. 멀티모달 로더는 일부 선형층을 BF16⁶으로 바꾸고 나서 원본 Gemma 모델도 로드해 구성 요소를 교체합니다. 계산 중 BF16 autocast를 쓴다는 말이 처음부터 모든 가중치를 절반 크기로 올린다는 뜻은 아닙니다. 최종 사용량만 보고 장비를 고르면 로딩 도중 실패할 수 있어, 특정 용량을 최소 사양으로 단정하지 않았습니다.

Mac의 메모리가 넉넉하더라도 현재 공개 load_jev_omni는 CUDA 외 장치를 거부합니다. GPU⁷ 두 장의 메모리를 합산하는 분산 로딩도 기본 함수에 없습니다. Mac에서는 기존 Qwen·MLX⁸ 기반 JEV형 구현을 먼저 살펴보는 편이 낫습니다. 양자화⁹하거나 로더를 수정하는 실험은 가능성을 검토할 별도 작업이지, 공개 예제가 이미 지원하는 기능으로 표시할 수는 없습니다.

아래는 공개 Python 헬퍼를 사용하는 순서입니다. 먼저 CUDA를 지원하는 PyTorch¹⁰가 현재 GPU에서 동작하는지 확인합니다. 코드는 모델 저장소에서 내려받아 실행하므로 jev_omni.py와 load_model.py를 읽어본 뒤 의존성을 설치하세요. 별도 가상환경¹¹을 쓰면 다른 로컬 AI 도구와 패키지 버전이 섞이는 일을 줄일 수 있습니다.

모델 카드의 요구 버전은 torch 2.10 이상과 transformers 5.17.0입니다. 음성을 사용할 때는 Python 패키지와 별개로 ffmpeg 실행 파일도 필요합니다. 처음 모델을 불러오면 Jev-Omni뿐 아니라 원본 Gemma의 멀티모달 구성도 내려받습니다. 다운로드 공간·시간과 추론 시간은 따로 생각하고, 첫 실행에 개인 파일 대신 테스트용 자료를 사용하세요.

다음 코드를 jev_demo.py로 저장하고 가상환경에서 python jev_demo.py로 실행합니다. 첫 질문은 모델 로딩과 출력 구조를 확인하는 용도입니다. Python 결과에는 선택지 문구와 확률이 함께 나오므로, 답변 문자열을 다시 해석하는 코드를 만들 필요가 없습니다. 아래 예제는 실제 측정 결과를 꾸며 넣은 것이 아니라 공개 함수 호출 방법입니다.

텍스트 호출이 끝난 다음 사진 예제의 주석을 해제하고 media에 실제 파일 경로를 넣습니다. 파일은 공개 헬퍼에서 로컬로 읽지만, 모델과 구성 파일을 처음 받는 단계에는 인터넷 연결이 필요합니다. 사진에 정답이 보이지 않으면 ‘판단 불가’를 고를 수 있도록 선택지를 설계하세요. 질문을 한국어로 바꿔 쓸 수 있는지와 업무 정확도는 따로 검증해야 하므로 예제는 영문으로 두었습니다.

모델 카드의 H200 결과는 웜 상태의 최적화된 백엔드에서 요청 20회의 중앙값입니다. 약 2천 토큰 텍스트는 83ms, 이미지는 26ms, 13초 음성은 31ms, 16프레임 영상은 504ms로 안내합니다. 전처리와 네트워크 시간은 별도입니다. 큰 영상 파일을 열고 프레임을 읽는 시간이나 처음 가중치를 올리는 시간까지 이 숫자에 포함되어 있지는 않습니다.

채팅 모델의 tok/s와 나란히 놓기도 어렵습니다. Jev-Omni는 긴 답변을 생성하지 않으므로 입력 처리와 분류 완료까지의 지연시간, 동시에 처리할 수 있는 요청 수가 더 적절한 지표입니다.

이 글의 H200 수치를 사이트의 RTX·Mac 속도 체감으로 변환하지 않은 이유입니다. 내 장비에서는 같은 파일·같은 질문으로 로딩을 끝낸 뒤 여러 번 재고, 전처리를 포함한 시간도 별도로 남기는 것이 좋습니다.

높은 confidence가 내 데이터에서도 높은 정답률을 보장하지는 않습니다. 공개 모델은 선택지 20개 이하를 중심으로 지원하고, 헤드가 받는 최대 256개와 그 범위의 검증된 품질은 다릅니다. 먼저 실제 질문 수십 개에 직접 정답을 달아 비교하고, 틀렸을 때의 확률도 보세요. 자동 통과 기준은 그 기록으로 정하고, 애매한 결과는 검토 대기 목록에 남기는 편이 안전합니다.

저장소는 Apache-2.0으로 표시되어 있고 원본 Gemma 4도 같은 라이선스를 안내합니다. 다만 학습 데이터와 내가 넣는 사진·녹음의 권리는 별개입니다. TypeSafe AI와 제휴하거나 그 Jev의 출력으로 학습한 프로젝트도 아니라는 점을 구분해두면 이름 때문에 생기는 오해를 줄일 수 있습니다.

로컬 AI를 써보고 싶은 이유가 꼭 긴 대화를 나누기 위해서일 필요는 없습니다. 매일 열어보던 사진 폴더에서 확인할 것만 골라주거나, 반복되는 분류를 대신해주는 작은 기능도 충분히 쓸모가 있습니다.

Jev-Omni는 그런 방향의 공개 사례입니다. 지금 가진 장비에서 더 작은 Qwen 구현으로 질문과 선택지를 먼저 다듬어도 됩니다.

그 과정에서 답이 좋아졌을 때, 더 큰 멀티모달 모델을 올릴 이유도 분명해집니다.