구글 Gemma 3 270M: 초고효율 AI를 위한 컴팩트 모델 공개

• Gemma 3 270M은 2억 7천만 파라미터의 경량 모델로, 강력한 지시문 수행 능력과 텍스트 구조화 기능을 갖춤
• 256k 토큰의 대규모 어휘 집합을 통해 희귀 토큰 처리에 강하며, 특정 도메인과 언어에 맞춘 파인튜닝 기반 모델로 설계
• Pixel 9 Pro SoC에서 INT4 양자화 모델이 25회 대화에 배터리 0.75%만 소모하는 등 에너지 효율이 뛰어남
• 대규모 범용 모델 대신 소형 특화 모델을 다수 운용해 속도·비용·정확성을 모두 확보하는 전략에 적합
• 온디바이스 실행, 빠른 반복 실험, 저비용 운영이 필요한 고정형 업무에 최적화되어 다양한 AI 애플리케이션 구축 가능

---

Gemma 3 270M 개요

• Google이 Gemma 3 및 Gemma 3 QAT에 이어 새롭게 공개한 소형 특화 파인튜닝용 모델
• 270M 파라미터 중 1억 7천만은 임베딩, 1억은 트랜스포머 블록에 할당됨
• 256k 토큰의 대규모 어휘로 희귀·특수 토큰 처리 가능
• 사전 학습(pretrained)과 지시문 튜닝(instruction-tuned) 버전 모두 제공

주요 특징

• 컴팩트하면서 강력한 구조: 특정 도메인/언어 맞춤 파인튜닝에 이상적
• 극도의 에너지 효율: Pixel 9 Pro SoC에서 INT4 모델이 25회 대화 시 배터리 0.75%만 사용
• 지시문 수행력: 범용 대화보다는 과업 중심에 최적화, 기본 상태에서도 지시문 수행 가능
• 양자화 지원(QAT): INT4 정밀도로 성능 저하 최소화, 자원 제약 환경에 적합

‘적재적소’ 철학

• AI 설계 시 효율성 중심의 접근을 강조
• 작은 모델로 빠른 응답과 저비용 운영 가능
• 텍스트 분류, 데이터 추출 등 명확한 과업에 특화 시 높은 성능 발휘

실제 적용 사례

• Adaptive ML이 SK텔레콤의 다국어 콘텐츠 모더레이션에 Gemma 3 4B 모델을 파인튜닝해 대규모 독점 모델을 능가하는 성능 달성
• 270M 모델은 이 접근을 더 작은 규모로 확장해, 특화 작업군별 ‘전문 모델’을 대량 생성 가능
• Hugging Face의 웹 기반 Bedtime Story Generator 앱은 Gemma 3 270M을 통해 오프라인 혹은 웹 브라우저 내에서 실시간 콘텐츠 생성이 가능

적합한 사용 시나리오

• 명확하고 대량의 과업 처리: 감정 분석, 엔티티 추출, 질의 라우팅, 텍스트 변환, 창작, 컴플라이언스 검사 등 특정 분야 과업에 이상적임
• 최고의 경제성과 속도: 경량 인프라 혹은 온디바이스에서 매우 낮은 코스트로 운영, 즉각적 응답 제공 가능함
• 빠른 개발 및 배포: 모델 크기가 작아, 파인튜닝 실험 및 최적화/테스트 과정이 수 시간 내로 이루어짐
• 개인정보 보호: 클라우드 전송 없이 디바이스 온보드 처리 가능, 민감 정보 보장에 유리함
• 맞춤 특화모델 운영: 예산 부담 없이 다양한 목적별 모델을 동시에 구축·배포 가능함

파인튜닝과 배포

• Hugging Face, Ollama, Kaggle, LM Studio, Docker 등에서 모델 다운로드 가능
• Vertex AI, llama.cpp, Gemma.cpp, LiteRT, Keras, MLX 등 다양한 추론 도구 지원
• Hugging Face, UnSloth, JAX 기반 전체 파인튜닝 가이드 제공
• 로컬 환경부터 Google Cloud Run까지 유연하게 배포 가능

결론

• Gemma 3 270M은 작지만 강력한 기반 모델로, 특정 과업에 최적화된 AI 솔루션 구축을 가속화
• 저비용·고효율·빠른 배포를 동시에 추구하는 개발자에게 이상적인 선택

[kaydash]

.task 파일로 만들어주면 안드로이드 스마트폰에서 마음껏 써볼텐데..

[kaydash]

누가 만들어둔 .task(non web) 파일이 있길래 모바일에서 해봤는데 간결하게, 빠르게 답변 잘 합니다.

하지만 qwen3:0.6b 가(물론 이게 더 무겁겠지만) 더 잘 하는 것 같아요

[GN⁺]

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 태깅은 다소 실망스러웠음. 하지만 비인도유럽어 번역(예: 타이, 인도네시아어를 영어로 번역)은 놀랄 만큼 잘 작동했음