구글이 EmbeddingGemma 2를 소개하며 적은 191MB는
Pixel 11 Pro에서 텍스트 전용 가중치로 돌렸을 때의 값이었다.
같은 모델을 내 맥 CPU에서 PyTorch fp32로 처음 돌리자
최대 RSS는 6.4GB로, 지금 쓰는 bge-m3의 3.58GB보다 컸다.
발표 숫자를 잰 조건은 발표 문서 안에 이미 적혀 있었다.
숫자를 옮기면서 그 조건과 비교 대상, 버전을 같이 옮기지 않으면
그 값이 어느 환경에서 나온 것인지 알 수 없다.
문제
새 모델 발표를 보면 내가 먼저 묻는 것은
내 시스템에서 쓸 만한가다.
Jev 때는 쓰임새를 생각해 보라고 했다가 그 작업을 끊고
"jev부터 조사해봐 새로운유형의 ai야"라고 다시 요청했다.
EmbeddingGemma 2 때는 공개 소식을 붙여 넣고
"내 하인드사이트 임베딩모델이랑 정량비교한번해줘"라고 했다.
Hindsight는 코딩 에이전트 여럿이 함께 쓰는 내 메모리 시스템이다.
비교를 시작할 때 임베딩 설정은 로컬에서 실행하는 BAAI/bge-m3,
1024차원이었다.
이렇게 물으면 발표 숫자를 곧바로 내 기계의 값으로 읽고 싶어진다.
그런데 두 사건의 숫자는 전부 다른 기계와 다른 정밀도,
다른 비교 대상에서 나온 값이었다.
발표 글은 측정 조건을 스스로 적고 있었다
TypeSafe AI의 발표 글은
Jev를 구조화된 출력에 최적화되고 환각을 일으킬 수 없는 모델로 소개한다.
속도와 배율, 환각률 중 어느 숫자를 봐도
같은 글 안에 그 숫자가 나온 조건이 붙어 있었다.
| 발표 글의 숫자 | 같은 글이 붙인 조건 |
|---|---|
| 응답 시간 70ms-500ms, 40x-200x 빠름 | 공개한 평가는 대체로 서부 해안의 노트북에서 돌렸다 |
| 홈페이지의 193.6x faster, 444.6x cheaper | 실제 이득의 높은 쪽으로 본다. 평가 워크플로는 자사 모델 역량 팀이 만들었고 "some bias could exist" |
| Jev의 환각 0% | "Our number is not empirical." 스키마 일치가 보장되므로 0%를 넣었다 |
| 비교 대상 LLM의 환각 수치 | OpenRouter에서 가져왔고 "there almost certainly is bias here" |
속도는 서부 해안의 노트북에서 호출해 잰 응답 시간이므로,
한국에서 호출하는 내 환경과는 출발점부터 다르다.
0%는 측정이 아니라 설계상의 보장에서 끌어낸 수치이고, 글도 그렇게 밝힌다.
TypeSafe 모델 문서의 언어 지원 절은
영어가 주 학습 언어이고, CJK도 처리되지만 같은 수준은 아니니
자기 내용으로 직접 시험해 보라고 권한다.
자체 모델이라는 말의 출처는 벤더였다
Jev가 특정 파운데이션 모델을 서빙하는 것이냐고 묻자,
Claude Code 세션의 에이전트는 TypeSafe가 바닥부터 학습한
자체 모델이라고 단정했다.
근거로는 병렬 샘플러 구조와 RLHF 대신 쓴 학습법인 RLCD,
모델 고유의 실패 특성을 다룬 문서, 이렇게 세 가지를 들었다.
Qwen 3.5 기반으로 구현할 수 있다는 루머가 무슨 뜻인지 다시 묻자,
같은 에이전트는 루머를 웹에서 확인하고 4분 16초 뒤 앞선 답을 정정했다.
"자체 모델"은 TypeSafe의 마케팅 문구를 그대로 받아 쓴 것이었고
아키텍처·파라미터 수·가중치·라이선스가 공개되지 않았으니
벤더 주장으로 낮춰 다뤄야 한다는 정정이었다.
실제로 발표 글 본문에는 parameter와 weights라는 낱말이 한 번도 나오지 않는다.
루머 쪽도 출처를 나눠 읽어야 했다.
발표 이틀 뒤 만들어진 openjev-sglang은
Qwen3.6-35B-A3B로 Jev HTTP API를 구현한 서버이고,
jev-latest를 설정된 Qwen 모델의 호환용 별칭으로 쓰며
"No requests go to TypeSafe."라고 적는다.
Qwen3.5-0.8B 위에 Jev 방식의 판정 모델을 만든
qwen-rlcd도 하루 먼저 나와 있었다.
독립 개발자의 역공학 글은
415개 프로브로 공개 토크나이저 192개를 시험했지만 일치하는 것이 없었고
가장 가까운 Qwen이 348개에서 일치했다고 쓴다.
그 글도 이 결과만으로 공개 기반 모델일 가능성까지 배제하지는 못한다고 적었다.
정정 답변이 루머를 Jev 본체가 Qwen이라는 이야기와
Qwen으로 Jev를 흉내 낼 수 있다는 이야기로 나눈 것도 그래서다.
제3자 벤치마크도 비교 조건을 달고 있다
제3자가 공개한
피싱 이메일 2,000통 벤치마크는
jev-1.13.0과 사고 기능 없이 돌린 Claude Haiku 4.5에게
"이메일의 링크를 눌러도 되는가"라는 한 가지 판정을 시켰다.
| 조건 | Jev | Haiku 4.5 |
|---|---|---|
| 한 가지 판정, 2,000통 정확도 | 62.6% | 81.3% |
| 신호 질문 다섯 개 회귀, 2,000통 | 95.1% | - |
| 같은 다섯 질문 회귀, 평가용 절반 B | 95.0% | 93.2% |
| 지연 p50, 프랑스에서 잼 (네트워크 하한) | 239 ms (163 ms) | 687 ms (18 ms) |
| 1,000통당 정가 비용 | $0.038 | $0.462 |
조사 세션의 정리 답변은 62.6%와 81.3%를 보여 준 뒤 95.1%를 붙여
"설계가 성능을 지배한다"는 항목을 썼고
한국어 열세도 질문 분해로 상당 부분 상쇄된다고 맺었다.
그 답변에는 93.2%가 없었다.
같은 벤치마크에 따르면 Haiku에게도 2,000통 전부에 같은 다섯 질문을 물어
같은 절차를 적용하면 평가용 B에서 93.2%가 나오고
같은 B에서 Jev가 낸 95.0%와의 차이는 유의하지 않다(McNemar p = 0.063).
URL 정규식 규칙만으로도 평가용 B에서 91.8%가 나왔다.
95.1%와 함께 옮겼어야 할 조건은
비교 대상도 같은 절차를 거쳤는가였다.
191MB는 휴대폰에서 잰 값이었다
구글 개발자 블로그 글은
첫 단락에서 Pixel 11 Pro 기준으로 텍스트 전용 가중치는 "~191MB active RAM",
전체 멀티모달 모델은 "~567MB"까지 줄여 실행할 수 있다고 적는다.
본문은 양자화 인식 학습(QAT)으로 가중치를 INT4와 INT8로 압축한다고 설명한다.
LiteRT 번들 모델 카드는
수치를 플랫폼별 지표로 쟀으므로 운영체제끼리 직접 비교할 수 없다고 못 박는다.
Android는 ru_maxrss로, iOS와 맥북은 phys_footprint로 쟀고
phys_footprint가 아닌 지표에는 GPU·NPU·TPU 메모리가 포함되지 않으며
측정은 두 번째 로드에서 했다.
같은 카드의 텍스트 입력 표에서 Pixel 11 Pro(TPU)는 112 MB,
iPhone 18 Pro CPU는 84 MB다.
같은 Pixel 11 Pro인데도 블로그 글과 카드 표의 숫자가 다르다.
공개 자료만으로 먼저 비교해 달라고 하자,
에이전트가 만든 스펙 표는 "메모리 사용량" 한 행에
bge-m3 2167MB, EmbeddingGemma 1 578MB,
EmbeddingGemma 2 191MB(Pixel, 텍스트 전용)를 나란히 놓았다.
표 아래에는 앞의 둘은 EmbeddingGemma 1 논문의 표에서 가져온 값이고
EmbeddingGemma 2는 모바일 INT4 기준이라 조건이 다르다는 문장이 붙어 있었다.
17분 19초 뒤 나는 "제일큰 장점은 eg2는 메모리를 얼마안먹네?"라고 물었다.
조건 문장은 표 아래에 있었고, 숫자는 한 행에 나란히 있었다.
에이전트는 191MB가 다른 실행 경로에서 나온 값이라고 답했다.
Pixel에서 LiteRT로 INT4·INT8 양자화 번들을 돌린 값이고,
Hindsight는 sentence-transformers(PyTorch)로 임베딩을 돌리므로
그 수치를 그대로 가져다 쓸 수 없다는 설명이었다.
2026-10-20에 열어 본 Hindsight 컨테이너에서도 로컬 제공자는
SentenceTransformer를 불러 쓰고 있었고 torch는 CPU 빌드였다.
뒤이어 아이폰 15 Plus에서는 얼마나 먹느냐고 묻자
에이전트는 텍스트 전용 기준 약 85MB로 추정했다.
그러면서 카드에 15 Plus 값이 없어 iPhone 18 Pro 값으로 추정했다는 점과,
int4 번들 값이라 맥 PyTorch의 2~4GB와는 다른 경로라는 점을 같이 적었다.
이번에는 추정에 근거가 붙어 나왔다.
내 맥에서 다시 잰 값도 조건을 탄다
내 기계에서 잰 숫자도 조건을 적지 않으면 같은 문제가 생긴다.
아래 표는 메모리 질문 직후 세션이 다시 잰 값과,
2026-10-20에 같은 측정 코드를 새 가상환경에서 다시 돌린 값이다.
전부 맥 CPU, 문서 64건, 배치 16, 최대 길이 1024 조건이다.
| 측정 | 입력 | bge-m3 | EmbeddingGemma 2 |
|---|---|---|---|
| 세션, fp32 안정 RSS | 뱅크 문서 | 2.99GB | 4.48GB |
| 세션, bf16 안정 RSS | 뱅크 문서 | 2.50GB | 2.11GB |
| 재측정, fp32 안정 RSS | 기록 본문 900자씩 | 2.6GB | 2.37GB |
| 재측정, bf16 안정 RSS | 기록 본문 900자씩 | 1.44GB | 1.81GB |
| 재측정, fp32 안정 RSS | 기록 본문 2400자씩 | 3.0GB | 3.17GB |
세션에서 잰 fp32 값은 EmbeddingGemma 2 쪽이 컸다.
입력을 바꾼 재측정에서는 900자일 때 방향이 뒤집혔고
2400자일 때는 같은 방향이었지만 차이가 작았다.
처음 잰 6.4GB 대 3.58GB도 문서 256건, 스레드 4개 조건에서 잰 최대 RSS다.
같은 스크립트를 MPS로 돌리면 bge-m3는 1.17GB, EmbeddingGemma 2는 2.45GB였다.
교체는 하지 않았다.
같은 비교의 품질 측정에서 에이전트는 교체하지 않는 쪽을 권했고
2026-10-20에 다시 읽은 Hindsight 설정도 bge-m3, 1024차원 그대로다.
결론
두 사건에서 숫자의 측정 조건은 매번 원문 안에 있었고
빠진 것은 그 조건을 숫자와 함께 옮기는 일이었다.
서부 해안의 노트북, 실측이 아닌 0%, Haiku가 빠진 95.1%,
Pixel의 INT4 번들은 전부 숫자 바로 옆이나 같은 문서 안에 있었다.
벤더 숫자 대신 내 기계에서 잰 숫자로 채택 여부를 가른 일은
TEI 추론 서버 글에 적었는데,
이번에는 내 기계에서 잰 숫자에도 입력과 정밀도를 붙여야 했다.
다음 발표를 읽을 때는 숫자보다 그 숫자를 잰 문장을 먼저 찾고
내 비교표에는 조건 열을 숫자 열보다 먼저 만든다.
한계·재검토 트리거
벤치마크가 쓴 버전은 jev-1.13.0이다.
TypeSafe 모델 문서는 jev-latest가 jev-1.13.0을 가리키고
별칭이 움직이면 코드를 바꾸지 않아도 답이 바뀔 수 있다고 적으며
Jev 1.14가 2026-10-14부터 나와 있다고 적는다.
2026-10 기준 / 재검토 트리거: jev-latest가 1.14 이후를 가리키거나
Hindsight 임베딩 모델이 바뀔 때
참고
- TypeSafe AI 발표 글 - Jev 속도·배율·환각 수치와 그 조건
- TypeSafe 모델 문서 - 언어 지원,
jev-latest별칭, Jev 1.14 - openjev-sglang - Qwen으로 구현한 Jev 호환 서버
- qwen-rlcd - Qwen3.5-0.8B 위의 Jev 방식 판정 모델
- 독립 개발자의 역공학 글 - 토크나이저 대조
- jev-phishing-bench - 피싱 이메일 2,000통 벤치마크
- 구글 개발자 블로그 - EmbeddingGemma 2 공개 글
- LiteRT 번들 모델 카드 - 플랫폼별 메모리 측정 방식과 표
- TEI 추론 서버 판정문 - 벤더 수치 대신 내 기계 숫자로 채택을 가른 기록