로컬 LLM

로컬 LLM 실험실

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

Serio의 X 스레드

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

  1. 1

    결국 이 새벽에 또 혼자 답답해서 지피티랑 도커 까고 앉아있네. 도커 모델 러너가 답이 될 수 있겠다는 (왜 이걸 못찾았지?) 생각으로 들여다보는 중

    https://t.co/mzDbxZZYfX

    역시 고래한테는 답이 있나.

    원문 보기
  2. 2

    9일은 뒤쳐져 있을 수 있는데 114 커밋 뭐냐.

    무슨 전세계의 LLM들이 안데스산맥의 AI 짐승을 들쳐 매고 뛰고 있기라도 한거야? https://t.co/8R4vVDNoiR

    원문 보기

문향의 생각

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

Serio님은 로컬 LLM 운용 과정에서 겪은 기술적 병목을 해결하기 위해 도커(Docker) 기반의 모델 러너를 검토하며, 특정 저장소의 급격한 커밋 횟수 증가에 놀라움을 표하셨습니다. 깃허브(GitHub)의 llama.cpp 저장소 등을 통해 모델 최적화와 업데이트가 매우 빠르게 이루어지고 있다는 사실은 객관적으로 확인되지만, 이를 '안데스산맥의 AI 짐승을 메고 뛴다'고 비유한 부분은 개인의 주관적 감상이 투영된 표현입니다.

다만, 구체적으로 어떤 모델의 어떤 버전이 114회의 커밋을 유발했는지, 그리고 그것이 실제 성능 향상으로 이어졌는지에 대한 직접적인 연결 고리는 제공된 자료만으로는 확인이 필요합니다. 도커 모델 러너가 Serio님의 환경에서 실질적인 '답'이 될 수 있을지는 하드웨어 제약과 재현 가능성을 따져봐야 할 개인의 실험 영역입니다. 결국 이 기록은 최신 기술의 빠른 업데이트 속도와 그 간극을 메우려는 사용자의 시행착오를 보여주는 기술적 경험 기록이라 판단됩니다.

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

THREAD ESSAYX THREAD ARCHIVE

나도 결국 언젠가 윈도우를 버려야 할 시점이 오는가.

3개 글

Serio의 X 스레드

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

  1. 1

    나도 결국 언젠가 윈도우를 버려야 할 시점이 오는가.

    최소한 버리진 않더라도 Api 호출 / 개발 이원화를 해야 되는 시점이 필요할 거 같다는 생각.

    결국 성능을 바라는 순간 Vllm/Sglang인데 리눅스 아니면 정말 쓰기 까다롭고, llama.cpp 또한 제대로 쓰려면 리눅스 환경이 아니면 어렵다.

    원문 보기
  2. 2

    결국 모델 서빙과 개발 이원화를 해 두어야만 한다.

    전에 둘의 조화를 꾀하다 실패했고 결국 윈도우에 남아버렸지만 그건 6개월 전의 이야기고 그동안 많은 발전이 있어서 이번에는 다르지 않을까 생각 중.

    곧 방향을 설계하고 진행해 봐야겠다.

    원문 보기
  3. 3
    WSL2는 잘 만들어진 물건이지만, 메인으로 쓰긴 곤란. Wsl2를 사용하면서 관리가 안된 프로세스의 오버런이 윈도우의 실행환경을 압박하는 모습을 자주 목격했다. 윈도우가 OOM 에 상대적으로 강해서 느려지기만 할 뿐. 하나의 디바이스에 OS가 둘 이상 공존하는건 장난감일 때만 가능한 것.
    원문 보기

문향의 생각

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

Serio님은 로컬 LLM의 성능 최적화를 위해 윈도우 환경을 벗어나 모델 서빙과 개발 환경을 이원화하려는 계획을 밝히셨습니다. vLLM, Sglang, llama.cpp와 같은 도구들이 리눅스 환경에서 더 효율적으로 작동한다는 점은 기술적으로 확인되는 사실입니다. 다만, 6개월 전의 실패 이후 현재의 기술 발전이 이원화 설계를 성공시킬 수 있을지에 대해서는 개인적인 기대치에 해당하므로 실제 구현을 통한 검증이 필요합니다.

WSL2 사용 중 프로세스 오버런이 윈도우 실행 환경에 압박을 주었다는 주장은 개별 사용자의 경험 기록이며, 공식 자료로 일반화된 수치나 사례가 확인되지 않은 영역입니다. 특히 윈도우가 OOM(Out Of Memory) 상황에서 상대적으로 강하다는 판단 역시 구체적인 벤치마크 근거가 부족하여 확인이 필요합니다. 결국 하나의 디바이스에 두 OS를 공존시키는 것이 비효율적이라는 결론은 기술적 정답이라기보다 운용상의 시행착오에서 비롯된 주관적 판단에 가깝습니다.

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

Serio의 X 스레드

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

  1. 1

    가만히 있으면 한시라도 생각/망상이 쉬지 않는 사람으로서 로컬 LLM을 파면서 이걸로 폐쇄망에서 대체 무엇을 할 수 있는지를 진짜 여러번 생각했는데.

    제대로 된 생성/툴 콜링을 할 수 있는 모델이 이제서야 나왔고 이것조차 대충 gemini 3 - opus 4.5 사이의 어딘가 물건임.

    원문 보기
  2. 2

    결국 외부 레포 접근할 수 폐쇄망에서 참고용 코드 생성을 하고 그걸 자신의 지식과 비교해서 적용하거나, 검색 및 코드 리뷰 정도의 목적으로 활용하는 수준으로만 활용해야 한다.

    그러지 않고 바로 활성화된 폐쇄망 서비스에 붙이려고 한다면 재앙을 볼 것이다.

    원문 보기
  3. 3

    정말 사용하려면 꼼꼼히 짠 하네스로 작업의 방향을 제한시켜야 할 것인데, 그 순간 문제가 발생한다.

    ‘이게 대체 프로그램이랑 차이가 무엇인가?’

    그게 지금 AI의 가장 큰 딜레마임.

    자율성을 부여하면 원하지 않는 방향으로 작동하고 자율성을 제한하면 기존 프로그램들과 다를게 없어진다.

    원문 보기
  4. 4

    지나가다 본 트윗에, 한참 전에 했던 고민과 비슷한 고민을 하고 계시는 분이 있어서 다시 한 번 생각을 정리함.

    도움이 조금이나마 되었으면 좋겠습니다.

    그리고 혹시 도움이 되었다면 해피빈/카카오 같이가치 등에 후원하시면 그보다 더 기쁜 일은 없을 겁니다.

    https://t.co/mcOeeZjvDC

    원문 보기

문향의 생각

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

로컬 LLM의 폐쇄망 활용 가능성에 대해 다룬 이 글은 기술적 제약과 운용의 딜레마를 동시에 짚고 있습니다. 작성자는 최근 툴 콜링 능력이 향상된 모델들이 등장했으나, 여전히 특정 상용 모델들의 성능 범위 내에 머물러 있다는 기술적 판단을 내놓았습니다. 다만, 폐쇄망 서비스에 직접 연결했을 때 '재앙'이 올 것이라는 주장이나 구체적인 성능 비교 수치는 공식 자료로 검증되지 않은 개인의 경험적 판단이므로 추가적인 확인이 필요합니다.

결국 AI의 자율성과 통제 사이에서 발생하는 정체성 혼란이 핵심 쟁점으로 보입니다. 자율성을 제한해 프로그램처럼 운용하면 기존 소프트웨어와 차별점이 사라지고, 자율성을 부여하면 예측 불가능한 결과가 도출된다는 지적은 현재 LLM 운용의 실질적인 한계를 잘 보여줍니다. 이는 객관적 지표보다는 실제 구현 과정에서 겪는 시행착오에 기반한 기록으로, 로컬 환경에서 모델을 운용하려는 이들에게 유의미한 참고 자료가 될 것입니다.

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

SINGLE POSTX POST ARCHIVE

Deepseek V4 는 훌륭한 성과다.

1개 글

Serio의 X 포스트

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

  1. 1

    Deepseek V4 는 훌륭한 성과다.

    1.8T Moe로 열강과 우뚝 선것뿐만 아니라 제작 논문을 공개해 누구든지 딥시크를 어떻게 만들었고, 어떤 기술을 쓸 수 있는지 알렸다.

    한번이라도 AI모델 서빙을 해 본 사람이라면, Moe모델로 저 크기와 저 정밀도를 달성하는게 극히 어려운 일이라는 걸 알 것이다.

    원문 보기

문향의 생각

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

Serio님은 DeepSeek V4가 1.8T MoE 구조를 통해 거둔 성과와 논문 공개의 가치를 높게 평가하셨습니다. 모델의 규모와 논문 공개 사실은 공식 자료를 통해 확인되는 객관적 사실이나, 이를 통해 '열강과 우뚝 섰다'는 표현은 작성자의 주관적 판단이 개입된 영역입니다. 특히 MoE 모델에서 해당 크기와 정밀도를 달성하는 것이 극히 어렵다는 주장은 기술적 경험에 기반한 견해이므로, 보편적 사실로 확정하기에는 근거가 부족하여 확인이 필요합니다.

이 기록은 모델 서빙 경험을 가진 사용자가 체감한 기술적 난이도와 구현 성과에 집중하고 있습니다. 하드웨어 제약과 모델 최적화라는 실무적 관점에서 서술되었으나, 구체적인 벤치마크 수치나 재현 데이터가 제시되지 않은 점은 아쉽습니다. 결국 이 글은 공식 문서의 데이터보다는 실제 운용 과정에서 느낀 기술적 경이로움을 기록한 경험적 논평에 가깝습니다.

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

Serio의 X 포스트

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

  1. 1

    Mimo 2.5 q4 양자화는 170G 언저리쯤 되겠고 Q2~3 양자화가 관건인데. 128G램에 올라가야 로컬에서 의미가 있겠지.

    Vram 32기가/128기가가 장벽으로 되 있는걸 보니 옛날생각도 좀 나고 그러네요.

    320M 하드디스크 쓰고 하던 시절 말이죠.

    원문 보기

문향의 생각

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

Serio님은 Mimo 2.5 모델의 q4 양자화 용량을 약 170GB로 추산하며, 로컬 환경에서의 실질적인 활용을 위해 128GB 램 진입 여부가 관건이라고 분석하셨습니다. 다만, 구체적인 양자화 수치와 메모리 점유율에 대한 부분은 공식 문서나 저장소를 통해 직접적으로 검증된 사실이라기보다, 모델 크기에 기반한 개인의 기술적 추정치에 가깝기에 정확한 수치 확인이 필요합니다.

하드웨어 제약으로 인해 과거 320MB 하드디스크 시절을 회상하신 대목은 기술적 사실보다는 개인의 경험적 기록으로 보입니다. VRAM 32GB와 128GB라는 물리적 장벽이 로컬 LLM 운용의 실질적인 제약이 되고 있다는 점은 현재의 하드웨어 생태계와 맞물려 설득력이 있습니다. 결국 이 논의의 핵심은 모델의 경량화 수준이 일반 사용자의 하드웨어 가용 범위 내로 들어올 수 있느냐는 재현 가능성의 문제로 귀결됩니다.

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

SINGLE POSTX POST ARCHIVE

반복 이야기하지만

1개 글

Serio의 X 포스트

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

  1. 1

    반복 이야기하지만

    ‘LLM 컨텍스트 1M’

    을 믿지 마세요.

    아직 그 어떤 모델들도 공식적으로 ‘컨텍스트 부패’를 해결한 모델은 없습니다. 많은 모델들이 컨텍스트가 늘수록, 작업 사이클이 늘어날수록 내용을 잃어버립니다. 저는 그래서 에이전트의 롱텀 자율 작업을 부정적으로 봅니다.

    원문 보기

문향의 생각

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

Serio님은 LLM의 거대 컨텍스트 윈도우가 실제로는 '컨텍스트 부패'로 인해 내용을 소실한다는 점을 지적하며, 1M(백만) 토큰의 수치를 맹신하지 말 것을 권고합니다. 컨텍스트가 늘어날수록 정보 유지력이 떨어진다는 현상은 여러 벤치마크와 기술 문서에서 나타나는 경향성이므로 기술적 근거가 있는 주장입니다. 다만, 모든 모델이 공식적으로 이 문제를 해결하지 못했다는 단정적 표현은 모델별 업데이트 속도가 상이하므로 추가적인 전수 조사가 필요한 영역입니다.

에이전트의 롱텀 자율 작업에 대해 부정적인 견해를 보인 부분은 기술적 사실보다는 개인의 경험적 판단에 가깝습니다. 이는 특정 하드웨어 환경이나 모델의 제약 내에서 발생한 시행착오의 기록으로 보이며, 보편적인 기술적 한계로 확정 짓기에는 근거가 부족하여 확인이 필요합니다. 결국 수치상의 스펙보다 실제 운용 시의 재현 가능성과 신뢰도를 우선시해야 한다는 실무적 관점의 기록으로 이해됩니다.

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

Serio의 X 스레드

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

  1. 1
    다들 Qwen 3.6 27b 을 24G Vram에서 192K, 256K 컨텍스트로 작업했다고 말하는데 아무리 하이브리드로 설계되었다 한들 현행 구조상 컨텍스트 증가에 따른 Kv 캐쉬 메모리 팽창을 막을 수 없잖아. 세팅만 256K 했다 하곤 실제론 캐쉬공간 20~30K 써놓고 192K 256K 로 작업했다 말하는 것처럼 보임.
    원문 보기
  2. 2

    Qwen 3.6 plus 27b Q4 15G jacklong 기준

    • 3090 24G 단독 작동시의 컨텍스트 한계 80K.
    • Unsloth Q3 13.2G 의 경우 110K 정도.

    즉, LLama.cpp의 기본 설정인 공유 메모리 사용 켜놓고 설정만 하이 컨텍스트 실제론 로우 컨텍스트로 작업하고 있는 것으로밖에 안보임.

    원문 보기
  3. 3
    가용 Vram 을 다 쓴 다음에 공유 메모리에 컨텍스트를 보내니까, 설정 256K 를 해놓았다 한들 작업 컨텍스트량이 적으면 문제 없이 돌아가는 것으로 보임. 컨텍스트 Full-load 테스트를 하는 사람은 보이질 않네. 그런 면에서 금닭님 @gosrum 같이 실 세션 데이터를 보여주시는 사람은 귀중함.
    원문 보기
  4. 4

    @gosrum 내 작업환경은 3090X2 (48G) 인데 여기서

    Qwen 3.6 27b 를 256K 풀컨텍스트 로드시 예상 메모리 소요량은 47G 임. 그런데 그렇게 돌려도 컨텍스트가 230K 수준에 도달하면 토큰 생성 속도가 급속도로 느려지고 시스템 메모리 사용량이 늘어남.

    그래서 192K로 타협 보고 사용하고 있음.

    원문 보기

문향의 생각

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

Serio님은 Qwen 3.6 27B 모델을 24GB VRAM 환경에서 192K 이상의 고컨텍스트로 운용했다는 일부 주장이 실제로는 KV 캐시 메모리 팽창이라는 구조적 한계를 간과한 것이라고 지적합니다. 특히 Llama.cpp의 공유 메모리 설정으로 인해 설정값만 높고 실제 작업량은 적은 상태일 가능성이 크며, 3090 단독 사용 시 컨텍스트 한계가 80K~110K 수준이라는 구체적인 수치를 제시했습니다. 다만, 제시된 하드웨어별 컨텍스트 한계치와 메모리 소요량에 대한 데이터는 공식 벤치마크가 아닌 개인의 실험 기록이므로, 범용적인 지표로 확정하기에는 추가적인 검증이 필요해 보입니다.

작성자는 48GB VRAM 환경에서도 256K 풀 컨텍스트 로드 시 메모리 점유율이 임계치에 도달하며, 특정 시점부터 생성 속도가 급감하는 현상을 경험했다고 밝혔습니다. 이는 설정상의 수치와 실제 추론 과정에서의 가용 자원 사이에는 괴리가 있음을 시사하는 유의미한 운용 기록입니다. 다만, 시스템 메모리 전이로 인한 속도 저하의 정확한 임계점이 모델의 구조적 특성인지 혹은 특정 런타임의 최적화 문제인지는 아직 명확히 확인되지 않았습니다. 결국 실제 세션 데이터를 통한 풀 로드 테스트만이 하드웨어의 실질적 한계를 증명할 수 있을 것입니다.

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

THREAD ESSAYX THREAD ARCHIVE

벤치만 놓고 보면 '황제의 귀환'

3개 글

Serio의 X 스레드

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

  1. 1

    벤치만 놓고 보면 ‘황제의 귀환’

    중화권 AI의 만인지상 답게 애초부터 경쟁상대는 양키 최상위 그룹하고만 비교하는 패기. 그러면서도 1M 인/아웃풋 합계 5달러가 안됨.

    딥시크쇼크가 과연 재현될지? https://t.co/qgYVTW0TKl

    원문 보기
  2. 2

    공개날자도 Gpt 5.5와 같이 잡은건 우연이려나. 아니려나.

    오! 양키! 한번 한 번 제대로 붙어보자!

    라고 내놓긴 했는데 아직은 벽이 좀 있어 보임. 물론 그 벽은 작년에 비하면 진짜 격차가 줄어든 상태이지만.

    Pro보다는 Flash가 맘에 든다. 컨텍스트 확대가 마냥 답은 아님.

    원문 보기
  3. 3

    그래서 사실 게임체인저는

    Qwen 3.6 plus 27b

    인데. 로컬 단일그래픽카드 or 32기가 통합메모리에서 20~50t/s로 실행하는 Opus 4.5.

    세상이 너무 고자극에 길들여졌는지 이 의미를 잘 모르는 것 같아서 아쉽다. 🫠

    원문 보기

문향의 생각

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

최근 공개된 중화권 AI 모델들의 벤치마크 성능과 파격적인 가격 정책은 시장에 상당한 충격을 주고 있습니다. 특히 1M 토큰당 비용이 5달러 미만이라는 점과 특정 모델의 성능 수치는 공식 자료를 통해 어느 정도 확인되나, GPT-5.5와의 출시일 일치 여부나 의도적인 경쟁 구도는 추측에 가깝기에 확인이 필요합니다. 전반적으로 성능 격차가 줄어든 것은 사실이지만, 여전히 최상위 모델과의 간극이 존재한다는 판단은 합리적인 분석으로 보입니다.

다만 Qwen 3.6 plus 27b 모델이 로컬 환경의 단일 그래픽카드나 32GB 통합 메모리에서 초당 20~50토큰의 속도로 Opus 4.5 수준의 성능을 낸다는 주장은 근거가 부족합니다. 이는 하드웨어 제약과 모델 최적화 수준에 따라 결과가 판이하게 달라지는 영역이며, 공식적인 벤치마크보다는 개인의 실행 경험 기록으로 보는 것이 타당합니다. 고자극의 성능 지표보다 실제 로컬 운용 효율성에 주목해야 한다는 시각은 유효하나, 구체적인 수치적 재현 가능성은 추가 검증이 필요합니다.

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

SINGLE POSTX POST ARCHIVE

아.

1개 글

Serio의 X 포스트

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

  1. 1

    아.

    qwen 3.5 27b Q4 양자화로 128K 만 올릴수있으면 2장 있는 3090을 동시에 사용할 수 있는데. 지금은 Q3 가 100K 고, Jacklong 튜닝버전이 80K 수준이네. 256K 를 올렸다는데 어떻게 했지?

    llama.cpp로 다시 넘어가야하는가? 조금 성능 손해보더라도 설정 귀찮아서 안넘어가고있었거늘.

    원문 보기

문향의 생각

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

Serio님은 RTX 3090 2장의 VRAM 자원을 활용해 Qwen 3.5 27B 모델의 컨텍스트 길이를 확장하려는 시도와 그 과정에서의 제약을 언급하셨습니다. Q3 양자화 모델의 100K 지원과 Jacklong 튜닝 버전의 80K 수준이라는 수치는 개별 모델의 배포 상태에 따른 경험적 기록으로 보이나, 특정 버전이 256K까지 확장되었다는 주장은 공식 자료만으로는 명확히 검증되지 않아 추가 확인이 필요합니다.

현재 사용 중인 환경에서 성능 손실을 감수하고 llama.cpp로 회귀할지를 고민하는 지점은 하드웨어 제약과 소프트웨어 설정 사이의 전형적인 트레이드오프 상황을 보여줍니다. 다만, 양자화 수준에 따른 컨텍스트 윈도우의 가변성과 실제 가용 메모리 계산의 상관관계에 대해 구체적인 근거 제시가 부족하므로, 이는 기술적 사실보다는 개인의 운용 경험에 기반한 판단으로 읽힙니다. 효율적인 자원 배분을 위해 툴 체인 변경을 고려하는 실무적인 고민이 돋보이는 기록입니다.

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

SINGLE POSTX POST ARCHIVE

하루종일 Qwen 3.7 27b 로 작업해보고있는데

1개 글

Serio의 X 포스트

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

  1. 1
    하루종일 Qwen 3.7 27b 로 작업해보고있는데 결과물은 괜찮은데 생각보다 호출/프리필/토큰생성이 불안함. 로드 잘 걸리면 잘 되는데, 안될때도 종종 있음. 안데스 야생동물의 업글이 시급하다. https://t.co/xBm78rsvPc
    원문 보기

문향의 생각

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

Serio님은 Qwen 3.7 27b 모델을 사용하며 결과물의 품질은 만족스러우나, 호출과 프리필 및 토큰 생성 과정에서 간헐적인 불안정성을 경험하셨습니다. 다만, 이러한 성능 저하가 모델 자체의 결함인지 혹은 특정 추론 엔진이나 하드웨어 가속 환경의 문제인지는 공식 자료를 통해 명확히 확인되지 않아 추가적인 확인이 필요합니다.

특히 '안데스 야생동물'로 비유된 특정 환경의 업그레이드가 시급하다는 주장은 개인의 사용 경험에 기반한 판단으로 보입니다. 로컬 LLM 운용 특성상 재현 가능성이 낮고 환경 변수가 많으므로, 이를 일반적인 기술 결함으로 단정하기에는 근거가 부족합니다. 따라서 해당 내용은 기술적 사실보다는 개별적인 시행착오 기록으로 읽는 것이 적절합니다.

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