Gemma 3 270M: 효율적인 AI를 위한 컴팩트 모델
(developers.googleblog.com)- Google이 Gemma 3 270M을 공개하며, 높은 에너지 효율성과 지시 수행 능력을 강조함
- 270M 파라미터와 256k 토큰을 가진 작은 크기의 모델로, 특정 과업에 최적화된 파인튜닝에 적합함
- 모델의 INT4 양자화 버전은 장치 배터리 효율성이 매우 뛰어나, 온디바이스 혹은 저가 인프라에서 운영 가능함
- 텍스트 분류·데이터 추출 등 다양한 실무 및 창의적 활용 사례에 적용할 수 있음
- 개발자는 빠른 파인튜닝 및 배포, 개별 과업에 맞춘 맞춤형 모델 구축이 용이함
Gemma 3 270M 소개
최근 몇 달간 Gemma 오픈모델 패밀리는 Gemma 3, Gemma 3 QAT, Gemma 3n 등 다양한 모델을 출시하며 AI 활용의 지평을 넓혀왔음. 개발자를 위한 실용적인 툴 제공을 목표로 하며, 다운로드 수가 2억 건을 돌파하는 등의 활발한 커뮤니티인 Gemmaverse도 성장 중임.
이번에는 이 Gemma 3 제품군에 2억 7천만 파라미터를 가진 Gemma 3 270M이 추가됨. 이 모델은 크기가 작지만, 지시 수행·텍스트 구조화 능력이 강하게 내장되어 특정 과업에 파인튜닝하여 사용할 수 있도록 설계됨.
Gemma 3 270M의 주요 기능
- 컴팩트하고 강력한 아키텍처: 270M 파라미터(임베딩 170M + 트랜스포머 블록 100M) 채택, 256k 대형 어휘수로 희귀 토큰까지 효과적으로 처리 가능함
- 극한의 에너지 효율성: INT4 양자화 버전은 Pixel 9 Pro SoC에서 25번 대화 시 배터리 0.75%만 사용, Gemma 시리즈 중 가장 높은 효율성을 보임
- 지시 수행력: 사전학습 체크포인트 외에 인스트럭션 튜닝된 버전 제공. 복잡한 대화형 용도보다는 일반적인 명령수행 과업에 효과적임
기술적으로는 거대한 모델이 아닌, 효율적이고 목적에 맞는 소형 모델이 실무에서 더욱 유용함을 강조함. Gemma 3 270M은 이런 ‘적재적소’ 철학을 반영하여, 파인튜닝을 거치면 텍스트 분류, 데이터 추출 등 다양한 과업을 빠르고 저렴하게 수행할 수 있음. 컴팩트한 모델에서 시작해 비용을 크게 절감하며 실용 시스템을 구축할 수 있음.
실제 적용 사례와 성공 전략
이러한 소형 특화모델 전략은 이미 업계에서 성과를 나타냄. Adaptive ML이 SK Telecom과 협력하여 복잡한 다국어 콘텐츠 모더레이션 문제를 해결할 때, 무거운 범용 모델 대신 Gemma 3 4B를 파인튜닝하여 놀라운 결과를 얻었음. 해당 과업에서 소형 Gemma 특화모델이 훨씬 큰 독점모델을 능가하는 성능을 보임.
Gemma 3 270M의 주요 설계 목적은 이런 특화모델 전략을 더 작은 모델 규모로 확장하는 것에 있음. 개발자는 여러 개의 소형 과업 특화모델을 손쉽게 생성해 운영할 수 있음.
또한 엔터프라이즈 영역뿐 아니라 창의적 활용도 적극 지원함. 예시로, Hugging Face 커뮤니티의 웹 기반 Bedtime Story Generator 앱은 Gemma 3 270M을 통해 오프라인 혹은 웹 브라우저 내에서 실시간 콘텐츠 생성이 가능하였음.
Gemma 3 270M 선택 시점
Gemma 3 270M은 Gemma 3 시리즈의 진보된 기반 아키텍처와 고품질 사전학습의 장점을 계승함. 다음과 같은 상황에서 최적의 선택임:
- 명확하고 대량의 과업 처리: 감정 분석, 엔티티 추출, 질의 라우팅, 텍스트 변환, 창작, 컴플라이언스 검사 등 특정 분야 과업에 이상적임
- 최고의 경제성과 속도: 경량 인프라 혹은 온디바이스에서 매우 낮은 코스트로 운영, 즉각적 응답 제공 가능함
- 빠른 개발 및 배포: 모델 크기가 작아, 파인튜닝 실험 및 최적화/테스트 과정이 수 시간 내로 이루어짐
- 개인정보 보호: 클라우드 전송 없이 디바이스 온보드 처리 가능, 민감 정보 보장에 유리함
- 맞춤 특화모델 운영: 예산 부담 없이 다양한 목적별 모델을 동시에 구축·배포 가능함
파인튜닝 가이드 제공
Gemma 3 270M은 Gemma 3 다른 모델과 동일한 구조 및 툴킷을 제공하여, 빠른 파인튜닝 및 자체 솔루션 제작 환경을 지원함. 풀 파인튜닝에 필요한 가이드를 공식 문서를 통해 손쉽게 참고할 수 있음.
Gemmaverse의 기본 철학은 모든 크기의 혁신을 지향하는 것임. Gemma 3 270M으로 개발자는 더 똑똑하고, 빠르고, 효율적인 AI 솔루션을 만들 수 있는 역량을 얻게 됨. 다양한 맞춤형 특화 AI 모델 구축에 대한 기대감이 높아짐.
Hacker News 의견
-
나는 이 모델들을 멋진 팀과 함께 만들었음, 그리고 오픈 모델 생태계 전반에서 다운로드할 수 있으니 모두 한번씩 사용해 보길 추천함. 우리는 모델의 크기에 비해 강력한 성능을 목표로 설계했고, 사용 사례에 맞게 누구나 쉽게 파인튜닝할 수 있도록 했음. 작은 모델 크기 덕분에 다양한 하드웨어에서 실행할 수 있고, 파인튜닝 비용도 매우 저렴함. 직접 무료 Colab에서 5분 이내로 파인튜닝해 볼 수 있음. Gemma 사이즈 선택을 위한 가이드로 직접 녹화한 1b ~ 27b, 그리고 최근 추가된 270m 버전 소개 영상을 참고하면 좋음 유튜브 링크. 나는 Google에서 연구자로 일하고 있지만 여기 의견은 모두 개인적인 견해임. 기술적 질문에 초점을 맞춰 최대한 많이 공유할 예정임
-
Gemma 3 모델 정말 멋지다고 생각함. 노르웨이어 생성도 괜찮고, 인스트럭션 팔로잉도 대부분의 경우 좋은 편임. 하지만 검열과 관련된 문제로 보이는 부분이 있는데, 특히 진지한 주제에서는 지침과 다르게 너무 보수적으로 행동함. 예를 들어 플레이어가 서로를 죽일 수 있는 게임에서 대화 메시지가 실제 위협인지, 게임 내 위협인지 분류하도록 요청해도 잘 동작하지 않음. 게임 내 위협인지 불분명할 땐 게임 관련으로 분류하라고 해도 안전 위주로 편향되는 경향 있음. 심지어 도움말 라인을 내보내는 경우도 있음. 모델이 안전하게 동작해야 한다는 훈련 영향일 것 같은데, 혹시 이유를 아는지 궁금함
-
BSidesSF에서 만났던 멋진 Google 엔지니어가 생각남. 질문에 성심성의껏 대답해줬던 분인데, 영상을 클릭하니 바로 당신이었음! 매우 영감을 받았던 순간이었음, 고마움
-
파인튜닝된 버전의 실제 사례가 있다면 공유해줄 수 있는지 궁금함. 설명만으로도 좋고, 데모나 심지어 모델 웨이트(GGUF 포맷이면 더 좋음)를 다운로드할 수 있다면 최고임
-
이건 정말 멋진 일임. 실제로 270M 파라미터급 모델이 이렇게 효율적으로 나온다는 게 드물음. 아키텍처 선택도 새롭고 흥미로움. 혹시 더 자세한 학습 정보를 공유해줄 수 있는지 궁금함. 임베딩 파라미터가 170M인데, 학습 중 임베딩 붕괴 없이 임베딩 매트릭스를 어떻게 안정적으로 유지했는지 궁금함. 파라미터 분할(170m/100m)에 대한 내부 실험이나 성능 트레이드오프에 대해 더 들려줄 수 있는 자료가 있는지 알고 싶음. 모델 전체 시리즈에 감사함
-
정말 인상적인 작업임. 이 모델은 요약이나 자동완성과 같은 1회성 작업에서 매우 좋게 느껴짐. 출시일에 quantized aware training 버전까지 공개한 점도 매우 좋음, 덕분에 모델이 더 작아졌음
-
-
270M-F16 모델과의 대화가 인상적이었음. "지구에서 두 번째로 높은 산은?"이라고 물어보니 "에베레스트"라고 계속 대답함. "그럼 첫 번째는?"에도 "에베레스트"라고 함. "세 번째는?" "네 번째는?" 모두 "에베레스트"라고 대답함. "이미 제일 높은 산이 에베레스트라 했잖아"라고 하니까 "맞음, 기쁨"이라는 반응을 보임. 계속해서 두 번째로 높은 산을 묻는데도 "에베레스트"라는 답변만 반복함. 결국 "1~5위 산 리스트"를 요구했을 때에야 1. 에베레스트, 2. K2, 3. Sahel, 4. Fuji, 5. McKinley라고 답변을 바꿈. "그러면 두 번째로 높은 산은 K2지?"라고 해도 계속 "에베레스트"라고 답변함. 이런 소형 모델은 훌륭하지만, 정말로 유아와 대화하는 기분임
-
이 모델은 270M 정도의 파라미터로, 1B의 1/3 수준임. 본질적으로는 약간의 행렬 곱셈만 하는 셈이라 많은 지식, 문법, 일관성을 기대할 수 없음. 이런 1B 미만의 모델은 특정 목적에 최적화된 특화 모델임. 예시로, 고객 리뷰에서 JSON 객체로 정보를 추출하는 등 입력 텍스트를 프로그램에서 의미 있게 사용할 수 있는 형태로 변환하는 용도에 적합함. 이런 모델은 기대하는 데이터에 대해 매우 적극적으로 파인튜닝해야 결과가 좋아짐. 결국 270MB 모델이 파인튜닝으로 원하는 결과를 낼 수 있다면 굳이 32GB짜리 범용 모델을 쓸 필요가 없음
-
여기에 덧붙여, 우리는 애초에 완벽한 사실 대응성을 목표로 하지 않았음. 모델 사이즈와 무관하게 이 가중치는 이미 고정되어 있음. 추천하고 싶은 건 RAG 시스템과 연결해서 외부 지식에 의존하거나, 원하는 사실만 담아 직접 파인튜닝하는 것임. 새로운 지식도 빠르게 습득함
-
270M 모델을 백과사전적 지식 테스트에 쓰는 건, 압축이 심한 JPG 파일을 보고 "화질이 깨지네"라고 감상하는 것과 같음
-
프롬프트를 보면 지식 평가를 하려는 것 같은데, 이 모델은 그 용도에 맞지 않음. 블로그 포스트에서 언급했듯이, "텍스트 분류나 데이터 추출 등에서 정확성, 속도, 비용 측면에서 뛰어난 성능을 보임"
-
"파리 2일 여행 일정 짜줘" 요청에 대한 답변으로, 파리의 명소, 랜드마크, 미술관 탐방, 다양한 먹거리 체험, 마레 지구와 라탱 지구 산책, 오르세 미술관 방문 등 구체적인 여행 일정을 시간별로 안내함. 여행 준비 팁도 꼼꼼하게 제공함
-
-
이 모델은 정말 재밌음. 241MB 정도로 아주 작은 크기에 엄청 빠르면서도, 거의 모든 것을 자유롭게 "환각"으로 만들어냄. 예를 들어 "자전거를 타는 펠리컨의 SVG를 생성해줘" 요청에 대해, 모델이 시를 써줬음(예: '이건 고양이, 커다란 날개와 행복한 꼬리', '자전거 불빛이 밝게 빛난다', '모험할 준비가 되어 있다' 등). 여러 개의 시도 결과를 Gist로 올렸음. 앞으로 선정된 작업에 쓸 수 있는 유용한 결과물을 낼 수 있게 파인튜닝된 모델이 나오길 기대함
-
이 시도에서 크게 웃었음. 시인지 노래인지 뭔가를 생성하더니, 각각의 줄이 SVG에 어떻게 반영되는지 설명하면서, "이 SVG 코드는 장면을 명확하고 시각적으로 전달함"으로 마무리함
-
ollamas ggufs를 사용 중인 것을 봤음. 기본값으로 Q4_0 양자화 모델을 받게 되는데,
gemma3:270m-it-bf16
을 사용하거나, unsloth ggufs의hf.co/unsloth/gemma-3-270m-it-GGUF:16
으로 더 나은 결과를 얻을 수 있음 -
쓸모 없는 토큰을 많이 만들어내기도 하지만, 정말 엄청난 양의 토큰을 쏟아냄
-
241MB 다운로드면 플로피 디스크 170장 이상이 필요함
-
"율리우스 카이사르는 언제 태어났나요?"라는 질문에 "율리우스 카이사르는 로마에서 태어났음"이라는 답이 나옴. 아름다움 :D(이걸 깎아내리려는 게 아니라, 길들이는 데 더 노력이 들어갈 거라는 의미임)
-
-
Apple도 이런 모델을 해야 한다고 생각함. 만약 검색 계약을 AI 계약으로 대체하는 게 목적이 아니라면, Apple이 이렇게 존재감이 없는 게 너무 이상함. Tim Cook이 "우리가 가져가야 할 기회"라고 했지만 요즘 행보를 보면 방향을 잃은 느낌임. Google 화이팅임
-
HN의 모든 LLM 스레드에서 나오는 말인데, LLM은 아직 바보 같고 쓸모없다고들 함. 그 말에는 동의하지 않지만, 지금까지 어느 기업도 장기적으로 투자 가치가 충분히 입증된 AI 활용법을 찾지 못한 게 사실임. Apple은 늘 늦게 시장에 진입해도(예: MP3, 스마트폰, 스마트워치) 혁신적인 제품으로 경쟁을 압도한 전력이 있음
-
GPT2 수준의 모델이 이미 Apple 자동완성에서 사용되고 있음 자세한 내용 링크
-
"이런" 모델이 SLM(소형 언어 모델)이라면, Apple이 이미 오래전부터 관련 연구를 진행해 온 것이 사실임
-
Apple 역시 하고 있음. 공식 문서도 존재함 Foundation Models Doc. 최신 베타 설치 시 직접 API 호출 가능함. 추가로, 거의 모든 기기에 적용되는 모델에 대해서 파인튜닝도 공식 지원함 관련 문서
-
Apple은 이런 모델을 출시하지 않을 것임. 이미 다른 댓글에서 알 수 있듯이, 지금 당장은 성능이 부족함. 실사용에서 적당한 속도로 토큰을 뽑으면서 기기가 과열되지 않고, 헛소리를 내뱉지 않는 모델을 찾기 정말 어려움(직접 여러 개 써봤음). Apple은 항상 미완성/완성도 낮은 제품을 선호하지 않고, 차라리 출시를 미룸
-
-
나는 DistilBERT를 활용해 wordpress 글 분류 작업을 하고 있음. 데이터가 10만 개 이상이고, 파인튜닝 후 레포트까지 충분히 만들 수 있음. 분포가 고르지 않아도 트릭으로 어느 정도 해결 가능함. 앞으로 이 모델로 교체하고 성능을 비교해 볼 예정이고, 변화가 있으면 공유할 계획임
- 특정 용도의 파인튜닝이라면 ModernBERT가 더 나은 베이스 모델이 될 수 있음 ModernBERT 소개
-
사용자가 이렇게 작은 모델을 실제 파인튜닝해 프로덕션에 적용한 현실적 사례가 있는지 궁금함
-
RAG 시스템용 reranker를 작은 모델로 만든 경험이 있음. 후보 생성(벡터 검색+BM25)과 비즈니스 로직, ACL 필터 후에 남은 텍스트 청크가 실제로 쿼리와 연관이 있는지 tiny 모델로 판단해서 필터링함. 실제 프로덕션에 들어갔지만, 모델들의 컨텍스트 크기가 커지면서 가격 문제와 품질 문제로 해당 모듈은 결국 빠짐. 그래도 잠시나마 운영된 것은 사실임
-
우리 회사는 작은 모델로 선별해, 신뢰도가 높으면 ChatGPT로 확인하는 방식으로 확장하고 있음. 이 방법을 언어 감지에도 적용해 볼 계획임. 기존 오픈 소스 ML 모델들은 혼합 언어/문장 길이/특정 도메인에서 약점이 있음(예: 성경 번역에만 훈련된 경우 등)
-
어디에 쓸 지는 애매하지만, 태그 생성 정도에는 쓸 만할 것 같음. 이 정도 크기의 인코더는 다른 특정 작업에서 오히려 크게 앞설 때도 있음
-
기억이 맞으면, 안드로이드(특히 Pixel)에서 온디바이스 어시스턴트 등에 fine-tuned Gemma 모델을 쓰고 있음
-
9gag.com 댓글용
-
-
요즘 모델 최적화 경쟁이 치열한데, 불필요한 언어/도메인 정보를 빼면 얼마나 파라미터를 줄일 수 있는지 궁금했음. 예를 들어 영어만 지원하면, 중국어나 유럽 언어를 빼고 같은 파라미터 안에서 더 많은 작업을 가능하게 할 수 있을지 궁금함
-
이 질문이 바로 우리가 이 모델을 만들 때 가장 고민한 부분임. "얼마나 많은 작업에서 얼마나 잘 하고자 하는가"에 따라 트레이드오프가 발생함. 다른 데이터, 다른 트레이닝 전략을 선택해 성능을 측정해야 함. 실제로 자신의 작업셋에 모델을 훈련해 성능 트레이드오프를 평가해보라 권장함. 이런 시도로 LLM의 역량 변화를 직접 체감할 수 있음
-
실제로 그렇게 간단하게 되지는 않음. transfer learning(전이 학습)을 참고하면 좋음
-
-
2025년에 발표된 LLM을 내 아이폰에서, BF16 전체 정밀도로 실행하게 될 줄은 정말 몰랐음. 아이폰 16 프로에서 초당 80 토큰 정도 나옴
- 아이폰에서 이 모델을 실제로 어떻게 돌렸는지 방법이 궁금함
-
기사에 첨언하자면, Gemma 3 270M의 정확한 IFEval 점수는 51.2임. Qwen 3는 산점도상에서 (0.6, 59.2)에 위치함
-
프롬프트 선택이 이 모델 성능에 엄청난 영향을 미친다는 점을 언급함. NER이나 POS 태깅은 다소 실망스러웠음. 하지만 비인도유럽어 번역(예: 타이, 인도네시아어를 영어로 번역)은 놀랄 만큼 잘 작동했음