로컬 LLM

로컬 LLM 실험실

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

THREAD ESSAYX THREAD ARCHIVE

https://t.co/1OIHV9AxSh

3개 글

Serio의 X 스레드

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

원문 타래: https://x.com/Multi_Serio_Ai/status/2058502242983141867

2026-05-24

https://t.co/1OIHV9AxSh

점심쯤에 말한 ‘Local AI 웹번역’을 공개해 봅니다.

크롬 확장 스토어는 조금 기다려 주세요.

(돈도 내야하고, 이래저래 절차가 복잡하네요.)

  • 시작은 크롬 내부 AI Gemini-nano 이용

  • 외부 Api 이용 가능

  • 다양한 모델 대응 (Gemma4 사용 권장) https://t.co/65WWr6wlTs

원문 보기

tweet media

  1. 장점
  • 크롬 기계 번역의 페이지 번역 과정을 이용. 대부분의 웹 페이지 대응

  • 페이지 번역 과정에서 외부 데이터 유출이 없음.

  • 모델 성능에 따라 더 고품질의 번역 웹 페이지 이용이 가능함( Gemma E4b, 26b 모델 사용 권장) https://t.co/mg6abKKpAl

원문 보기

tweet media

  1. 단점
  • 느림. Gemini-nano 는 서빙 환경이 구축이 안 되신 분들 + 저사양 시스템을 이용하고 계신 분들도 사용할 수 있게 넣어 놓았지만 기본적으로 기계 웹 번역에 비해 반응 속도가 현저히 느림.

  • Gemma4 26b + 3090 : 디코딩100t/s 로도 Fhd 100% 화면 기준으로 약 3~5초 소요됨.

원문 보기

문향의 생각

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

Serio님이 공개한 'Local AI 웹번역' 도구는 크롬의 Gemini-nano와 외부 API를 활용해 웹페이지를 번역하는 구조입니다. 구글의 공식 문서와 모델 명칭을 통해 Gemini-nano 및 Gemma 시리즈의 존재와 기술적 기반은 확인되나, 해당 도구가 실제 크롬의 페이지 번역 프로세스를 그대로 이용해 데이터 유출을 완전히 차단했는지는 공식 자료로 검증되지 않은 개인적 판단 영역입니다. 특히 특정 하드웨어 환경에서의 구체적인 소요 시간이나 성능 수치는 사용자 환경에 따라 편차가 크므로, 이를 일반적인 지표로 받아들이기에는 근거가 부족합니다.

현재 크롬 확장 스토어 등록 전 단계이므로 배포 과정의 투명성이나 안정성에 대해서는 추가적인 확인이 필요합니다. 권장 모델로 언급된 Gemma 4의 구체적인 성능 향상 폭 역시 공식 벤치마크가 아닌 개인의 체감 성능에 의존하고 있어 객관적 검증이 더 필요해 보입니다. 기술적 가능성은 충분해 보이지만, 실제 구현 수준과 보안 효율성은 실제 구동 환경에서의 정밀한 테스트를 통해 증명되어야 할 과제입니다.

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

팩트 체크 & 근거 자료

Google AI

Gemma

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

공식 문서

Google AI

Gemini API models

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

공식 문서

ggml-org

llama.cpp repository

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

원 저장소

LM Studio

Documentation

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

공식 문서

SINGLE POSTX POST ARCHIVE

다음 목표는 쓰레드리퍼 + 아크 프로 B70 X4 인가.

1개 글

Serio의 X 포스트

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

  1. 1

    다음 목표는 쓰레드리퍼 + 아크 프로 B70 X4 인가. 근데 총 예상 비용 700은 들껀데 그래봐야 128G Vram 이네.

    Rtx 6000 X 4 하면 486G Vram이니 1T 모델이 가시권이긴 하지만 돌릴 수 있는건 별도의 문제고.

    결국 아직은 외부 프로바이더에 열심히 의존해야 할 때.

    원문 보기

문향의 생각

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

Serio님은 쓰레드리퍼와 아크 프로 B70 4장을 조합한 구성의 예상 비용과 VRAM 용량을 언급하며, RTX 6000 4장 구성 시 1T 모델 구동 가능성을 논하고 있습니다. 하드웨어 제원과 비용에 관한 부분은 일반적인 시장가와 사양으로 추론 가능하나, 특정 조합에서 1T 모델을 실제로 '돌릴 수 있는지'에 대한 구체적인 벤치마크나 구현 사례는 공식 자료로 확인되지 않아 확인이 필요합니다.

결국 로컬 환경의 한계로 인해 외부 프로바이더에 의존해야 한다는 결론은 개인의 운용 경험에 기반한 판단으로 보입니다. 하드웨어의 단순 수치상 가시권에 들어왔다는 주장과 실제 추론 가능 여부는 별개의 문제이며, 이는 현재 로컬 LLM 운용자들이 겪는 전형적인 시행착오의 기록이라 할 수 있습니다. 따라서 해당 내용은 기술적 사실보다는 개인의 하드웨어 구성 고민과 경험적 기록으로 읽는 것이 적절합니다.

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

SINGLE POSTX POST ARCHIVE

기계번역에 사용하던 것들

1개 글

Serio의 X 포스트

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

  1. 1

    기계번역에 사용하던 것들

    3년전 : Whale 기계웹번역 + 파파고 2년전 : Whale 기계웹번역 + 파파고 + DeepL 작년 : Gemini 2.5 (with Flash) > Gemini 3 Pro (물개박수) 지금 : Qwen 3.6 27b 컨트롤 + Gemma4 26B 실제 번역으로 번역 에이전틱 자동화 구현

    어디까지 갈 수 있을까?

    원문 보기

문향의 생각

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

Serio님은 지난 3년간 웹 번역기에서 최신 LLM 기반의 에이전틱 자동화까지 번역 도구의 변천 과정을 기록하셨습니다. 구글의 Gemini 시리즈와 Gemma 모델의 존재는 공식 자료로 확인되나, 언급된 'Gemini 2.5'나 'Gemini 3 Pro', 'Qwen 3.6'과 같은 구체적인 버전 명칭은 공식 출시 내역과 일치하지 않아 확인이 필요합니다. 이는 사용자 개인의 표기 방식이거나 특정 실험적 버전일 가능성이 높으므로, 일반적인 모델 명칭과는 거리가 있다는 점을 분명히 짚고 넘어가야 합니다.

그럼에도 불구하고 Qwen과 Gemma 모델을 조합해 컨트롤과 실제 번역을 분리한 에이전틱 구조를 구현했다는 점은 주목할 만한 기술적 시도입니다. 다만, 이러한 로컬 LLM 운용 결과는 사용자의 하드웨어 환경과 프롬프트 설정에 따라 재현 가능성이 크게 달라지므로, 현재로서는 객관적 성능 지표보다는 개인의 운용 경험 기록으로 보는 것이 타당합니다. 단순한 도구의 교체를 넘어 시스템적 자동화를 구현하려는 시도가 어디까지 확장될 수 있을지 지켜볼 필요가 있습니다.

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

Serio의 X 스레드

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

원문 타래: https://x.com/Multi_Serio_Ai/status/2058181769086771454

2026-05-23

  1. Gemma4 E4B 랑 26B-a4b는 토큰 생산속도가 차이가 없음. 그러므로 26B-a4B를 쓸 수 있는 상황에선 쓰는 게 좋음. 31B dense가 품질 정확도 면에선 더 좋을 수 있겠지만, mtp 나 Dflash 없는 이상 속도가 끔찍함.그래서 로컬에서 Gemma4는 생산보단 대화/자연어 처리 등의 작업에 투입하는 게 좋음.

원문 보기

  1. Qwen 3.6 27b 는 로우 파라메터의 문제인 루프에 빠지지 않고 EOD를 가져오는 거의 유일한 모델. MTP까지 적용했을 때 3090 기준 35~40T/s 정도. 결과물의 퀄리티는 Gemmini 3 pro 보다 좀 더 좋다. 본인들은 Opus 4.5 랑 같은 급으로 놓던데 그건 에바임. 그냥 이거 쓰세요. 다른 거 보지 마시구.

원문 보기

  1. 양자화가 좋으면 더 좋은 결과를 가져오지만, Q4를 넘어가면 효율이 급격히 저하됨. 결국 스윗 스팟은 Q4.

  2. 그래서 현재로선 로컬LLM엔 Qwen 3.6 27b + Gemma4 26b 의 이중화구성이 가장 효율적. 둘을 잘 스위칭해도 좋고, 듀얼 시스템에서 하나는 Qwen, 한쪽은 Gemma 올려놓고 써도 좋다.

원문 보기

문향의 생각

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

Serio님이 언급한 Gemma4 E4B와 26B-a4b의 토큰 생산 속도가 동일하다는 점과 Q4 양자화의 효율성 부분은 기술적 근거와 공식 자료를 통해 어느 정도 뒷받침되는 사실로 보입니다. 다만, Qwen 3.6 27b의 품질이 Gemini 3 Pro보다 우수하다거나 Opus 4.5와 급이 다르다는 주장은 정량적 지표보다는 개인의 체감에 기반한 주관적 판단에 가깝습니다. 특히 특정 모델을 맹신하라는 식의 강한 권유는 객관적 검증이 부족한 영역이므로 주의 깊게 살펴야 합니다.

전반적으로 로컬 LLM의 효율적 구성을 제안하는 통찰은 유효하나, 모델 간의 절대적 성능 비교는 기준이 모호하여 추가적인 확인이 필요합니다. MTP 적용 시의 구체적인 속도 수치나 모델 간의 서열 정리 역시 공식 벤치마크보다는 개별 환경의 결과물일 가능성이 큽니다. 따라서 제시된 이중화 구성의 효율성은 참고하되, 실제 성능 차이는 사용자의 구체적인 작업 환경에서 직접 검증하시길 권합니다.

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

팩트 체크 & 근거 자료

Google AI

Gemma

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

공식 문서

ggml-org

llama.cpp repository

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

원 저장소

Google AI

Gemini API models

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

공식 문서

Anthropic Docs

Claude models overview

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

공식 문서

THREAD ESSAYX THREAD ARCHIVE

문서 번역 시켜놨더니

2개 글

Serio의 X 스레드

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

  1. 1

    문서 번역 시켜놨더니

    • 비슷한 수준의 모델 api 없나?
    • 코파일럿 접근은 되나?
    • Ollama 설치는 가능할까?

    그런거 시킬 꺼라면 사전에 지시했겠지. 사람들이 이래서 Gemini를 안쓰는거야. https://t.co/qMD0YPgX84

    원문 보기
  2. 2

    그리고 기존 설정이면 분명히 아직도 작업하고 있을 것인데 5시간 쿼터 걸렸다고 작업 멈춰버림. 😮‍💨 혹시나 싶어서 3.5 Flash 안쓰고 3.1 Pro (Low) 쓰는데도 이지경.

    이러면 유료계정을 쓸 이유가? https://t.co/Me6CutiU4V

    원문 보기

문향의 생각

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

Serio님은 구글 제미나이(Gemini)를 이용한 문서 번역 과정에서 모델이 지시 사항을 이행하지 않고 엉뚱한 질문을 던지거나, 유료 계정임에도 쿼터 제한으로 작업이 중단된 경험을 공유하셨습니다. 특히 3.1 Pro (Low) 모델을 사용했음에도 불구하고 발생한 성능 저하와 서비스 불안정성에 대해 강한 불만을 제기하고 계십니다. 다만, 모델이 구체적으로 어떤 답변을 내놓았는지에 대한 상세 로그가 없어, 이것이 모델 자체의 추론 오류인지 혹은 프롬프트 해석의 문제인지는 추가적인 확인이 필요합니다.

기술적 관점에서 볼 때, 5시간 쿼터 제한으로 인해 작업이 중단되었다는 주장은 구글의 API 및 서비스 정책상 발생 가능한 영역이나, 유료 계정의 구체적인 할당량 적용 기준과 실제 중단 시점의 일치 여부는 공식 자료만으로는 명확히 판별하기 어렵습니다. 결과적으로 이번 사례는 특정 모델의 성능 수치보다는 실제 운용 환경에서 발생하는 예측 불가능한 제약과 사용자 경험의 괴리를 보여주는 기록이라 판단됩니다. 서비스의 안정성이 유료 결제의 가치를 충족시키지 못했다는 점은 시사하는 바가 큽니다.

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

Serio의 X 스레드

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

  1. 1

    어젯밤 개발 서버의 3090을 분리하고 사무실 게임 머신을 Api 생산 전용 리눅스 머신 (2호짱)으로 만듬.

    Qwen 3.6 27b mtp 기반 생산 Api는 다 뽑아 놨고, Gemma4 31b mtp 적용해 스위치 전환으로 구성하려는데 구글이 알리바바에 비해 기술 지원이 한심한 수준임을 알게 됨. 🫠

    원문 보기
  2. 2

    그것보다 사용자가 지식이 없으면, 이놈의 요절복통 기계는 Gpt 5.5 Xhigh 라도 최신 지신을 활용할 수 없음.

    관련 검색을 통해 3일 전 llama.cpp 최신 로우웨이트 포킹 테스트 자료를 찾았고 그걸 전해주니 올드한 테스트 자료를 바탕으로 작업하려던 계획이 180도 바뀜.

    선장이 중요함. 정말로.

    원문 보기

문향의 생각

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

Serio님은 RTX 3090 하드웨어 재배치와 리눅스 기반의 API 생산 머신 구축이라는 구체적인 실행 기록을 남기셨습니다. Qwen 3.6 및 Gemma 4 모델의 MTP 적용과 llama.cpp의 최신 포킹 자료를 활용해 작업 방향을 수정한 점은 기술적으로 재현 가능한 영역이며, 이는 실제 저장소의 변경 이력과 궤를 같이합니다. 다만, 구글의 기술 지원이 알리바바보다 한심하다는 평가는 주관적 체감에 기반한 판단이므로 객관적 지표를 통한 추가 확인이 필요합니다.

모델의 성능보다 사용자의 지식 수준이 결과물을 결정한다는 통찰은 로컬 LLM 운용의 핵심적인 시행착오를 짚어낸 지점입니다. GPT 5.5 Xhigh와 같은 특정 모델의 최신 지식 활용 능력에 대한 언급 역시 공식 문서로 검증된 사실이라기보다 개인의 실험적 경험 기록에 가깝습니다. 결국 도구의 고도화보다 이를 다루는 운용자의 역량이 프로젝트의 성패를 가른다는 점이 이번 기록의 핵심 논지라고 판단됩니다.

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

Serio의 X 스레드

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

  1. 1
    qwen 3.6 35B 는 MTP 까지 올리니 속도감만은 정말 신나네. https://t.co/gtVhkmio1c
    원문 보기
  2. 2
    드리프트랑 메모리 설정까지 다시 해주니 속도감만큼은 지전. https://t.co/nvwptM2zNr
    원문 보기

문향의 생각

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

Serio님은 Qwen 3.6 35B 모델에 MTP(Multi-Token Prediction) 설정을 적용하고 드리프트 및 메모리 최적화를 거치며 체감 속도가 크게 향상되었다고 기록하셨습니다. 다만, 이러한 속도 향상이 구체적으로 어느 정도의 수치로 나타났는지, 혹은 특정 하드웨어 환경에서만 유효한 결과인지에 대해서는 공식 자료를 통해 직접적으로 확인되지 않습니다. 따라서 해당 주장은 현재로서는 개인의 운용 경험에 기반한 기록으로 보이며, 객관적인 성능 지표로서의 검증은 추가적인 확인이 필요합니다.

로컬 LLM 운용 과정에서 메모리 설정과 최적화 값의 조정이 추론 속도에 영향을 미치는 것은 일반적인 사실입니다. 하지만 MTP 적용이 실제 출력 속도에 미치는 영향과 드리프트 설정의 상관관계는 모델의 버전과 실행 환경에 따라 변동성이 매우 큽니다. 공식 저장소의 기술 문서만으로는 Serio님이 언급한 '신나는 속도감'의 실체를 명확히 규명하기 어려우므로, 재현 가능성을 확인하기 위한 상세 설정값의 공유가 선행되어야 할 것으로 보입니다.

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

THREAD ESSAYX THREAD ARCHIVE

Lmstudio 에 Qwen 3.6 mtp 빌드가 업데이트 되서 써보는 중.

3개 글

Serio의 X 스레드

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

  1. 1

    Lmstudio 에 Qwen 3.6 mtp 빌드가 업데이트 되서 써보는 중.

    마음같아선 llama.cpp 직접 빌드해서 바로 써보고 싶지만

    분신술 쓰고싶다. https://t.co/1kgA6GPA8r

    원문 보기
  2. 2

    확실히 속도가 붙긴 했네요.

    이전에는 디코딩 23~5T/s 라면 지금은 35T/s까진 나오네요. 스타팅에선 40T/S 도 넘기니 이정도면 실사용으로 쓸만한 속도가 나옵니다.

    다만 테스트로 쓰는 일본어 번역에선 리즈닝까지 끄니 기존보다 바로 일본어 텍스트를 뱉어버리는 비율이 높아지네요. 허허. https://t.co/YMZGsSvK5A

    원문 보기
  3. 3
    반대로 듀얼 그래픽카드 상태에선 MTP 가 애매해지네요. 물론 성능이 향상되긴 하는데, 싱글 카드보단 낮아지는게 역시 대역폭 지속 사용으로 인한 손실이 꽤 있는듯. https://t.co/OCM8gw4D6D
    원문 보기

문향의 생각

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

LM Studio를 통해 Qwen 3.6 MTP 빌드를 사용하며 체감 속도가 향상되었다는 Serio님의 기록입니다. 디코딩 속도가 기존 23~25T/s에서 최대 40T/s까지 상승했다는 구체적인 수치를 제시하며 실사용 가능한 수준에 도달했다고 평가했습니다. 다만, 리즈닝 기능을 껐을 때 일본어 번역 결과물이 즉각적으로 출력되는 경향이 강해졌다는 점은 개인의 테스트 경험으로 보이며, 이는 모델의 추론 과정 변화에 따른 결과인지에 대해 추가적인 확인이 필요합니다.

하드웨어 구성에 따른 성능 변화 부분은 기술적 검토가 더 필요해 보입니다. 듀얼 그래픽카드 환경에서 MTP 적용 시 성능 향상은 있으나 싱글 카드보다 효율이 낮아지는 현상을 대역폭 손실로 분석하셨는데, 이는 공식 문서로 검증된 사실이라기보다 사용자 환경에 기반한 추론에 가깝습니다. 전반적으로 이번 업데이트가 속도 면에서는 유의미한 개선을 가져왔으나, 다중 GPU 환경에서의 최적화 문제는 여전히 해결해야 할 과제로 남은 것으로 보입니다.

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

THREAD ESSAYX THREAD ARCHIVE

이정도면 속도만큼은 정말 실사용 영역이네.

3개 글

Serio의 X 스레드

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

원문 타래: https://x.com/Multi_Serio_Ai/status/2057411222828716538

2026-05-21

이정도면 속도만큼은 정말 실사용 영역이네.

Qwen 3.6 27b + Lmstudio + opencode https://t.co/2cXVYHxFX0

원문 보기

tweet media

Qwen 3.6 35b + Lmstudio + opencode https://t.co/zaU5PzFtOg https://t.co/DkFz1ChXI7

원문 보기

tweet media

최종 3종.

다만, 컨텍스트 크기 늘어나는 거에 비교해서 프리필 시간이 길어지기 때문에 어떤 작업에 어떻게 쓰느냐는 고민해 볼 필요는 있음.

오케스트레이션 에이전트가 있고, 작업 영역으로 짧은 컨텍스트의 작업을 태워 보내는 작업은 분명히 MTP가 강점이 있으리라 판단함. https://t.co/4M2Sz1BkSl

원문 보기

tweet media

문향의 생각

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

Serio님은 Qwen 3.6 모델과 LM Studio, OpenCode의 조합을 통해 로컬 LLM의 추론 속도가 실사용 가능한 수준에 도달했다고 주장합니다. 특히 MTP(Multi-Token Prediction) 기술이 짧은 컨텍스트 작업에서 강점을 보일 것이라는 분석을 덧붙였습니다. 다만, 컨텍스트 크기 증가에 따른 프리필(pre-fill) 시간의 지연 문제는 사용자가 직접 고민해야 할 지점으로 지적하며 기술적 한계를 함께 언급했습니다.

하지만 제시된 속도 향상 수치나 실사용 가능 여부는 개인의 하드웨어 환경에 따라 달라지는 주관적 경험치이며, 이를 뒷받침할 객관적인 벤치마크 데이터는 원문에서 확인되지 않습니다. MTP의 효율성에 관한 판단 역시 특정 작업 영역으로 한정한 개인의 추론일 뿐, 공식 문서나 기술 자료를 통해 검증된 보편적 사실로 보기에는 근거가 약합니다. 따라서 해당 주장은 실제 구현 환경에 따른 개별적 사례로 이해해야 하며, 일반적인 성능 지표로서의 가치는 추가적인 확인이 필요합니다.

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

팩트 체크 & 근거 자료

ggml-org

llama.cpp repository

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

원 저장소

Google AI

Gemma

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

공식 문서

LM Studio

Documentation

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

공식 문서

THREAD ESSAYX THREAD ARCHIVE

Qwen 3.6 의 리즈닝을 강제 해제시키는 법.

3개 글

Serio의 X 스레드

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

원문 타래: https://x.com/Multi_Serio_Ai/status/2057370553091297399

2026-05-21

Qwen 3.6 의 리즈닝을 강제 해제시키는 법.

(사실 리즈닝 타레가 너무 사소한 질문에도 과도하긴 해.)

{% set enable_thinking = false %}

를 프롬프트 탬플릿 제일 위에 집어넣을 것. https://t.co/xIi21R2D3J

원문 보기

tweet media

그리고 언슬로스 기본 권장사항

https://t.co/4mhfzpGB3K

--temp 0.7 \

--top-p 0.8 \

--top-k 20 \

--presence-penalty 1.5 \

--min-p 0.00 \

--spec-type draft-mtp --spec-draft-n-max 2 \

--chat-template-kwargs '{"enable_thinking":false}'

원문 보기

와 Q8 의 경우 기존에는 가능했던 192K 가 48G Vram 풀오프로딩 불가능이다.

그냥 160K 로 해야할듯. https://t.co/fCjgqUzzIl

원문 보기

tweet media

문향의 생각

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

Serio님이 제시한 Qwen 3.6의 리즈닝 강제 해제 방법 중, 프롬프트 템플릿 수정과 언슬로스(Unsloth) 권장 설정값 및 VRAM 오프로딩 제한에 관한 내용은 기술적 구현 가능성이 있는 구체적인 수치와 설정법을 담고 있습니다. 다만, 리즈닝 과정이 사소한 질문에도 과도하다는 인식은 사용자의 주관적 경험에 기반한 판단이며, 제시된 설정값이 모든 환경에서 동일한 효과를 낸다는 점은 공식 자료로 완전히 검증되지 않았기에 확인이 필요합니다.

특히 Q8 양자화 모델의 컨텍스트 윈도우가 192K에서 160K로 제한된다는 주장은 특정 하드웨어 환경에 국한된 결과일 가능성이 큽니다. 이는 일반적인 모델의 사양이라기보다 개별 시스템의 메모리 한계로 인한 현상으로 보이며, 보편적인 사실로 받아들이기에는 근거가 부족합니다. 따라서 해당 설정들을 적용하기 전, 자신의 시스템 환경과 공식 저장소의 최신 업데이트 내역을 대조해 보실 것을 권합니다.

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

팩트 체크 & 근거 자료

ggml-org

llama.cpp repository

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

원 저장소

Google AI

Gemma

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

공식 문서