Gemma와 Gemini는 다른 모델보다 출력 토큰을 훨씬 적게 쓰면서도 최상위 벤치마크 성능에 꽤 근접해 있음
Gemma와 Qwen을 비교하면 Qwen이 조금 더 잘하지만 작업에 22분을 쓰고, Gemma는 버튼 정렬을 틀리더라도 같은 프롬프트를 4분 만에 끝내는 경우가 흔함
겉보기로는 Gemma가 선두 오픈 모델보다 5~10% 낮은 성능을 내지만, 시간은 1/10만 쓰는 셈임
체감상 월 15달러짜리 Gemini 기본 플랜으로 하루 종일 코딩해도 한도에 걸리지 않음
Claude나 Codex에서 다른 사람들이 월 100달러 플랜으로 올리는 것처럼 업그레이드할 필요도 못 느낌
다만 Gemini는 지난 1년 동안 몇 번 성능이 낮아졌고, 속도 제한도 빡빡해졌기 때문에 앞으로도 이만큼 좋을지는 모름
Dwarkesh 팟캐스트에서 SemiAnalysis의 Dylan Patel이 Google은 훨씬 많은 연산 자원과 TPU 접근성 덕분에 경쟁사보다 큰 모델을 감당할 수 있다고 했음
같은 지능 단위당 큰 모델이 보통 더 적은 토큰을 쓰므로, 토큰 사용량 차이를 설명할 수 있어 보임
Gemma가 빠르다 보니 원래는 크기가 부족한 GPU에서도 돌릴 수 있음
4070에서 실행해 봤는데 출력이 엄청 빠르진 않아도 쓸 만했음
아직 복잡한 작업에는 써보지 않았고, 그런 경우엔 다를 것 같음
지금은 Claude가 매우 유행하지만, Gemini를 쓰면서 문제를 겪거나 갈아탈 필요를 느낀 적은 없음
Google I/O 이후에는 더 많은 사람이 Gemini가 얼마나 좋은지 알게 될지도 모름
맞는 말이지만 공정하게 보려면 누적 토큰 출력량을 합산해야 함
정렬 문제가 생기면 이를 고치기 위해 입력·출력 토큰을 한 번 더 써야 함
MTP 추론이 추론 스택의 어디에 들어가는지는 정확히 모르겠지만, MLX 생태계에서 구현 가능한지 아는 사람이 있으면 궁금함
Google이 서구권 오픈소스 모델을 거의 혼자 떠받치고 있음
Gemma 4 31B는 훌륭함
다만 시각 기능과 곧 나올 드래프터까지 포함해 최상의 버전을 24GB VRAM에 맞추려면 꽤 고통스러움
내 빌드는 GPU를 더 추가할 수 없고, 최고 성능을 내려면 4090을 하나 더 사야 할 것 같은데 너무 비싸거나, 아니면 아예 교체해야 할 듯함
llama.cpp에서 --no-mmproj-offload를 쓰면 멀티모달 프로젝터, 즉 오디오·이미지·PDF 이해 부분을 시스템 RAM에 둘 수 있음
물론 그러면 GPU 가속은 안 되지만 VRAM은 절약됨
그래도 Qwen이 Gemma보다 낫다고 봄
작업별로 더 조정할 수도 있어서, 사고와 정확도를 우선할지 추론 속도를 우선할지 선택 가능함
컴퓨터가 글을 쓰는 걸 보고 있으면 예전 BBS에 모뎀으로 접속하던 시절이 떠오름
이건 300 보드에서 1200 보드로 올라간 것 같은 느낌이라 큰 개선이긴 하지만 여전히 꽤 느리고, 언젠가는 우리가 이걸 어떻게 참고 썼는지 의아해할 것 같음
요즘 상태는 정말 전화 접속 시대 같고, 앞으로의 “광대역” 시대가 어떤 모습일지 계속 생각하게 됨
토큰이 흘러나오는 걸 보는 건 JPEG가 픽셀 몇 줄씩 로드되는 걸 보는 느낌이고, 앱들이 속도가 충분히 빨라지기 전 각자 구현하던 여러 로딩·연결 애니메이션도 떠오름
Cerebras나 Taalas가 하는 작업은 그런 방향에서 무엇이 가능할지 보여주는 흥미로운 단서임
지금 최첨단 모델도 초당 백만 토큰을 아주 낮은 비용으로 쓸 수 있다면 무엇이 가능할지 상상해 보는 것도 재미있음
전화 접속 시대를 떠올리게 한다는 건 맞지만, 300에서 1200이라기보다는 4800 보드에 더 가까워 보임
Claude가 계산한 모뎀 대 Claude 비교는 이렇음: 2368자 기준 300은 1분 19초, 1200은 19.7초, 2400은 9.9초, 14.4K는 1.6초, 33.6K는 705ms, 56K는 447ms, Claude는 7.9초임
여기 올라왔던 어떤 스타트업은 AI가 즉시 응답하게 하는 맞춤형 하드웨어를 만들었음
초당 수천 토큰 수준이었음
Google의 전략은 다른 프런티어 제공자들과 조금 다른 것 같음
순수 성능보다 연산 대비 성능 효율에 더 집중하는 듯하고, 그래서 Gemini가 겉보기에는 뒤처져 보이는 걸지도 모름
다른 제공자들은 용량 한계에 부딪히고 추론 비용 보조에도 한계가 오는 중임
Google의 전략은 이 모델들을 기존 수십억 사용자에게 확장하고 배포하는 쪽으로 보임
Gemini가 뒤처진다고 보지는 않음
오히려 최신 GPT-5와 Claude 계열과는 다른 종류의 지능처럼 느껴짐
후자는 점점 생산성과 업무 자동화에 집중하고, 길고 에이전트적인 자기수정 추론 루프에 최적화되어 있음
Gemini는 훨씬 똑똑한 기본 모델 같고, 특히 Deep Think 모드에서는 직관이 훨씬 깊게 느껴지지만, 장거리 자기수정형 에이전트 루프는 그만큼 잘하지 못함
몇 달 동안 내 작업 흐름은 창의적 도약과 통찰에는 Gemini를 쓰고, 반복적이거나 정밀한 작업에는 Codex, Claude, GPT-5.5 Pro를 선호하는 방식이었음
그 방향으로 모두의 전략이 바뀌는 중 아닌가 싶음
로컬 모델을 한동안 쉬다가 최근 26B A4B 모델을 RTX 3090에서 vLLM 4비트로 설정했는데, 1000달러 미만 투자로 얻을 수 있는 속도와 품질에 완전히 놀랐음
처음엔 Qwen으로 해봤지만 불안정했고, 사고 흔적이 터무니없이 길었음
qwen3.6의 초기 양자화본 중 일부는 깨져 있었음
아직도 까다롭긴 하지만 조금만 손봐주면 정말 대단함 로컬 모델이 미래라서 멋짐
turboquant / Q4를 쓰면 3060에도 올라가고, 약 200달러 카드에서 괜찮은 속도인 40T/s가 나옴
A4B 모델은 엄청 빠르고 일반 질의에 매우 좋음
코딩 작업에서는 Qwen 3.6보다 확실히 떨어지지만, 그건 오히려 Qwen 모델이 뛰어나다는 뜻에 가까움
31B도 조밀 모델치고는 놀라울 만큼 빠름
내 컴퓨터에서는 다른 30B 모델과 비교했을 때 tg가 기대보다 적어도 두 배 빠른데, 아마 하이브리드 어텐션 덕분인 듯함
다만 입력 처리 쪽은 조금 더 느림
이걸 LM Studio에서 동작시키는 데 성공한 사람이 있는지 궁금함
UI에 옵션은 있는데 활성화가 되는 것 같지 않음
됨
작은 모델이 없으니 Gemma 희소 모델을 쓰고 있지 않은지 확인해야 함
그리고 작업 공간에서 이미지 모델을 전부 제거했음
보통 LM Studio가 싫어하는 경우는 폴더 안에 mmproj 파일이 있을 때임
가끔 이것들을 지우면 표시되기도 함
이 파일들이 어떻게든 시각 기능과 연결되어 있고 추측 디코딩을 막는 듯한데, 이유는 묻지 말아 달라
Gemma에서는 LM Studio보다 llama-server 경로로 추측 디코딩을 쓰는 쪽이 더 잘 됐음
다른 모델로는 동작시킨 적 있음
보통 제공자, 양자화 등에서 서로 완벽히 맞아야 함
짝이 맞는 세트를 구하려면 시간이 좀 걸릴 수 있음
내 테스트에서는 Gemma 4 31B 모델이 코딩 작업에서 Ollama의 MLX 러너를 쓸 때 가장 큰 속도 향상을 보였고, 대략 2배였음
다만 양자화가 수락률을 크게 깎기 때문에 꽤 강력한 Mac이 필요함
다른 세 개의 더 작은 모델은 드래프트 모델 검증 시간이 성능 향상을 대부분 먹어버려서 그만큼 좋지 않았음
더 나은 성능을 낼 수 있는지 아직 조정 중임
Ollama 0.23.1에서 ollama run gemma4:31b-coding-mtp-bf16를 실행해 시험해 볼 수 있음
llama.cpp에 병합되면 정말 빨리 써보고 싶음
내 환경에서는 Gemma 4 26B-A4B가 Qwen3.6-35B-A3B보다 약 3배 빠르기 때문에, 여기에 1.5배 가속이 더해진다는 생각만 해도 끌림
드래프트 모델도 시도했지만 성과는 제한적이었고, 더 작은 3B 드래프트 모델과 조밀 14B Ministral 모델도 이미 너무 많은 오버헤드를 만들었음
vLLM에서 5090을 쓰면 awq 4비트 양자화와 MTP 추측 디코딩으로 120~180TPS가 나옴
Gemma4 26B는 같은 양자화에서 200TPS를 넘음
Qwen은 추론 효율이 극도로 낮다는 점도 중요함
사고 사슬이 평균적으로 Gemma보다 약 3배 김
이건 운영체제의 분기 예측 같은 건가 싶음
다만 확률이 모델 자체에 내장되어 있으니 훨씬 더 신뢰할 수 있는 형태임
Hacker News 의견들
Gemma와 Gemini는 다른 모델보다 출력 토큰을 훨씬 적게 쓰면서도 최상위 벤치마크 성능에 꽤 근접해 있음
Gemma와 Qwen을 비교하면 Qwen이 조금 더 잘하지만 작업에 22분을 쓰고, Gemma는 버튼 정렬을 틀리더라도 같은 프롬프트를 4분 만에 끝내는 경우가 흔함
겉보기로는 Gemma가 선두 오픈 모델보다 5~10% 낮은 성능을 내지만, 시간은 1/10만 쓰는 셈임
Claude나 Codex에서 다른 사람들이 월 100달러 플랜으로 올리는 것처럼 업그레이드할 필요도 못 느낌
다만 Gemini는 지난 1년 동안 몇 번 성능이 낮아졌고, 속도 제한도 빡빡해졌기 때문에 앞으로도 이만큼 좋을지는 모름
같은 지능 단위당 큰 모델이 보통 더 적은 토큰을 쓰므로, 토큰 사용량 차이를 설명할 수 있어 보임
4070에서 실행해 봤는데 출력이 엄청 빠르진 않아도 쓸 만했음
아직 복잡한 작업에는 써보지 않았고, 그런 경우엔 다를 것 같음
Google I/O 이후에는 더 많은 사람이 Gemini가 얼마나 좋은지 알게 될지도 모름
정렬 문제가 생기면 이를 고치기 위해 입력·출력 토큰을 한 번 더 써야 함
llama.cpp에 MTP 지원이 추가되고 있고, 적어도 Qwen 모델용으로는 진행 중임(https://github.com/ggml-org/llama.cpp/pull/20533)
Gemma 4도 곧 따라올 것 같음
최근 몇 달 동안 로컬·자체 호스팅 모델의 품질과 속도 향상이 놀라울 정도임
오랫동안 로컬 모델을 돌려온 입장에서는 정말 흥미로운 시기임
MTP와 비교하면 어떨지 빨리 보고 싶음
꽤 괜찮은 도구였음
Google이 서구권 오픈소스 모델을 거의 혼자 떠받치고 있음
Gemma 4 31B는 훌륭함
다만 시각 기능과 곧 나올 드래프터까지 포함해 최상의 버전을 24GB VRAM에 맞추려면 꽤 고통스러움
내 빌드는 GPU를 더 추가할 수 없고, 최고 성능을 내려면 4090을 하나 더 사야 할 것 같은데 너무 비싸거나, 아니면 아예 교체해야 할 듯함
--no-mmproj-offload를 쓰면 멀티모달 프로젝터, 즉 오디오·이미지·PDF 이해 부분을 시스템 RAM에 둘 수 있음물론 그러면 GPU 가속은 안 되지만 VRAM은 절약됨
작업별로 더 조정할 수도 있어서, 사고와 정확도를 우선할지 추론 속도를 우선할지 선택 가능함
컴퓨터가 글을 쓰는 걸 보고 있으면 예전 BBS에 모뎀으로 접속하던 시절이 떠오름
이건 300 보드에서 1200 보드로 올라간 것 같은 느낌이라 큰 개선이긴 하지만 여전히 꽤 느리고, 언젠가는 우리가 이걸 어떻게 참고 썼는지 의아해할 것 같음
토큰이 흘러나오는 걸 보는 건 JPEG가 픽셀 몇 줄씩 로드되는 걸 보는 느낌이고, 앱들이 속도가 충분히 빨라지기 전 각자 구현하던 여러 로딩·연결 애니메이션도 떠오름
Cerebras나 Taalas가 하는 작업은 그런 방향에서 무엇이 가능할지 보여주는 흥미로운 단서임
지금 최첨단 모델도 초당 백만 토큰을 아주 낮은 비용으로 쓸 수 있다면 무엇이 가능할지 상상해 보는 것도 재미있음
Claude가 계산한 모뎀 대 Claude 비교는 이렇음: 2368자 기준 300은 1분 19초, 1200은 19.7초, 2400은 9.9초, 14.4K는 1.6초, 33.6K는 705ms, 56K는 447ms, Claude는 7.9초임
초당 수천 토큰 수준이었음
Google의 전략은 다른 프런티어 제공자들과 조금 다른 것 같음
순수 성능보다 연산 대비 성능 효율에 더 집중하는 듯하고, 그래서 Gemini가 겉보기에는 뒤처져 보이는 걸지도 모름
다른 제공자들은 용량 한계에 부딪히고 추론 비용 보조에도 한계가 오는 중임
Google의 전략은 이 모델들을 기존 수십억 사용자에게 확장하고 배포하는 쪽으로 보임
오히려 최신 GPT-5와 Claude 계열과는 다른 종류의 지능처럼 느껴짐
후자는 점점 생산성과 업무 자동화에 집중하고, 길고 에이전트적인 자기수정 추론 루프에 최적화되어 있음
Gemini는 훨씬 똑똑한 기본 모델 같고, 특히 Deep Think 모드에서는 직관이 훨씬 깊게 느껴지지만, 장거리 자기수정형 에이전트 루프는 그만큼 잘하지 못함
몇 달 동안 내 작업 흐름은 창의적 도약과 통찰에는 Gemini를 쓰고, 반복적이거나 정밀한 작업에는 Codex, Claude, GPT-5.5 Pro를 선호하는 방식이었음
로컬 모델을 한동안 쉬다가 최근 26B A4B 모델을 RTX 3090에서 vLLM 4비트로 설정했는데, 1000달러 미만 투자로 얻을 수 있는 속도와 품질에 완전히 놀랐음
처음엔 Qwen으로 해봤지만 불안정했고, 사고 흔적이 터무니없이 길었음
아직도 까다롭긴 하지만 조금만 손봐주면 정말 대단함
로컬 모델이 미래라서 멋짐
코딩 작업에서는 Qwen 3.6보다 확실히 떨어지지만, 그건 오히려 Qwen 모델이 뛰어나다는 뜻에 가까움
내 컴퓨터에서는 다른 30B 모델과 비교했을 때 tg가 기대보다 적어도 두 배 빠른데, 아마 하이브리드 어텐션 덕분인 듯함
다만 입력 처리 쪽은 조금 더 느림
이걸 LM Studio에서 동작시키는 데 성공한 사람이 있는지 궁금함
UI에 옵션은 있는데 활성화가 되는 것 같지 않음
[1] https://github.com/ml-explore/mlx-lm/pull/990
[2] https://github.com/ggml-org/llama.cpp/pull/22673
작은 모델이 없으니 Gemma 희소 모델을 쓰고 있지 않은지 확인해야 함
그리고 작업 공간에서 이미지 모델을 전부 제거했음
가끔 이것들을 지우면 표시되기도 함
이 파일들이 어떻게든 시각 기능과 연결되어 있고 추측 디코딩을 막는 듯한데, 이유는 묻지 말아 달라
Gemma에서는 LM Studio보다 llama-server 경로로 추측 디코딩을 쓰는 쪽이 더 잘 됐음
보통 제공자, 양자화 등에서 서로 완벽히 맞아야 함
짝이 맞는 세트를 구하려면 시간이 좀 걸릴 수 있음
내 테스트에서는 Gemma 4 31B 모델이 코딩 작업에서 Ollama의 MLX 러너를 쓸 때 가장 큰 속도 향상을 보였고, 대략 2배였음
다만 양자화가 수락률을 크게 깎기 때문에 꽤 강력한 Mac이 필요함
다른 세 개의 더 작은 모델은 드래프트 모델 검증 시간이 성능 향상을 대부분 먹어버려서 그만큼 좋지 않았음
더 나은 성능을 낼 수 있는지 아직 조정 중임
Ollama 0.23.1에서
ollama run gemma4:31b-coding-mtp-bf16를 실행해 시험해 볼 수 있음llama.cpp에 병합되면 정말 빨리 써보고 싶음
내 환경에서는 Gemma 4 26B-A4B가 Qwen3.6-35B-A3B보다 약 3배 빠르기 때문에, 여기에 1.5배 가속이 더해진다는 생각만 해도 끌림
드래프트 모델도 시도했지만 성과는 제한적이었고, 더 작은 3B 드래프트 모델과 조밀 14B Ministral 모델도 이미 너무 많은 오버헤드를 만들었음
Gemma4 26B는 같은 양자화에서 200TPS를 넘음
Qwen은 추론 효율이 극도로 낮다는 점도 중요함
사고 사슬이 평균적으로 Gemma보다 약 3배 김
이건 운영체제의 분기 예측 같은 건가 싶음
다만 확률이 모델 자체에 내장되어 있으니 훨씬 더 신뢰할 수 있는 형태임
분기 예측 실패는 사이클을 태워버리지만, 여기서 나쁜 추측은 보통 보너스 토큰을 못 얻는 정도임
https://arxiv.org/abs/2211.17192