이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
이 글은 AMD RX 480 8GB와 RX 9070 XT 16GB처럼 비교적 저렴한 GPU에서 open weights LLM을 self-hosting한 경험을 기록합니다. 작은 Gemma 4, gpt-oss, Qwen 모델은 빠르지만 잘못된 도구 호출과 환각, 무한 반복 때문에 중요한 작업을 맡기기 어려웠고, 27B 모델도 긴 인프라 작업에서는 검증과 개입이 필요했습니다. 반면 UD-Q2_K_XL로 양자화한 Qwen 3.8 27B는 RX 9070 XT에서 약 30~50 tok/s를 내고 도구 호출 안정성과 지속성이 개선되어 실제 engineering 작업을 맡길 만한 수준에 가까워졌습니다. 다만 로컬 실행은 하드웨어 비용과 설정 부담을 요구하므로, privacy·비용·data sovereignty를 중시하면서 수동 설정과 검증을 감수할 때 적합하다는 결론입니다.
섹션별 상세
작성자는 외부 API 모델이 갑자기 중단된 일을 계기로 직접 살 수 있는 하드웨어에서 open weights LLM을 실행하기 시작했습니다. 테스트 장비는 10년 된 AMD RX 480 8GB와 약 700~900 EUR인 AMD RX 9070 XT 16GB였으며, ThinkPad P14s gen 4는 메모리 대역폭이 RX 9070 XT보다 약 6배 불리해 실험에서 제외했습니다. Linux의 AMD 환경에서는 최신 ROCm이 RX 480을 지원하지 않아 llama.cpp와 Vulkan backend를 사용했고, 모델 파일·파라미터·토큰·VRAM 같은 기본 요소가 실제 성능을 좌우했습니다.
로컬 모델은 llama.cpp 서버와 OpenCode 또는 Pi 같은 harness를 통해 파일 수정, 웹 검색, 외부 리소스 접근을 수행합니다. 모델과 Context Window가 GPU VRAM에 들어가지 않으면 일부가 system memory로 넘어가 속도가 크게 떨어지므로, 작성자는 타협 끝에 128K context를 선택하고 RX 9070 XT에서 긴 세션 중 발생한 메모리 부족을 막기 위해 llama-server에 --cache-ram 0을 설정했습니다. 또한 작은 모델이 작업 파일을 삭제할 수 있어 sandbox와 백업이 필요했고, harness의 plan mode도 엄격한 안전장치가 아니라는 점이 드러났습니다.
Gemma 4와 gpt-oss는 Tool Calling이 불안정했고, unsloth의 Qwen 4B와 9B 모델은 빠르지만 긴 세션에서 지속성과 판단력이 부족했습니다. 더 큰 27B 모델은 9B보다 나았지만 잘못된 도구 호출, Ansible 인프라 변경의 미묘한 오류, ansible-vault에 SSH public key를 암호화해야 한다는 잘못된 주장, 같은 도구를 반복하는 무한 루프가 이어졌습니다. RX 480과 RX 9070 XT의 처리 속도 차이는 상황에 따라 10~20배였지만, 16GB VRAM의 RX 9070 XT도 LLM 전용 구매 대상으로는 메모리가 제한적이라는 평가입니다.
게임용 PC의 GPU를 LLM 실행과 게임에 번갈아 쓰는 방식은 비용을 줄이는 현실적인 선택으로 작동했습니다. Bazzite와 SteamOS에서는 Podman 컨테이너와 systemd quadlet로 llama.cpp를 관리하고, 게임을 시작할 때 단축키나 SSH 명령으로 모델을 중지해 VRAM을 해제할 수 있습니다. llama.cpp의 자동 unload 기능은 유휴 시 모델을 내리지만 첫 요청이 느려지고 게임 중 요청이 들어오면 GPU 사용을 방해할 수 있어, 작성자는 상시 agent보다 필요할 때 직접 조종하고 검토하는 사용 방식을 선호했습니다.
Qwen 3.8 27B는 UD-Q2_K_XL 양자화와 RX 9070 XT 16GB 조합에서도 이전 모델보다 안정적인 Tool Calling과 긴 작업에서의 지속성을 보였습니다. 작성자는 medium reasoning level을 사용했으며, 한 번 minor detail을 파고드는 조사 루프를 중단한 것을 제외하면 큰 문제를 거의 겪지 않았고, llama.cpp Vulkan backend에서 출력 생성 속도는 약 30~50 tok/s, prompt processing은 약 1100~500 tok/s였습니다. 네 명이 참여한 사내 비교에서는 공시 재무보고서 요약과 red flag 탐색 결과에서 Pi와 Qwen 3.8 27B Q2 조합이 Claude Code와 Opus 5보다 선호됐으며, 규칙·skills·결정적 도구·스크립트·테스트를 갖추자 결과가 더 좋아졌습니다.
작성자는 open weights 모델이 짧은 기간에 실제 작업에 접근할 정도로 발전했지만, Claude Code와 Opus 계열처럼 모호한 목표를 받아 실행하고 결과까지 검증하는 수준에는 아직 차이가 있다고 평가합니다. 로컬 실행은 privacy, 비용, data sovereignty 문제를 줄이는 대신 GPU를 먼저 구매하고 환경을 직접 구성해야 하며, 더 많은 VRAM과 비용을 투입하면 결과가 개선될 여지가 있습니다. 최소 128GB의 빠른 메모리를 갖춘 하드웨어는 에스토니아의 senior product engineer 월급보다 비싸 당장은 보류한 상태입니다.
용어 해설
- 양자화(Quantization)
- — 양자화는 모델 가중치의 표현 정밀도를 낮춰 파일 크기와 메모리 사용량을 줄이는 기법입니다. 이 글에서는 UD-Q4_K_XL과 UD-Q2_K_XL 같은 양자화 버전을 사용해 제한된 VRAM에서 더 큰 Qwen 모델을 실행하지만, 모델 정확도와 응답 품질이 일부 낮아질 수 있다는 절충이 핵심으로 나타납니다.
- Mixture of Experts
- — Mixture of Experts는 하나의 거대한 모델 안에 여러 전문가 모듈을 두고, 각 입력을 처리할 때 일부 전문가만 활성화하는 구조입니다. 전체 파라미터 수는 크더라도 실제 계산에 참여하는 부분을 줄일 수 있어, 모델 규모와 실행 비용 사이의 균형을 맞추는 데 사용됩니다.
- Context Window
- — Context Window는 모델이 한 번에 입력과 이전 대화, 도구 실행 결과를 유지할 수 있는 토큰 범위입니다. 범위가 커지면 긴 agentic 세션과 많은 파일을 처리할 수 있지만 메모리 사용량도 늘어나므로, 글에서는 llama.cpp와 OpenCode 양쪽에서 128K로 맞추고 GPU VRAM에 들어오는지 확인합니다.
- Tool Calling
- — Tool Calling은 모델이 파일 읽기·수정, 웹 검색 같은 외부 기능을 호출하도록 요청을 생성하는 방식입니다. 글의 로컬 모델 실험에서는 잘못된 도구 호출과 반복 호출이 자주 발생했으며, 결정적 도구와 테스트를 갖춘 harness가 모델의 실행 범위를 제한하는 장치로 작동합니다.
- Vulkan Backend
- — Vulkan Backend는 GPU에서 llama.cpp 추론을 실행하는 그래픽·컴퓨트 API 기반 backend입니다. AMD RX 480이 최신 ROCm 지원 대상에서 제외되어 작성자는 Linux에서 Vulkan 기반 실행 경로를 사용했고, RX 9070 XT에서는 Qwen 3.8 27B가 약 30~50 tok/s로 생성됐습니다.
기술
- AMD RX 480 8GB
- AMD RX 9070 XT 16GB
- llama.cpp
- Vulkan
- OpenCode
- Pi
- Podman
- Bazzite
- SteamOS
- Hugging Face
- unsloth
- Qwen 3.8 27B
- Gemma 4
- gpt-oss
- Claude Code
활용 사례
- 로컬 coding agent 실행
- 인프라 저장소 점검
- Hugo 설정 수정
- rsync 백업 스크립트 작성
- 공시 재무보고서 요약과 red flag 탐색
- 게임과 LLM 실행을 병행하는 GPU 활용
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 02.수집 2026. 09. 02.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
