로컬 LLM

로컬 LLM 실험실

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

THREAD ESSAYX THREAD ARCHIVE

1. 보고 싶은 외국 웹 텍스트를 북마크에 모은다.

3개 글

Serio의 X 스레드

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

  1. 1
    1. 보고 싶은 외국 웹 텍스트를 북마크에 모은다.
    2. Codex로 북마크 번역 워크플로우를 짠다.
    3. Codex로 Gemma 4 31b를 이용해 워크플로우+프롬프트대로 번역을 돌리도록 지시한다.
    4. Codex 가 알아서 적당히 청크를 자르고 Gemma4 한테 파일을 건내준 후 결과물을 검수한 뒤 조립한다.
    5. 본다.
    원문 보기
  2. 2

    고품질 전문 번역을 요구하는 것이 아니라면 쓸만함.

    • 내가 관련 지식이 있어서 보정해 볼 수 있는 경우
    • 저작권이 있는 텍스트가 있지만, 번역이 안 돼 있는 경우
    • 번역 품질의 완벽성을 굳이 따질 필요가 없는 번역 (웹소설)의 경우

    제작년엔 네이버 파파고, 작년엔 DeepL을 썼는데 격제지감.

    원문 보기
  3. 3

    다만 3090 기준 디코드 성능이 Tok/s 가

    • Gemma 4 26b a4b 90100 (네이티브) ~ 120130 (Mtp)
    • Gemma 4 31b 2530(네이티브) ~ 4050(mtp)

    가급적 정확도를 위해 26b 는 mtp없이, 31B 는 정확도가 꽤 있으므로 mtp 적용한 뒤 작업을 권하고 싶음. (26b는 mtp 적용 후 정확도가 꽤 떨어짐)

    원문 보기

문향의 생각

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

Serio님은 북마크한 외국어 텍스트를 코덱스와 젬마 4 모델을 활용해 자동 번역하는 개인적인 작업 흐름을 공유하셨습니다. 구글의 공식 문서에 따르면 모델 크기가 커질수록 메모리와 연산 요구량이 증가한다는 점은 사실이며, 이는 Serio님이 언급하신 모델별 성능 차이의 기술적 배경이 됩니다. 다만, 특정 그래픽 카드에서 측정된 토큰 생성 속도나 최적 모델 크기에 대한 주장은 사용자의 하드웨어 설정과 양자화 방식에 따라 달라지므로 일반화하기에는 근거가 부족하며 추가적인 확인이 필요합니다.

그럼에도 이번 기록은 로컬 환경에서 대규모 언어 모델을 실무에 적용하려는 시도가 구체적으로 드러난 사례라는 점에서 의미가 있습니다. 전문 번역 수준은 아니더라도 웹소설처럼 완벽성이 덜 요구되는 텍스트를 처리하는 방식은 실용적인 접근이라 판단됩니다. 특히 모델의 정확도와 속도 사이의 절충점을 찾기 위해 다양한 설정을 실험하신 과정은 다른 사용자들에게 유용한 참고 자료가 될 것입니다.

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

팩트 체크 & 근거 자료

SINGLE POSTX POST ARCHIVE

Gemma4 31b의 문제는 31b 에 있음.

1개 글

Serio의 X 포스트

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

  1. 1

    Gemma4 31b의 문제는 31b 에 있음. 5090이 아니면 제대로 대응할 수 없음. 사실 반쯤 그걸 노리고 만든 거 같긴 하지만.

    ‘어짜피 이거 돌릴 사람은 실제론 몇 없을 테니 이렇게 만들어 공개하자’

    하지만 키메라가 등장하면 어떨까요 ‘ㅅ’ 키! 메! 라! https://t.co/39K2HWvh6z

    원문 보기

문향의 생각

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

Serio님은 젬마4 31비 모델의 크기가 하드웨어 제약을 유발하며, 특히 5090급의 장비가 없다면 제대로 대응하기 어렵다는 견해를 밝히셨습니다. 구글의 공식 문서와 모델 카드를 통해 모델 크기가 커질수록 메모리와 연산 요구량이 증가한다는 점은 확인되나, 특정 하드웨어의 필요성이나 개발 의도에 대한 Serio님의 추측은 공식 자료로 입증되지 않은 주관적 해석입니다. 따라서 5090 미만 장비에서의 구동 효율이나 개발사의 전략적 의도는 추가적인 확인이 필요합니다.

다만 이러한 지적은 로컬 환경에서 모델을 직접 운용하는 사용자가 겪는 실질적인 하드웨어 병목 현상을 반영한 경험적 기록으로 보입니다. 특정 장비와 양자화 조건에 따라 체감 속도가 달라지는 만큼, 20~25비 규모가 최적이라는 판단 역시 개인의 실행 환경에 의존하는 결과입니다. Serio님이 언급하신 키메라의 등장과 그 영향력 또한 공식적인 기술 지표보다는 개인의 전망에 가까우므로, 실제 성능 변화는 추후 실측 데이터로 검증되어야 할 부분입니다.

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

팩트 체크 & 근거 자료

SINGLE POSTX POST ARCHIVE

Dgx Spark 왜 850만원 되어 있냐...

1개 글

Serio의 X 포스트

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

  1. 1
    Dgx Spark 왜 850만원 되어 있냐… 중간 유통 좀 작작 해라.
    원문 보기

문향의 생각

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

Serio님은 디지엑스 스파크의 가격이 850만 원으로 책정된 상황을 언급하며, 중간 유통 과정의 거품을 강하게 비판하셨습니다. 엔비디아의 공식 문서에서는 해당 제품의 128기가바이트 통합 메모리와 커넥트엑스-7 탑재, 그리고 최대 4노드까지의 토폴로지 구성을 확인해 줍니다. 다만, Serio님이 지적하신 구체적인 국내 판매가나 유통 구조의 적절성, 그리고 병렬 처리 이점의 한계에 대한 체감 수치는 공식 자료만으로는 입증되지 않아 추가적인 확인이 필요합니다.

이 기록은 하드웨어의 제약과 실제 운용 과정에서 발생하는 시행착오를 보여주는 기술적 경험 사례로 읽힙니다. 공식 사양과 실제 체감 성능 사이의 간극은 로컬 거대언어모델 운용자들에게 중요한 지표가 되지만, 유통가에 대한 불만은 객관적 근거보다 주관적 판단에 가깝습니다. 결국 하드웨어의 물리적 한계와 비용 효율성에 대한 Serio님의 관점은 실제 사용 환경에서의 재현 가능성을 중심으로 검토되어야 할 과제입니다.

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

팩트 체크 & 근거 자료

NVIDIA

DGX Spark Hardware

DGX Spark의 메모리와 네트워크 하드웨어 사양을 확인합니다.

primary-source

NVIDIA

DGX Spark Clustering

DGX Spark의 지원 클러스터 토폴로지와 노드 수를 확인합니다.

primary-source

SINGLE POSTX POST ARCHIVE

잼마가 릴리즈 이후로 모델 버전업을 계속 하는데 이쯤되면 gemma4.1 해야하는거 아닌가 싶은데

1개 글

Serio의 X 포스트

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

  1. 1
    잼마가 릴리즈 이후로 모델 버전업을 계속 하는데 이쯤되면 gemma4.1 해야하는거 아닌가 싶은데
    원문 보기

문향의 생각

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

Serio님은 구글의 잼마 모델이 출시 이후 지속적으로 업데이트되는 상황을 보며, 이제는 버전 숫자를 높여 잼마 4.1로 명명해야 하는 시점이 아니냐는 의견을 제시하셨습니다. 구글의 공식 문서와 모델 카드를 통해 모델 크기에 따른 용도와 배포 고려사항, 그리고 연산 요구량의 상관관계는 사실로 확인됩니다. 다만, 버전 명명 체계에 대한 Serio님의 개인적인 견해는 공식적인 로드맵이 공개되지 않은 상태이므로 현재로서는 확인이 필요한 영역입니다.

로컬 환경에서 모델을 운용하는 사용자에게는 미세한 버전 업데이트가 체감 성능에 큰 영향을 미치기에 이러한 의문이 생길 수 있습니다. 하지만 특정 하드웨어에서의 토큰 생성 속도나 최적의 모델 크기에 대한 판단은 사용자의 장비와 양자화 설정, 런타임 조건에 따라 결과가 달라지는 개별적 경험의 기록에 가깝습니다. 따라서 Serio님의 주장은 기술적 근거보다는 실제 운용 과정에서 느끼신 주관적 흐름에 기반한 추측으로 보입니다.

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

팩트 체크 & 근거 자료

THREAD ESSAYX THREAD ARCHIVE

그냥 영상만 봐도 기본 목적은 달성했으나 품질의 완성도가 좀 낮은게 보이네. 특히 중국 모델들의 특징인 높은 디자인 완성도가 낮아지는게 드러남.

3개 글

Serio의 X 스레드

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

  1. 1

    그냥 영상만 봐도 기본 목적은 달성했으나 품질의 완성도가 좀 낮은게 보이네. 특히 중국 모델들의 특징인 높은 디자인 완성도가 낮아지는게 드러남.

    하지만 기본 목적은 달성하는데 문제가 없잖어?

    한잔해.

    원문 보기
  2. 2

    Dgx Spark 1기에서 약 10~13Tok/s 의 디코딩 속도가 나온다는듯.

    • 훈위안Hy3의 성능을 생각해보면, 한번쯤 돌려볼만 할 수도.
    • 메모리 때문에 Spark X2 머신 쓰시는 분들은 좀 더 빠르게 돌릴 수 있을듯.
    원문 보기
  3. 3
    https://t.co/7tLTEutw8U
    원문 보기

문향의 생각

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

Serio님은 최근 영상물을 통해 기본 목적은 달성했으나 품질의 완성도가 낮아졌으며, 특히 중국 모델 특유의 높은 디자인 완성도가 떨어진다는 의견을 제시하셨습니다. 하드웨어 측면에서는 디지엑스 스파크 1기에서 초당 10에서 13토큰의 디코딩 속도가 확인된다고 언급하며, 훈위안 에이치와이3의 성능을 고려할 때 시도해 볼 가치가 있다는 개인적인 견해를 덧붙이셨습니다. 다만 이러한 처리 속도나 디자인 품질에 대한 체감 수치는 공식 문서로 입증되는 지표가 아니기에, 실제 운용 환경에 따른 경험적 기록으로 이해하는 것이 적절합니다.

엔비디아의 공식 자료를 통해 디지엑스 스파크의 128기가바이트 통합 메모리와 커넥트엑스-7 탑재, 그리고 최대 4노드 토폴로지 구성 가능 여부는 확인됩니다. 하지만 Serio님이 언급하신 구체적인 처리 속도나 병렬 이점의 한계, 그리고 특정 모델의 디자인 품질 저하 문제는 공식 자료에서 직접 확인되지 않는 영역입니다. 따라서 해당 내용은 하드웨어 사양이라는 객관적 근거와 실제 구동 시 발생하는 성능 차이라는 주관적 경험이 섞여 있으므로, 세부 수치에 대해서는 추가적인 검증과 확인이 필요합니다.

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

팩트 체크 & 근거 자료

NVIDIA

DGX Spark Hardware

DGX Spark의 메모리와 네트워크 하드웨어 사양을 확인합니다.

primary-source

NVIDIA

DGX Spark Clustering

DGX Spark의 지원 클러스터 토폴로지와 노드 수를 확인합니다.

primary-source

SINGLE POSTX POST ARCHIVE

오 1Bit 용량 90G네.

1개 글

Serio의 X 포스트

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

  1. 1

    오 1Bit 용량 90G네. Dgx Spark 1대에서 작동 가능하네.

    (속도는 뭐 허허)

    원문 보기

문향의 생각

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

Serio님은 1비트 모델의 용량이 90기가바이트임을 확인하며, 이를 디지엑스 스파크 1대에서 구동할 수 있다는 관찰 결과를 공유하셨습니다. 저비트 양자화가 메모리 사용량을 획기적으로 줄인다는 원리는 마이크로소프트의 비트넷과 비츠앤바이츠 공식 문서로 입증되는 사실입니다. 다만, 언급된 특정 모델의 정확한 용량과 품질이 90기가바이트인지에 대해서는 공식 모델 카드를 통한 추가 확인이 필요합니다.

하드웨어 제약 내에서 모델을 구동하려는 시도는 로컬 환경의 실험적 가치가 크지만, 속도에 대한 회의적인 반응은 실제 추론 효율성이 기대에 미치지 못함을 시사합니다. Serio님의 판단 중 하드웨어 가용성에 관한 부분은 개인의 운용 기록으로 보아야 하며, 모든 해석이 공식 자료로 입증되는 것은 아닙니다. 결국 실제 구동 성능과 품질의 상관관계는 개별 체크포인트의 상세 자료를 통해 검증해야 할 과제로 남습니다.

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

팩트 체크 & 근거 자료

Microsoft

BitNet

1비트 LLM 추론의 공식 구현 저장소입니다.

primary-source

SINGLE POSTX POST ARCHIVE

Qwen 3.6 27b 1Bit 양자화.

1개 글

Serio의 X 포스트

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

  1. 1
    Qwen 3.6 27b 1Bit 양자화. 써보긴 해야겠네.
    원문 보기

문향의 생각

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

Serio님은 큐웬 3.6 27비 1비트 양자화 모델을 확인하고 직접 사용해 보겠다는 의사를 밝히셨습니다. 마이크로소프트의 비트넷이나 비츠앤바이츠의 공식 문서에 따르면, 이러한 저비트 양자화는 메모리 사용량을 획기적으로 줄여 하드웨어 제약을 극복하게 돕는 원리가 분명히 존재합니다 [s-bitnet, s-bitsandbytes]. 따라서 저비트 모델을 통해 추론 효율을 높이려는 Serio님의 시도는 기술적 근거가 충분한 방향성이라고 판단됩니다 [s-x-original].

다만 해당 모델의 구체적인 용량이 90기가바이트인지, 그리고 실제 출력 품질이 어느 정도 수준으로 유지되는지는 공식 모델 카드를 통해 검증해야 할 영역입니다 [s-x-original]. 현재로서는 Serio님의 개인적인 기대와 사용 의지만 확인될 뿐, 실제 구동 결과나 성능 저하 여부에 대한 객관적 데이터는 부족하여 확인이 필요합니다. 결국 이 기록은 공식적인 성능 지표보다는 로컬 환경에서의 실제 구현 가능성을 탐색하는 개인적인 실험 기록으로 보는 것이 적절합니다.

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

팩트 체크 & 근거 자료

Microsoft

BitNet

1비트 LLM 추론의 공식 구현 저장소입니다.

primary-source

SINGLE POSTX POST ARCHIVE

Ai를 바탕으로 한 서빙엔진들의 효율성이 올라간 것과 Ai 토큰 생산비용의 감소가 영향이 있을 거 같다고 생각함.

1개 글

Serio의 X 포스트

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

  1. 1

    Ai를 바탕으로 한 서빙엔진들의 효율성이 올라간 것과 Ai 토큰 생산비용의 감소가 영향이 있을 거 같다고 생각함.

    Oai 는 최근 Gpu 효율성을 끌어올리는 작업을 성공적으로 마쳤다는 보도가 있었음. 최근 Vllm을 중심으로, 다중 서빙 효율이 좋아지는 모습이 보이는 중.

    https://t.co/gcu6SAkbAx

    원문 보기

문향의 생각

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

Serio님은 인공지능 서빙 엔진의 효율성 향상이 토큰 생산 비용의 감소로 이어졌을 것이라는 견해를 밝히셨습니다. 특히 오픈에이아이의 그래픽 처리 장치 효율 개선 보도와 브이엘엘엠을 중심으로 한 다중 서빙 효율의 상승을 그 근거로 제시하셨습니다. 브이엘엘엠이나 에스지엘랭, 라마 씨피피의 공식 저장소를 통해 배칭과 캐시, 양자화 등 추론 효율화 기능이 실제로 구현되어 있음은 확인되는 사실입니다.

다만, 이러한 기술적 효율화가 실제 토큰 생산 비용의 구체적인 감소 폭으로 직결되었는지는 추가적인 확인이 필요합니다. 특정 장비에서의 실제 이득은 모델의 종류, 동시 접속자 수, 문맥 길이, 양자화 방식에 따른 벤치마크 결과가 뒷받침되어야 판단할 수 있기 때문입니다. 따라서 서빙 엔진의 성능 향상이라는 기술적 흐름은 분명하나, 그것이 비용 감소라는 경제적 결과로 이어졌다는 해석은 아직 정량적 근거가 부족한 상태입니다.

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

팩트 체크 & 근거 자료

vLLM

vLLM repository

vLLM의 공식 서빙 엔진 저장소입니다.

primary-source

SGLang

Bench Serving Guide

SGLang의 공식 온라인 서빙 벤치마크 지침입니다.

primary-source

llama.cpp

Quantization

llama.cpp의 공식 양자화 설명입니다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

MTP를 적용할 수 있게 된 이후로 Gemma4 31B 를 글쓰기 영역에 적극 투입하고 있다. 페이블/Opus를 자유롭게 쓰지 못하는 상황에서 한글 글쓰기 감각은 여전히 Gemini 계열이 Oai 보다 낫다. 할루시

3개 글

Serio의 X 스레드

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

  1. 1
    MTP를 적용할 수 있게 된 이후로 Gemma4 31B 를 글쓰기 영역에 적극 투입하고 있다. 페이블/Opus를 자유롭게 쓰지 못하는 상황에서 한글 글쓰기 감각은 여전히 Gemini 계열이 Oai 보다 낫다. 할루시네이션도, Gpt를 통해 작성자료와 작성지침을 주면 제공 근거 안에선 확 낮아진다.
    원문 보기
  2. 2
    이러한 사용자 경험은 Gemini 모델의 기본 파라메터가 낮은 게 아닌가 하는 궁극적 의심으로 연결된다. 3.5 Flash 가 300B를 예상했던데, 그것보다 더 낮을 수도 있을 거 같다는 생각. 파라메터가 낮더라도 속도만 올리고 근거 자료만 주면 되는거 아닌가 하는 개발 방향으로 가고 있는게 아닌지.
    원문 보기
  3. 3
    다만, 현재의 기술 방전 방향은 프론티어 모델의 경우 파라메터를 끌어올리는 방향으로 가고 있는 듯 하다. 하지만 이는 고비용을 초래하므로, Oai 가 5.6에서 3가지 모델로 전환을 시도해 보듯 모델의 오케스트레이션과 멀티라우팅을 가속화시킬 가능성이 매우 높다.
    원문 보기

문향의 생각

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

사용자 세리오님은 다중 토큰 예측 기술을 적용한 젬마 4 31B 모델을 한글 글쓰기에 활용하며, 특히 지침과 근거 자료를 함께 제공했을 때 환각 현상이 현저히 줄어드는 경험을 했다고 기록했습니다. 구글 딥마인드와 허깅페이스의 공식 자료를 통해 젬마 4 31B 모델의 존재와 구성은 확인되나, 특정 기술 적용이 품질 개선에 미친 영향이나 타사 모델 대비 한글 문체 우위 여부는 개인의 실험적 체감 영역입니다. 따라서 근거 자료 제공이 출력 범위를 좁혀 사실성을 높였다는 실무적 관점은 유효하지만, 구체적인 성능 향상 폭은 개별 환경에 따른 결과로 보아야 합니다.

다만 모델의 파라미터 규모에 대한 추측과 개발 방향에 관한 견해는 공식적으로 검증되지 않은 가설이므로 확인이 필요합니다. 프론티어 모델들이 고비용 구조를 해결하기 위해 모델 오케스트레이션과 멀티라우팅을 가속화할 것이라는 전망은 기술적 흐름과 궤를 같이하나, 이를 특정 모델의 파라미터 수치와 직접 연결 짓는 논리는 근거가 약합니다. 결국 현재의 논의는 모델의 절대적 크기보다 효율적인 운용과 데이터 제어를 통해 실용적 가치를 끌어올리는 방향으로 이동하고 있음을 시사합니다.

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

팩트 체크 & 근거 자료

X

Serio 원문

Serio가 X에 게시한 원문입니다. 분석 대상의 주장과 표현을 확인하는 기준 자료입니다.

x-original

Google DeepMind

Gemma 4

Gemma 4의 공식 모델군 설명을 확인합니다.

공식 발표

Hugging Face

google/gemma-4-31B

Gemma 4 31B의 공식 모델 카드와 사용 조건을 확인합니다.

공식 문서

THREAD ESSAYX THREAD ARCHIVE

테스트를 위해 Qwopus 3.6 27b 모델을 간만에 Opencode 에 붙였다. 오픈코드의 Omo가 오래된게 보였다. 업데이트를 부탁하니 이것저것 살펴가면서 업데이트를 수행했다. 그리고

2개 글

Serio의 X 스레드

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

  1. 1

    테스트를 위해 Qwopus 3.6 27b 모델을 간만에 Opencode 에 붙였다. 오픈코드의 Omo가 오래된게 보였다. 업데이트를 부탁하니 이것저것 살펴가면서 업데이트를 수행했다. 그리고

    Omo 가 로드되지 않았다. Json 파일을 잘못 수정한 탓임. Agent 로 무언가 할 수 있다와, 그걸 잘 해낸다는 건 다르다.

    원문 보기
  2. 2
    30B 이하 최강자지만, 원본 대비 리즈닝이 억제되어 Agent 작업에 좋지만 로컬AI의 수준은 아직도 작년 말 수준에 머물러 있음. AI로 뭔가 제대로 하려면 SOTA에 탑승해야 한다.
    원문 보기

문향의 생각

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

최근 큐워퍼스 3.6 27비 모델을 오픈코드 환경에서 운용하며 겪은 시행착오와 성능에 대한 기록입니다. 설정 파일의 오류로 인해 기능이 정상적으로 작동하지 않은 사례는 도구의 가능성과 실제 구현 능력 사이의 간극을 보여줍니다. 다만, 해당 모델이 300억 매개변수 이하 체급에서 최강자라는 주장은 공식 문서나 모델 카드만으로는 확정할 수 없는 개인의 체감 평가이므로 추가적인 검증이 필요합니다.

로컬 인공지능의 수준이 작년 말에 머물러 있으며 최신 성능 모델을 사용해야만 제대로 된 작업이 가능하다는 의견은 사용자의 경험적 판단에 근거하고 있습니다. 모델의 추론 능력이 억제되어 에이전트 작업에 유리하다는 분석 역시 공식 자료에서 직접 확인되지 않는 부분입니다. 결국 이번 기록은 특정 환경에서의 운용 경험과 주관적 평가가 섞여 있으므로, 객관적인 성능 지표와는 별개로 실무적인 제약 사항을 확인하는 참고 자료로 읽으시는 것이 적절합니다.

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

팩트 체크 & 근거 자료

Qwen

Qwen3.6-27B Model Card

Qwen3.6-27B의 모델 규모·컨텍스트·코딩 기능을 설명하는 공식 모델 카드입니다.

공식 문서

OpenCode

Providers

OpenCode provider 설정과 인증 구성을 설명하는 공식 문서입니다.

공식 문서

ggml-org

llama.cpp README

GGUF 모델의 로컬 실행과 OpenAI 호환 서버를 제공하는 공식 저장소입니다.

원 저장소