dev.to

Small Apache-2.0 Models Against Gemma 4 E2B on One TPU v5e: Which Ones Keep Up?

TPU v5e 한 장에서 Gemma 4 E2B와 겨룬 소형 Apache-2.0 모델

TPU v5e 한 장에서 Gemma 4 E2B와 Apache-2.0 또는 MIT 라이선스 모델을 같은 vLLM 이미지와 설정으로 비교했습니다. Qwen3-4B는 수학·도구 호출 점수가 Gemma와 비슷했지만 출력 속도는 0.57배였고, 긴 프롬프트에서는 Gemma의 KV 캐시 구조가 속도 우위를 유지했습니다.

에디터 노트

이 비교에서 대체 모델의 실용성을 가르는 기준은 정확도 하나가 아니라 긴 입력에서 유지되는 처리량입니다. Qwen3-4B는 두 정확도 시험에서 Gemma와 차이가 측정되지 않았지만 3,072토큰 입력 처리량은 0.36배였습니다. Gemma의 작은 KV 캐시 사용량이 이 격차를 설명하며, 가중치 크기만으로 속도를 예측하기 어렵다는 점도 수치로 드러납니다. 다만 시험은 v5e-1 한 장과 최대 4,096토큰 설정에 한정됩니다. 댓글에서 요청한 더 긴 max-model-len 비교 결과는 아직 제시되지 않았습니다.

AI 요약

Google Cloud의 TPU v5e-1 한 장에서 Gemma 4 E2B와 소형 오픈 웨이트 모델을 비교했습니다. 모두 Apache-2.0 또는 MIT 라이선스 모델을 대상으로 삼고, 같은 vLLM 컨테이너 이미지와 추론 설정을 적용했습니다. 장비의 HBM은 15.75 GiB이며 vLLM에 배정되는 메모리는 약 14 GiB입니다. 가중치와 KV 캐시 공간을 고려해 이 조건에 들어오는 모델을 골랐습니다. 비교 도구인 model-sweep은 Hugging Face API에서 라이선스, 구조, 가중치 크기를 읽고 후보 모델을 분류합니다. KV 캐시 공간이 최소 2 GiB 남아야 포함하며, vLLM TPU의 실행 방식에 따라 JAX와 PyTorch 계열로 나눠 측정했습니다.

측정 조건과 결과

모든 모델은 vLLM 0.29.1 개발 버전과 같은 컨테이너 이미지 다이제스트에서 실행했습니다. 최대 입력 길이는 4,096 토큰, 동시 요청 수는 최대 16개로 설정하고 prefix caching을 켰습니다. 처리량은 출력 256토큰 요청을 동시 요청 수 1, 4, 16으로 보내 세 차례 측정한 중앙값입니다. 긴 프롬프트 시험은 캐시가 재사용되지 않도록 서로 다른 1,024토큰·3,072토큰 입력을 사용했습니다. GSM8K 1,319문제는 탐욕적 디코딩으로 풀게 했고, BFCL의 단순 도구 호출 기록 400개도 평가했습니다. 모델별 점수 차이는 같은 문제의 결과를 짝지어 10,000회 재표집한 95% 구간으로 계산했습니다. 구간에 0이 포함되면 측정된 차이가 없다고 봤습니다.

Gemma 4 E2B의 GSM8K 점수는 0.911, BFCL 점수는 0.927입니다. Qwen3-4B는 각각 0.915와 0.940으로 두 점수 모두 Gemma와 차이가 측정되지 않았습니다. 다만 동시 요청 16개에서 출력 속도는 Gemma의 0.57배였고, 3,072토큰 프롬프트에서는 0.36배였습니다. SmolLM3-3B는 BFCL에서 0.945로 Gemma와 차이가 측정되지 않았지만 GSM8K는 0.858로 5.3%포인트 낮았습니다. 출력 속도는 Gemma의 0.76배입니다. Granite 3.3 2B와 Qwen3-1.7B도 BFCL 점수에서 Gemma와 차이가 측정되지 않았습니다. Qwen3-1.7B는 동시 요청 16개에서 Gemma보다 빨랐지만 GSM8K 점수는 0.827로 낮았습니다. 2B 미만 모델 대부분은 GSM8K에서 Gemma보다 18~45%포인트 낮았습니다.

KV 캐시와 모델 구조

Gemma 4 E2B는 가중치가 8.97 GiB로 비교 대상 가운데 가장 컸지만, KV 캐시에 321,280토큰을 담았습니다. Granite 3.3 2B는 125,184토큰, SmolLM3-3B는 120,320토큰, Qwen3-1.7B는 100,096토큰, Qwen3-4B는 50,688토큰을 담았습니다. Gemma는 KV 헤드가 하나이며 35개 레이어 가운데 28개가 512토큰 슬라이딩 윈도우를 사용합니다. 또 20개 레이어가 앞선 레이어의 KV 캐시를 공유합니다. 이 구조로 비교 대상 모델보다 2.6~6.3배 많은 토큰을 캐시에 저장했고, 긴 프롬프트에서도 처리량 우위를 보였습니다.

Qwen3와 SmolLM3는 기본 설정에서 추론 과정을 출력합니다. GSM8K 답변 토큰 한도가 2,048이라 추론 문장이 예산을 차지하는 문제를 줄이기 위해 요청마다 enable_thinking을 false로 설정했습니다. MIT 라이선스인 DeepSeek-R1-Distill-Qwen-1.5B는 vLLM 이미지의 Qwen2 구현에서 설정 객체를 읽는 과정에 오류가 나 로드에 실패했습니다. 작성자는 Python의 getattr 기본 인수가 먼저 평가되면서 tie_word_embeddings가 false인 Qwen2 체크포인트에서 오류가 발생한다고 설명합니다. OLMo 2 1B도 TPU의 벡터 메모리 한도를 넘겨 컴파일에 실패했습니다. Ministral 3 3B와 Qwen3.5 모델은 서버 오류 또는 사용할 수 없는 출력 때문에 표에서 제외했습니다. Phi-4-mini는 도구 호출 파서가 결과를 만들지 못해 GSM8K와 속도만 보고했습니다. 코드와 로그, 점수 결과는 GitHub 저장소에 공개했습니다.

dev.to 반응

  • @fgrandon — 훌륭한 벤치마크와 방법론입니다. vLLM TPU 컨테이너 이미지를 고정하고 Cloud TPU v5e 한 장의 실제 사용 가능 메모리 예산인 14 GiB 안에서 시험한 점이 공정한 비교를 뒷받침합니다. Gemma 4 E2B의 슬라이딩 윈도우와 전체 어텐션에서 서로 다른 헤드 크기, 그리고 레이어 간 KV 캐시 재사용을 분석해 긴 프롬프트에서도 처리량 우위를 보이는 이유를 설명한 점이 좋습니다. Qwen3-4B가 정확도는 맞추면서 처리량은 0.57배라는 결과는 메모리가 제한된 추론 환경에서 단순한 어텐션 구조와 특수한 KV 캐시 배치가 어떻게 맞바뀌는지 보여줍니다. 경량 TPU 평가 작업에 참고할 수 있도록 측정 도구를 GitHub에 공개해 주셔서 감사합니다.
    • @xbill — v5e1 장비를 꽤 꾸준히 구할 수 있었습니다. 그 점만으로도 TPU 작업이 훨씬 수월해졌습니다.
  • @qisuancloud — 탄탄한 벤치마크 방법론입니다. vLLM TPU 이미지 다이제스트를 고정하고 실제 사용 가능 메모리인 14 GiB 안에서 시험한 점이 수치의 신뢰도를 높입니다. 특히 Gemma의 단일 KV 헤드와 슬라이딩 윈도우 구조가 2.6~6.3배 많은 토큰을 저장한다는 결과가 눈에 띕니다. 가중치 크기만으로 추론 효율을 판단할 수 없다는 점을 잘 보여줍니다. max-model-len을 더 크게 설정했을 때 격차가 어떻게 바뀌는지도 보고 싶습니다. 실제 프롬프트가 4천 토큰보다 짧은 경우만 있는 것은 아니니까요.

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗