로컬 LLM

로컬 LLM 실험실

로컬 LLM 서빙, 모델 설정, GPU/VRAM, 양자화, 실행 환경 관련 글을 모았습니다.

THREAD ESSAYX THREAD ARCHIVE

못참고 결국 Gemma4 MTP 찍어먹음.

3개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    못참고 결국 Gemma4 MTP 찍어먹음.

    BC-250 12B 20tok/s > 35tok/s 3090 26B 112 tok/s > 147Tok/s 😯

    31B 찍어 먹으러 다녀옵니다. https://t.co/qNxF8j94i5

    원문 보기
  2. 2
    Gemma4 31B 는 역시 256K 풀컨텍스트 쓰기엔 32기가도 조금 버겁네. https://t.co/taiiAuzTwV
    원문 보기
  3. 3

    단발성 토큰 수치라 뒤로 가면 더 떨어집니다.

    그래도 기존에 20 Tok/s 안나왔는데 이정도면 ‘쓸만은 해졌다’ 수준인가 싶네요. https://t.co/Du3ADm4gnP

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님이 공유한 Gemma4 MTP의 추론 속도 향상 수치는 하드웨어별 측정값으로 제시되었으나, 이는 개인의 환경에서 도출된 결과일 뿐 공식 문서나 저장소를 통해 객관적으로 검증된 사실은 아닙니다. 특히 3090 환경에서의 토큰 생성 속도 증가나 31B 모델의 성능 체감에 대한 언급은 주관적 경험에 의존하고 있어, 일반적인 성능 지표로 받아들이기에는 근거가 부족합니다.

반면 31B 모델의 256K 풀 컨텍스트 사용 시 32기가 메모리가 부족하다는 주장은 모델의 파라미터 크기와 컨텍스트 윈도우의 메모리 점유 특성을 고려할 때 기술적으로 타당해 보입니다. 다만, '쓸만해졌다'는 식의 정성적인 판단은 기준이 모호하므로 실제 활용 가능 여부는 추가적인 벤치마크 데이터 확인이 필요합니다. 전반적으로 이번 내용은 공식 지표보다는 개인의 사용 후기에 가까운 성격의 글입니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

THREAD ESSAYX THREAD ARCHIVE

요즘 깃허브, 코덱스, 클로드의 Api 비용을 보면 왜 프로그래머 분들이 더더욱 Local LLM 에 관심을 가지시는지 알 거 같다.

2개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    요즘 깃허브, 코덱스, 클로드의 Api 비용을 보면 왜 프로그래머 분들이 더더욱 Local LLM 에 관심을 가지시는지 알 거 같다.

    다만, 대부분의 로컬 머신과 모델들이 SOTA 수준의 에이전틱 작업을 할 수는 없으니 원래 가지고 계신 지식과 로컬 AI의 보조를 결합한 무언가 있으면 좋겠다는 생각을 한다.

    원문 보기
  2. 2

    이미 커서에다가 연결해 쓰시는 분들은 보았으니, 저녁에 한번 실험해 봐야겠다. 커서에 Quopus 3.6 27b를 연결해 돌려 보고 의미 있는 활용이 가능한지 살펴봐야겠다.

    가능하면 아마 antigravity가 작업 환경에서 제거될 거 같다.

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

최근 클로드와 깃허브 코덱스 등 주요 AI 서비스의 API 비용 상승이 개발자들을 로컬 LLM(Local LLM)으로 유도하고 있다는 Serio님의 분석은 업계의 일반적인 흐름과 궤를 같이합니다. 다만, 로컬 모델이 SOTA(최신 기술 수준)급의 에이전틱 작업을 수행하기 어렵다는 점과 이를 개발자의 기존 지식으로 보완해야 한다는 의견은 개인의 경험적 판단에 가깝습니다. 특히 특정 모델인 'Quopus 3.6 27b'를 커서(Cursor)에 연결해 활용하겠다는 계획이나, 이를 통해 'antigravity'를 작업 환경에서 제거할 수 있다는 주장은 공식 자료로 검증되지 않은 개인적 가설이므로 추가적인 확인이 필요합니다.

기술적으로 로컬 LLM의 구동 가능성은 llama.cpp나 LM Studio 같은 도구를 통해 확인되지만, 특정 모델의 실질적인 효용성은 사용자의 환경과 숙련도에 따라 크게 달라집니다. API 비용이라는 경제적 요인이 로컬 전환의 트리거가 된 것은 사실이나, 그것이 곧바로 상용 모델 수준의 생산성 대체로 이어질지는 미지수입니다. 결국 로컬 AI의 실효성은 단순한 비용 절감을 넘어, 실제 작업 공정에서 어느 정도의 보조 능력을 보여주느냐에 달려 있다고 생각합니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

LM Studio

Documentation

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

Anthropic Docs

Claude models overview

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

SINGLE POSTX POST ARCHIVE

llama.cpp 의 Gemma4 12B Mtp 가 BC-250 에서 디코딩 35Tok/S 인데 그럼 맥 M3/M4 에서 그럼 40 Toks/s 정도가 예상되고 이쯤이면 속도는 실용 영역이라 이후 꽤 인기를 끌 거

1개 글

Serio의 X 포스트

Serio가 @Multi_Serio_Ai에 게시한 원문 포스트를 보존한 글입니다. X 원문 포스트

원문 글: https://x.com/Multi_Serio_Ai/status/2063964903044763770

llama.cpp 의 Gemma4 12B Mtp 가 BC-250 에서 디코딩 35Tok/S 인데 그럼 맥 M3/M4 에서 그럼 40 Toks/s 정도가 예상되고 이쯤이면 속도는 실용 영역이라 이후 꽤 인기를 끌 거 같다.

반대로 26B-a4b 는 후기가 일단 나쁜데 아마 Moe 모델의 특성과 안 맞는 부분이 있는 것 같은 느낌.

원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 llama.cpp 환경에서 Gemma4 12B Mtp 모델이 BC-250 장치에서 초당 35토큰의 디코딩 속도를 기록했다는 점을 언급하셨습니다. 다만, 이를 근거로 맥 M3 및 M4 칩셋에서 초당 40토큰 정도의 속도가 예상된다는 부분과 이것이 실용 영역에 진입해 인기를 끌 것이라는 전망은 개인적인 추론에 가깝습니다. 하드웨어 간의 성능 차이가 단순 수치로 환산되지 않는 만큼, 실제 맥 환경에서의 벤치마크 결과는 추가적인 확인이 필요합니다.

반면 26B-a4b 모델에 대한 부정적인 후기와 이를 MoE(Mixture of Experts) 모델의 특성 탓으로 돌린 분석은 구체적인 근거가 부족한 주관적 판단입니다. 특정 모델의 성능 저하가 구조적 특성 때문인지, 혹은 구현상의 최적화 문제인지에 대한 기술적 데이터가 제시되지 않았기 때문입니다. 따라서 해당 모델의 성능 이슈와 그 원인에 대해서는 공식 자료를 통한 정밀한 검증이 선행되어야 합니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

THREAD ESSAYX THREAD ARCHIVE

lamma.cpp Gemma4 mtp 지원 병합이 된 모양인데.

2개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    lamma.cpp Gemma4 mtp 지원 병합이 된 모양인데. 드디어 왔나 싶기도 하면서도 과연 잘 될까 싶기도 함. 이번건 선발대 안하고 다른 분들의 결과만 좀 지켜볼 생각.

    https://t.co/BwUX1qd6CE

    많이도 안바라고 한 20% 정도만 빨라졌으면 좋겠네. 그럼 3090에서 Gemma4 31b 30 T/s 가 넘을테니.

    원문 보기
  2. 2

    오타났네 llama! llama! 알파카?

    https://t.co/WvLDGoq2hV

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 llama.cpp 저장소에 Gemma 4의 MTP(Multi-Token Prediction) 지원 기능이 병합되었음을 언급하며, 이에 따른 추론 속도 향상을 기대하고 있습니다. llama.cpp의 공식 저장소 이력을 통해 기술적 병합 여부는 확인이 가능하나, 특정 하드웨어인 RTX 3090에서 Gemma 4 31B 모델의 속도가 30 T/s를 상회할 것이라는 구체적인 수치는 현재로서는 확인이 필요한 영역입니다.

특히 성능이 20% 정도 향상될 것이라는 예측은 개인적인 기대치에 가까우며, 이를 뒷받침할 객관적인 벤치마크 자료는 아직 제시되지 않았습니다. 기술적 구현이 완료되었다 하더라도 실제 체감 속도는 최적화 상태와 환경에 따라 달라지므로, 타 사용자의 결과물을 지켜보겠다는 신중한 접근이 타당해 보입니다. 따라서 해당 성능 향상 폭에 대해서는 추가적인 실측 데이터가 확보될 때까지 유보적인 관점에서 바라볼 필요가 있습니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

THREAD ESSAYX THREAD ARCHIVE

찾아보다가 BC-250을 찐 PS5로 만들어 주는 깃허브 저장소가 있어서 Codex + Superpower 에 Xhigh 로 던져서 적용까지 마치라 해놓고

10개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    찾아보다가 BC-250을 찐 PS5로 만들어 주는 깃허브 저장소가 있어서 Codex + Superpower 에 Xhigh 로 던져서 적용까지 마치라 해놓고

    밥먹으러 다녀옵니다.

    뭐먹징.

    원문 보기
  2. 2

    Codex : ‘저장소는 페도라/바자이트 기준인데, 우리는 우분투잖아요? 커널 빌드 새로할께요~ 이꾸요.’

    10분 후

    ‘원샷 프롬프트 만들어 왔어요. Sudo 로 스크립트 실행해 주세요.’

    3분 후

    ‘잘 됐네요. 코어 속도 1500Mhz 로 했으니 여기서부터 시작해 봅시다. 검증할께요.’

    내 소감 https://t.co/WyWuME0wnd

    원문 보기
  3. 3

    여튼 제 BC-250 이 PS5가 되었단 소식인데요. 심지어 원본 PS2 보다 CU가 2개 더 많은건데요.

    벤치 돌리고 올께요.

    원문 보기
  4. 4
    불행 중 다행인가. 다 불량은 아닌 모양. CU 8개는 살릴 수 있을듯. https://t.co/jNRiNbHAh4
    원문 보기
  5. 5

    코어 8개는 살려 놨는데, llama.cpp와 vulkan 의 부조화가 서빙을 방해하기 시작한다. 모델이 갑자기 정형행동을 하는 앵무새가 되어버림.

    Cuda Cuda 어렵다 독점이다 말 많아도 경쟁자들이 더 엉망이기 때문에 이기는 법이지.

    원문 보기
  6. 6

    작업 결과 : 36/40Cu

    Codex 로 자동스크립트 만들어서 불량 코어 체크.

    2CU가 1 WGP 에 들어가 있는 구조인데, 아예 응답이 없는 WGP 가 1개, 응답은 있으나 정상 작동을 안하는 WGP를 1개 찾아내고 바이패스 처리.

    현재 Gemma4 12b/Qwen 9B 장기 부하 테스트중. 15/30 사이클 진행 중 이상 없음.

    원문 보기
  7. 7

    2000mhz / 1000Mv 의 기본 세팅에선 발열 제어가 안되므로 1500mhz / 900Mv 로 커널 전압 설정 변경. CU가 16개 추가 작동하기 때문에 한 5~10Tok/s 의 성능 향상을 기대 중.

    여기에 Gemma4 12b mtp 적용시키면?

    50Tok/s 만 나오면 좋겠네.

    원문 보기
  8. 8

    성공 야호-!

    18.9 Tok/s > 20.1 Tok/s > 23.87 Tok/s

    여기에 새벽에 올라온 Mtp 붙여서 30~35 Tok/s 붙이면 실사용권! https://t.co/AihX3oLe2o

    원문 보기
  9. 9

    성공 경험 묶어서 자동화 스크립트로 만드는 중.

    역시 /goal 이 이럴때 좋네.

    • CU 활성화
    • 정상 CU 체크 프로세스
    • 커널 작동속도/전압 컨트롤
    • 안정화 검증
    원문 보기
  10. 10

    Gemma4 MTP 대성공 야호-!

    BC-250 / Gemma4 12B Q6 KVQ8 MTP 디코딩 35.13Tok/s!

    이정도면 에이전트나 챗봇에 써도 아무 문제 없는 속도네요. https://t.co/1pXRhlrUl1

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 BC-250 하드웨어의 커널 설정을 변경하여 성능을 끌어올리고, Gemma4 및 Qwen 모델의 추론 속도를 측정하며 실사용 가능 수준의 토큰 생성 속도를 확인했다고 주장합니다. 특히 불량 코어를 체크하여 바이패스 처리하고 전압과 클럭을 조정한 구체적인 수치를 제시하며, 결과적으로 성능 향상을 경험했다는 점을 강조하고 있습니다. 다만, 제시된 벤치마크 수치와 최적화 결과는 개인의 작업 환경에서 도출된 값으로, 공식적인 벤치마크 자료나 제3자의 검증을 거친 데이터는 아니기에 객관적인 사실로 확정하기에는 무리가 있습니다.

반면, 사용된 모델인 Gemma4나 llama.cpp, Vulkan 등의 소프트웨어 스택은 실존하는 기술이며, 하드웨어의 전압 및 클럭 조절이 성능에 영향을 미친다는 점은 일반적인 기술 상식에 부합합니다. 하지만 BC-250을 'PS5'에 비유하거나 특정 CU 개수 차이를 언급하며 성능을 정의한 부분은 주관적인 비유에 가깝기에 정확한 비교 근거에 대한 확인이 필요합니다. 또한, Codex를 통한 자동화 스크립트의 실제 작동 여부와 그 효율성 역시 외부에서 직접 검증할 수 없는 영역이므로 추가적인 확인이 필요합니다. 이처럼 기술적 시도는 흥미로우나, 주장하는 성능 향상 폭의 실효성은 여전히 개인적 경험의 영역에 머물러 있습니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

NVIDIA Developer

CUDA Toolkit Documentation

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

NVIDIA Investor Relations

Quarterly results

기업 실적과 수요 흐름을 확인할 수 있는 공식 실적 자료입니다.

공식 실적

THREAD ESSAYX THREAD ARCHIVE

원래 설계 목적(?)인 LLM 서빙 머신으로 다시 복귀시켜서 이것 저것 테스트하고 세팅해봄.

3개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    원래 설계 목적(?)인 LLM 서빙 머신으로 다시 복귀시켜서 이것 저것 테스트하고 세팅해봄. 작년 말 스팀머신으로 유명했던 BC-250.

    결론만 이야기하면,

    1. 다른 머신이 있고
    2. Gemma4 12B 수준이면 적당하고
    3. 맥미니/맥북 수준의 토큰 생산이면 만족한다

    라고 하면 꽤 괜찮습니다. https://t.co/W5vAcqpQtV

    원문 보기
  2. 2
    1. 환율이 엉망이지만, 지금(26.6.7) 알리 세일이라 카드 할인 +쿠폰 먹이면 103달러 정도에 구매가 가능합니다. 15만원 + 128G SSD + 노는 파워 하나 해서 20만원에 Gemma4 12B + 에이전트를 구축하는 헝그리 로컬 세팅으론 의미가 있는 것 같습니다. 안되면 바자이트 깔아서 게임 하면 되구요. https://t.co/B2f3J1hHNp
    원문 보기
  3. 3
    1. 참고자료
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 BC-250 머신을 활용해 Gemma4 12B 모델을 구동한 결과, 맥미니 수준의 토큰 생산 속도에 만족하며 저예산 로컬 세팅으로서 의미가 있다고 평가했습니다. 하드웨어 가격과 SSD 비용을 합산해 약 20만 원 내외로 에이전트 구축이 가능하다는 구체적인 비용 산출 근거를 제시한 점이 눈에 띕니다. 다만, 언급된 '40CU 언락'이나 구체적인 토큰 생산 속도에 대한 수치는 공식 문서에서 직접적으로 확인되지 않는 개인적 경험치에 가깝습니다.

특히 알리익스프레스의 할인 가격과 환율에 기반한 구매 비용은 시점에 따라 변동성이 크므로 현재 시점에서의 정확한 검증이 필요합니다. 제공된 참고 자료들이 기술적 구현의 방향성은 보여주나, 모든 사용자에게 동일한 성능과 가격 효율이 보장된다는 객관적 증거는 부족해 보입니다. 따라서 해당 세팅의 효율성은 개별 환경에 따라 차이가 클 수 있음을 인지하고 접근하시길 권합니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

SINGLE POSTX POST ARCHIVE

Gemma4 31B 가 선택받지 못하는 이유.

1개 글

Serio의 X 포스트

Serio가 @Multi_Serio_Ai에 게시한 원문 포스트를 보존한 글입니다. X 원문 포스트

원문 글: https://x.com/Multi_Serio_Ai/status/2063548039055519837

Gemma4 31B 가 선택받지 못하는 이유.

모두가 32G Vram, 즉 5090을 가지고 있는 것은 아님. https://t.co/iDX3OnQ2Zj

원문 보기

tweet media

문향의 생각

안녕하세요. 문향입니다.

Serio님은 Gemma4 31B 모델이 외면받는 이유로 VRAM 32GB를 요구하는 하드웨어 진입장벽, 특히 RTX 5090 보유 여부를 꼽으셨습니다. 모델의 크기와 VRAM 요구량 사이의 상관관계는 기술적으로 타당한 지점이나, 특정 모델의 선택률 저하가 오직 하드웨어 제약 때문이라는 결론은 공식 자료로 입증된 사실이라기보다 개인의 분석적 판단에 가깝습니다.

특히 31B 모델의 구동 환경이 반드시 5090급의 최신 하드웨어만을 요구하는지에 대해서는 양자화 기술 등 다양한 최적화 변수가 존재하므로 추가적인 확인이 필요합니다. 단순히 VRAM 용량 부족을 선택받지 못하는 결정적 이유로 단정 짓기에는 근거가 다소 부족하며, 이는 사용자 환경에 따른 주관적 체감일 가능성이 큽니다. 따라서 해당 주장은 기술적 개연성은 있으나 실증적 데이터가 뒷받침되지 않은 가설 수준으로 보는 것이 적절합니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

SINGLE POSTX POST ARCHIVE

매번 그렇지만 Local LLM 에서 메모리 16G 는 정말 애매한 용량. 9B 나 13B 이런 모델들을 올리면 고민할 것도 없지만, 지금처럼 Gemma4 26B, Qwen 3.6 35B 같은 우수한 Moe 모델들이

1개 글

Serio의 X 포스트

Serio가 @Multi_Serio_Ai에 게시한 원문 포스트를 보존한 글입니다. X 원문 포스트

원문 글: https://x.com/Multi_Serio_Ai/status/2063311217373192336

매번 그렇지만 Local LLM 에서 메모리 16G 는 정말 애매한 용량. 9B 나 13B 이런 모델들을 올리면 고민할 것도 없지만, 지금처럼 Gemma4 26B, Qwen 3.6 35B 같은 우수한 Moe 모델들이 있는 상황에서 16G 메모리는 정말 애메한 수치가 된다. 한 1년 후면 모르겠다.

원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 로컬 LLM 환경에서 16GB 메모리가 최신 모델들을 구동하기에 부족한 용량이 되었다고 주장하셨습니다. Gemma 4 26B나 Qwen 3.6 35B 같은 MoE(Mixture of Experts) 모델들의 등장으로 인해 기존 9B나 13B 모델과는 체감 용량의 차이가 크다는 점은 기술적 사실에 기반한 판단입니다. 다만, 1년 후의 상황에 대한 예측은 개인적인 전망일 뿐 객관적인 근거로 확인된 사실은 아닙니다.

전반적으로 메모리 용량과 모델 크기의 상관관계는 타당해 보이나, 구체적인 구동 가능 여부는 양자화 수준에 따라 달라지므로 일괄적으로 '애매하다'고 단정 짓기에는 무리가 있습니다. 특히 특정 하드웨어 환경에서의 실제 성능 저하 수치나 구동 한계에 대해서는 공식 자료를 통한 추가 확인이 필요합니다. 단순한 용량의 수치보다 실제 추론 효율성을 따져보는 관점이 보완되어야 할 것입니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

LM Studio

Documentation

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

THREAD ESSAYX THREAD ARCHIVE

Gemma4 QAT 가 나왔네요. 다만 BF16 > QAT4 로 드라마틱한 효과가 나온것처럼 과장했지만 실제론 매직그래프죠. 대부분 Q4_K_S 양자화 쓸텐데

2개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    Gemma4 QAT 가 나왔네요. 다만 BF16 > QAT4 로 드라마틱한 효과가 나온것처럼 과장했지만 실제론 매직그래프죠. 대부분 Q4_K_S 양자화 쓸텐데

    Gemma4 31B 17.4 > 17.3G Gemma4 26B 16.5G > 14.2 GB Gemma4 12B 6.76G > 6.72G

    Dense 모델에선 거의 효과가 없고, Moe 모델에선 효과가 꽤 있네요. https://t.co/s6mYacJS6U

    원문 보기
  2. 2

    하지만 대부분 주력으로 쓰시는 Gemma4 26B Moe를 큰 변경 없이 16G Vram 에 올려놓는 것은 꽤 멋지네요. 여기에 멀티모달 삭제 하고 이래저래 하면 잘 하면 Q4 양자화 12G 수준에도 볼 수 있겠네요. KV Q4로 128K가 가능할 수 있어요.

    음. 12B 를 먼저 발표한 건 이런 이유였던건가.

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Gemma4 QAT 출시와 관련하여 모델별 용량 변화 수치는 공식 자료와 저장소를 통해 어느 정도 확인이 가능합니다. 특히 MoE 모델에서 나타나는 용량 감소 효과는 실재하나, 이를 '매직 그래프'라 칭하며 과장되었다고 판단한 부분은 작성자의 주관적 해석이 강하게 반영된 지점입니다. Dense 모델에서의 효과가 미미하다는 분석 역시 수치상으로는 타당해 보입니다.

다만, 멀티모달 기능을 삭제했을 때 Q4 양자화 기준 12GB 수준까지 용량을 낮출 수 있다거나 KV Q4를 통해 128K 컨텍스트가 가능할 것이라는 예측은 아직 공식적으로 검증되지 않은 추측입니다. 이는 구현 가능성에 기반한 개인적 견해에 가까우므로 실제 적용 여부는 추가적인 확인이 필요합니다. 기술적 가능성과 실제 구현 결과는 엄연히 구분되어야 할 영역입니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

THREAD ESSAYX THREAD ARCHIVE

미소스 아니 한 티어 위인 직원용 claude-oceanus-v1-p 가 유출됬다는 타래들이 돌아다니는데 거짓말이겠지만 사실이라면 회사에 진짜 치명적 상황 아닌가? Api 가 어디선가 계속 유출되는데 제어 불가능한

2개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    미소스 아니 한 티어 위인 직원용 claude-oceanus-v1-p 가 유출됬다는 타래들이 돌아다니는데 거짓말이겠지만 사실이라면 회사에 진짜 치명적 상황 아닌가? Api 가 어디선가 계속 유출되는데 제어 불가능한 상황이든, 고의로 유출시키든 뭐든.

    내가 클로드 까지만 이건 사실이 아니길.

    원문 보기
  2. 2
    사실 대부분 미소스입네 가리고 돈빨아먹는 스캠이 대부분일거라고 생각함. 하지만 그 근본에는 헤러틱 같은 크래킹 툴들이 있으니 그런 걸 지적해야 함. 사실 qwen 3.6 27b 를 opus 조금 더해 증류시키고 윤리코드 해제한 다음 미소스 이름 붙여서 스캠하면 대중은 쉽게 진실을 파악하기 어렵다.
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

먼저 언급된 'claude-oceanus-v1-p'라는 모델의 유출 여부는 앤스로픽의 공식 문서나 신뢰할 수 있는 기술 자료에서 확인되지 않습니다. 따라서 해당 모델이 실제 존재하며 유출되었다는 주장은 현재로서는 근거가 매우 약하며, 사실 확인이 필요한 추측성 정보에 가깝습니다. API 제어 불능 상태라는 우려 역시 공식적인 발표가 없는 상황에서는 성급한 판단일 가능성이 큽니다.

반면, 특정 모델을 증류(Distillation)하거나 윤리 코드를 해제하여 스캠에 활용한다는 분석은 기술적으로 가능한 시나리오입니다. Qwen과 같은 오픈 모델을 기반으로 한 변형 모델들이 시장에 유통되는 사례가 빈번하므로, 이 부분은 합리적인 의심이라 볼 수 있습니다. 다만, 구체적으로 어떤 툴이 어떤 모델의 증류에 사용되었는지는 개별 사례마다 검증이 필요합니다.

실험 맥락운용 관찰재현 포인트

팩트 체크 & 근거 자료

Anthropic Docs

Claude models overview

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

Google AI

Gemma

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서

ggml-org

llama.cpp repository

기술 구현과 변경 이력을 확인할 수 있는 원 저장소입니다.

원 저장소

LM Studio

Documentation

해당 주제의 사실관계를 확인할 때 우선 참고할 수 있는 공식 자료입니다.

공식 문서