# \#llama-cpp **URL:** https://discuss.pytorch.kr/tag/llama-cpp/4791.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [Hugging Face, Apple Foundation Models 코드를 그대로 로컬과 클라우드에서 사용 가능한 AnyLanguageModel 1.0 공개](https://discuss.pytorch.kr/t/hugging-face-apple-foundation-models-anylanguagemodel-1-0/12258)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 23, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/hugging-face-apple-foundation-models-anylanguagemodel-1-0/12258 "2026-10-23T07:30:45Z")
핵심 요약 Hugging Face가 Apple Foundation Models API를 그대로 따르는 Swift 패키지인 AnyLanguageModel 1.0을 발표했습니다. import 한 줄만 바꾸면 같은 세션 코드로 시스템 모델, MLX, llama.cpp, Core ML, 클라우드 API를 바꿔 쓸 수 있습니다. 지난 1년 동안 도구 호출과 구조화된 출력(Guided Generation)이 모든 제공자에서 동작하게 되었습니다. 클라우드 쪽도 Open Responses 호환 엔드포인트와 Private Cloud Compute까지 넓어졌고, 클라우드 제공자도 로컬 모델과 같은 기능을 받습니다. 함께 1.0이 된 swift-huggingface와 swift-xet는 Hub에서 모델을 받는 경로를 맡습니다. 세 패키지 모두 공개 API를 확정하면서 호환성을 깨는 변경이 있습니다. 기존 앱은 업그레이드 전에 AnyLanguageModel 1.0.0 릴리스 노트를 확인해야 합니다. 예전 버전이 만든, 연관 값이 있는 enum 콘텐츠는 1.0에서 디코딩되지 않습니다. AnyLanguageModel 1.0 소개 AnyLanguageModel 은 Apple의 Foundation Models 프레임워크와 같은 API를 제공하면서, 앱이 쓸 모델과 제공자를 개발자가 고르게 해 주는 Swift 패키지입니다. Mattt가 2025년 11월 Hugging Face 블로그에 첫 소개 글을 낸 뒤 1년 동안 수십 번 릴리스했고, 2026년 10월 13일에 1.0.0을 냈습니다. 10월 20일에 나온 블로그 글은 그 1년을 정리하고 다음 계획을 밝힙니다. Foundation Models는 Apple이 OS 26 세대부터 기기 안 소형 언어 모델을 쓰라고 제공한 프레임워크입니다. LanguageModelSession 하나로 프롬프트를 보내고 스트리밍 응답을 받습니다. 같은 세션에서 @Generable 매크로로 타입이 정해진 출력을 요청하거나 도구를 호출할 수도 있습니다. 문… --- ## [Strata: 12GB 그래픽카드 PC에서 125B 모델 Qwen3.8-Flash-Next만을 위해 만든 추론 엔진](https://discuss.pytorch.kr/t/strata-12gb-pc-125b-qwen3-8-flash-next/12189)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 16, 2026, 12:00오후 UTC](https://discuss.pytorch.kr/t/strata-12gb-pc-125b-qwen3-8-flash-next/12189 "2026-10-16T12:00:01Z")
핵심 요약 Strata는 1,250억(125B) 파라미터 MoE 모델 Qwen3.8-Flash-Next 하나만을 위해 작성한 추론(Inference) 엔진입니다. 12GB 이상 그래픽카드와 32GB 이상 RAM을 갖춘 Windows/Linux PC에서 이 모델을 실행합니다. 개발자가 RTX 5070(12GB)과 64GB RAM PC에서 측정한 짧은 대화의 생성 속도는 2비트 Q2\_0 기준 초당 94토큰, 기본 크기 중 가장 큰 IQ3\_S 기준 초당 53토큰입니다. 그래픽카드에는 자주 쓰이는 전문가(expert)만 두고, 전문가 2만 4,576개 전체는 RAM에 둔 채 CPU가 나머지를 동시에 계산합니다. 모델에 들어 있는 다중 토큰 예측(MTP) 층으로 여러 토큰을 한 번에 검증해 생성 속도를 1.6~1.8배 높입니다. 같은 RTX 3060 PC에서 개발자가 비교한 llama.cpp v0.6.0 대비 생성 속도는 약 4.6배였지만, llama.cpp 쪽 튜닝 범위가 좁았다고 개발자 스스로 밝힌 자체 측정입니다. OpenAI와 Anthropic 호환 API를 127.0.0.1:8080에 열어 코딩 에이전트를 연결할 수 있고, 기본 설정은 한 번에 한 요청만 처리합니다. Strata 소개 Qwen3.8-Flash-Next (:pytorch::kr: Qwen3.8-Flash-Next, 1/9의 학습 비용으로 Qwen3.7-Plus(397B-A17B) 수준에 도달한 125B-A6B 모델)는 전체 125B 파라미터 중 토큰마다 6B만 활성화하는 전문가 혼합(Mixture of Experts, MoE) 모델입니다. 활성 파라미터가 작아도 가중치 전체는 어딘가에 올려 두어야 하고, Strata 개발자에 따르면 쓸 만한 품질을 내는 가장 작은 양자화(quantization) 파일도 66GB로 12GB 그래픽카드 메모리의 5.5배입니다. 보통은 llama.cpp 같은 범용 엔진으로 일부 가중치를 시스템 RAM에 두고 CPU에서 계산합니다. 개발자는 이 방식이 동작은 … --- ## [DigUp: EmbeddingGemma 2 모델로 사진, PDF, 녹음, 영상 속 내용을 문장으로 찾는 (macOS의 Spotlight와 같은) 로컬 파일 검색 앱 🔍](https://discuss.pytorch.kr/t/digup-embeddinggemma-2-pdf-macos-spotlight/12205)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 16, 2026, 8:30오전 UTC](https://discuss.pytorch.kr/t/digup-embeddinggemma-2-pdf-macos-spotlight/12205 "2026-10-16T08:30:40Z")
핵심 요약 DigUp은 Google DeepMind의 EmbeddingGemma 2 모델로 사진, PDF, 문서, 녹음, 영상, 코드를 한 색인에 넣는 데스크톱 앱입니다. 파일 이름 대신 내용을 설명하는 문장으로 파일을 찾습니다. 검색 결과를 열면 PDF는 해당 페이지, 녹음과 영상은 해당 시점, 코드는 편집기의 해당 줄로 이동합니다. 송장 번호나 오류 코드 같은 정확한 문자열은 별도의 키워드 색인으로 찾습니다. 모델(865MB)을 처음 한 번 내려받는 것과 하루 한 번의 업데이트 확인 외에는 네트워크를 쓰지 않으며, 계정과 원격 측정(Telemetry)이 없습니다. Apple Silicon Mac(macOS 14 이상)용이 정식 버전이고 Windows와 Linux용은 2026년 10월 14일에 공개된 베타입니다. 첫 릴리스가 10월 9일인 초기 프로젝트라 버그 보고와 기능 요청 이슈가 많이 열려 있습니다. DigUp 소개 팟캐스트에서 수면 이야기가 나온 대목이나 영상에서 얼룩말이 나온 장면을 다시 찾으려 할 때, 기억나는 것은 파일 이름이 아니라 내용인 경우가 많습니다. DigUp 개발자는 운영체제의 기본 검색인 Spotlight와 Windows Search가 파일을 이름, 텍스트, 메타데이터로 찾는다고 설명합니다. 녹음 속 대화나 영상 속 장면처럼 파일이 보여 주거나 들려주는 내용으로 찾고, 그 페이지나 시점까지 바로 여는 것이 DigUp이 기본 검색과 다른 점입니다. 이번에 소개하는 DigUp은 내 컴퓨터의 파일을 내용 기준으로 색인하는 로컬 검색 앱입니다. 찾고 싶은 것을 문장으로 설명하면 파일 종류와 상관없이 맞는 결과를 보여 줍니다. DigUp은 Google DeepMind가 2026년 10월 공개한 멀티모달 임베딩 모델 EmbeddingGemma 2를 사용합니다. 임베딩(Embedding) 모델은 입력을 고정 길이의 벡터로 바꾸고, 뜻이 가까운 입력끼리 벡터도 가깝게 놓는 모델입니다. EmbeddingGemma 2는 텍스트, 이미지, 오… --- ## [Liquid AI, 엣지 기기에서 한 번의 순전파로 판단하는 결정 모델 d1-3B와 d1-omni-600M 공개](https://discuss.pytorch.kr/t/liquid-ai-d1-3b-d1-omni-600m/12130)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 9, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/liquid-ai-d1-3b-d1-omni-600m/12130 "2026-10-09T06:30:14Z")
핵심 요약 Liquid AI가 Open d1 소개 글에서 결정 모델 두 종의 가중치를 공개했습니다. 디코더 기반 d1-3B는 텍스트와 이미지를, 인코더 기반 실험판 d1-omni-600M은 텍스트와 이미지 또는 텍스트와 음성을 받습니다. 두 모델 모두 문장을 생성하지 않고, 예/아니오(Noul), 선택(Choice), 점수(Score) 질문에 대한 확률을 순전파 한 번으로 돌려줍니다. Transformers와 llama.cpp로 로컬에서 실행할 수 있습니다. Liquid AI가 직접 잰 Decision Index 0.2.1에서 d1-3B는 48.57점으로 10B 미만 모델 중 가장 높았습니다. d1-omni-600M은 15.95점이며, Hugging Face 블로그 본문에는 이 점수가 빠져 있습니다. d1-3B는 Jetson AGX Thor에서 질문 하나에 16ms, Jetson Orin Nano에서 50ms가 걸렸습니다. d1-omni-600M의 속도는 공개하지 않았습니다. 라이선스는 LFM Open License v1.0입니다. 연 매출 1천만 달러 이상인 기업의 상업적 사용은 허가 범위 밖이어서, Liquid AI 블로그의 "제한 없이"라는 표현과 다릅니다. :information\_source: 이전 d1 글과 무엇이 다른가요? 이전 d1 글은 9월 말 출시된 호스팅 API d1을 다뤘고, 이 글은 가중치를 공개한 별도의 작은 모델 두 종을 다룹니다. 대상 모델: 이전 글은 가중치를 공개하지 않은 API d1, 이 글은 공개 가중치 d1-3B와 d1-omni-600M입니다. 이름은 같은 계열이지만 서로 다른 모델이고, Decision Index 자체 측정 점수도 약 60점 대 48.57점으로 다릅니다. 실행 방식: 이전 글은 Liquid API를 typesafe-sdk로 호출하는 방법을, 이 글은 Transformers, llama.cpp, Jetson에서 로컬로 실행하는 방법을 설명합니다. 다루는 내용: 이전 글은 질문 설계, confi… --- ## [Hugging Face Transformers, 이제 GGUF 가중치도 지원하여 바로 불러와 실행 가능 (feat. llama.cpp, ggml)](https://discuss.pytorch.kr/t/hugging-face-transformers-gguf-feat-llama-cpp-ggml/12036)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 29, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/hugging-face-transformers-gguf-feat-llama-cpp-ggml/12036 "2026-09-29T02:30:02Z")
Transformers의 GGUF 직접 실행 지원 소개 Hugging Face가 Transformers에서 llama.cpp용 GGUF 양자화 체크포인트를 압축된 그대로 불러와 실행하는 기능을 공개했습니다. Hub에서 GGUF 파일 하나를 골라 from\_pretrained()에 파일 이름만 넘기면, 노트북 메모리에 맞게 줄여 둔 모델을 익숙한 Transformers API로 바로 생성에 쓸 수 있습니다. 첫 지원 대상은 Apple Silicon Mac과 Qwen3.5 계열 아키텍처입니다. 로컬 추론 생태계에서 llama.cpp가 차지하는 위치는 큽니다. Ollama, LM Studio, Jan 같은 로컬 AI 도구가 llama.cpp의 추론 엔진 위에서 동작하고, Apple의 MLX와 함께 노트북에서 LLM을 실행하는 일을 일상적인 선택지로 만들었습니다. 이 과정에서 llama.cpp 팀이 만든 GGUF 포맷은 로컬 추론에 널리 쓰이는 포맷이 되었습니다. llama.cpp 팀은 Hub의 ggml-org에 직접 양자화 체크포인트를 올리고 있고, Unsloth, LM Studio Community, bartowski 같은 배포자도 여러 양자화 수준의 GGUF를 제공합니다. Hugging Face에 따르면 GGUF 모델의 누적 다운로드는 수백만 회에 이릅니다. 사실 Transformers에서 GGUF 파일을 여는 것 자체는 새로운 일이 아닙니다. 2024년 5월의 Transformers v4.41.0부터 gguf\_file 인자로 GGUF를 불러올 수 있었습니다. 다만 이 방식은 불러오는 시점에 모든 가중치를 역양자화(Dequantization) 해서 일반적인 PyTorch 밀집(dense) 모델로 바꾸었기 때문에, 4비트로 줄여 둔 파일이 메모리 안에서는 다시 원래 크기로 부풀었습니다. 양자화로 얻은 메모리 절감이 불러오는 순간 사라지는 셈입니다. 이번 업데이트의 핵심은 가중치를 압축된(packed) 상태 그대로 GPU에 올리고, llama.cpp가 쓰는 g… --- ## [llmfit: 로컬 LLM 모델을 내려받기 전, 내 하드웨어에서의 생성 속도(tok/s)가 얼마 정도일지 추정하는 도구](https://discuss.pytorch.kr/t/llmfit-llm-tok-s/11922)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 16, 2026, 3:00오전 UTC](https://discuss.pytorch.kr/t/llmfit-llm-tok-s/11922 "2026-09-16T03:00:55Z")
llmfit 소개 로컬에서 대규모 언어 모델(Large Language Model, LLM)을 직접 실행해 보려는 사람이 가장 먼저 부딪히는 질문은 내 컴퓨터에서 어떤 모델이 실제로 실행 가능한지에 대한 것입니다. 모델 크기(파라미터 수)와 양자화(Quantization) 포맷, 컨텍스트 길이, GPU의 VRAM과 시스템 RAM 등, 여러가지 요구 조건과 제약들을 따져봐야 하기 때문에 모델 카드만 보고 메모리 요구량을 짐작하기가 쉽지 않습니다. 그래서 수 GB짜리 GGUF 파일을 먼저 내려받아 실행해 본 뒤에야 메모리가 모자라거나 초당 토큰 수가 쓸 만한 수준이 아니라는 사실을 알게 되는 경우도 흔하게 발생합니다. 사용해보려고 하는 후보 모델이 늘어날수록 이러한 시행착오의 횟수도 함께 늘어나고, 어느 양자화 단계까지 내려가야 메모리에 들어가는지는 결국 하나씩 다운로드 받아 실행하며 확인하게 됩니다. 이번에 소개하는 llmfit은 이러한 확인 작업을 줄이는 것을 목표로 하는 프로젝트로, 지금 사용하는 컴퓨터에서 어떤 모델이 얼마나 빠르게 토큰을 생성(tok/s)할 수 있을지를 추정하는 터미널 도구입니다. llmfit은 실행하는 즉시 CPU 코어 수와 시스템 RAM, GPU와 VRAM, 가속 백엔드 등을 자동으로 확인한 다음, 내장 카탈로그에 담긴 수백 개 모델을 품질과 속도, 적합도, 컨텍스트라는 네 가지 기준으로 점수를 매겨 표로 정리합니다. 각 행에는 그 모델이 지금 이 컴퓨터에서 어떤 양자화로 실행 가능한지, 예상 속도가 몇 tok/s인지, 메모리를 몇 퍼센트나 쓰는지가 함께 표시됩니다. 여기에 더해 llmfit은 그 속도 숫자가 공식으로 계산한 추정치인지 누군가 같은 하드웨어에서 실제로 측정한 값인지를 등급으로 구분해 표시합니다. 실제로 측정한 처리량과 공식으로 계산한 값이 모두 tok/s라는 같은 단위로 표시되기 때문입니다. llmfit은 Rust로 작성하였으며, 실행 모드 시 의존성이 필요 없는 가벼운 대화형 터미널 UI(TUI)를 기본… --- ## [Hugging Face가 공개한 2026 여름 기준 공개된 AI 모델 보고서: 좋아요와 다운로드는 서로 다른 경제입니다](https://discuss.pytorch.kr/t/hugging-face-2026-ai/11674)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 20, 2026, 10:00오전 UTC](https://discuss.pytorch.kr/t/hugging-face-2026-ai/11674 "2026-08-20T10:00:00Z")
Hugging Face 2026 여름 오픈 모델 보고서 소개 Hugging Face가 2026년 1월부터 8월까지 자사 Hub에서 관측한 오픈 모델 생태계의 변화를 6개의 발견으로 정리한 State of Open Models: Summer 2026 Observations를 공개했습니다. 반년 주기로 나오는 이 보고서의 특징은 업계 관계자 인터뷰나 벤치마크 리더보드가 아니라 Hub의 실제 활동 로그, 즉 저장소 생성, 다운로드, 좋아요, 파생 모델 생성, 라이브러리 태그 선언을 원자료로 삼는다는 점입니다. 어떤 모델이 화제인지가 아니라 어떤 모델이 실제로 파이프라인에 꽂혀 있는지를 볼 수 있는 자료라서, 모델을 고르고 배포해야 하는 입장에서는 리더보드보다 실용적인 정보를 담고 있습니다. 이번 보고서는 2026년 봄 보고서의 후속편입니다. 봄 보고서가 오픈소스 AI의 지형 변화, 즉 중국이 월간 다운로드에서 미국을 앞지른 사건과 산업계 비중이 70%에서 37%로 내려가고 개인 및 무소속 개발자의 비중이 17%에서 39%로 올라간 구조 변화를 다뤘다면, 이번 여름 보고서는 그 지형 위에서 벌어진 7개월간의 움직임을 훨씬 좁고 구체적인 수치로 좁혀 봅니다. 작성자는 Hub의 중국 생태계를 담당하는 Adina Yakefu, 멀티모달 아트 팀의 Apolinário Passos, 정책 및 사회적 영향 책임자인 Irene Solaiman 세 사람입니다. 먼저 전체 규모를 보겠습니다. 이 기간에 공개 모델 저장소는 243만 개에서 296만 개로, 데이터셋은 71만 1천 개에서 100만 개로, Spaces는 100만 개에서 144만 개로 늘었습니다. 다만 이 성장의 분포는 극단적으로 치우쳐 있습니다. 전체 모델의 약 85.6%는 누적 다운로드가 200회 미만이고, 상위 1.5%의 저장소가 전체 다운로드의 99.2%를 차지합니다. 아래에 이어지는 모든 발견은 이 형태 안에서 벌어지는 일이라는 전제를 깔고 읽어야 합니다. 데이터셋 증가 곡선은 이 가속을 한눈에 보여… --- ## [Fermion Research, 3진 계열 포맷으로 직접 학습한 Neutrino-1 모델군 3종 공개](https://discuss.pytorch.kr/t/fermion-research-3-neutrino-1-3/11456)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 30, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/fermion-research-3-neutrino-1-3/11456 "2026-07-30T00:30:41Z")
Neutrino-1 모델군 소개 Fermion Research가 2026년 7월 27일 Neutrino-1 모델군 3종을 공개했습니다. 8B급 플래그십인 Neutrino-1 8B, 초안 모델 겸 소형 모델인 Neutrino-1 0.6B, 그리고 대화용으로 마무리한 Neutrino-1 0.6B-Chat입니다. 세 모델 모두 Apache License 2.0 오픈 가중치이며 대기 명단이나 승인 절차 없이 Hugging Face에서 바로 받을 수 있습니다. 이 릴리즈에서 가장 먼저 눈에 들어오는 숫자는 하나입니다. 8B 파라미터 모델이 디스크에서 3.88GB, 다운로드로는 2.56GB이고, 그 상태로 5-shot MMLU 72.1을 받았다는 것입니다. 지난 10년간 이 분야는 저장 폭의 사다리를 한 칸씩 내려왔습니다. 8비트 추론이 2010년대 후반에 표준이 되고, 4비트 가중치가 2023년 오픈 7B 모델들과 함께 대중화됐습니다. 그 다음 칸이 오래 비어 있었습니다. 가중치를 3개 상태로 저장하는 접근은 BitNet b1.58 계열로 2024년에 트랜스포머 언어 모델까지 올라왔지만, 8B급에서 상위권 지식 점수를 유지한 사례는 나오지 않았습니다. 단일 스트림 디코딩(single-stream decode) 이 대역폭 문제라는 사실이 이 사다리를 계속 내려가게 만드는 동력입니다. 토큰 하나를 만들려면 모델의 살아 있는 가중치를 전부 한 번 읽어야 하므로, 저장 폭이 절반이 되면 토큰당 옮길 바이트도 절반이 됩니다. Fermion Research가 내놓은 답은 포맷을 학습 중에 미리 넣어두는 것(native-format training) 입니다. 완전 정밀도로 학습한 뒤 반올림하는 것이 아니라, 학습의 모든 순전파가 이미 그 저해상 포맷 안에서 일어나게 만듭니다. 세 모델은 토크나이저, 컨테이너 레이아웃, 추론 엔진을 공유합니다. H100에서 도는 파일과 맥북에서 도는 파일이 바이트 단위로 같고, 그래서 0.6B가 8B와 같은 프로세스 안에 올라가 초안 모델(… --- ## [Club-3090: RTX 3090 GPU에서 vLLM, llama.cpp, SGLang으로 LLM을 서빙하는 커뮤니티 레시피 모음](https://discuss.pytorch.kr/t/club-3090-rtx-3090-gpu-vllm-llama-cpp-sglang-llm/10021)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [5월 4, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/club-3090-rtx-3090-gpu-vllm-llama-cpp-sglang-llm/10021 "2026-05-04T09:30:49Z")
Club-3090 프로젝트 소개 소비자용 GPU인 RTX 3090으로 대규모 언어 모델(Large Language Model, LLM)을 서빙하려는 시도는 매력적이지만 실제로 해보면 수많은 장벽에 부딪힙니다. 메모리 최적화, 엔진 설정, 모델 양자화, 멀티 GPU 구성 등 각 환경마다 최적의 설정이 다르기 때문에 시행착오에 많은 시간이 소요됩니다. club-3090은 바로 이 문제를 커뮤니티 협업으로 해결하려는 프로젝트입니다. RTX 3090 환경에서 LLM을 서빙하기 위한 실전 설정과 레시피를 체계적으로 모아둔 오픈소스 저장소로, 개인 개발자와 소규모 팀이 고가의 데이터센터 GPU 없이도 최신 모델을 운영할 수 있도록 돕습니다. 이 프로젝트의 핵심은 멀티 엔진 지원입니다. vLLM, llama.cpp, SGLang 세 가지 주요 LLM 추론 엔진을 모두 지원하며, 각 엔진의 특성에 맞는 최적화된 설정 파일을 제공합니다. vLLM은 높은 처리량(throughput)과 PagedAttention 기반의 효율적인 KV 캐시 관리로 API 서버 용도에 적합하고, llama.cpp는 양자화된 모델의 CPU/GPU 혼합 추론에 강점이 있으며, SGLang은 복잡한 프롬프트 패턴과 구조화된 출력을 다룰 때 유리합니다. club-3090은 이 세 엔진을 RTX 3090 환경에서 어떻게 구성하는지 실전 경험을 바탕으로 정리해두었습니다. 현재 club-3090이 중점적으로 제공하는 설정은 Qwen3.6-27B 모델을 위한 것입니다. RTX 3090 1장(24GB VRAM) 환경과 2장 환경 모두에 대한 설정을 별도로 제공하여, 보유한 GPU 구성에 따라 바로 적용할 수 있습니다. Apache-2.0 라이선스로 공개되어 있어 커뮤니티 기여도 활발하게 진행되고 있으며, 모델-하드웨어 조합이 늘어날수록 레시피 풀이 확장되는 구조입니다. club-3090의 지원 엔진 비교 club-3090이 지원하는 세 엔진은 각각 다른 사용 사례에 적합합니다. 엔진 주요 … --- ## [\[GN⁺\] Gemma 4를 Codex CLI에서 로컬 모델로 실행하기](https://discuss.pytorch.kr/t/gn-gemma-4-codex-cli/9760)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 17, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/gn-gemma-4-codex-cli/9760 "2026-04-17T09:30:08Z")
Gemma 4를 Codex CLI에서 로컬 모델로 실행하기 글 소개 Gemma 4를 클라우드 대신 로컬 Codex CLI 환경에서 실행해 도구 호출 성능과 안정성을 검증한 사례로, GPT-5.4 대비 비용/프라이버시 이점을 확인 Mac(M4 Pro) 24GB 에서 26B MoE 와 NVIDIA GB10 128GB 에서 31B Dense 로 각각 llama.cpp와 Ollama를 사용해 동일한 코드 생성 작업을 수행, 설정 차이에 따른 성능을 비교 도구 호출 성공률이 6.6%에서 86.4%로 향상되어 로컬 모델의 실용 가능성이 입증되었으며, GB10 환경에서는 완전한 코드 생성을 달성 Mac은 5.1배 빠른 토큰 생성 속도를 보였으나, 메모리 제약과 양자화 설정으로 인해 반복 시도가 필요했고, GB10은 느리지만 첫 시도에 성공 결과적으로 로컬 모델도 실무 수준 코드 생성이 가능하며, 프라이버시 중심의 로컬 처리와 복잡 작업의 클라우드 전환을 병행하는 하이브리드 접근을 추천 로컬 모델 전환 동기 비용 문제로, Codex CLI를 하루 여러 세션, 때로는 병렬로 실행하면서 API 비용이 누적 프라이버시 요구로, 일부 코드베이스는 외부 서버로 전송되면 안 됨 안정성 확보 필요로, 클라우드 API는 스로틀링, 장애, 가격 변경 리스크 존재 이전에 로컬 모델을 시도하지 않은 이유는 도구 호출(tool calling) 불가 때문이었으며, Codex CLI의 핵심 가치는 모델이 파일 읽기, 코드 작성, 테스트 실행, 패치 적용을 수행하는 데 있음 이전 Gemma 세대는 tau2-bench 함수 호출 벤치마크에서 6.6%(100번 중 93번 실패)였으나, Gemma 4 31B는 86.4% 로 도약하여 테스트 가치가 생김 Mac 설정 과정 Ollama로 시작했으나, v0.20.3에서 Gemma 4의 도구 호출 응답이 tool\_calls 배열 대신 reasoning output으로 잘못 라우팅되는 스트리밍 버그 발생 Apple Silicon에서 Gemma 4 사… --- ## [agent.cpp: Mozilla AI가 공개한 C++ 기반의 경량 로컬 LLM 에이전트 프레임워크](https://discuss.pytorch.kr/t/agent-cpp-mozilla-ai-c-llm/8555)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [12월 31, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/agent-cpp-mozilla-ai-c-llm/8555 "2025-12-31T03:30:19Z")
agent.cpp 소개 agent.cpp는 Mozilla AI에서 개발한 C++ 기반의 LLM 에이전트 구축 라이브러리입니다. 이 프로젝트는 \*\*로컬 환경(Local)\*\*에서 소형 언어 모델(SLM)을 활용하여 에이전트를 구동하는 데 초점을 맞추고 있으며, 추론 엔진으로 llama.cpp를 핵심 구성 요소로 사용합니다. 최근의 AI 에이전트 개발이 대부분 Python 생태계(LangChain, AutoGen 등)나 외부 클라우드 API에 의존하는 것과 달리, agent.cpp는 외부 API 호출 없이 로컬 장비에서 완전히 독립적으로 동작하는 에이전트를 C++로 구현할 수 있게 해줍니다. 이는 인터넷 연결이 없는 환경이나 고성능이 요구되는 엣지 디바이스, 임베디드 시스템에서 AI 에이전트를 통합하려는 개발자들에게 적합합니다. agent.cpp 라이브러리는 단순히 텍스트를 생성하는 것을 넘어, 모델이 '도구(Tools)'를 사용하고, 작업을 반복(Loop)하며, 콜백(Callbacks)을 통해 시스템과 상호작용하는 에이전트 패턴을 C++ 표준(C++17 이상) 환경에서 제공합니다. 개발자는 이를 통해 시스템 쉘 명령을 실행하거나, 메모리를 관리하고, 복잡한 작업을 수행하는 다중 에이전트(Multi-Agent) 시스템을 구축할 수 있습니다. agent.cpp vs. llama.cpp 및 Python 프레임워크와의 비교 agent.cpp의 위치를 명확히 이해하기 위해 다른 기술들과 비교해 볼 수 있습니다. 먼저 llama.cpp와 비교를 해보면, llama.cpp는 LLM의 '두뇌' 역할을 하는 추론 엔진입니다. 모델 파일(GGUF)을 로드하고 텍스트를 생성하는 raw level의 기능을 제공합니다. 이에 비해, agent.cpp는 llama.cpp를 내장하여 그 위에 행동을 얹은 프레임워크입니다. 모델이 언제 도구를 사용해야 하는지 판단하고, 도구 실행 결과를 다시 모델에 입력하는 '루프(Loop)'와 '상태 관리' 기능을 제공합니다. 다음으로 Lan… --- ## [EdgeFoundry: 로컬 AI 모델을 위한 DevOps 플랫폼](https://discuss.pytorch.kr/t/edgefoundry-ai-devops/7897)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 3, 2025, 9:00오전 UTC](https://discuss.pytorch.kr/t/edgefoundry-ai-devops/7897 "2025-10-03T09:00:36Z")
EdgeFoundry 소개 EdgeFoundry는 로컬 환경에서 AI 모델을 배포, 모니터링, 관리할 수 있는 통합 DevOps 플랫폼입니다. TinyLlama, Phi-3 Mini 같은 경량 GGUF 모델을 대상으로 단순 실행 이상의 기능을 제공하며, 개발자가 모델 로딩, API 서버 구성, 성능 모니터링 등 번거로운 작업을 따로 신경 쓰지 않아도 되도록 만들어졌습니다. 이 프로젝트의 핵심 가치는 “로컬에서 간단하고 직관적으로 AI 모델을 실행하고 운영할 수 있는 경험”을 제공하는 데 있습니다. 일반적으로 로컬 AI 모델을 활용하려면 다양한 라이브러리 설치, 실행 환경 설정, 대시보드 구성까지 여러 단계를 거쳐야 합니다. 하지만 EdgeFoundry는 이를 하나의 패키지로 묶어 CLI 한 줄 명령어로 모델 배포부터 실시간 모니터링까지 처리할 수 있습니다. FastAPI 기반의 API 서버와 React 기반의 대시보드를 포함해, 개발자가 곧바로 실험과 운영을 시작할 수 있도록 돕는 것이 특징입니다. EdgeFoundry 플랫폼은 실시간 성능 추적, 모델 전환, 로컬 우선(Local-first) 설계라는 세 가지 키워드를 중심으로 발전하고 있습니다. 이를 통해 클라우드 의존성을 줄이고, 경량 모델 기반의 빠른 응답과 저비용 운영을 가능하게 합니다. 특히 연구, 개인 프로젝트, 기업 내부 테스트 환경 등 다양한 활용 시나리오에서 유용하게 쓰일 수 있습니다. 기존에는 로컬에서 모델을 실행하려면 llama.cpp 같은 경량 실행기와 별도의 모니터링 툴을 조합하거나, 클라우드 API를 활용하는 방식이 주류였습니다. 하지만 이 방식은 설정이 번거롭고 통합 관리가 어렵다는 단점이 있습니다. EdgeFoundry는 이러한 불편을 해결하기 위해 모델 관리, API 서버, 실시간 대시보드, 텔레메트리(telemetry) 시스템을 한 곳에 통합했습니다. 결과적으로 Docker 기반 배포보다 가볍고, Hugging Face API 기반보다 독립적이며, llama.cpp… --- ## [flask-htmx-llm: Flask, HTMX, LangChain으로 만드는 최소한의 학습용 LLM 챗봇 인터페이스](https://discuss.pytorch.kr/t/flask-htmx-llm-flask-htmx-langchain-llm/7421)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 5, 2025, 3:30오전 UTC](https://discuss.pytorch.kr/t/flask-htmx-llm-flask-htmx-langchain-llm/7421 "2025-08-05T03:30:41Z")
flask-htmx-llm 프로젝트 소개 오늘날 대규모 언어 모델(LLM)을 웹 애플리케이션에 통합하려는 시도가 활발히 이루어지고 있습니다. 하지만 대부분의 프로젝트는 복잡한 프론트엔드 프레임워크와 과도한 백엔드 설정으로 인해 초보자들이 접근하기 어려운 경우가 많습니다. 이러한 상황에서 flask-htmx-llm 프로젝트는 간결하고 직관적인 학습용 구조로 주목받고 있습니다. flask-htmx-llm 프로젝트는 Flask, HTMX, LangChain, 그리고 llama.cpp를 결합하여 구축된 미니멀한 LLM 챗봇 인터페이스로, 실습을 통한 학습에 초점을 맞춘 구조입니다. 특히 이 프로젝트는 프론트엔드에 복잡한 JavaScript 프레임워크를 사용하지 않고 HTMX를 활용하여 간단하고 직관적인 사용자 경험을 구현하고 있으며, 백엔드에서는 Server-Sent Events(SSE)를 통해 모델 응답을 스트리밍하는 방식을 채택하고 있습니다. :warning: 이 프로젝트는 프로덕션 환경에 적합하지 않지만, 로컬에서 안전하게 실험하며 기술을 익히기에 매우 좋은 출발점이 됩니다. LLM을 웹 앱에 통합하고 싶은 개발자라면 한 번쯤 직접 실행해보는 것을 추천합니다. :warning: LLM 기반 챗봇을 만들기 위한 프레임워크로는 LangChain 외에도 LlamaIndex, Haystack 등 다양한 라이브러리가 존재합니다. 그러나 LangChain은 워크플로우 구성과 다양한 모델, 툴 연동에 특화되어 있어 학습용으로 가장 널리 사용되는 도구 중 하나입니다. 또한 프론트엔드 측에서는 React, Vue.js, Svelte 등 다양한 대안이 있지만, HTMX는 HTML 속성 기반으로 인터랙티브한 UI를 구축할 수 있어, 복잡한 JS 코드 없이도 실시간 사용자 경험을 구현할 수 있다는 장점이 있습니다. 이 프로젝트는 그러한 장점을 잘 활용하여 최대한 간결한 구조로 챗봇 인터페이스를 구성하고 있습니다. flask-htmx-llm의 주요 구성 요소 Lan… --- ## [LTEngine: Rust 기반으로 완전 로컬 실행 가능한 AI 번역 API](https://discuss.pytorch.kr/t/ltengine-rust-ai-api/7128)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 19, 2025, 9:30오전 UTC](https://discuss.pytorch.kr/t/ltengine-rust-ai-api/7128 "2025-06-19T09:30:54Z")
LTEngine: Rust 기반으로 완전 로컬 실행 가능한 AI 번역 API LTEngine은 Rust로 작성된 오픈소스 로컬 AI 머신 번역 서버입니다. LibreTranslate의 API와 호환되며, llama.cpp와 llama.cpp의 Rust 바인딩인 llama-cpp-rs를 통해 로컬에 설치된 GGUF 형식의 대형 LLM을 사용해 번역을 수행합니다. 기존 LibreTranslate가 Argos Translate 기반 경량 모델을 사용했다면, LTEngine은 메모리와 속도를 희생해서라도 더 나은 번역 결과를 제공합니다. CPU만으로도 실행할 수 있지만, CUDA, Metal, Vulkan 같은 GPU 가속기를 활용하면 실사용에 충분히 대응할 수 있습니다 . LTEngine의 주요 기능 LibreTranslate API 호환: 기존 코드 수정 없이 대체 가능 다양한 모델 지원: gemma3-1b, 4b, 12b, gemma4-27b 등 GPU 가속 지원: CUDA, Metal (macOS), Vulkan 호환 정적 바이너리 빌드: 하나의 바이너리로 윈도우, 맥, 리눅스 실행 가능 AGPL‑3.0 라이선스: 강력한 오픈소스 보호 :hammer\_and\_wrench: 사용 방법 1. 의존성 설치 Rust clang, CMake C++ 컴파일러(g++, MSVC) 2. 클론 및 빌드 git clone https://github.com/LibreTranslate/LTEngine --recursive cd LTEngine cargo build --release --features cuda,vulkan,metal 3. 실행 ./target/release/ltengine 4. 모델 선택 기본은 gemma3-4b 명시적 실행 예시: ./ltengine -m gemma3-12b --model-file /path/to/custom.gguf GGUF 형식 모델은 llama.cpp 호환시 모두 지원 5. API 사용 예시 await fetch… --- ## [prima.cpp: 70B 규모의 LLM을 저사양 클러스터(Home Cluster)에서 실행하는 프로젝트](https://discuss.pytorch.kr/t/prima-cpp-70b-llm-home-cluster/6795)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [4월 16, 2025, 10:00오전 UTC](https://discuss.pytorch.kr/t/prima-cpp-70b-llm-home-cluster/6795 "2025-04-16T10:00:07Z")
prima.cpp 소개 llama.cpp 기반으로 개발된 prima.cpp는 70B급 LLM도 일반 가정용 기기에서 분산 실행할 수 있도록 도와주는 프로젝트입니다. prima.cpp는 대규모 언어 모델(LLM)을 실행하기 위해 고사양 GPU 서버가 필요하다는 인식을 깨는 프로젝트로, 극도로 낮은 메모리 사용량과 독특한 분산 구조를 통해 가정에 있는 노트북이나 스마트폰에서도 Llama 3-70B 같은 모델을 실행하는 것을 목표로 합니다. prima.cpp는 llama.cpp의 분산 구현체로, LLM을 여러 대의 저사양 기기에서도 실행할 수 있게 설계된 프로젝트입니다. 기존 llama.cpp 대비 월등한 성능과 혁신적인 분산 구조를 바탕으로, 저비용 클러스터 환경에서도 LLM을 운용할 수 있는 새로운 가능성을 제시합니다. 특히, 이 프로젝트는 mmap 기반의 레이지 로딩으로 메모리 압력을 최소화하며, 실제 실험에서는 70B 모델도 10% 이하의 메모리 사용률을 유지할 수 있었다고 합니다. 이는 OOM 걱정 없이 대규모 모델을 돌릴 수 있는 획기적인 접근 방식입니다. 또한, 모델 추론 속도 측면에서도 llama.cpp 대비 최대 15배 이상 빠른 성능을 보여주며, 다양한 플랫폼(맥OS, 리눅스, 안드로이드, HarmonyOS 등)을 지원합니다. Llama, Qwen, QwQ, DeepSeek 시리즈 등 다양한 모델을 지원하여 프라이버시 보호가 중요한 개인화 음성 비서(Home Siri) 등의 응용 사례에도 활용 가능성이 높습니다. prima.cpp의 주요 기능 낮은 메모리 압력: 모델 가중치를 mmap 방식으로 레이지 로딩하며, OS의 페이지 캐시 관리를 통해 메모리 부담을 최소화합니다. GPU/CPU 동시 활용: VRAM이 부족한 경우 일부 모델 레이어를 시스템 메모리로 오프로드하여 처리할 수 있습니다. 고급 병렬화 구조: piped-ring parallelism을 적용하여 레이어 프리페치와 디스크 I/O 병목을 해소합니다. 이기종…