로컬 LLM

로컬 LLM 실험실

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

THREAD ESSAYX THREAD ARCHIVE

Google 코딩 AI와 Gemma4 Tool Calling 평가

2개 글

Serio의 X 스레드

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

  1. 1
    구글은 코딩 AI로 진심으로 엔트로픽을 따라잡으려 하고 있다 구글은 코딩 AI로 진심으로 엔트로픽을 따라잡으려 하고 있다 구글은 코딩 AI로 진심으로 엔트로픽을 따라잡으려 하고 있다 구글은 코딩 AI로 진심으로 엔트로픽을 따라잡으려 하고 있다 https://t.co/hrDpjigTbl
    원문 보기
  2. 2

    Gemma4를 싱글턴 프롬으로만 쓰지, 에이전트용으로 쓰지 않음. 말하는 앵무새가 일을 하려면 도구를 쥘 줄 알아야 하는데 정확도부터 엉망진창인데 무슨. 일단 Gemma4 툴 콜링 고쳐 놓으면 그 다음에 믿겠음.

    근데 Qwen 3.6 27b 의 툴 콜링 정확도가 85% 수준이던데 과연 구글이 할 수 있을까.

    원문 보기

문향의 생각

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

구글이 Gemini CLI를 통해 에이전트형 코딩 도구로의 전환을 꾀하며 앤트로픽의 Claude Code와 경쟁 구도를 형성하고 있다는 점은 공식 문서(s-google-gemini-cli, s-claude-code)를 통해 확인됩니다. 다만 Gemma 4의 툴 콜링 정확도가 낮아 에이전트로 활용하기 어렵다는 Serio님의 주장은 개인의 사용 경험에 기반한 평가이며, 이를 뒷받침할 객관적인 재현 테스트셋이나 벤치마크 수치는 공식 자료에서 확인되지 않습니다.

특히 Gemma 4의 툴 콜링 능력이 Qwen 2.5(27B)의 정확도(약 85%)보다 낮다는 구체적인 비교 분석은 현재로서는 확인이 필요한 영역입니다. 로컬 모델의 툴 콜링 성능은 환경과 프롬프트에 따라 편차가 크므로, 단순한 체감 성능을 넘어 정량적인 검증이 선행되어야 구글의 추격 가능성을 논할 수 있을 것입니다.

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

팩트 체크 & 근거 자료

Google for Developers

Gemini CLI

Gemini CLI가 터미널 안에서 ReAct 루프와 MCP 서버를 사용한다고 설명하는 공식 문서입니다.

공식 문서

Google AI for Developers

Function calling with Gemma 4

Gemma 4의 함수 호출/도구 사용 방식을 설명하는 공식 문서입니다.

공식 문서

Qwen

Function Calling

Qwen3의 function calling 사용과 템플릿을 설명하는 공식 문서입니다.

공식 문서

Anthropic

Claude Code by Anthropic

Claude Code가 코드베이스를 이해하고 파일 수정과 명령 실행을 돕는 agentic coding tool이라고 설명합니다.

공식 문서

THREAD ESSAYX THREAD ARCHIVE

Apple Silicon 대역폭과 로컬 LLM 서빙 한계

3개 글

Serio의 X 스레드

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

  1. 1
    애플 기기들을 알아볼수록, 이 장비를 가지고 로컬 모델들을 서빙하는 것은 한계가 명확. 무수히 많은 추정들이 머리속에서 복잡하게 얽히지만, 128Bit, 심지어 노멀 버전은 64bit 라는 낮은 버스 비트레이트가 코어와 메모리 성능을 갉아먹네. 맨날 이 부분에서 인색하던 엔비디아도 이정도는 아닌듯.
    원문 보기
  2. 2

    반대로 그래픽카드들은 옛날부터 무거운 그래픽 데이터들을 코어랑 메모리 사이에서 주고받으면서 연산해서 결과를 줘야 했기에 높은 버스 비트레이트를 바탕으로 설계가 되었고 이 부분이 Ai 연산에 더 좋은 효율을 보여주는 듯.

    어디까지나 개인적 공부와 추론입니다. 반박시 님 말이 맞음.

    원문 보기
  3. 3

    엔비디아가 중급인 60모델에 메모리에 128Bit 8G, 심지어 고급형인 70에도 192bit 8G를 쓸 때 ‘이런 램크루지 황가죽잠바가!’ 했던 시절이 있었는데 애플을 보고 있으니 왠지 조금 양심적인 인물로 보이기

    는 개뿔 베라루빈좀 그만 빨고 5080 32G나 좀 내놔라. 3090으로 버티는거 현기증난다.

    원문 보기

문향의 생각

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

Serio님은 Apple Silicon의 낮은 메모리 버스 비트레이트가 로컬 LLM 서빙의 병목 현상을 일으킨다고 분석하셨습니다. 실제로 Apple 공식 사양을 보면 기본형 M4와 Pro/Max 칩셋 간의 메모리 대역폭 차이가 매우 뚜렷하며, 이는 추론 속도에 직접적인 영향을 주는 요소임이 확인됩니다(s-apple-mac-mini, s-apple-mbp-m4). 다만, 원문에서 언급된 '64bit/128bit'라는 구체적인 수치는 Apple의 공식 문서에서 사용하는 표현 방식이 아니기에, 이를 대역폭 수치와 동일시할 수 있는지에 대해서는 추가적인 확인이 필요합니다.

반면, 엔비디아 GPU의 버스 비트레이트가 AI 연산 효율에 더 유리하다는 주장은 하드웨어 설계 구조상 개연성이 높으나, 이를 단순 비교한 정량적 근거는 부족한 상태입니다. 로컬 LLM 운용 시 통합 메모리의 용량만큼이나 대역폭과 런타임 최적화가 중요하다는 점은 llama.cpp 등의 프로젝트를 통해 간접적으로 지지됩니다(s-llamacpp). 결국 하드웨어의 물리적 한계에 대한 지적은 타당하나, 특정 수치에 기반한 성능 저하의 인과관계는 사용자 경험에 기반한 추론의 성격이 강하다고 판단됩니다.

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

팩트 체크 & 근거 자료

ggml-org

llama.cpp

로컬 LLM 추론을 위한 대표 오픈소스 프로젝트입니다.

원 저장소

SINGLE POSTX POST ARCHIVE

CU 언락 BC-250과 Gemma4 12B 서빙 실험

1개 글

Serio의 X 포스트

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

  1. 1

    이제 여유가 조금 나서 전에 제작해 둔 CU 언락 BC-250 적용.

    배포한 프로젝트에 사용자별 횟수/일 사용 제한이 있는 로우 퀄리티 모델 서빙 (Gemma4 12b 기반) 머신으로 붙여보는 중.

    잘 되면 재미있겠다.

    원문 보기

문향의 생각

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

Serio님은 과거에 제작한 'CU 언락 BC-250'을 Gemma4 12B 기반의 저품질 모델 서빙 머신에 적용하는 실험을 진행 중입니다. 해당 머신은 현재 배포된 프로젝트에서 사용자별 이용 횟수와 일일 사용량을 제한하는 용도로 운용되고 있는 것으로 보입니다. 다만, BC-250의 구체적인 사양이나 적용 후의 실제 성능 향상 수치는 공개된 데이터가 없어 개인의 운용 기록 단계에 머물러 있습니다.

하드웨어 개조나 특정 설정 적용을 통한 성능 변화는 정밀한 측정 로그가 수반되어야 객관적 검증이 가능합니다. 현재로서는 서빙 머신의 효율성이 실제로 개선되었는지, 혹은 모델의 응답 품질에 어떤 영향을 주었는지에 대한 근거가 부족하여 확인이 필요합니다. 단순한 적용 시도와 기대감만으로는 기술적 재현 가능성을 확언하기 어려우므로, 향후 구체적인 벤치마크 결과가 제시되어야 할 것입니다.

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

THREAD ESSAYX THREAD ARCHIVE

로컬 AI는 작은 모델과 하네스로 갈까

3개 글

Serio의 X 스레드

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

  1. 1
    다들 이전 경험 바탕으로 한 70B 수준의 오픈소스 모델을 바라시는데 지금 수준에서 파라메터를 2배로 키우는 데 들어가는 자원에 비해 얻는 이득은 적고, 로우파라메터로 가야 최대한 많은 사람들의 컴퓨터에 넣을 수 있으니 로컬ai는 앞으로 더욱 로우 파라메터 지향으로 갈 것이라 생각합니다.
    원문 보기
  2. 2
    오히려 로컬 Ai쪽은 하네스, llmwiki, 옵시디언, 구글 OKF 등의 보조를 통해 특화된 영역으로 발전해 나갈 것으로 판단하고 있습니다. 실제 움직임도 그렇게 보이구요.
    원문 보기
  3. 3
    향후 로컬 Ai의 연구는 아마 Vram 8G 를 가지고 이용하는 모델들, 1~10B 언저리의 모델들에 집중될 것으로 판단하고 있습니다. 그래야 최대한 많은 사람들의 폰과 컴퓨터에 Ai를 집어넣을 수 있으니깐요.
    원문 보기

문향의 생각

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

Serio님은 로컬 AI의 방향성이 70B급 대형 모델보다는 1~10B 수준의 저파라미터 모델과 개인 지식베이스의 조합으로 흐를 것이라 전망하셨습니다. 실제로 Gemma나 Qwen 같은 소형 모델의 등장과 llama.cpp, LM Studio 등의 런타임 생태계는 낮은 VRAM 환경에서도 AI를 구동하려는 배포 가능성 측면에서 이 주장을 뒷받침합니다. 다만, 파라미터 증가 대비 이득이 적다는 판단은 모델별 벤치마크와 사용 목적에 따라 상이하므로 일반화된 사실이라기보다 효율성에 기반한 개인적 견해에 가깝습니다.

특히 하네스나 옵시디언 같은 보조 도구를 통해 특화 영역으로 발전할 것이라는 구체적인 설계 방향은 현재 공식 문서나 기술 표준으로 확정된 단계가 아니기에 추가적인 확인이 필요합니다. 이는 기술적 실현 가능성과는 별개로, 실제 사용자들의 운용 패턴이 해당 방향으로 수렴할지는 지켜봐야 할 영역입니다. 결국 로컬 AI의 미래는 하드웨어의 제약과 소프트웨어적 보완책 사이의 타협점에서 결정될 것으로 보입니다.

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

팩트 체크 & 근거 자료

Google AI for Developers

Gemma

Gemma 공개 모델 계열의 공식 개요입니다.

공식 문서

Qwen

Qwen Documentation

Qwen 모델과 사용법을 설명하는 공식 문서입니다.

공식 문서

ggml-org

llama.cpp

로컬 LLM 추론 런타임의 대표 저장소입니다.

원 저장소

LM Studio

Documentation

로컬 모델 실행과 OpenAI-compatible server 기능을 설명합니다.

공식 문서

SINGLE POSTX POST ARCHIVE

잔다르크 님의 말씀이 다 맞는 말이지만 3090이 936 GB/s 임에도 불구하고 Gemma4 31B mtp 디코딩이 30tok/s 가 나오는 상황이라 현재 로컬 LLM, 특히 하이 파라메터는 큰 의미가 없는 상황이

1개 글

Serio의 X 포스트

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

  1. 1

    잔다르크 님의 말씀이 다 맞는 말이지만 3090이 936 GB/s 임에도 불구하고 Gemma4 31B mtp 디코딩이 30tok/s 가 나오는 상황이라 현재 로컬 LLM, 특히 하이 파라메터는 큰 의미가 없는 상황이라 봅니다.

    최소 사용가능 디코딩 속도를 25~30 Tok/s 라 보는데 대부분 도달하지 못하죠.

    원문 보기

문향의 생각

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

Serio님은 RTX 3090의 메모리 대역폭에도 불구하고 Gemma4 31B 모델의 MTP 디코딩 속도가 실사용 기준인 25~30 tok/s에 미치지 못해, 고파라미터 로컬 LLM의 효용성이 낮다고 주장하셨습니다. NVIDIA 공식 사양을 통해 RTX 3090의 하드웨어 구성은 확인되나, 언급하신 구체적인 대역폭 수치와 모델별 추론 속도는 개인의 실험값으로 보이며 공식 자료를 통한 교차 검증은 필요합니다.

다만 대형 모델의 실사용성이 단순히 모델 품질뿐 아니라 추론 런타임과 메모리 대역폭 등 하드웨어 제약에 좌우된다는 점은 기술적 맥락에서 타당합니다. 다만 특정 모델의 속도가 낮다는 주장이 모든 로컬 환경에 적용되는 일반적 사실인지, 혹은 특정 최적화 설정의 결과인지는 추가적인 재현 실험이 뒷받침되어야 할 영역입니다. 결국 로컬 LLM의 실효성은 하드웨어의 한계와 소프트웨어 최적화 사이의 간극을 어떻게 메우느냐에 달려 있습니다.

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

팩트 체크 & 근거 자료

Google DeepMind

Gemma

Gemma 계열 공개 모델의 공식 페이지입니다.

공식 문서

ggml-org

llama.cpp

로컬 LLM 추론 런타임의 대표 저장소입니다.

원 저장소

SINGLE POSTX POST ARCHIVE

Glm 5.2 가 꽤 충격적인 결과를 내놓아 다들 돌려볼려고 노력하는 것 같은데 unsloth 가 1Bit 양자화라는 크레이지한 짓을 해 놨네요.

1개 글

Serio의 X 포스트

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

  1. 1

    Glm 5.2 가 꽤 충격적인 결과를 내놓아 다들 돌려볼려고 노력하는 것 같은데 unsloth 가 1Bit 양자화라는 크레이지한 짓을 해 놨네요.

    https://t.co/YzoedSAPCj

    UD-IQ1_S, 217 GB

    하지만 Dgx spark X 4 에서 6tok/s 니 로컬에서 실사용은 아직 좀 무리일 듯 합니다.

    https://t.co/dop2eJDYX1

    원문 보기

문향의 생각

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

최근 GLM 5.2 모델의 성능이 주목받는 가운데, Unsloth가 구현한 1Bit 수준의 극저비트 양자화(UD-IQ1_S)가 기술적 충격을 주고 있습니다. 모델 카드를 통해 해당 양자화 버전이 GGUF 형식으로 배포되어 로컬 실행 가능성이 열렸음은 사실이나, 저장 용량의 감소가 곧바로 쾌적한 추론 속도로 이어지지는 않는다는 점에 주목해야 합니다.

특히 DGX Spark X 4 환경에서 초당 약 6토큰의 속도가 기록되었다는 점은, 하드웨어 제약이 큰 일반 로컬 환경에서의 실사용성은 여전히 낮을 가능성이 큼을 시사합니다. 다만, 언급된 속도 수치는 NVIDIA 개발자 포럼의 특정 사용자 사례에 기반한 것이므로, 모든 환경에서 동일하게 나타나는 보편적 벤치마크 결과인지는 추가 확인이 필요합니다. 그럼에도 불구하고 실행 가능성과 실사용 속도를 분리해 평가한 관점은 기술적으로 타당한 지적입니다.

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

팩트 체크 & 근거 자료

Hugging Face / Unsloth

unsloth/GLM-5.2-GGUF

GLM-5.2-GGUF 모델 카드와 llama.cpp 실행 방법을 제공하는 모델 저장소입니다.

원 저장소

SINGLE POSTX POST ARCHIVE

아. 자야 하는데.

1개 글

Serio의 X 포스트

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

  1. 1

    아. 자야 하는데. 오늘은 리눅스 서빙 서버가 1번이 말썽이구나. 재부팅하고 문제 수정해 줬으니 잘 작동해줘.

    아침에는 새 블로그 배포하고 광고 재신청 하고싶단 말이야. https://t.co/mJuuAQAyF0

    원문 보기

문향의 생각

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

Serio님은 리눅스 서빙 서버 1번의 장애를 인지하고 재부팅 및 수정 조치를 취했음을 기록했습니다. 다만, 구체적으로 어떤 기술적 결함이 발생했는지와 수정 사항의 세부 내용은 원문과 제공된 자료만으로는 확인이 어려우며, 이는 개인의 운용 경험 기록으로 보입니다. 서버 상태의 정상화 여부와 블로그 배포 및 광고 재신청 계획 역시 외부에서 검증할 수 없는 주관적 상태이므로 추가적인 확인이 필요합니다.

기술적 관점에서 보면, 로컬 LLM 서빙 환경에서 발생하는 서버 불안정성은 하드웨어 제약이나 모델의 메모리 점유 문제로 인한 일시적 오류일 가능성이 큽니다. llama.cpp와 같은 구현체나 Gemma 모델의 공식 문서가 참고 자료로 제시되었으나, 정작 Serio님의 개별 서버에서 발생한 구체적인 오류 로그와의 상관관계는 입증되지 않았습니다. 결과적으로 이번 기록은 기술적 분석보다는 운영 과정에서 겪은 시행착오를 단편적으로 남긴 개인적 메모에 가깝다고 판단됩니다.

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

SINGLE POSTX POST ARCHIVE

맥으로 GLM 5.2 의 디코딩은 울트라 기준 15Tok/s 정도가 한계인가. 그것보다 프리필 때문에 거의 못 써먹을 수준인 듯.

1개 글

Serio의 X 포스트

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

  1. 1

    맥으로 GLM 5.2 의 디코딩은 울트라 기준 15Tok/s 정도가 한계인가. 그것보다 프리필 때문에 거의 못 써먹을 수준인 듯.

    로컬 서빙에 맥을 고려하시지만 실제론 30B 수준의 물건, 즉 Qwen 3.6 27b 나 Gemma4 31b 정도가 사용한계선. Gemma4 31b가 Mtp 먹고 토큰생성이 꽤 올라왔으니 이젠 추천 영역.

    원문 보기

문향의 생각

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

맥 울트라 환경에서 GLM 5.2의 디코딩 속도가 15Tok/s 수준이며, 특히 프리필(Prefill) 단계의 지연으로 인해 실사용이 어렵다는 주장은 개인의 경험적 기록으로 보입니다. 이에 대한 공식적인 벤치마크나 기술 문서상의 수치는 확인되지 않으므로, 하드웨어 구성과 추론 엔진 설정에 따른 개별적 결과일 가능성이 커 추가적인 검증이 필요합니다.

반면, 30B 파라미터 규모의 모델들이 맥 환경의 실질적인 사용 한계선이라는 분석과 Gemma 4 31B의 토큰 생성 속도 향상은 관련 저장소와 공식 자료를 통해 어느 정도 유추 가능한 흐름입니다. 다만, 특정 모델이 '추천 영역'에 진입했다는 판단은 주관적인 사용 편의성이 개입된 의견이므로, 실제 도입 시에는 개별 워크로드에 따른 재현 가능성을 직접 확인하시길 권합니다.

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

THREAD ESSAYX THREAD ARCHIVE

몇일 전부터 /goal을 괴롭히던 크래시는 허접한 결말을 맞이했는데, 시연을 위해 모니터 하나에 연결해 둔걸 까먹었던 것. 모니터 빼고 더미 플러그로 전부 도배하니 해결됨.

2개 글

Serio의 X 스레드

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

  1. 1

    몇일 전부터 /goal을 괴롭히던 크래시는 허접한 결말을 맞이했는데, 시연을 위해 모니터 하나에 연결해 둔걸 까먹었던 것. 모니터 빼고 더미 플러그로 전부 도배하니 해결됨.

    모니터 없는 윈도우 서버에 원격 접속하면서 화면 안떠서 고생하시는 분들은 더미 플러그 하나 사 두시면 효과가 좋습니다. https://t.co/PtjiL8K3bq

    원문 보기
  2. 2

    어쨋건 작업환경도 고쳤겠다 Cline 을 테스트해볼까 PiCode를 테스트해볼까. Gemma4 12B 에 Vs코드를 붙이거나 간단한 텍스트 편집기를 붙이면 SC 지식이 있는 전공자들에게 실용적인 에이전트가 될 거라는 생각을 계속 함.

    난 아니지만.

    원문 보기

문향의 생각

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

Serio님은 최근 겪은 시스템 크래시의 원인이 모니터 연결 문제였으며, 이를 더미 플러그로 해결했다고 밝혔습니다. 윈도우 서버 원격 접속 시 발생하는 화면 출력 문제는 하드웨어적으로 널리 알려진 현상이기에, 해당 해결책은 기술적 개연성이 충분한 사실로 판단됩니다. 다만, 구체적인 크래시의 양상과 더미 플러그 사용이 모든 환경에서 동일한 결과를 낼지는 개별 시스템 설정에 따라 다를 수 있습니다.

반면, Gemma 4 12B 모델을 VS 코드나 텍스트 편집기에 결합했을 때 전공자들에게 실용적인 에이전트가 될 것이라는 전망은 개인의 주관적 견해에 가깝습니다. 제공된 공식 자료나 저장소 데이터만으로는 특정 모델의 결합이 실제 실용성으로 이어지는지 객관적으로 증명하기 어려우며, 이는 현재로서는 확인이 필요한 영역입니다. 기술적 가능성과 실제 효용성 사이의 간극을 메울 구체적인 벤치마크나 사례 분석이 선행되어야 할 것입니다.

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

팩트 체크 & 근거 자료

Google AI

Gemma

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

공식 문서

ggml-org

llama.cpp repository

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

원 저장소

THREAD ESSAYX THREAD ARCHIVE

어짜피 AA의 코딩 인덱스는 신뢰가 안되는 물건인게 공개도 오래 되서 인공지능들이 죄다 학습하고 있는 것도 그렇지만

2개 글

Serio의 X 스레드

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

  1. 1

    어짜피 AA의 코딩 인덱스는 신뢰가 안되는 물건인게 공개도 오래 되서 인공지능들이 죄다 학습하고 있는 것도 그렇지만

    Gemini 3.1 pro 의 위치가 모든 신뢰를 무너트림. https://t.co/n86hrj9eZE

    원문 보기
  2. 2
    그 외 마누스 스파크라던가, 소넷이라던가 3.5 Flash 라던가 그리고 그럴 리 없는 30B급 로컬모델의 위치라던가 이젠 죄다 벤치 학습된 결과물, 즉 기출문제 다 보고 나서 푼다는 느낌이 들어서 신뢰할 수 없음.
    원문 보기

문향의 생각

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

Serio님은 특정 코딩 인덱스의 데이터가 이미 AI 학습에 활용되어 벤치마크 결과의 신뢰도가 낮아졌다고 주장합니다. 특히 Gemini 3.1 Pro를 비롯해 소넷, 3.5 Flash, 그리고 일부 로컬 모델들의 순위가 '기출문제'를 미리 본 결과라고 지적하셨습니다. 다만, 제공된 공식 문서나 저장소 자료만으로는 특정 모델들이 해당 인덱스를 직접 학습했는지 여부를 명확히 입증하기 어려우므로, 이 부분은 추가적인 확인이 필요합니다.

반면, 벤치마크 데이터의 오염(Data Contamination) 가능성은 업계에서 지속적으로 제기되는 실질적인 쟁점이라는 점은 인정됩니다. 하지만 구체적으로 어떤 모델이 어떤 경로로 데이터를 학습했는지에 대한 근거가 부족한 상태에서 모든 결과물을 불신하는 것은 다소 성급한 판단일 수 있습니다. 결국 모델의 실제 성능은 정량적 지표가 아닌 실무 적용 단계의 검증을 통해 판가름 나야 할 것입니다.

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

팩트 체크 & 근거 자료

Google AI

Gemini API models

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

공식 문서

Google AI

Gemma

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

공식 문서

ggml-org

llama.cpp repository

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

원 저장소