Jamesob의 최신 수준 LLM 로컬 실행 가이드

 (github.com/jamesob)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 로컬에서 최신 수준 LLM과 음성-텍스트 변환을 돌리기 위한 하드웨어 구성, PCIe 스위치 설정, Docker 실행 구성을 한 저장소에 정리함
  • 약 $2k 예산은 2× RTX 3090으로 48GB VRAM을 확보해 Qwen3.6-27B와 whisper-large-v3 기반 로컬 STT를 실행하는 구성을 목표로 함
  • 약 $40k 예산은 4× RTX PRO 6000 Blackwell Workstation으로 384GB VRAM을 확보해 Claude Opus에 꽤 가까운 모델 지능을 얻는 구성을 전제로 함
  • 실제 4× RTX 6000 Pro 시스템은 중고 EPYC/DDR4 기반 본체와 c-payne PCIe Gen4 스위치를 조합해 GPU 간 P2P 통신을 CPU 루트 컴플렉스 대신 스위치 패브릭 안에서 처리함
  • BIOS, GRUB, ACS, 전력 제한 설정까지 맞춘 결과 P2P는 27.5GB/s 단방향, 50.4GB/s 양방향, 0.37–0.45µs 지연으로 Gen4 라인레이트에 도달함

로컬 LLM 실행을 위한 예산 구간

  • 이 구성은 로컬에서 최신 수준의 모델과 음성-텍스트 변환을 실행하려는 사용자를 대상으로 함
  • 저장소에는 사용 중인 하드웨어, 구입 이유, 설정 팁, 로컬 STT 실행 방식, Docker 컨테이너 기반 모델 실행 구성이 포함됨
  • README의 표를 제외한 내용은 AI가 작성하지 않았다는 주석이 있음

  • 약 $2k 구성

    • 2× RTX 3090으로 총 48GB VRAM을 확보하는 구성을 제안함
    • 이 구성에서 Qwen3.6-27B를 실행할 수 있음
    • 로컬 STT는 whisper-large-v3를 사용하며, 접근용으로 크로스플랫폼 stt 하네스를 사용함
    • ./runners/stt에는 Nvidia GPU에서 약 11GB VRAM만 있다고 가정하는 실행 준비된 STT 설정이 있음
    • 로컬 STT는 호스팅 서비스보다 편하게 사용할 수 있는 도구로 다뤄짐

  • 약 $40k 구성

    • 4× RTX 6000 Pro로 총 384GB VRAM을 확보하는 구성을 전제로 함
    • 이 가격대에서는 Claude Opus에 꽤 가까운 수준의 모델 지능을 얻는 단계로 표현됨
    • 2026-07 기준 4× RTX6kPRO용 현재 최선 모델로 GLM-5.2-Int8Mix-NVFP4-REAP-594B가 제시됨
    • 실행 구성은 runners/GLM-5.2-594B에 있음
    • 다른 접근으로는 4× DGX Spark 클러스터를 연결해 512GB VRAM을 확보하고, 느린 큰 브레인으로 Qwen3.7-27B가 반복 작업을 빠르게 처리하게 하는 방식도 언급됨

실제 4× RTX 6000 Pro 하드웨어

  • 실제 시스템은 4× RTX PRO 6000 Blackwell Workstation을 중심으로 구성됨
  • GPU는 각 96GB, 총 384GB VRAM이며 가격은 약 $46,000임
  • 본체는 이전 세대 EPYC와 eBay DDR4 부품을 활용해 기본 시스템 비용을 낮추고 VRAM에 비용을 집중함
  • 2026년 7월 기준 PCIe5/DDR5 기반 시스템이 매우 비싸기 때문에 PCIe Gen4 스위치와 DDR4 기반 본체를 선택함

  • 기본 시스템 BOM

    • 기본 시스템은 대부분 eBay에서 구한 이전 세대 EPYC 부품으로 구성됨
    • 주요 부품과 가격은 다음과 같음
    • ASRock Rack ROMED8-2T 메인보드: $715
    • AMD EPYC Milan 7313P 16코어 3.0GHz CPU: $504
    • 8× 16GB Crucial DDR4 ECC RDIMM, 총 128GB RAM: $642
    • 2× Super Flower 1700W PSU: $750
    • c-payne Microchip Switchtec PM40100 Gen4 PCIe 스위치: 약 $1,330
    • 4TB 부팅 NVMe: $291
    • 2× 8TB 모델 가중치용 NVMe: $1,200
    • 기본 시스템 합계는 $5,587임

  • PCIe Gen4 스위치

    • c-payne의 PCIe4 스위치를 사용해 GPU 간 통신을 거의 직접 처리함
    • 텐서 병렬화의 allreduce 단계에서 GPU 간 데이터가 PCI 루트 컴플렉스를 거치지 않고 스위치 패브릭 안에서 이동함
    • 스위치 서브 BOM은 약 €1,220, 약 $1,330 USD임
    • Microchip Switchtec PM40100 기반 PCIe Gen4 5× x16 스위치
    • SlimSAS PCIe Gen4 Host Adapter x16
    • SlimSAS SFF-8654 8i 케이블 2개
    • GPU와 PCI 스위치용 나무 인클로저를 직접 제작했으며 약 하루가 걸림
    • PCI 스위치 내장 팬은 매우 시끄럽고 쓸모없어 보여 보드에서 분리함

모델 가중치 저장과 실행 방식

  • 모든 모델 가중치는 두 개의 8TB 드라이브에 복제된 ZFS 파일시스템에 로컬 저장됨
  • 파일시스템은 ~/storage에 마운트됨
  • 실행할 모델은 먼저 다음 명령으로 로컬에 다운로드함
hf download <model-name> --local-dir ~/storage/<model-name>
  • 각 모델은 별도 디렉터리에 docker-compose.yml을 두고 자체 Docker 컨테이너 안에서 실행됨
  • 실행 구성은 ./runners/에 있음
  • 각 컨테이너는 캐시된 가중치를 읽기 위해 ~/storage/models를 읽기 전용으로 마운트함
  • 모델이 http://clank.j.co:5000에서 서빙되면 다른 머신의 VM에서 호스팅되는 opencode로 접근함
  • 내부 DNS 서버로 clank.j.co를 LLM 머신에 매핑하지만, http://<llm-machine-ip>:5000 형태도 가능함

에이전트 하네스와 도구 구성

  • 별도 VM 안에서 ~/src 트리의 각 디렉터리마다 tmux 세션을 만들고, 각 세션에서 opencode 인스턴스를 실행하는 애플리케이션을 사용함
  • 각 opencode 인스턴스는 추론 머신의 HTTP API인 http://clank.j.co:5000을 백엔드로 사용함
  • 오픈소스 모델을 잘 쓰기 위한 핵심은 도구 구성으로 다뤄짐
  • skills/ 요약에는 다음 도구가 포함됨
    • camofox, kagi.com API 키, searXNG를 통한 웹 브라우징과 검색
    • Telegram 봇을 통한 커뮤니케이션과 알림
    • 소스 코드 협업용 로컬 비공개 Gitea 인스턴스
  • 에이전트는 세션에서 대화형으로 함께 작업하거나, Gitea 이슈를 처리하고 PR을 올리는 방식으로 맡길 수 있음
  • 이 작업은 샌드박스 VM 안에서 실행되며, 호스트와의 통신은 공유 파일시스템 마운트로만 이뤄짐

PCIe 스위치와 멀티 GPU 설정

  • BIOS 설정

    • ROMED8-2T 메인보드에서 PCI 스위치 속도가 내려가지 않도록 BIOS 설정을 조정함
    • AMD PCIE Link Width는 스위치 슬롯에 대해 x16으로 설정함
    • 기존 x8/x8 분기 설정은 슬롯을 나눠 upstream 링크가 Gen4 x8로 훈련되게 함
    • SlimSAS 8i 케이블 2개가 모두 연결되어야 하며, 각 케이블은 x8을 담당함
    • PCIe Link Speed는 Gen4로 강제함
    • Blackwell Gen5 장치가 Gen4 스위치를 통해 자동 협상할 때 훈련에 실패하고 Gen1로 떨어질 수 있음
    • ASPM은 Disabled로 설정함
    • ASPM L1은 유휴 링크를 2.5GT/s로 낮춤
    • lspci에서 Gen1으로 다운그레이드된 것처럼 보이는 원인이었지만, 부하 중에는 Gen4로 동작함
    • Re-Size BAR는 Enabled로 설정함
    • 전체 96GB VRAM BAR 노출과 GPU P2P에 필요함
    • SR-IOV는 Disabled로 설정함
    • 베어메탈 추론 환경에서 IOMMU 오버헤드와 P2P 간섭을 피하기 위한 설정임
    • Preferred IO는 Auto로 둠
    • 수동으로 c-payne 스위치 버스 81을 지정하면 약간의 지연 개선 여지가 있지만, 수정이 아니라 최적화이며 BIOS 변경 후 버스 번호가 바뀔 수 있음

  • Redriver와 케이블

    • c-payne 조언에 따라 c-payne tool로 redriver gain을 lvl 3으로 낮춤
    • gain 수준은 SAS 커넥터 케이블 길이에 따라 달라짐
    • c-payne에서 케이블을 너무 적게 주문해 Amazon에서 비슷해 보이는 SAS 케이블을 샀지만, 약간의 차이로 문제가 생겨 다시 주문함

커널, ACS, 전력 제한

  • GRUB와 NVIDIA UVM

    • /etc/default/grub에 다음 커널 파라미터를 설정함
    GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
    • iommu=off가 없으면 멀티 GPU P2P에서 NCCL이 멈춤
    • NVIDIA UVM P2P 수정을 위해 다음 설정을 적용함
    echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u

  • ACS 비활성화

    • ACS가 기본값으로 활성화되어 있으면 P2P 트래픽이 스위치 패브릭 안에 머물지 않고 CPU 루트 포트를 거침
    • 이 상태에서는 PCIe 스위치의 효과가 사라짐
    • pcie_acs_override에는 패치된 커널이 필요하므로 런타임에 setpci로 ACS를 비활성화함
    • 부팅 때마다 systemd oneshot 서비스로 /usr/local/bin/disable-acs.sh를 실행함
    • 검증 방법은 다음과 같음
    • lspci -vvv | grep ACSCtl에서 모두 minus sign으로 표시되어야 함
    • nvidia-smi topo -m에서 네 GPU 사이가 PIX로 보여야 하며 PHB/NODE가 아니어야 함
    • ./tools/measure-gpu-speed.sh로 P2P 대역폭과 지연을 쉽게 측정할 수 있음

  • GPU 전력 제한

    • 220V 회로 설치를 피하기 위해 단일 110V 회로에서 실행하되 GPU 전력을 제한함
    • systemd로 부팅 시 persistence mode와 전력 제한을 적용함
    sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
    • GPU 전력 제한은 GPU당 350W이며 기본값은 600W임
    • 4×350W는 GPU 부하 1,400W로 PSU 예산에 맞춘 값임
    • 240V 회로 전의 단일 1700W PSU 단계에서는 GPU를 약 260W로 운용함
    • 4×260W = 1,040W GPU
    • 시스템 약 280W를 더해 총 약 1,320W임
    • 검증은 nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv로 함

측정 결과와 참고 자료

  • CPU 방향 upstream은 Gen4 x16이며 약 30GB/s임
  • 스위치를 통한 P2P는 27.5GB/s 단방향, 50.4GB/s 양방향임
  • 지연은 0.37–0.45µs로 Gen4 라인레이트 수준임
  • ASPM이 어딘가에서 활성화되어 있으면 lspci가 유휴 상태의 downstream GPU 링크를 2.5GT/s (downgraded)로 표시할 수 있음
  • 이 표시는 cosmetic이며, 링크는 부하가 걸리면 Gen4로 재훈련됨

  • Resources

    • local-inference-lab/rtx6kpro: 4, 6, 8장 RTX 6000 Pro 카드 활용을 자주 업데이트하는 저장소
    • c-payne: 이 구성에서 사용하는 인디 PCI 스위치
    • RTX6kPRO Discord: RTX6kPRO 벤치마크와 새 모델 테스트를 다루는 Discord 서버

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 로컬 LLM을 많이 써봤고 하드웨어에도 과하게 돈을 썼는데, 기대치를 낮추고 세부 조건을 잘 읽어야 함
    기사 속 대형 빌드는 예산이 4만 달러로 시작하지만, 1장에 1.2만 달러인 GPU 4장을 포함하므로 실제로는 5만~5.5만 달러에 가까움
    로컬 구성은 모델을 하드웨어에 맞추려고 양자화나 REAP 같은 기법에 자주 의존함. 4비트 양자화가 무손실이라는 주장도 많지만, 작은 말뭉치에서의 KL 발산 측정에서 나온 말이고, 긴 문맥 코딩 작업에 쓰면 품질 저하가 뚜렷함. 데이터셋 분석 같은 비코딩 작업에서도 4비트, 8비트 양자화, 때로는 16비트 원본 사이의 품질 차이를 꽤 측정할 수 있음
    이 글은 REAP 모델 사용도 권하는데, 이는 누군가 모델을 작게 만들려고 일부 가중치를 잘라냈다는 뜻임. 특정 작업에 덜 유용한 가중치를 제거한다는 발상이지만 전체 출력 품질은 다시 낮아짐
    함정은 사람들이 “GLM-5.2를 로컬에서 돌린다”고 말하면 벤치마크를 보고 대단해 보이지만, 실제로는 GLM-5.2가 아니라 대부분의 비트를 버리고 일부 전문가를 제거한 파생 모델을 돌리는 것임. 아주 작은 작업이나 채팅에서는 양자화/REAP 모델과 원본의 차이가 잘 안 보이지만, 작은 오류가 누적되는 장기 작업에서는 차이가 고통스러워짐
    그러다 이미 5만 달러를 썼으니, 품질을 조금 더 올리고 투자 가치를 만들려면 1.2만 달러짜리 GPU를 한두 장만 더 사면 된다는 식의 미끄러운 경사에 빠지게 됨

    • RTX4090에서 Qwen3.6을 돌리는데 대부분의 경우 아주 잘 작동함
      코딩 작업은 여러 호출로 세션을 나눠야 함. https://github.com/aka-rider/orqestra를 만들었지만, 요즘 도구 실행 환경이라면 거의 어디서든 직접 비슷하게 할 수 있음
      핵심은 코드를 읽고 도구를 호출하느라 문맥을 태우는 세션을 따로 두고, “관련 코드와 문서가 여기 있고 근거는 이것”이라는 마크다운 보고서를 만들어 환각을 줄이는 것임. 계획 세션은 별도로 두고, 작은 모델이 세부를 건너뛰므로 비평가와 설계자를 1~3회 왕복시키고, 작업자와 검증자도 같은 이유로 왕복시킴
      Qwen3.6은 읽기 전용 모드에서 복잡한 버그를 몇 시간씩 찾을 수 있고 대개 찾아냄. 제안하는 수정은 아마 해키하겠지만 Sonnet도 마찬가지임
      Qwen3.6은 Opus가 만든 계획에 따라 기계적으로 코드를 쓸 수 있음. 이후에는 “네 변경을 직접 검토해라. 버그가 있나? 원래 계획과 교차검증해 빠진 게 있나? CLAUDE.md 위반이 있나?”처럼 프롬프트해야 함. 그런데 이것도 Sonnet에 똑같이 해야 함
      로컬 LLM은 지식 베이스 재색인에도 씀. 티켓 정리에서는 “오류 렌더링용 단일 패널, 모든 오류 메시지 이동” 같은 원시 메모만 남겨도 목표와 문맥이 붙은 90%쯤 완성된 명세로 돌아올 수 있음
    • 내 컴퓨터에서 8비트 양자화, 비-MoE, 26B Qwen을 로컬로 돌렸을 때도 비슷했음
      작은 작업에는 정말 좋지만, 처음 큰 작업을 시켰을 때 에이전트 실행 환경이 무엇인지 까먹고 도구 호출 형식을 틀리게 쓰기 시작했음. Pi에서 돌고 있었는데 스스로 Claude에서 돌고 있다고 믿고 존재하지 않는 Claude 도구를 호출하려 했음
    • RAM 가격이 미치기 전에 산 MBP에서 ds4를 돌리는데 꽤 유용함
      혼자서 전체 애플리케이션을 작성하진 않지만, 직접 파악할 시간도 의욕도 없던 tailnet의 귀찮은 네트워크 문제를 해결해 줬고, 간단하지만 조사 비용이 커서 안 했을 작업에도 자주 손이 감. Opus는 아니지만 유용하고, 구독료나 API 비용 대비 가치를 뽑고 있는지 걱정하지 않아도 됨
    • “로컬에서 실행”한다는 글과 댓글도 비교를 위해 같은 공개 벤치마크를 다시 돌린 결과를 함께 냈으면 좋겠음
    • 완전히 맞는 말임. 코딩 LLM을 로컬에서 돌리려는 열풍은, 목적에 맞게 만든 소형 언어 모델이 실제로 유익할 수 있는 로컬 AI에 오히려 해가 됐음
      자연어 처리, 음성 합성, 이미지 처리, 오디오 엔지니어링, 신호 처리, Krita용 확산 플러그인 같은 작은 도구들은 로컬 구성에 아주 좋음. 며칠 전에 짧게 쓴 글도 있음[1]
      [1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...

  • “약 4만 달러면 모델 지능이 한 단계 올라가서 Claude Opus에 꽤 가까운 수준”이라는 건, 월 200달러 기준 Claude Opus 4.8이나 Codex GPT 5.5를 16.8년 쓰는 비용과 같음
    로컬 모델 실행을 정말 좋아하지만, 여전히 터무니없이 비싸고 품질은 낮으며, 백도어가 있으면 위험할 수도 있음. 진심으로 그렇지 않았으면 좋겠음

    • 월 200달러는 전체 API 가격을 내야 하는 경우, 예컨대 “엔터프라이즈” 회사라면 이미 월 4,000달러에 더 가까움. 그러면 동등 비용은 10개월로 줄어듦
      다만 로컬 장비가 실제로 월 4,000달러어치 API 사용량과 동등하게 처리할 수 있을지는 의심스러움. 로컬 장비는 Anthropic의 여러 데이터센터만큼 프롬프트를 병렬로 효율적으로 돌리기 어렵기 때문임
    • 요지에는 동의하지만, 이 계산은 LLM 가격이 계속 일정하다는 가정을 둠
      OpenAI와 Anthropic 같은 회사들은 아직 벤처자본의 힘으로 보조된 가격에 요금제를 팔고 있고, 그 자본은 언젠가 수익을 원할 것임
    • 선도 모델들이 백도어되어 있다는 건 말이 안 됨. 백도어된 모델을 하나도 들어본 적이 없고, 발견되면 Hugging Face에서 빠르게 제거될 것임. 이건 문제가 아님
    • 하드웨어에서는 월 200달러 요금제보다 훨씬 많은 토큰을 쓸 수 있음
      OEM spark로 첫 달에 10억 토큰을 썼는데, Opus 기준으로는 1,000달러가 넘는 양임. 토큰 패턴이 다르니 공정한 비교는 아니지만, 그 뒤 vLLM 개선, 주로 MTP 덕분에 속도도 2~3배 향상됐음. DiffusionGemma는 일반 Gemma보다 약 4배 빠름
    • 로컬에서 돌리려 하지 말고 클라우드 GPU를 빌리면 됨
      광회선도 소유하지 않는데, 왜 빠르게 감가상각되고 비싸고 귀찮은 자산을 또 소유하려 하나 싶음
      클라우드 GPU를 빌리면 거대한 취미용 프랑켄슈타인 박스를 만들지 않아도 소유 문화, 데이터 통제, 가격 통제, 해킹 문화에 참여할 수 있음. 그 박스는 비싸고, 증류되어 실질적으로 쓸모가 줄고, 유지보수도 골칫거리임

  • “4만 달러면 거의 Opus”라고 하지만, GLM 5.2가 “거의 Opus”라면 쾌적한 추론에는 최소 8xH200이 필요해서 4만 달러보다 40만 달러에 가까움
    글에서는 수정된 모델을 쓰라고 제안함: “REAP으로 가지치기되어 전문가 약 22%가 제거되고, Int8-mix NVFP4로 양자화된 GLM-5.2, 약 594B 매개변수”
    벤치마크 밖에서 실제로 어떻게 동작할지 궁금함. Qwen3.6도 6비트 양자화에서 추론 중 루프에 빠지는 일이 잦은데, 여기서는 전문가까지 일부 제거했음. 때로는 8비트나 16비트의 작은 모델이 뇌 절제된 대형 모델보다 더 똑똑할 수 있음. 코딩에는 8비트 아래로 내려가지 않는 게 좋다는 합의가 있는 듯함
    또 뇌 절제된 모델을 RTX 6000 4장에 맞춰 넣을 때 사용 가능한 문맥이 얼마나 남는지도 불분명함. 100k 미만은 필요한 문맥을 모으기 전에 압축에 걸리는 일이 많아 거의 쓰기 어려움. 저장소에서 확인하니 문맥은 240k였음

    • GLM 5.2를 H200 한 장으로만 돌리면 어떻게 되는지 궁금함
      아예 실행이 안 되는지, 아니면 너무 느려서 못 쓸 정도인지 알고 싶음. 로컬에서 최신급 모델의 빌드와 개념을 검증한 뒤, 18~24개월 후 GPU 가격이 크게 내려가면 나머지를 채우고 싶음
    • 이게 확장성과는 어떻게 맞물리는지 궁금함
      그러면 프롬프트 수백 개를 동시에 돌릴 수 있는 건가 싶음
    • 루프는 LLM 관련 현상 대부분처럼 샘플링 문제이고, DRY 패널티로 쉽게 해결할 수 있음
      llamacpp에 들어 있음. heretic을 만든 사람이 최신 수준의 루프 방지와 다양화 전략도 만들었음
    • 8x RTX6000에서 lukealonso NVFP4 양자화를 쓰면 1M 문맥도 가능하고, 최소 400k까지는 일관성과 유용성이 유지됨
      그냥 그러고 싶어서가 아니라면 8x H200을 돌릴 실질적 필요는 없음. 정기적으로 동시 사용자나 에이전트를 많이 서비스해야 한다면 예외임

  • 중간 선택지도 있음. 128GB VRAM을 확보하면, 통합 메모리 구조로 그 정도 용량을 얻을 수 있는 선택지가 이제 여러 개 있고, DwarfStar를 통해 DeepSeek V4 flash를 좋은 속도로 돌릴 수 있음
    돈을 쓰진 않겠지만, 많은 사람에게는 이 정도가 적절한 타협점일 것 같음

    • m4 max 128에서 막 써보기 시작했는데, 1년 전 이 기계를 산 뒤 처음으로 로컬 LLM이 꽤 괜찮은 코딩에 그냥 작동한다는 느낌이 듦
      다만 Pi를 써야 함. claude code는 부트스트랩 문맥이 너무 많아서 모든 게 훨씬 느려짐

  • “RTX 3090 2장으로 총 48GB VRAM을 갖추면 Qwen3.6-27B를 돌릴 수 있고, 훌륭한 모델”이라고 하지만, 3천 달러면 공유 메모리 48GB인 M5 MacBook Pro를 살 수 있고 거대한 박스도 아님
    또는 그 돈을 클라우드 호스팅 업체에 쓰는 것도 고려할 만함. 적어도 어느 정도, 어쩌면 훨씬 더 저렴할 수 있음. 물론 모델을 로컬에서 돌릴 수 있다는 건 멋진 일임

    • 겪어보지 못한 상황을 상상하지 못하는 바보라서, 로컬 LLM은 추구할 가치가 없는 장난감이라고 늘 생각했음
      그런데 Gemma 4 31B와 Qwen 3.6 27B처럼 괜찮은 걸 한 번 써보고 나서야 얼마나 유용한지 깨달음
      민감한 정보를 공유하고 있다는 걱정을 멈추게 되고, 토큰이 바닥날까 걱정하지 않게 되며, 원격 AI의 가용성도 걱정하지 않게 됨. 로컬 LLM은 매우 가치 있음
    • 3090의 멋진 점은 메모리 대역폭임. 토큰 생성은 대부분 메모리 대역폭이 병목임
      3090 두 장은 총 1.87 TB/s, 장당 0.936 TB/s의 메모리 대역폭을 갖지만, M5 MacBook Pro는 0.3 TB/s뿐임. Max 칩은 최대 0.63 TB/s지만 그 구성은 1만 달러짜리 기계임
      그래서 Qwen 27B는 3090 두 장에서는 실제 작업에 충분히 빠르게 돌아가지만 MacBook Pro에서는 고통스럽게 느림. 또 MacBook Pro에서 큰 모델을 돌리면 UI가 버벅이고 키보드가 뜨거워짐. 지하실에 3090 두 장을 두고 MacBook에서 접속하는 편이 훨씬 나음
    • M5 MacBook Pro도 있고 모델 실행용 별도 GPU 구성도 있는데, 속도 차이가 큼
      토큰 생성 속도만이 아니라 첫 토큰까지 걸리는 시간, 즉 프롬프트 처리 시간이 다름. M5 하드웨어는 그 자체로는 훌륭하지만 GPU가 여전히 훨씬 빠름
      모델을 GPU 박스에서 돌리면 노트북을 뜨거운 접시로 만들지 않고 무릎 위에서 쓸 수 있다는 장점도 있음
    • Qwen3.6-27B를 24GB GPU 한 장에서 80토큰/초로 돌리고 있어서, 두 장까지 필요하지도 않음
    • 합리적인 선택이긴 하지만, M5 Pro는 메모리 대역폭이 약 1/3이고 M5 Max도 약 2/3라는 점은 알아야 함. M5 Max 최저 구성도 4,100달러임
      따라서 FLOPS에 묶이는 프리필도, 대역폭에 묶이는 디코드도 둘 다 느릴 것임

  • 이번 주에 로컬 LLM을 막 구축했으니 내 경험도 보탬. Intel의 Arc B70이라는 32GB 카드를 골랐는데, 3090보다 싸고 RAM은 더 많지만 메모리 버스는 더 느림
    이걸 고른 이유는 쓰고 싶은 모델들이 24GB에 편하게 들어가기엔 조금 크고, 자동완성과 음성 인식용 작은 모델 몇 개를 더 올릴 공간도 필요했기 때문임. 또 이미 저렴한 서버가 있었고, 듀얼 GPU를 쓰려면 메인보드와 전원공급장치, 아마 케이스까지 바꿔야 했음
    설정은 꽤 까다로웠음. Intel 라인은 SYCL, 대략 Intel판 CUDA 같은 것을 지원하려면 “level zero”라는 드라이버 패키지가 필요했고, 이걸 제대로 동작시키기 어려웠음. llama.cpp를 Docker 컨테이너에서 돌리는데, 컨테이너가 카드를 보게 하는 데도 손이 좀 갔음. 최근 몇 달 안의 커널도 필요함
    일단 작동하고 나니 1천 달러 투자치고 결과가 매우 인상적임. Qwen 3.6 35B를 q4 양자화로 돌리면 RAM의 약 3/4을 쓰고 88토큰/초 정도가 나옴. 저렴하게 적당한 크기의 모델을 원한다면 한 방법임

    • 그건 틀렸음. 둘 다 GDDR6임
      B70은 256비트 버스에 2375MHz, 608 GB/s이고, 3090은 384비트 버스에 2438MHz, 936 GB/s임. 더 느린 게 아니라 채널이 적어서, 즉 폭이 더 좁은 것임

  • qwen3.6-27b는 q4 변형을 3090 한 장에서 전체 약 250K 문맥으로도 돌릴 수 있음
    답답하지 않을 만큼 충분히 빠르기 때문에 3090 두 장으로 얻는 속도 향상은 내게 가치가 없음. 두 장에서 q6를 절반 속도와 더 작은 문맥으로 돌리는 선택지도 있지만, 어차피 최신급 모델과 경쟁하진 못하므로 이미 3090 두 장이 있는 게 아니라면 현재 가격에서는 한 장이 최선의 투자라고 봄. 잘 구성된 실행 환경이 있으면 많은 일을 하기엔 충분함

    • 3090 한 장에서 qwen3.6-27b를 돌릴 때 KV 캐시도 q4로 두는 건가?
      내 경험상 그 정밀도에서는 긴 문맥 회상 정확도가 크게 떨어짐. KV 캐시는 q8로 두고 120k 문맥으로 작업하는 편이 더 좋았음
    • 250k 문맥, Q4 모델, 24GB VRAM이라는 계산은 K/V 캐시까지 q4 양자화일 때만 맞고, 그건 아마 좋은 생각이 아님

  • 관련해서, 지금 쓸 수 있는 최고의 격리 시스템은 무엇인지 궁금함. 완전한 두꺼운 VM까지 가야 하는지, Firecracker 비슷한 것으로 충분한지 모르겠음
    가능한 선택지마다 발을 날려버리기 쉬운 미묘한 함정이 있고, 사실상 보안이 전혀 없는 상태가 되기 쉬워 보임. VM은 보안이 이 기술의 기본 원칙이라고 실제로 신뢰할 수 있어서 쓰는 것이지, “이 20개 플래그를 쓰고 눈을 가늘게 뜨면 괜찮다” 같은 방식이 아님

    • MacOS에는 내장 seatbelt 샌드박스가 있음. Linux에서는 SELinux나 비슷한 유틸리티를 네임스페이스 위에 얹은 Docker를 쓸 수 있음
      먼저 공격 벡터를 모델링해야 함. rm -rf는 쓰기 제한으로 막고, curl malware.sh | sh는 쓰기 가능한 디렉터리에서 실행을 제한하면 됨(seatbelt/SELinux). 민감한 디렉터리에 대한 쓰기 제한만으로도 대부분의 악성코드는 상당히 무력화될 가능성이 큼
      자격 증명 유출은 환경 변수를 정리하고, .ssh, .aws 등 읽기를 금지하며, LLM을 운영 시스템 근처에 두지 않으면 됨
      MacOS용 작은 유틸리티 https://github.com/aka-rider/leash를 만들었지만, bash 스크립트로도 가능함
    • 무엇을 위한 것인지에 따라 다름. 보안 모델이 에이전트가 PC를 날려버리지 않게 샌드박스로 가두는 것이라면 선택지는 많음
      가벼운 것을 원하면 bubblewrap[1] 같은 것을 쓰거나 libkrun[2] 같은 microVM을 쓸 수 있고, 관련 도구까지 원하면 완전한 Docker까지 갈 수 있음
      [1] https://github.com/containers/bubblewrap
      [2] https://github.com/libkrun/libkrun
    • 모두에게 맞는 즉시 사용 가능한 구성은 없을 것 같음. 어떤 보안 경계든 각 강화 계층은 사용성 절충을 동반하기 때문임
      모든 게 단단히 잠겼다는 걸 어떻게 실제로 아느냐는 불확실성에는 공감함
      개인적으로는 VM이나 microVM이 맞는 길이라고 봄. 컨테이너와 달리 이들은 실제 보안 경계로 설계된 것들임. bubblewrap과 비교해도 에이전트에게 전체 파일시스템을 주고 YOLO 모드로 돌릴 수 있는 반면, bubblewrap은 각 개발 도구의 가용성을 일일이 부트스트랩하고 설정 디렉터리와 패키지 캐시 등을 안전하게 마운트해야 하며, 그래도 권한 오류를 계속 만날 가능성이 큼. 격리도 훨씬 약함
      실행 환경 지원은 제한적이지만, 호스트에서 실행 환경 프로세스를 돌리고 모든 도구 호출과 파일시스템 상호작용은 VM에 위임하는 방식이 꽤 타당하다고 봄. 그러면 세션 데이터와 인증 키를 메인 머신에 유지해 문맥 안으로 절대 들어가지 않게 할 수 있음. 대신 실행 환경 자체가 보안 경계의 일부가 되므로 그게 절충점임
      VM 안팎으로 데이터를 어떻게 옮길지도 사용성 문제가 됨. 로컬 git 저장소를 VM으로 밀어 넣고 원격처럼 다시 가져오는 스크립트를 쓰고 있는데, 그러면 VM이 호스트로 연결을 시작할 수 없고 git 자격 증명도 가질 필요가 없음. 하지만 에이전트가 GitHub에 바로 push하길 원하는 사람에게는 과한 노력일 수 있음
      VM 자체로 시도했거나 본 선택지는 qemu + libvirt, crun-vm, libkrun 계열임. qemu + libvirt는 맞추는 데 손이 가지만 매우 검증됐고 설정 가능성이 큼. crun-vm은 podman과 qemu 사이의 고수준 통합 계층 PoC인데, 버려진 것 같지만 기존 도구와 표준 중심이라 흥미로움. libkrun은 더 새로운 진입자이고 microsandbox, smolvm, krunvm 같은 래퍼가 있음. 모두 Linux 기준임
    • GPU 패스스루를 붙인 두꺼운 VM은 CPU만 쓰는 VM보다 훨씬 덜 신뢰함

  • 이렇게까지 애써서 LLM을 쓰는 게 이상하게 느껴짐. 특히 이런 식으로 최첨단을 좇는 건 더 그렇음
    Claude 같은 것들이 내일 사라져도 눈 하나 깜짝하지 않을 것임
    사람들이 왜 자기 뇌 주름을 슬롭 기계 접근권과 맞바꾸는지 이해가 안 됨. 좋은 비유라면, 숙련 목수에게 Ikea보다 한두 단계 낮은 품질의 가구를 배출하는 기계를 주는 것과 비슷할까 싶음. 일을 해내긴 하나? 대부분은 그렇다. 목수가 그 과정을 즐기나? 아니다

  • 내 경험상 q4처럼 심하게 양자화되었거나 어느 정도 변형된 모델을 돌려 보고 “와, 정말 대단하다”고 느낀 적은 없음. 오히려 몇 번 프롬프트를 넣고 나면 휴지통으로 갔음
    96GB짜리 RTX 6000 PRO가 있는데, 편하게 돌릴 수 있는 건 Qwen 3.6 27B나 MoE, Gemma 4 31B 정도임. 모델을 전체 정밀도와 최대 문맥 길이로 돌릴 때는 여기까지가 한계임
    이들은 성능이 좋고 코딩, 인터넷 조사 등 여러 용도에 쓸 수 있음. 계산해 봤을 때 Anthropic에 연 2,400달러보다 더 쓸 것 같다면 이런 카드를 사는 게 말이 될 수 있지만, 품질 저하는 받아들여야 함. 어차피 5년 뒤에도 인간이 코딩을 하고 있을지도 의문임

답변달기