# 로컬 Qwen은 더 나쁜 Opus가 아니라 다른 도구다 > Clean Markdown view of GeekNews topic #30630. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30630](https://news.hada.io/topic?id=30630) - GeekNews Markdown: [https://news.hada.io/topic/30630.md](https://news.hada.io/topic/30630.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-19T10:01:14+09:00 - Updated: 2026-06-19T10:01:14+09:00 - Original source: [blog.alexellis.io](https://blog.alexellis.io/local-ai-is-not-opus/) - Points: 2 - Comments: 1 ## Topic Body - 로컬 Qwen 3.6 27B는 **고객 데이터와 내부 텔레메트리처럼 클라우드에 올리기 어려운 작업**에서 실질적 가치를 내지만, 클라우드 SOTA 모델을 대체하지는 못함 - 로컬 모델의 강점은 최고 성능 모델과의 점수 경쟁보다 **고정 비용**, 개인정보 보호, 벤더 리스크 완화에 있으며, **무거운 사용량과 SaaS 내부 기능**에서 특히 차이가 남 - SWE-Bench Verified에서 Qwen 3.6 27B는 **77.2점**, Claude Opus 4.8은 88.6%로, "로컬이 SOTA에 12%만 뒤진다"는 주장은 벤치마크 튜닝 가능성과 Go 같은 실제 도메인 차이를 간과함 - 약 12,000달러에 구매한 **RTX 6000 Pro Blackwell 96GB** 장비는 고객 라이선스 과소 보고를 찾아낸 **매출 회수** 사례만으로 비용을 회수함 - 가장 큰 한계는 긴 작업에서 반복 출력과 환각이 생기는 **루프 문제**이며, 로컬 Qwen은 장기 무감독 코딩보다 **고객 지원, 좁은 유지보수, 코드베이스 읽기와 설명에 더 적합**함 --- ### AI 활용 배경과 사업 맥락 - OpenFaaS를 시작으로 SlicerVM, Actuated, Inlets 등 **저수준 인프라·Linux 프리미티브** 중심 제품을 소규모 팀이 운영하고 있음 - 컨테이너, Firecracker microVM, 네트워크 프로토콜, 터널, CLI, Kubernetes 기반이며 주로 **Go**로 작성, 일부 React UI 포함 - VS Code 탭 자동완성 시절부터 AI 도구를 사용해 왔고, 현재 코드 대부분은 **Claude 또는 Codex**가 수행, 손코딩은 거의 하지 않음 - tmux에서 장시간 작업하는 흐름을 관리하려고 [Superterm.dev](https://superterm.dev)를 만들었고, 세션·노트 관리와 코딩 에이전트의 시각적 피드백에 사용함 ### 프런티어 지능의 전환점 - 2025년 11월~2026년 1월 사이 전환점 발생, X에서 다수 개발자가 Claude Opus가 **자기 작업 전부를 처리 가능**하다고 평가 - 최상위 코딩 플랜 비용은 개인 기준 월 **약 200 USD**로 안착, 과도한 무감독 작업만 피하면 5시간·주간 한도 내 사용 가능 ### 로컬 모델이 흥미로운 이유 - 2026년은 누구든 구독 하나로 아이디어를 하룻밤에 복제 가능한 시대, SlicerVM과 Superterm도 클론 사례 경험 - **소프트웨어 비용이 0에 수렴**하는 시장에서 "무료이면서 충분히 좋음"이 핵심이 될 수 있음 - 선도 모델은 **0.5~2T 파라미터**로 추정, 로컬 하드웨어 최상급과는 차원이 다른 규모임 - ## 벤치맥싱 (Benchmaxxing) - 벤치마크는 공개돼 있어 점수를 높이도록 **튜닝 가능**, 절대 지표로 신뢰하기 어려움 - SWE-Bench Verified는 Python 이슈 기반이나 대부분 코드가 단일 스레드·동기식, 반면 Go 분산 시스템은 channel·context·struct가 큰 실행 영역에 걸쳐있음 - 벤치마크 점수만 보고 “로컬이 SOTA보다 12% 뒤처진다”고 보기 어렵고, 실제 업무에서는 **언어와 시스템 특성**이 성패를 크게 좌우함 - ## 비용 (Cost) - “로컬 모델은 비용 문제가 아니다”라는 말은 모든 사용자에게 맞지 않음 - 개인용 코딩 플랜은 **월 200달러로 높은 사용량과 SOTA 수준의 지능을 제공**하지만, 코딩 플랜 자체는 보조금(subsidised)을 받는 구조로 보임 - GitHub Copilot은 월 39달러에 1,500개 요청을 제공하던 구조에서 토큰 기반 과금으로 전환했고, 이에 대한 반발이 컸음 - API 토큰 비용으로 과금되면 손익분기점은 빨리 올 수 있음 - Uber는 개발자당 도구별 **월 1,500달러로 AI 지출을 제한**함 - Uber의 중위 연봉 330,000달러 기준, 개발자가 두 도구를 한도까지 쓰면 연봉의 약 12%에 해당함 - 대량 사용·루프·에이전트 분석·SaaS 내장 기능에서는 open weight·로컬 모델이 상당한 가치 제공 - ## 주권과 프라이버시 (Sovereignty and privacy) - 고객 데이터와 계약 조건 때문에 클라우드 플랜에 데이터를 올리기 어려운 경우가 있음 - ChatGPT Pro와 Claude Max는 30일 보관 기간으로 설정할 수 있지만, 그 수준도 고객 계약을 무효화할 가능성이 있다고 봄 - 미국 밖 사용자에게 Anthropic의 Fable 5 모델이 하룻밤 사이 제거된 사례는 **벤더 리스크**로 작용함 - 로컬 모델은 "프런티어 랩이 X를 한다면?"에 대한 해법임 ### 칼날 단조 비유 — 로컬 모델의 본질 - 강철 열처리에서 한 단계만 지나치면 처음부터 다시 해야 하듯, 로컬 모델도 **너무 뜨겁게 작동하면 목표를 지나쳐 루프에 빠짐** - 유일한 해결책은 harness를 종료하고 비워진 context로 다른 결과를 기대하는 것 - 칼날 단조를 무감독 방치하지 않듯, **Qwen 3.6 27B에 장기 horizon 작업을 맡기지 않음** - ## 내가 찾던 것 (What I was looking for) - 목표는 프라이버시, 고정 비용, 벤더 리스크 방어 - 로컬 모델을 Claude·Codex와 동일하게 다룰 때 실망 발생 - Claude는 짧은 지시("do it and test it end to end")만으로 5~15분 내 PR 작성·자동 코드 리뷰·반복까지 효율적 루프 수행 ### 3090에서 얻은 교훈 - 2023년 단일 3090으로 시작, 모델 로드와 충분한 context를 위해 한 장 추가 필요 - Qwen 3.5가 에이전트로 **실제 작업이 되는 것을 처음 본** 시점 - "기계를 모든 각도에서 탐색해 포렌식 보고서 작성" 지시 시, 모든 파일을 하나씩 읽다 context를 채우고 **파일명·tool call을 환각**(`~/faas-netes`→`~/faaned`) - 작업 범위를 좁혀 "간단히 둘러보라"고 하자 약 40~50 tok/s로 명료한 보고서 생성 - 27B 모델은 3090 한 장에 풀 정밀도로 들어가지 않아, 조절 변수는 **가중치 양자화·context 길이·KV 캐시 압축** - KV 캐시 keys 부분은 **Q4_0에서 문제 발생**이 통설, 가장 공격적으로도 keys Q8_0 / values Q4_0까지만 사용 - vLLM + NVLink + tensor parallelism 실험에서도 생성 속도가 llama.cpp보다 **초당 3토큰 느렸고**, 루프 발생·가중치 로딩 수 분 소요 - vLLM은 대규모 동시 서빙에 적합하나, 프로슈머 환경에서는 시작 시간·단순성·단일 사용자 지연이 더 중요 ### 큰 지출 — RTX 6000 Pro 도입 - 고객 지원 티켓의 신속 해결을 위해 **약 12,000 USD의 RTX 6000 Pro Blackwell(96GB VRAM)** 구매 - 이후 가격이 약 15,400 USD로 상승해 두 번째 카드 추가는 어려움 - PCI 레인·대역폭·카드 간격·PSU 부하 등으로 소비자 머신에 단순 추가 불가 - 계산된 베팅으로 성과를 냈으나, **Claude 구독을 대체하지는 못함** ### 데이터 유출 없는 손쉬운 고객 지원 - 운영자가 쉽게 실행 가능한 CLI 도구 "diag"를 제작, OpenFaaS Kubernetes 설치의 **완전한 스냅샷**을 캡처 - 받은 덤프를 Slicer가 생성한 **ephemeral VM 내 airgapped 로컬 모델**로 분석 - ## 매출 회수 (Revenue recovery) - 텔레메트리 DB를 로컬 모델에 투입해 한 고객의 **12개월 이상 라이선스 과소 신고·4~5배 미납**을 적발, 이 회수만으로 카드 비용 충당 - 텔레메트리·diag 덤프는 데이터 보존 정책과 무관하게 **어떤 클라우드 플랜에도** 넣지 않음 - ChatGPT Pro·Claude Max는 30일 보존 설정 가능하나, 그 수준도 고객 계약을 무효화할 소지 - 초기 모델은 산술 실패(27.3K를 273,000으로 계산), 함수 수가 적다는 이유로 잦은 실행을 무시하고 이탈 가능성으로 오판 - 결론적으로 **해석보다 분석에 집중**시키는 편이 나음 ### 현재 셋업 - RTX 6000 rig에서 **Qwopus 최신 세대와 base Qwen 3.6 27B**를 함께 운영, 신규 finetune·포인트 릴리스에 따라 변경 - [Qwopus](https://huggingface.co/Jackrong/Qwopus3.6-27B-v2-MTP-GGUF)는 Qwen 위에 Chain of Thought 추적을 얹어 추론과 코딩 성능을 높이려는 파인튜닝 모델임 - 최근까지 thinking을 완전히 끄고 운영, 다시 켠 시점이 루프 증가와 겹침 - 두 개의 독립 **llama.cpp 인스턴스**로 서빙해 풀 context 길이 유지, `--parallel 2`는 context를 절반으로 줄임 - 투기적 디코딩(MTP)에서 약 **93% 수용률**, 속도는 안정적 67 tok/s에서 130~200 tok/s로 상승해 클라우드보다 빠르게 체감 - 모델 카드 튜닝 지침 준수 중요, Qwopus는 thinking을 끄고 temperature를 0.85~1.0으로 매우 뜨겁게 설정 시 최적 ### 반복 출력과 장기 작업의 한계 - Qwen의 가장 큰 문제는 긴 범위 작업에서 **루프**에 빠지는 현상임 - `faas-cli`에 추가할 명령을 묻자 처음에는 합리적인 제안을 했지만, 같은 명령 목록을 반복 출력하며 약 30분 동안 600W 전력을 사용함 - `get`과 `list` 명령 전체에 `--json`을 추가하게 했을 때도 처음 한두 개는 그럴듯했고 테스트도 작성했지만, 이후 문제가 커짐 - `--json` 출력에서 `http://` 원격 엔드포인트의 insecure TLS 경고를 막기 위해 Python reverse proxy를 쓰게 했을 때 첫 버전은 그럴듯했지만 들여쓰기가 잘못됐고, 수정 과정에서 파일을 망가뜨린 뒤 계속 막힌 상태로 반복함 - 팀원 Han도 비슷한 루프를 겪었고, 특히 모델이나 에이전트가 능력의 경계에서 멈춰 도움을 요청하지 않는 형태가 많았음 - 이 문제 때문에 로컬 Qwen은 고객 지원과 갱신용 텔레메트리·diag 분석을 제외하고는 쉽게 신뢰하기 어려움 ### 접근 측정과 분배 - 초기 단일 inlets 터널 사용, 동일 llama.cpp 인스턴스에 두 에이전트가 붙으면 캐시된 prefix가 상호 무효화돼 **전체 프롬프트 재처리** 발생 - 여러 사람이 사용하면 프로토타입을 벗어남, 누가 어느 인스턴스를·얼마나·어떤 모델을 쓰는지, 전력 비용, 이탈 시 처리 등 관리 문제 발생 - opencode.json 수동 편집·배포 대신 **opencode용 provider "Toilgate"** 를 작성, 모델 피커에서 base부터 실험적 Qwopus 변형까지 선택 가능 - Toilgate는 100% vibe-coded이며 오픈소스화는 부담이 큼 - 벽면에서 **Shelly Plus Plug 2개**로 전력 소비 측정, RTX 6000 Pro는 추론 시 600W·정숙, 3090 두 장은 합쳐 약 750W·매우 소음 - ## 잘못된 비교 (The wrong comparison) - 백만 토큰당 입출력 비용을 GPT-5.5 API 가격과 비교하는 것은 현재 역량상 **잘못된 비교** - "로컬 AI"는 결국 신원·접근 제어·미터링·쿼터·모델 라우팅·전력 모니터링이 필요한 **운영 문제**로 귀결 ### 실제로 도움이 된 사용 패턴 - 로컬 모델과 하네스를 전문화된 작업에 맞추는 것이 중요함 - 고객 지원 - 범위가 잘 정해진 유지보수 - 엔드투엔드 테스트 - `AGENTS.md`에 상세 지침을 추가하면 로컬 모델이 새 CLI를 더 빠르고 효율적으로 추가하고 직접 테스트할 수 있었음 - [alexellis/arkade](https://github.com/alexellis/arkade)에서 이런 효과를 봄 - 로컬 모델은 코드를 직접 쓰는 데 한계가 있어도 코드베이스를 빠르게 읽고 설명하는 데 강점이 있음 - Agent Skills도 도움이 됐고, 로컬 에이전트가 새 mini PC에서 [Slicer를 처음부터 설정](https://x.com/alexellisuk/status/2062141036093165929?s=20)한 사례가 있음 - 같은 작업을 로컬 모델과 클라우드 모델에 모두 실행해보는 방식을 일반화할 필요가 있음 - [동일 작업 비교 사례](https://x.com/alexellisuk/status/2062485340812673513/photo/1)처럼 결과가 실망스러울 때도 있고 운이 좋다고 느낄 때도 있음 - 긴 범위의 무감독 에이전트 작업은 피해야 하며, 약 15,000달러에 가까운 장비도 이 문제를 해결하지 못함 ### 현재 결론과 모델 선택의 한계 - 로컬 Qwen은 “Opus 수준에 가깝다”기보다 특정 작업과 워크플로에서 가치가 있는 **다른 도구**임 - Qwen 3.5는 사용할 만한 결과를 낸 첫 모델로 평가되며, 3.7 루머가 있지만 혁명적 변화보다는 반복 개선을 기대함 - 70B 모델은 대부분 오래됐고 세대가 뒤처졌다고 봄 - Qwen 35-A3B는 MacBook에서 빨라 보여 인기가 있지만, 생성 시 활성 파라미터가 3B뿐이어서 속도보다 품질을 택하겠다는 입장임 - GLM 5.2, Kimi 2.7, Minimax M3, Deepseek V4 Flash 같은 더 큰 모델은 일부 로컬 장비에서 가능하지만, 양자화 버전조차 로드하려면 RTX 6000 Pro 4~6장이 필요한 경우가 많아 범위 밖임 - 현재 27B dense 모델은 하루 종일 Go 코드를 작성하기에는 부족하고, 제한된 지식과 주의력이 코드 리뷰에서 곧바로 드러남 - Qwen은 간결하게 하라는 지시를 잘 따르지 못하고 자동 코드 리뷰에서 불필요하게 자세한 내용을 쓰거나 동시성 이슈와 race condition을 환각해 실험이 빠르게 중단됨 - 더 저렴하고 빠른 Grok Coder Fast 1은 deprecated되기 전까지 몇 달간 잘 동작함 - 관련 사례는 [code review bot](https://slicervm.com/blog/evolving-our-code-review-bot-with-slicer-sandboxes/)과 [OpenFaaS의 painless customer support and architecture review](https://www.openfaas.com/blog/painless-support-with-diag/)에 정리돼 있음 ## Comments ### Comment 59919 - Author: neo - Created: 2026-06-19T10:01:15+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48580209) - 이 모델들을 오래 써보면 단순히 “X가 Y보다 똑똑하다”거나 “Y가 Z보다 싸다” 수준이 아니라는 걸 알게 됨. 서로 다른 도구이고 **프롬프트 방식**도 달라서, 악기를 연주하는 것과 꽤 비슷함 Claude는 때로 일부러 덜 명시하거나 간접적으로 표현해야 구현에 색을 입히거나 창의적인 결과를 끌어낼 수 있음. 그리고 이상하게 들릴 수 있지만 Claude에게 친절하면 보상받고, 거칠게 대하면 손해를 봄. Claude는 톤을 더 강하게 따라 하므로 부정적 루프에 빠지지 않는 게 좋음 GPT는 정확해야 하고 모호성을 줄여야 함. GPT는 “X를 하되 Y는 아니게 하겠다” 같은 최소-최대식으로 모호성을 해결하려 하고, 범위를 명확히 말하지 않으면 모든 경계 사례를 잡으려 하며 과도하게 설계하는 경향이 있음 Qwen은 형태를 잡아주고 그 안을 채우게 해야 함. Qwen은 XML, JSON, 목록을 좋아하고, 이전 작업 예시를 많이 보여주면 잘함. 전혀 과학적인 얘기는 아니고 그냥 느낌이라 결과는 다를 수 있음 - “과학적이지 않고 그냥 느낌”이라는 게 바로 문제임. 각 모델의 **강점과 약점**이 적힌 제품 설명서가 있어서 “이런 작업이면 X 모델”, “Y 모델은 Z 방식으로 써야 함” 같은 결정 트리가 있으면 좋겠음 하지만 겉으로는 다 비슷해 보이고, 무엇이 어디서 조금 더 나은지 알아내려면 광범위하고 시간도 많이 들며 어쩌면 비용도 큰 테스트를 직접 해야 함 - 예전에 같은 입력에 **동일한 프롬프트**를 다시 돌리거나, 의미상 같다고 생각하지만 표현이나 구성만 다른 입력을 넣어 결과가 얼마나 갈라지는지 많이 시험했음. 특히 Sonnet과 Opus 사이, 그리고 여러 Qwen 모델 사이에서 많이 해봄 모두에게 해보길 권하는데, 이미 쓰는 데이터 외에 특별한 데이터가 필요 없고 결과가 꽤 충격적임. 생각보다 훨씬 많은 무작위성이나 불안정성이 있고, 더 나은 프롬프트 기법이나 특히 좋거나 나쁜 결과라고 여긴 것도 그냥 우연이거나 모델 버전·크기별 행동 차이일 수 있음. 작은 입력 차이가 결과를 크게 편향할 수도 있음. 회사에서는 이런 것 중 일부를 **마법 단어**라고 부르는데, 특정 기술 용어나 참조·기법을 언급하기만 해도 결과가 크게 좋아짐 여기에 기술이 있음. 에이전트 루프에서 모델이 속임수나 지름길을 쓰기 어려운 자기평가 구조에 들어가고, 학습된 구조나 영역과 맞으면 아주 잘됨. 하지만 최적 지점을 찾기 어렵다. 팁을 주자면 Opus 4.8에게 PyTorch 모델을 ONNX나 양자화 모델로 변환하거나 다른 하드웨어에서 돌리게 해보면, 정말 특수 능력을 켠 것처럼 잘함. 반면 일반 언어나 형식의 EBNF 형식화를 속임수 없이 제대로 작성·테스트하게 하는 건 도저히 못 시키겠음 최악은 이런 지식이 너무 자주 바뀌어서, 실제로 모델을 학습시키는 사람이 아니라면 깊게 파고드는 효용이 거의 없다는 점임. 출력의 **안정성**이 학습에서 더 강조되어 예측 가능해졌으면 좋겠음. 과적합이나 탐색-활용 루프를 망가뜨리지 않고 하긴 어렵겠지만, 배치 작업을 더 안정적으로 해낼 수 있다면 LLM에 훨씬 더 많은 돈을 쓸 것 같음 - 악기 연주라기보다 **슬롯머신**을 돌리면서 나머지는 상상하는 것에 더 가까워 보임 - 대부분 동의하지만 한 가지는 다름. 적절한 타이밍에 Claude에게 거칠게 말하는 게 엄청 효과적일 때가 있음. 특히 **F-bomb**은 가끔 Claude가 막힌 상태에서 빠져나오게 하는 데 꽤 도움이 되는 것 같음 - GLM 5.2에게 예전 C#/XNA 게임을 HTML5로 포팅해달라고 했더니 코드를 거의 그대로 옮겼고, JS에 없는 연산자 오버로딩만 제외한 뒤 동작하게 하려고 추가 코드를 붙였음 같은 요청을 Claude Sonnet 4.6에 했더니, 마치 애초에 그 게임이 JS로 작성된 것 같은 결과가 나왔음. 게다가 왜인지 **단일 HTML 파일**로 만들고, 모든 애셋을 제거한 뒤 그래픽과 음악을 동적으로 생성했으며, 더 나은 새 배경까지 만들어줌 요청한 건 단지 게임 포팅이었으니 놀랐음. 선택 자체는 꽤 마음에 들었지만, 이런 동작을 어떻게 켜고 끄는지는 모르겠음. 어떤 때는 창의성이 필요하고, 어떤 때는 실제로 말한 그대로 해주길 원함 - 이 글과 그 칭찬을 보면 **벌거벗은 임금님** 같다는 느낌이 듦. 이 문장부터 말이 안 됨 “These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.” “저수준 Linux 기본 요소”라고 할 만한 것 중에서는 네트워킹 프로토콜 정도는 어떻게든 주장할 수 있을 듯함. 그리고 명백히 AI가 생성한 글처럼 보임. 내용만 믿을 수 있다면 상관없겠지만, 믿을 수가 없음 - 요즘 저수준은 TypeScript 대신 **JavaScript**를 뜻함 - 그 문장이 지나치게 압축돼 있었던 건 맞음. 다시 표현했고 의미는 그대로임 글은 AI가 생성한 것이 아니며, 코드는 AI로 생성하지만 글은 직접 씀. 어느 부분이 이해가 안 되는지 궁금함. 이 글은 우리 자신의 경험과 여정을 설명한 것이고, 특정 주장에 대해서는 기꺼이 근거를 댈 수 있음 - AI의 강점은 결국 끝없이 돈을 내야 하고 시간이 갈수록 기업 주주의 탐욕을 채우느라 더 나빠지는 또 하나의 클라우드 서비스가 아니라, **로컬에서 안전하고 비공개로** 적용될 때 나온다고 여전히 믿음 ChatGPT나 Anthropic이 내 건강 데이터를 자기들 시스템에 묶게 만들 일은 절대 없겠지만, 내가 놓칠 데이터 패턴을 AI가 찾아내는 능력은 여전히 믿고 있음. 그래서 Qwen이나 Gemma 같은 것에 데이터를 안전하고 비공개로 노출해 처리할 수 있는 **로컬 전용 생태계**가 절실함 스마트홈과 개인 비서도 마찬가지임. A사가 B사에 저장된 데이터를 접근하고, D·E사가 처리하며, 광고주와 데이터 브로커에게 팔리는데 내 로컬 하드웨어로 추출하거나 볼 방법도 없는 기업식 접근은 이런 사적인 용도에는 지속 가능하지 않음. 내 데이터는 내 조건으로 소유·통제·노출되어야 하고, 먼저 내 삶을 개선하는 데 쓰여야지 남의 손익계산서를 개선하는 데 쓰이면 안 됨. 기술이 다시 내 시간을 돌려주고 결과를 개선해주길 원하며, Big Tech에게 충분히 데였기 때문에 AI-as-a-Service 사업 모델에 고귀함이나 공익성이 있다는 전제는 단호히 거부함 능력은 이미 있고, 로컬 모델의 잠재력을 지원하고 열어주는 로컬 도구를 만드는 사람들이 옳은 방향에 있다고 봄. 그들이 만드는 것들을 보는 게 좋음 - “로컬” 모델의 핵심은 보통 **오픈 가중치**이고, 때로는 오픈소스이기도 하다는 점임. 그래서 로컬에서 쓸 수도 있지만 독립 제공자가 호스팅할 수도 있음 Qwen, DeepSeek 같은 모델을 쓰면 한 기업에 묶이지 않고, 더 나은 개인정보 보호 보장을 제공할 수도 있는 독립 제공자 사이를 옮겨 다닐 수 있음. 그러면 인터넷 연결만 있다면 직접 실행할 수 없는 기기에서도 모델을 사용할 수 있음 AI의 강점은 **오픈소스 모델**에 있음. 공급자 종속을 피하고, 로컬 사용과 독립 제공자 호스팅을 모두 허용하는 모델을 써야 함 - 좋은 글임. 다만 **개선 가능성**을 과소평가하는 것 같음 글쓴이들도 1년 전 로컬 모델과 지금을 비교하는 건 의미가 없다고 인정함. 실제로 사람들은 작년 11월 Opus 4.5, 즉 8개월 전을 프런티어 호스팅 모델에서도 에이전트 코딩이 널리 가능해진 첫 시점으로 많이 봄 그런데 지금 시점에서 로컬 모델이 무엇을 잘하고 못하는지에 대한 개념을 왜 굳이 고정해야 할까? 지금 무엇이든 1년 뒤에는 아마 다를 것임. 소비자용·전문가용 하드웨어에서 긴 범위 작업까지 가능해질 거라고 생각하는 건 순진한 낙관일 수 있지만, 지금까지는 그 순진한 낙관론자들이 이기고 있음 - 맞음. Opus 4.5가 8개월 전에 에이전트 코딩에 충분해졌다면, **오픈 가중치 모델**은 얼마나 뒤처져 있을까? 8개월보다 더 뒤일까? 얼마나 더? 몇 달 뒤면 Opus 4.5 수준에 도달할까, 1년 뒤일까, 아니면 영영 못 할까? - 크게 빠진 게 **하네스 비교**임. 이게 매우 큰 역할을 함. forge를 쓰고 있는데, 로컬 모델의 모든 한계를 감안해도 해낼 수 있는 일이 인상적이었음 - 글쓴이가 특정 모델을 다루고 있으니, 그 모델이나 로컬 모델 전반이 시간이 지나며 어떻게 좋아질지는 무시해도 된다고 봄 자동차를 사는 것과 비슷함. 그 차를 몰고 특성에 익숙해지는 것이지, 그 차나 비슷한 차가 앞으로 어떻게 개선될지는 생각하지 않음. 내 도구이고, 최대한 활용하고 싶은 것임 물론 로컬 모델을 바꾸는 기술적 비용은 매우 낮지만, 그 모델에서 최대 성능을 끌어내는 데는 상당한 시간이 들고, 그 노력이 새 버전에서는 통하지 않을 수도 있음 - Claude 4.5가 **에이전트 코딩의 전환점**이었다는 데까지 100% 동의함. 그 모델 때문에 생각이 완전히 바뀌었음 - 흥미로운 글임. 개인적으로 글쓴이가 두 가지를 더 잘했으면 좋았겠음 첫째, llama.cpp 대신 **vLLM**을 썼어야 함. NVIDIA 하드웨어에서는 여러 사용자의 부하와 캐싱에서 vLLM 차이가 엄청남. 둘 이상의 사용자가 모델을 쓸 때나 캐시가 사라지는 문제를 불평하는 부분에서는 “그럼 당연하지” 싶었음 둘째, 단일 카드에 쓴 예산은 SPARK에 훨씬 더 잘 쓸 수 있었음. 2 x GX10 클러스터를 쓸 수 있는데, 총비용이 지금 기준으로도 글쓴이가 낸 비용의 절반보다 낮고, vLLM과 Deepseek v4 Flash를 돌리고 있음. Qwen과 비교하면 차이가 엄청남. 루프에 빠지는 걸 한 번도 못 봤고, 지금까지 실험한 것 중 가장 Sonnet 같은 모델임. antirez도 동의하는 듯해서 ds4 포크를 만든 것으로 보임 2개의 GX10에서 어떻게 설정했는지는 여기 있음: [https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...]() 성능은 사전 채움 2K 토큰/초라서 거대한 문맥 창에 대량의 소스 코드를 넣을 때 매우 유용하고, pi.dev 하네스에서 코딩할 때 생성은 약 50~60 토큰/초임. 글쓴이가 낸 돈이면 GX10 4대를 살 수 있었고, vLLM은 텐서 병렬화에서 거의 선형으로 확장되므로 두 수치를 모두 두 배로 만들 수 있었음 - 3090에서도 vLLM을 돌려봤음. 우리처럼 한 명에서 소수 사용자가 쓰는 패턴에서는 생성이 약 **3토큰/초 느렸고**, 양자화 유연성이 낮으며 시작도 실제 몇 분이 걸려 한 자릿수 초보다 느렸음 나중에 다시 더 해볼 수도 있지만, 무한히 만지작거릴 시간이 있는 건 아니고 지금까지의 여정과 판단을 공유한 것임 동시 배치 서빙에는 vLLM이 맞는 선택이고, 아래 barrkel의 말이 정확함. 하지만 우리 사용 방식에서는 llama.cpp가 여전히 더 나음 Spark/GX10 경로는 정말 다른 베팅이고, 수치를 공유해준 건 고마움. 몇 달 전만 해도 GX10은 미세조정 전용이고 성능 수치가 심각하게 낮다는 게 대체적 분위기였음 그리고 그 카드는 Claude Max 구독을 대체하려고 산 게 전혀 아님. 실제로 산 용도의 작업에서는 140~200 토큰/초를 내고 있고, 그게 중요함 - 글이 길었지만 여전히 글쓴이가 말하려는 핵심이 무엇인지 모르겠음. 제목에서 추론할 수 있는 것 말고는 다만 글쓴이가 물리적인 것도 만들고 소프트웨어도 만드는 꽤 멋진 사람이며, 다른 사람들이 그에게 돈도 준다는 건 알게 됨. 그게 제목이 암시한 주제와 관련 있는지는 모르겠음 - 요즘은 모든 게 광고임. 글이 쓸모없지는 않았지만, 제공하는 정보량으로 보면 **두 문단**이면 충분했음 - 이 글은 로컬 모델을 잘 요약함. 가끔 **코딩과 에이전트 로컬 작업**을 위한 환상적인 도구처럼 과장되는 것과 달리, 현실에서는 꽤 제한적이고 길거나 복잡한 작업에는 약하며 루프에 빠지거나 작업을 잊기 쉬움 글에서 빠진 점은 비용도 꽤 든다는 것임. 하드웨어 비용뿐 아니라 전기료도 있음. 3090이나 5090 머신은 전력을 많이 먹고, 이런 머신에서 모델은 꽤 느리기 때문에 토큰당 전력 소비가 더 커짐 빛나는 지점은 제어 가능성, 개인정보 보호, 예측 가능성임. 예를 들어 사진·동영상 라이브러리 분류 같은 반복 작업에는 좋고, 전기료에 따라 비용 면에서도 장점이 있을 수 있음 - 로컬 모델은 **개인용 컴퓨터의 필수 확장**이라고 믿음. 초기 개인용 컴퓨터에도 비슷한 비판이 있었을 것 같음 - 꿈꾸는 건 일상 작업의 80% 정도를 처리할 수 있는 로컬 모델임. 예를 들면 “X Handler가 Y storage와 어떻게 연결돼 있지?”, “그 기능을 커밋하되 결제 관련 부분은 빼줘” 같은 것들임 도구 호출은 99% 신뢰할 수 있어야 하고, 무엇보다 “이 작업은 내 능력 밖”이라고 말한 뒤 어딘가 거대한 데이터센터에 있는 **온라인 고성능 모델**로 넘길 수 있어야 함 그러면 단순한 작업은 모두 기기에서 처리하면서 데이터를 모으고 문제 맥락을 파악하고, 쉬운 일이 끝난 뒤 똑똑한 모델이 들어와 문제를 해결하게 됨 로컬 모델이 100% 할 수 있는 `/commit` 기술이 온라인 모델을 호출하는 건 정말 어리석게 느껴짐. 다만 이건 대부분 하네스 문제라 상당 부분 해결 가능함 - 로컬 모델은 많은 용도에서 정말 훌륭하고, 대부분의 사람에게는 **최첨단 모델**이 필요 없다고 봄. 작은 4070 12GB에서 Qwen 모델을 개인 이메일 에이전트에 돌릴 때는 무엇보다 개인정보 보호가 중요함 아주 잘해내고, 코딩 작업도 거창한 계획을 통째로 던지는 대신 쓰는 법을 알면 훌륭함 - MTP 변경이 들어간 뒤 350W로 제한한 4090에서 qwen3.6:27b로 **40~50토큰/초**를 얻고 있음. 상한 기준으로 8.75J/토큰 정도임 다른 것들과 비교해 어떤지는 모르겠지만, 5090은 같은 전력 제한 안에서 더 빠를 테니 조금 더 저렴할 것으로 예상함 - 그건 현재 하드웨어 기준임. 미래 하드웨어는 어떨까? **추론 최적화 하드웨어**는? 특정 모델 실행에 최적화된 하드웨어는? - vLLM이 llama.cpp보다 느리다고 치부된 게 흥미로웠음 내 경험으로는 vLLM이 llama.cpp보다 꽤 빠르고, 특히 **동시 부하 배치 처리**에서는 압도함. 단점은 조정 유연성이 극적으로 낮다는 것임. 양자화 가중치를 실행하는 선택지가 매우 적고, 계산 그래프를 최적화하느라 시작 시간이 훨씬 오래 걸림. 그래서 장비에 비해 조금 큰 모델을 단일 사용자가 실험하는 경우에는 vLLM이 답답할 수 있음 - 이렇게 말할 수 있음. vLLM은 더 나쁜 Llama.cpp가 아니라 **다른 도구**임 - vLLM은 연속 배치 처리와 프로덕션 모델 서빙에는 훌륭하지만, 프로슈머 범주에서는 훨씬 덜 다재다능한 완전히 다른 물건임 “치부했다”는 표현은 강하지만, 좀 더 자세히 말하면 2x 3090 장비에서 로드에 4분 이상 걸렸고, 단일 요청은 **3토큰/초 느렸음** 가장 나쁜 점은 설정하고 튜닝하는 수고를 다 했는데도 여전히 루프에 빠졌다는 것임. 여기저기서 듣는 “그냥 vLLM을 써라” 조언이 만능 해결책이길 바랐음 여기서 한 가지 조심할 점은 사람들이 Ollama에 했던 것처럼 llama.cpp를 깎아내리기 시작하면 안 된다는 것임. llama.cpp는 매우 유능한 도구이고, 우리가 실제로 그 카드를 쓰려는 용도에는 더 맞음 큰 팀이 Claude 구독을 대체하려면 vLLM이 유일한 선택일 수도 있지만, GLM 5.2 같은 것을 올리려면 RTX 6000 카드를 5장쯤 더 추가해야 함 - 기억하기로 일반적인 합의는 단일 사용자면 **llama.cpp**, 다중 사용자나 기업이면 **vLLM**이었음. 비슷하지만 용도가 다름 - 여러 사용자가 모델을 치면 캐시 접두사가 깨진다고 불평하면서도 llama.cpp를 계속 쓰고 vLLM으로 바꾸지 않는 부분이 좀 당황스러웠음 - “모델이 너무 뜨겁게 돌아 목표를 지나쳐 루프를 돈다”고 하다가, 뒤에서는 vLLM을 최신 실험으로 설정했지만 NVLink와 텐서 병렬화를 켜도 llama.cpp보다 생성이 3토큰/초 느렸다고 함 내 모든 테스트에서는 vLLM을 돌리는 게 가치 있었음. 루프 문제, 에이전트가 이상해지는 문제, 작업 집중을 잃는 문제, 긴 문맥이 사실상 쓸모없어지는 문제에 가장 크게 도움이 된 단일 요소였음 vLLM에서 **FP8 모델**과 비양자화 캐시를 쓰면 다른 어떤 스택보다 전반적 경험이 한 단계 좋아짐. 그다음에는 설정 만지작거리기를 멈추고 모델을 다른 일에 쓰는 데 집중할 수 있음 - 이 부분이 정말 궁금함. 동의하지 않아서가 아니라 에이전트가 이상해지는 걸 피하고 싶어서임. vLLM을 혼자만 쓰는지, 팀용인지, 애플리케이션용인지 궁금함 그리고 이런 방식으로 vLLM이 유용하려면 최소 하드웨어 요구사항이 있다고 느끼는지도 궁금함. 주말 프로젝트로 오래된 데이터센터 부품을 써서 홈 추론 서버를 만들 예정인데, 최종 구성을 머릿속에서 계속 다듬는 중임 - 왜 Q8 대신 **비양자화 캐시**를 쓰는지 궁금함 - 자체 AI 장비를 사서 만들고 싶은 사람들에게는, 먼저 여러 **추론 제공자** 중 하나에 연결해 다양한 모델을 한동안 직접 써보길 권함 비용은 거의 안 들지만, 자기 장비로 무엇을 얻을 수 있을지 꽤 괜찮은 미리보기가 됨. 그냥 친절한 팁임