새 오픈 모델 2종(Gemma 4 31B · Qwen3.8-27B) — find 6전략에서 4가족 격자까지, 왜 tagmem 이 지는가

1 배경 / 목적

사용자(260918): API 는 비싸니 돈 안 드는 모델 중 Qwen3-VL-32B 보다 확실히 윗세대를 찾자. 후보 6종(Qwen3.8-27B · Kimi K3 · Flash-Next · GLM-5.3-Flash · Muse Glimmer · Gemma 4)을 WebSearch + HF config + vLLM v0.28.0 registry 대조로 검토했고, 이어 "리스토어, 리줌, 루틴 다 한 번 진행해서 전체 결과 표 만들고 확인해보자. 싹 다 돌려줘. 4개씩 따로따로 총 8개 잡." 지시로 find 만 측정했던 두 모델을 나머지 3가족까지 확장해 논문 본표(flash-3.7 · qwen3vl-32b)와 같은 칸 구조로 비교한다.

2 작업 내용

find 6전략 (본표 조건)

4가족 확장 (8잡, 모델 2 × 가족 4, own GPU 1장씩)

3 결과

find 헤드라인 (hidden 제외 place)

4가족 격자 (Avg %, 괄호는 그 모델의 예측 메모리 1위)

* 32B restore tagmem 은 쓰기 v11 로 본표에 반영된 값. † 표 작성 시점 Gemma4 routine 은 엔진 사망으로 89/100편(234행)만 집계(재개 잡 136789, 이후 완료·final_results 반영).

왜 지는가 — 쓰기 결합률 하나로 설명된다 (find 단일답, 같은 행 비교)

분해 검산 — Gemma4: .31×(+.178) + .31×(−.164) + .38×(−.197) = −.071 ≈ 실측 −.066(.198 vs .264). flash: +.021 ≈ 실측 +.013. 양의 문제가 아니다: 오픈 모델은 flash 보다 항목을 1.5~1.8배 많이 쓰는데(102~123 vs 68) 질의 물체를 담은 비율은 절반이고, 검색된 항목 수·사진 수(21~27개, 10~18장)는 비슷하다 → 검색·읽기 예산 차이가 아니다. 세대 효과는 '보존'에만 왔다: rf-v3 단계당 보존 Gemma4 95.8%·Qwen3.8 98.9%(flash 91.5%, 235B 59.3%, 32B 76.2%) — 덮어쓰기 붕괴는 해소됐지만 결합률은 그대로다.

해상도 가설 기각 (HF 프로세서로 640×480 JPEG q85 실측, 잡 136800)

글만 주면 네 모델이 45.7~47.6 으로 사실상 같다 → 언어·추론·답 형식은 동등. 같은 원본 8장을 주면 flash 40.0 vs 오픈 18.7~29.1 → 차이는 이미지에서 물체를 방·가구에 접지하는 시각 능력.

정정 — "미기록 = 아예 못 봤다"는 과한 해석이었다

GT 가 last_seen_frame·seen_s>0 을 보장하므로 프레임에서 물체는 실제로 보였다. 미기록 행 중 writer 가 정답 방+가구 항목을 이미 쓴 행(flash 71% · Gemma4 68% · Qwen3.8 61% · 32B 47%)의 obj 태그를 분류(tmp/namecheck/classify.py):

32B 실물 예: GT irish potato @ kitchen/dining table → 기록 obj=[green bottle, green vegetable, …] (명명 실패) · GT mug @ bedroom/bed → "picks up the teddy bear" (오인식) · 총칭 태그 상위: Qwen3.8·32B 는 robot(1,269·5,639) robot arm door window 에 태그를 낭비, 고유 obj 태그 flash 98 · Gemma4 156 · Qwen3.8 222 · 32B 718.

4 Takeaway

5 Next Steps