지금까지 저의 프로젝트에는 Gemini 3 / 2.5 Flash 또는 Flash-lite 을 사용했습니다. 모든 사용 사례는 에이전틱 (agentic) 이 아니며, 법률에서 참조문 추출, 분류, 명사형으로 제목 수정 등 원자적 작업에 대한 LLM 워크플로우입니다. 이는 모두 비영어권 (LT) 언어로 이루어지며, 다국어 품질이 매우 뛰어나기 때문에 원래 구글 모델을 사용한 이유 중 하나입니다.

각 단일 요청은 보통 2k - 6k 토큰의 컨텍스트에 적합합니다.

최근에 Gemini 2.5 Flash-lite 이조차도 끔찍한 결과를 생성하기 시작했으며, 이전에는 경험하지 못했던 루프 (looping) 현상까지 발생했습니다. 이것이 우연인지 Vertex API / 그들의 모델 내부에서 변화가 있었는지 확실하지 않습니다.

저는 RTX 5090 을 가지고 있으므로 Gemma 4 31B 로 시도해 보기로 결정했습니다.

저의 요구사항은 매우 간단합니다: 비영어권 언어에서 가능한 한 좋은 성능, 구조화된 JSON 응답 생성 능력이 좋고, 컨텍스트가 최대 8K 까지 가능하며, 출력 속도가 최대한 빠릅니다.

따라서 가능한 최고의 품질을 끌어내기 위해 gemma-4-31B-it-GGUF:Q6_K_L + gemma-4-E2B-it-GGUF:Q8_0 추상적 디코딩 (speculative decoding) 을 실행했습니다.

그리고 잘라, 초기 소규모 샘플 테스트에 대해 말할 수 있는 것은 Gemini 2.5 Flash-lite 보다 품질이 더 좋고 빠르며 로컬에서 실행된다는 것입니다. 제가 얻은 출력 속도는 130 - 200 토크/초로, 제가 얻는 품질을 고려할 때 놀라운 수준입니다. 설정에는 31.5 GB 의 VRAM 이 사용되어 내 GPU 에 겨우 맞습니다.

저의 주장은 가벼운 (lightweight) LLM 워크플로우 (데이터 추출 및 유사 작업) 를 위해서는 더 이상 Vertex API 가 필요하지 않다는 것입니다.

물론 다음 단계는 단순한 테스트 몇 개 대신 더 큰 규모에서 시도해 보는 것입니다.

https://preview.redd.it/m9j3wzb2bjxg1.png?width=856&format=png&auto=webp&s=15e6b2db2649e4d49f5bf04b0b0f618482ae88d8

유사한 사용 사례를 가진 다른 사람들과 공유하고 싶었습니다. 시도해 볼 가치가 있습니다. 저의 llama 명령어를 추가합니다:

./build/bin/llama-server \
  -hf bartowski/google_gemma-4-31B-it-GGUF:Q6_K_L \
  -hfd unsloth/gemma-4-E2B-it-GGUF:Q8_0 \
  -ngl 99 -ngld 99 -fa 1 \
  -c 8192 \
  --draft-max 12 --draft-min 2 \
  --parallel 1 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --reasoning-budget 0 --no-mmproj \
  --host 0.0.0.0 --port 8080 \
  --temp 1.0 --top-p 0.95 --top-k 64