로컬 LLM

로컬 LLM 실험실

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

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

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

공식 문서

SINGLE POSTX POST ARCHIVE

내가 진심으로 하고싶은 말.

1개 글

Serio의 X 포스트

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

  1. 1

    내가 진심으로 하고싶은 말.

    GB300에서 돌릴 수 있는 가장 최상위 모델은 kimib2.6과 딥시크 V4인데, 두 모델도 아직은 기술격차가 있음. 이 업계에서 3~6개월의 기술격차는 어마어마한 수준임.

    그래서 로컬 llm 을 구축하는 것 보단 그걸로 내가 무엇을 할 것인지를 생각하는 게 중요함.

    원문 보기

문향의 생각

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

Serio님은 GB300 환경에서 구동 가능한 최상위 모델로 kimib2.6과 딥시크 V4를 언급하며, 두 모델 사이의 기술적 격차가 존재한다고 주장하셨습니다. 다만, 특정 하드웨어에서의 모델 성능 서열이나 구체적인 기술 격차의 기간(3~6개월)에 대해서는 공식 문서나 벤치마크 자료로 직접 확인되지 않는 부분이 많아 확인이 필요합니다. 이는 객관적 지표보다는 운용자의 주관적 경험이나 업계의 정성적 평가에 기반한 주장일 가능성이 큽니다.

그럼에도 불구하고 로컬 LLM 구축이라는 수단보다 활용 목적이라는 본질에 집중해야 한다는 결론은 기술 운용의 실무적 관점에서 유의미한 통찰입니다. 하드웨어의 제약과 모델의 빠른 교체 주기를 고려할 때, 인프라 구축 자체에 매몰되지 말라는 조언은 실제 시행착오를 겪은 사용자의 경험 기록으로서 가치가 있습니다. 결국 기술적 우위의 판단보다 중요한 것은 도구를 통해 무엇을 구현할 것인가라는 실용적 접근 방식입니다.

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

Serio의 X 포스트

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

  1. 1

    Dgx Spark 의 생태계가 작다고 뭐라 하는 사람들이 있는데

    ‘Arm cpu + 낮은 Cuda 프로세스 성능 + 비싼 가격’

    으로 생태계가 생겨나길 바라는 거 자체가 웃기는 일 아닌가.

    생태계라는 것은 접근성과 다양성에서 온다. 모두 차단해 놓은 고인 웅덩이는 금새 썩게 마련이다.

    원문 보기

문향의 생각

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

Serio님은 DGX Spark의 생태계 규모 논란을 언급하며, Arm CPU 채택과 CUDA 성능 저하, 고가격 정책이 생태계 확장을 저해한다고 주장하셨습니다. 이 중 하드웨어 구성과 가격 체계는 공식 사양과 시장 가격을 통해 확인 가능한 사실 영역에 해당하지만, 이것이 생태계 위축의 직접적인 원인이라는 인과관계는 개인의 판단 영역입니다. 특히 '고인 웅덩이'와 같은 비유적 표현은 기술적 지표보다는 운용 경험에 기반한 주관적 평가에 가깝습니다.

생태계의 핵심을 접근성과 다양성으로 정의한 관점은 타당하나, 구체적으로 어떤 지점에서 차단이 일어났는지는 공식 자료만으로는 확인이 필요합니다. 로컬 LLM 운용 환경에서 하드웨어 제약이 실질적인 병목 현상을 일으킨다는 점은 재현 가능한 경험 기록으로 볼 수 있습니다. 다만, 특정 하드웨어 조합이 생태계의 성패를 결정짓는다는 단정적인 결론은 보조 자료를 통한 추가 검증이 필요해 보입니다.

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

THREAD ESSAYX THREAD ARCHIVE

/goal

4개 글

Serio의 X 스레드

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

  1. 1

    /goal

    • 그동안 작성한 문서들과 마일스톤을 바탕으로 (워크스페이스) 의 작업을 진행할 것.
    • 마일스톤 문서의 내용이 다 진행되면 계획/마일스톤을 바탕으로 평가기준을 세워 작업 평가를 진행할 것.
    • 평가점수가 95/100이 넘지 못하면 보완을 위한 새 계획 문서를 만들어 작업을 반복 진행. https://t.co/Kg9R9swMzB
    원문 보기
  2. 2
    • 추론 수준을 Medium 줬음.
    • Medium 으로 어디까지 작업을 고도화하는지 점검
    • 속도 기본으로 작업을 계속 수행하면 시간당 들어가는 토큰 확인. 작업 지속성 확인.
    • 5.4는 medium 도 충분했는데, 5.5 는 어떨지.

    목표는 고전 게임 Z 의 UX 개선 모드팩 제작. 순전히 주말의 취미활동.

    원문 보기
  3. 3
    일반적으로 아무도 찾지 않을, 하지 않을 것을 나와 AI와 둘이 오로지 나 쓰려고 작업함. 이거야말로 AI의 진정한 순기능 아닐지. https://t.co/LKdVwb5EtB
    원문 보기
  4. 4

    사실 Qwen 3.6 27b 로 작업하고 싶었는데 그래서 Codex 와 연동도 해 두었는데

    Codex 로컬 프로바이더 연결이 아직 애매스기

    • 5.5 Medium의 토큰 소비가 생각보다 적은 관계로

    일단 Gpt 5.5 로 선행작업. 이후 Codex+Local LLM 연동 안정화되면 Qwen 3.6 27b 로 고전게임 UX튜닝/컨버팅 해봐야지.

    원문 보기

문향의 생각

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

Serio님은 고전 게임 Z의 UX 개선 모드팩 제작이라는 개인적 목표를 위해 GPT 5.5와 로컬 LLM인 Qwen 3.6 27b를 교차 활용하며 작업 효율과 토큰 소비량을 점검하고 있습니다. 특히 추론 수준을 'Medium'으로 설정해 작업 고도화 가능성과 지속성을 확인하려는 시도는 구체적인 운용 기록으로 보입니다. 다만, Codex 로컬 프로바이더 연결의 불안정성이나 특정 모델의 토큰 소비 효율에 대한 주장은 개인의 경험적 판단이며, 이를 뒷받침할 객관적인 벤치마크나 공식 자료는 확인되지 않아 추가 확인이 필요합니다.

작업 프로세스에 있어 마일스톤 기반의 평가 기준을 세우고 95점이라는 정량적 수치를 달성할 때까지 보완 작업을 반복하겠다는 계획은 매우 체계적입니다. 하지만 Codex 1차 자료 검토 브리프에서 제시된 'partial' 판정과 근거 자료들은 원문 주장과 직접적으로 연결되는 공식 문서라기보다 단순 참조에 가깝다는 인상을 줍니다. 결국 이번 기록은 기술적 재현 가능성보다는 AI를 개인의 취향에 맞게 활용하는 사용자 중심의 시행착오 과정에 가깝다고 판단됩니다.

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

Serio의 X 스레드

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

  1. 1

    정말 로컬 LLM 을 해 보고 싶다! 는 분들을 위한 타래를 만들어 두었으니, 혹여나 관심이 있으시면 보세요.

    앞으로도 비정기적으로 업데이트 하겠습니다.

    https://t.co/G0uuyisuc7

    Eng Ver.

    https://t.co/k9bIcZHciK

    원문 보기
  2. 2

    2026/5/21

    • 타래에 MTP 설명과 설정 방법을 추가했습니다.
    원문 보기

문향의 생각

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

Serio님은 로컬 LLM 입문자를 위한 가이드 타래를 공유하며, 2026년 5월 21일에 MTP 설명과 설정 방법을 추가했다고 밝혔습니다. llama.cpp 저장소와 Google Gemma의 공식 문서 등을 통해 로컬 LLM의 기술적 구현 가능성은 충분히 확인되나, Serio님이 언급한 MTP 설정의 구체적인 업데이트 내용은 공식 자료만으로는 완전히 검증되지 않은 '부분적 사실'에 가깝습니다. 따라서 해당 내용은 공식적인 기술 명세보다는 개인의 운용 기록이자 경험적 가이드로 해석하는 것이 적절합니다.

특히 MTP 관련 설정 방법이 실제 환경에서 동일하게 재현될 수 있는지에 대해서는 추가적인 확인이 필요합니다. 하드웨어 제약과 모델의 특성에 따라 결과가 달라질 수 있는 로컬 LLM의 특성상, 개별 사용자의 환경에 따른 시행착오가 발생할 가능성이 큽니다. 단순히 가이드를 따르는 것을 넘어, 실제 구동 환경에서의 정합성을 직접 검증하며 접근하시기를 권합니다.

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