로컬 Qwen이 왜 최고 수준의 클라우드 모델을 대체하지는 못하지만, 프라이버시, 고정 비용, 고객 지원, 특정 워크플로에서는 여전히 실질적인 가치를 제공하는지에 대한 현업 경험담.
우리는 모두 로컬 Qwen 27B나 35-A3B가 "거의 Opus 수준"이라는 말을 들어봤지만, 나는 소프트웨어 비즈니스와 오픈 소스 프로젝트에서 나온 증거를 갖고 있고, 여러분에게 투명하게 이야기하려고 한다.
이 글이 긴 형식인 데에는 이유가 있다. 이것은 피상적으로 훑어본 글도 아니고, Claude Max를 해지했다는 X의 근거 없는 주장도 아니며, 32K 컨텍스트 창에서 초당 한 자릿수 토큰으로 돌아가는 모델에 대한 취미 사용자 보고서도 아니다. 비행기 안에서 코딩 이야기를 트윗하는 유명 CEO가 쓴 글도 아니다.
이것은 작은 소프트웨어 회사의 창업자로서 내가 걸어온 여정이다. 로컬 모델은 실제로, 단서가 붙는 가치이긴 하지만, 분명한 가치를 만들어냈다. 나는 이해관계가 걸려 있지만, 클라우드 모델이든 로컬 모델이든 어느 한쪽을 밀어야 할 유인은 없고, 로컬 모델이 더 유능하고 신뢰할 만해지기를 강하게 바라고 있다.
나는 이 카드가 첫 두세 달 안에 어떻게 제값을 했는지, 우리 특수한 비즈니스 사용 사례에서 어떻게 계속 역할을 하고 있는지, 왜 여전히 감독 없이 믿을 수 없는지, 그리고 Qwen의 최악의 특성인 무한 루프와 환각 위험에 대해 다룰 것이다. 이런 문제는 특히 소비자용 GPU에 맞추기 위해 양자화를 많이 했을 때 가장 자주 나타난다.
RTX 6000 Pro의 전원 커넥터를 맞춰보는 중
AI에 대한 내 사용 사례
유지관리자이자 창업자로서의 내 여정은 OpenFaaS에서 시작됐다. 이 프로젝트는 완전히 손으로 만들어졌고, 2016년부터 최근까지의 모든 소프트웨어가 그랬듯 직접 구축됐다. 이는 프로젝트의 핵심을 내가 직접 깔아놓고, 이후 커뮤니티를 통해 다른 사람들을 참여시키는 것을 뜻했다. 내가 혼자 할 수 없어서가 아니라, 내 목표가 성공적인 오픈 소스 프로젝트를 만드는 것이었기 때문이다. 2017년 무렵에는 내 시간을 마련하기 위해 VMware에 합류하려 했고, 2019년에는 시장 변화 이후 스스로 이 일을 지속할 방법이 필요해져 오픈 코어로 방향을 틀고 자력으로 회사를 세웠다. 오늘날 우리 작은 팀은 OpenFaaS, SlicerVM - AI 샌드박스와 "Linux에 없던 API", Actuated.com - GitHub/GitLab용 셀프호스팅 CI 러너, Inlets.com - 셀프호스팅 HTTP/TCP 터널을 유지관리하고 있다.
이 제품들은 컨테이너, Kubernetes, Firecracker microVM, 네트워크 프로토콜 같은 매우 저수준의 Linux 기본 요소를 사용한다. 크게 보면 모두 효율성, 사용자 경험, 제어, 자율성에 초점을 맞춘 의견이 반영된 인프라 제품들이다. 이들은 Go로 작성되었고, 일부는 React 기반 UI 컴포넌트, 랜딩 페이지, 문서, 에이전트 스킬, CLI도 포함한다. 코드와 함께 우리는 최고 수준의 지원도 제공한다. 우리는 작은 팀이고, 고객을 돕기 위해 확장되지 않는 일도 기꺼이 하기 때문이다.
나는 AI 도구를 사용할 수 있게 된 초기부터 계속 사용해 왔다. 초창기 VS Code의 탭 완성부터, ChatGPT로 코드 덩어리를 생성하거나 버그를 찾게 하는 것, 그리고 하루 12시간 tmux 안에서 살아가는 것까지 해왔다. tmux 안에 있는 시간이 너무 많아져서, 세션과 노트를 추적하고 코딩 에이전트의 시각적 피드백을 얻기 위해 무료 도구 Superterm.dev를 직접 만들었다. 그 시간 동안 나는 기능이 "반복 코드 줄이기"에서 "처음부터 끝까지 설계하고 아키텍처를 짜고 테스트하기"로 발전하는 것을 봐왔다. 내 일의 대부분은 Claude나 Codex가 하고 있고, 글쓰기는 내가 직접 해야 한다고 고집하지만, 코드는 손으로 거의 쓰지 않는다. 이렇게 말하는 것이 아프긴 하지만 말이다.
최전선 지능의 전환점
대략 2025년 11월부터 2026년 1월 사이가 전환점이었다고 본다. X의 많은 개발자들이 Claude Opus가 달라졌고 이제는 자신의 모든 일을 해낼 수 있다고 말하기 시작했다. 수동 코딩은 냉장고 밖에 둔 우유가 금방 상하듯 금세 나쁜 선택이 됐다. 최고급 코딩 플랜의 비용은 개인 기준 대략 월 200 USD 수준으로 자리잡았다. 결코 작은 금액은 아니지만, 그들이 만들어내는 가치에 비하면 감당 가능한 수준이었다. 지금도 너무 많은 무인 작업만 피하면, 5시간 제한과 주간 제한 안에서 꽤 오래 쓸 수 있다.
로컬 모델이 흥미로운 이유
이런 주장도 있다. "감당할 수 있는 최고의 것을 두고 왜 그보다 못한 것을 쓰는가?"
2026년은 확실히 새로운 개척지다. 이제는 어떤 아이디어든 개발도상국에서 구독 하나만 가진, 이름도 들어본 적 없는 누군가에게 하룻밤 사이 복제될 수 있는 곳에 우리가 와 있다는 뜻이다. 나는 그것이 우리 SlicerVM 제품(원래 2022년에 손으로 작성됨)과 Superterm(2026년 신제품, 100% 코딩 에이전트로 작성됨)에서 실제로 일어나는 것을 보았다. 바이브 코딩된 복제품이 경험 많은 팀이 지원하는 잘 설계되고 잘 아키텍처된 솔루션과 100% 동등하다는 뜻은 아니지만, 소프트웨어의 비용이 0이 된 시장에서는 무료이고 충분히 괜찮은 것만으로도 전부가 될 수 있다.
그렇다면 이렇게 경쟁이 치열한 환경에서 왜 스스로를 더 나쁜 것에 제한해야 할까? 그것은 기회비용이 아닌가? 생계를 위험에 빠뜨리는 것 아닌가?
선도적인 모델은 0.5-2T 파라미터를 가진다는 추정이 있다. 이것은 로컬 하드웨어에서 쓸 수 있는 최고급 모델보다 "조금 더 많다"거나 "몇 배 더 많다"는 수준이 아니다. 아예 다른 차원이다. 파라미터 수는 대략적인 용량, 지식, 추론 능력의 대리 지표다. 그런데도 somehow, Qwen 3.6 27B 같은 작은 밀집형 모델도 SWE-Bench Verified에서 77.2라는 꽤 권위 있는 점수를 기록했고, Claude Opus 4.8은 88.6%였다.
그래서 여러분이 X에 가서 "로컬은 SOTA보다 겨우 12% 뒤처질 뿐"이라고 크게 외친다 해도 이해는 간다. 실제로 많은 사람이 그렇게 했고, Space Invaders 같은 원샷 데모도 활발히 올렸다. 6년 된 GPU 한 장이면 월 200 USD인 ChatGPT Pro 구독을 대체할 수 있다고까지 주장할 수도 있고, 실제로 그렇게 말한 사람도 많다.
벤치마크 극대화
벤치마크는 움직이는 표적이고, 널리 공개되어 있기 때문에 모델이 이 테스트에서 원래보다 더 높은 점수를 받도록 학습시키고 튜닝하는 것도 가능하다. 고전적인 SWE-Bench Verified 벤치마크는 여러 오픈 소스 프로젝트의 Python 이슈 집합을 바탕으로 한다. Python에는 스레드와 async가 있지만, 실제로 마주치는 대부분의 코드는 단일 스레드에 동기식이다. 반면 우리는 Go로 분산 시스템을 작성하며, 여기서는 channel, context, struct가 넓은 실행 범위에 걸쳐 있다.
비용
"로컬 모델은 비용 때문에 쓰는 게 아니다"라는 매우 인기 있는 견해가 있는데, 그것은 특권적인 위치에서 나오는 말이다. 개인은 월 200 USD로 업무 시간 동안 많은 사용량을 제공하는 코딩 플랜을 쓸 수 있다. 그 기준이라면 여러분은 SOTA 수준의 지능, 무언가가 제대로 작동하고 품질이 좋을 가능성, 버그를 찾을 가능성, 또는 랜딩 페이지를 생성할 가능성을 얻는 셈이다.
코딩 플랜은 분명히 보조금이 들어가 있다. GitHub Copilot 플랜에서 무슨 일이 있었는지만 봐도 된다. 처음에는 월 39 USD에 1500개의 요청을 제공했고, 그것으로 꽤 오랫동안 아주 싸게 버틸 수 있었다. GitHub/Microsoft/Azure 내부에서 공개되지 않은 어떤 변화가 생겼고, 모두를 토큰 기반 가격으로 옮기면서 반발이 엄청났다. 진짜 비용은 너무 오랫동안 숨겨져 있어서, 우리는 그것에 익숙해져 버린 것이다.
이제 API 요금으로 토큰을 지불하고 있다면, 손익분기점은 많은 사람이 생각하는 것보다 더 빨리 온다. 최근 Uber는 지출 상한을 설정했다. 개발자 1인당 도구별 월 1500 USD다. Uber의 중간 연봉은 연 330k USD이므로, 어떤 개발자가 두 도구를 최대한으로 사용한다면 연간 총보상의 대략 12% 수준이다.
그래서 대량 사용, 루프, 에이전트 기반 분석, SaaS 시스템을 통해 배포되는 제품 내 기능에서는 오픈 웨이트 또는 로컬 모델이 상당한 가치를 줄 수 있다. 비용을 이유에서 제외하는 것은 공정하지 않지만, 많은 사람에게는 그것만이 전부는 아니다.
주권성과 프라이버시
우리는 데이터 통제를 매우 गंभीर하게 여기는 여러 엔터프라이즈 고객과 일한다. 우리 제품군을 크게 보면, 우리는 전부 프라이버시와 주권성에 관한 것이다. OpenFaaS는 여러분의 인프라에서, 여러분의 제한과 선호 언어, 이벤트에 따라 함수를 실행한다. SlicerVM은 어떤 추상화된 클라우드 기반 베어메탈이 아니라 여러분 자신의 장비, 심지어 MacBook에서도 microVM을 실행한다. Inlets는 터널 클라이언트와 서버를 여러분이 통제할 수 있는 100% 프라이버시의 터널을 제공한다. Actuated는 GitHub Actions의 번거로운 부분을 없애고 "여러분의 머신에 에이전트만 설치하면 된다"고 말한다.
그래서 우리는 자연스럽게 로컬 모델에 끌린다. 인터넷이 어떠해야 하는지에 대한 우리의 핵심 가치와 신념 때문이기도 하고, 의무 때문이기도 하다.
여러분은 이런 신념을 공유하지 않을 수도 있고, 어떤 고객 데이터도 다루지 않을 수도 있다. 하지만 미국 밖에 살고 있다면 Anthropic의 Fable 5 모델이 하룻밤 사이 사라진 일이 충격이었을지도 모른다. 다시 말해, 공급업체 위험은 진지한 문제이고, 우리 중 많은 사람은 이미 그 원천에 중독되어 있다.
로컬 모델은 "최전선 연구소가 X를 하면 어떻게 하지?"에 대한 해답이다.
나는 로컬 모델이 SOTA와 같은 도구가 아니라고 말했다. 그게 무슨 뜻일까?
나는 손도구로 가구를 만들고, 가끔 오픈 소스 프로젝트를 필요 때문에 공개하듯, 끌, 홈파기 대패날, 송곳, 조각용 Sloyd knife 같은 날도구를 만든다.
가열한 줄의 뒷면 위에서 일본식 마킹 나이프를 짚색이 될 때까지 템퍼링하는 모습.
강철을 다루는 방법은 투자할 수 있는 정도에 따라 두 가지가 있다. 단조는 원재료인 강철을 가열하고 망치로 두들겨 필요한 형태로 만드는 것이다. 이것이 가장 순수하고 명예로운 방식, 즉 "진짜 방식"으로 여겨진다. 반면 작은 물건에는 "stock removal"이 훨씬 접근하기 쉽다. 강판을 가져와 형태를 잘라내고, 비벨이나 끝을 갈아 만드는 방식이다.
하지만 그것은 모양 잡기일 뿐이다. 그 다음에는 강철을 가열하고 기름이나 물에 담가 급랭시켜야 한다. 그러면 강철은 극도로 단단해지는데, 너무 단단해져서 떨어뜨리면 산산조각 날 정도다. 그래서 검은 찌꺼기를 닦아내고, 다시 가열하면서 무지개 같은 색을 지켜봐야 한다. 우리가 필요한 색을 한 단계라도 지나치면, 열처리를 처음부터 다시 해야 한다.
우리 팀의 로컬 모델 경험은 바로 이 템퍼 색을 놓치는 것과 정확히 같다. 모델이 너무 뜨겁게 돌아가서 목표를 지나쳐 루프에 빠져버린다. 이를 고칠 수 있는 방법은 하네스를 종료하고, 컨텍스트를 비운 뒤 다른 결과가 나오길 바라는 것뿐이다.
나는 칼날을 템퍼링하면서 절대 자리를 비우지 않을 것이고, 마찬가지로 Qwen 3.6 27B를 긴 지평선의 작업에 혼자 맡겨두지도 않을 것이다. 강철에서는 변동성을 없애기 위해 가마나 온도 제어 오븐을 쓰는 것이 우회책이다.
우리가 단조한 그 Sloyd knife로 못을 박는 데 쓸 수도는 있겠지만, 손을 베고 날을 망칠 가능성이 크다. 처음으로 돌아가 보자. 이것이 다른 도구라면, 무엇에 좋은가?
내가 찾고 있던 것
나는 앞 절에서 다룬 모든 것을 찾고 있었다. 프라이버시, 고정 비용, 공급업체 위험에 대한 방어다. 내가 실망했고 지금도 계속 실망하는 지점은, opencode 안의 로컬 모델을 Claude나 Codex를 대하듯 똑같이 다룰 때다. 그들이 실제 목표를 향해 진짜 진전을 만들면서 얼마나 오랫동안 완전 무인으로 일할 수 있는지는 거의 섬뜩할 정도다.
나는 다음과 같은 내용을 붙여넣을 수 있다. "Eoin이 Slicer VM을 루프로 돌리다 FD가 고갈됐다고 했다. VSock를 의심하고 있다" 그러면 몇 분 뒤 Claude는 "이제 전체 그림이 보입니다. 당신은 X를 하고 있고, Y를 해야 합니다"라고 답한다. 나는 "그걸 하고 내 미니 PC에서 끝에서 끝까지 테스트해"라고 말하고, 5분이든 15분이든 어느 정도 시간이 지나면 PR을 올리고, 자동 코드 리뷰를 받게 한 뒤, 다시 Claude에게 읽고 한 번 더 반복하라고 할 수 있다.
이것은 여러 제품을 관리하고 엔터프라이즈 및 커뮤니티 사용자와 매우 밀접하게 일하는 우리 같은 작은 팀에게 놀라울 정도로 효율적인 루프다.
3090에서 배운 뼈아픈 교훈
나는 2023년에 3090 카드 한 장으로 시작했고, 모델을 로드하고 충분한 컨텍스트를 확보하려면 곧 하나가 더 필요하다는 것을 깨달았다. 2023년의 로컬 모델에 대해서는 여기서 굳이 다룰 만한 것이 없다. 쓰기가 너무 어려워서 결국 포기했기 때문이다. Qwen 3.5는 에이전트가 실제 일을 해내는 것을 내가 처음 본 시점이었다.
Q4 양자화와 200k 컨텍스트(이것도 양자화됨)로 모델을 어느 카드든 올리고, 지시를 잘 주면 작은 작업은 시킬 수 있었다. 그것이 얼마나 빨리 망가졌는지 아직도 기억한다. 나는 모델에게 "이 머신을 모든 각도에서 살펴보고, 이 머신과 그 사용 방식에 대한 포렌식 보고서를 완성해"라고 말했다. Claude라면 대수롭지 않게 해냈을 것이다. Qwen은 내 머신의 모든 파일을 하나씩 읽기 시작했고, 컨텍스트를 가득 채운 뒤에는 파일명과 도구 호출까지 환각했다. ~/faas-netes가 ~/faaned가 되는 식이었다. 한 걸음 물러서서 작업 범위를 "이 머신을 빠르게 둘러보고, 누가 왜 쓰는지 말해줘"라고 좁히자 꽤 또렷한 보고서를 얻을 수 있었고, 생성 속도는 초당 대략 40-50 토큰이었다.
27B 모델은 1x 3090 카드에 완전한 충실도로는 들어가지 않는다. 그래서 조절할 수 있는 손잡이와 다이얼은 모델 가중치의 압축 수준(양자화), 컨텍스트 길이, 그리고 컨텍스트의 key/value 압축 수준이다.
KV 캐시의 key 부분을 Q4_0로 내리면 나쁜 일이 생기기 시작한다는 잘 알려진 경험칙이 있다. 내가 가장 공격적으로 해본 설정은 keys는 Q8_0, values는 Q4_0였다.
3090들은 지속적인 골칫거리였다. 내가 편하다고 느끼는 수준보다 훨씬 더 낮게 양자화해야 했다. 카드 하나는 켤 때 손가락을 교차해야만 나타났다. 재부팅으로도 고쳐지지 않았고, 매번 AC 전원을 완전히 끄고 전원 케이블을 30초 동안 뽑아야 했다.
가장 최근 실험은 vLLM(프로덕션 및 동시 서빙의 사실상 표준)을 설정하는 것이었는데, NVLink(175GBP)와 tensor parallelism을 켠 상태에서도 동등한 구성 기준으로 생성 시 llama.cpp보다 초당 3토큰 느렸다.
나는 결과보다 그것들을 작동시키는 데 더 많은 시간을 쓰고 있었다.
큰돈 쓰기
우리는 제품을 사용하는 엔터프라이즈 기업에 지원 계약을 제공하고 있고, 티켓이 들어오면 가능한 한 빨리 해결할 유인이 있다. 나는 모든 자잘한 문제를 없애줄 카드를 사면 로컬 모델 문제가 해결될 것이라 생각했고, 고객 지원이라면 그 위험을 감수할 가치가 있다고 봤다.
우리는 VRAM 96GB를 가진 RTX 6000 Pro Blackwell 에디션에 대략 12000 USD를 썼다. 두어 달 지난 지금은 가격이 약 15400 USD까지 올라 두 번째 카드를 추가하는 일은 훨씬 정당화하기 어려워졌다. 소비자용 머신에 그냥 "카드 하나 더 꽂기"는 불가능하다. PCI 레인, 대역폭, 카드 간격, PSU 전력 소모까지 많은 문제가 있다.
이것은 계산된 베팅이었고, 실제로 성과를 냈다. 하지만 Claude 구독을 대체해서가 아니다. 그것은 할 수 없다.
고객 데이터를 유출하지 않으면서 고통 없는 고객 지원
많은 엔터프라이즈 운영자는 매우 유능하고 숙련되어 있지만, 수작업 절차와 관행에 발목이 잡혀 있다. 운이 좋으면 누군가가 문제 해결 가이드의 모든 항목을 따라가고 무엇을 잘못했는지 알려준다. 다른 때는 이메일 체인이 150번의 답장을 넘겼는데도 모든 것을 밝혀줄 그 한 명령을 아직 실행하지 않은 경우도 있다.
그래서 우리는 운영자가 쉽게 실행할 수 있고 Kubernetes 상의 OpenFaaS 설치 전체 스냅샷을 수집하는 "diag"라는 CLI 도구를 만들었다. 그러면 그들은 이 덤프를 우리에게 이메일로 보낼 수 있고, 우리는 Slicer가 만든 일회성 VM 안에서 에어갭된 로컬 모델로 이를 분석할 수 있다. 우리가 발견한 문제에 대해서는 OpenFaaS 블로그의 Introducing: Painless support and hands-off architecture reviews에서 더 읽을 수 있다.
매출 회수
최근 갱신 건 하나가 있었는데, 내가 텔레메트리 데이터베이스를 로컬 모델에 넣어보았기 때문에 비로소 그들이 12개월 넘게 라이선스를 실제보다 적게 보고하고 약 4-5배 적게 지불해왔다는 사실을 알게 됐다. 그 매출 회수만으로도 카드 값을 치렀다.
그들의 데이터 보존 정책이 어떻든 간에, 텔레메트리 덤프나 고객의 diag 출력물을 어떤 클라우드 플랜에라도 양심적으로 넣었을 리는 없다. 이 지점에서 근동 및 극동의 코딩 플랜에 대해 말하자면, caveat emptor다. 나는 아직까지 입력과 출력의 학습 및 소유권에 대해 당신의 IP 위에 특권적 지위를 두지 않는 플랜을 본 적이 없다. ChatGPT Pro와 Claude Max는 30일 보존 기간으로 설정할 수 있지만, 그 정도 수준조차도 고객과의 계약을 무효화할 가능성이 크다.
가끔은 GPT나 Opus에 텔레메트리 테이블의 스키마를 주고, 로컬 모델이 가장 잘 따를 법한 AGENTS.md를 쓰게 한 적도 있다. 우리의 데이터는 여러 고가용성 복제본에서 하루에 여러 차례 보고되므로, 24시간 단위로 단순 합산할 수 없다. 모델의 이전 버전에서는 산술에 실패하는 것을 봤다. 27.3K를 273,000으로 세는 식이었다. 내가 철저히 검토했기 때문에 그 실수를 잡아낼 수 있었다.
또 다른 때에는 모델이 함수 수가 적다는 이유로 어떤 고객이 이탈할 가능성이 크다고 추론했다. 하지만 그 고객이 그 적은 수의 함수를 하루에도 여러 번 실행한다는 점은 완전히 무시했다. 그래서 모델에게는 해석보다 분석에 집중시키는 편이 더 나을 때가 많다.
우리의 현재 설정
나는 Jack Rong과 Kyle Hessling 같은 사람들을 강하게 지지한다. 이들은 Qwen 같은 오픈 웨이트 모델의 파인튜닝 작업을 해왔다. Qwopus는 Qwen 위에 Chain of Thought 추적을 덧씌워 추론과 코딩을 더 잘하게 만들려는 시도다. 이들은 커뮤니티를 돕기 위해, 그리고 로컬 AI에 대한 깊은 신념 때문에 이런 일을 한다.
우리 팀은 RTX 6000 장비에서 최신 세대의 Qwopus와 기본 27B Qwen 3.6 모델을 둘 다 돌리고 있다. 이것은 시간이 지나며 바뀐다. 새로운 파인튜닝이 나오고, 새로운 Qwen 포인트 릴리스가 나오고, 우리가 새로운 엣지 케이스와 한계를 만나기 때문이다. 아주 최근까지 우리는 thinking을 완전히 꺼둔 채 돌렸고, 최근에야 다시 켰는데, 그 시점과 루프가 더 자주 보이기 시작한 시점이 겹친다.
모델은 서로 독립된 두 개의 llama.cpp 인스턴스로 서빙되는데, 이는 전체 컨텍스트 길이를 유지한다는 뜻이다. "동시성"에 대한 기본 답은 --parallel 2를 실행하는 것이지만, 그러면 사용 가능한 컨텍스트가 절반으로 줄어든다.
$ nvidia-smi
Wed Jun 17 11:56:03 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 590.48.01 Driver Version: 590.48.01 CUDA Version: 13.1 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA RTX PRO 6000 Blac... Off | 00000000:01:00.0 Off | Off |
| 30% 32C P8 15W / 600W | 85937MiB / 97887MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 2265 C ...ma.cpp/build/bin/llama-server 31198MiB |
| 0 N/A N/A 2544 C ...ma.cpp/build/bin/llama-server 54718MiB |
+-----------------------------------------------------------------------------------------+
llama.cpp는 소스에서 빌드하며, 매주 또는 필요 시 최신 상태로 유지한다. Nvidia GPU 지원을 추가하려면 소스 빌드가 필요하다.
다음은 전체 컨텍스트 길이와 전체 품질 컨텍스트로 Qwen 단일 인스턴스를 띄우는 명령이다.
#!/bin/bash
~/llama.cpp/build/bin/llama-server \
-hf unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q8_K_XL \
--alias Qwen3.6-27B-Base \
--host 0.0.0.0 \
--port 8085 \
-ngl 99 \
-c 262144 \
--cache-type-k f16 \
--cache-type-v f16 \
--flash-attn on \
--parallel 1 \
--threads 16 \
-b 4096 \
-ub 2048 \
--jinja \
--reasoning-budget 2048 \
--temperature 0.6 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.0 \
--presence-penalty 1.1 \
--reasoning on \
--spec-type draft-mtp \
--spec-draft-n-max 6 \
--chat-template-kwargs '{"preserve_thinking": true}' \
--chat-template-file chat_template.jinja \
--reasoning-budget-message "reasoning budget consumed, time to answer now"
우리는 MTP 기반 speculative decoding에서 약 93%의 acceptance rate를 얻고 있고, 속도는 안정적인 67 tok/s에서 장시간 지속 시 130-200 tok/s로 올라간다. 체감상 클라우드 모델보다 빠르게 느껴진다.
llama.cpp를 튜닝할 때는 모델 카드의 지시를 따르는 것이 중요하다. 특정 temperature가 연구소에서 선택된 데에는 대개 이유가 있다. 예를 들어 Qwopus 파인튜닝은 thinking을 끄고 temperature를 0.85-1.0처럼 아주 높게 했을 때 가장 잘 동작한다.
그 루프 말인데
최근 나는 루프를 피하려고 튜닝을 해왔다. 다시 템퍼링 비유로 돌아가자면, 이 모델을 긴 지평선의 작업에 그냥 맡겨둘 수는 없다.
나는 Qwen에게 faas-cli에 어떤 명령을 추가해야 하는지 물었고, 꽤 그럴듯한 제안을 내놓았지만 거기에서 멈춰 같은 내용을 계속 반복하며 내 전기를 600W씩 30분가량 태워버렸다.
58. faas-cli function import - Import functions from a YAML file or URL.
59. faas-cli function export - Export deployed functions back to a stack.yaml file.
60. faas-cli function scale - Manually scale function replicas without redeploying.
61. faas-cli function rename - Rename a function in-place.
62. faas-cli function diff - Compare local stack.yaml with what's deployed - show differences.
63. faas-cli function import - Import functions from a YAML file or URL.
64. faas-cli function export - Export deployed functions back to a stack.yaml file.
65. faas-cli function scale - Manually scale function replicas without redeploying.
66. faas-cli function rename - Rename a function in-place.
67. faas-cli function diff - Compare local stack.yaml with what's deployed - show differences.
68. faas-cli function import - Import functions from a YAML file or URL.
69. faas-cli function export - Export deployed functions back to a stack.yaml file.
70. faas-cli function scale - Manually scale function replicas without redeploying.
71. faas-cli function rename - Rename a function in-place.
72. faas-cli function diff - Compare local stack.yaml with what's deployed - show differences.
Build · Qwen3.6-27B-Base toilgate
내가 "모든 get 및 list 명령에 --json을 추가해"라고 했을 때도 같은 일이 벌어졌다. 처음 한두 개는 꽤 설득력 있었고 테스트도 썼다.
그런데 --json은 기계가 읽는 형식이기 때문에, faas-cli는 http:// 원격 엔드포인트를 사용할 때 insecure TLS에 대한 경고를 더 이상 출력하지 않아야 했다. Qwen은 이를 해결하지 못했고, 그래서 나는 Python으로 reverse proxy를 쓰고 그것을 대신 호출하라고 시켰다. 첫 번째 버전은 그럴듯해 보였지만 들여쓰기가 엉망이었다. 문제가 무엇인지 깨달았을 때는 파일을 망가뜨렸고, 어떻게 고쳐야 할지 모르겠고 다른 종류의 루프에 빠졌다고 계속 불평했다. 포기하지는 않았지만, 점점 더 탈선해 갔다.
팀의 Han도 매우 비슷한 루프를 보고했다. 대부분은 두 번째 종류였다. 모델이나 에이전트가 능력의 경계에서 막혀 있으면서 도움을 요청하지 않는 것이다. 나는 주로 첫 번째 종류를 겪었는데, 솔직히 그게 더 나쁘다고 생각한다. 그래서 고객 지원/갱신용 텔레메트리와 diag 작업을 넘어서면 좀처럼 믿지 못한다.
접근 측정과 분배
처음에는 inlets 터널 하나만 설정해두고 에이전트들이 서로 충돌하지 않기를 바랐다. 서로 관련 없는 컨텍스트를 가진 두 에이전트가 같은 llama.cpp 인스턴스를 치면, 각 요청은 상대방의 캐시된 prefix를 무효화한다. 그래서 매번 전체 프롬프트를 처음부터 다시 처리하게 되고, 그런 지연의 쓰래싱은 자주 겪고 싶지 않다. 그때는 대부분의 작업을 여전히 코딩 플랜에서 하고 있었기 때문에 아직 진짜 문제는 아니었다.
그 설정을 배포하는 것은 간단했다. opencode.json을 수정해 URL과 토큰을 추가한 뒤, 그 파일을 각자의 머신이나 Slicer VM에 복사하면 됐다.
하지만 다른 사람이 모델을 쓰는 순간, 그것은 더 이상 프로토타입이 아니다. 누가 어느 llama.cpp 인스턴스를 쓰고 있는가? 얼마나 쓰고 있는가? 어느 모델인가? 전기료는 얼마나 들었는가? 그 사람이 팀을 떠나면 어떻게 되는가? 팀에 다른 모델을 어떻게 추가하는가?
Toilgate는 100% 바이브 코딩으로 만들어졌고 오픈 소스로 공개하기에는 일이 너무 많다. 아이디어가 마음에 든다면 직접 만들어 보길 바란다.
내 opencode.json 파일을 수동으로 고쳐 여러 팀원에게 보내는 대신, 나는 opencode용 provider를 직접 쓰기로 했다. 그것은 안정적인 기본 모델부터 양자화된 더 실험적인 Qwopus 변형들까지 사용 가능한 모델을 관리한다. opencode를 실행한 뒤 모델 선택기에서 toilgate를 고르고, 그다음 원하는 것을 선택하면 된다.
Shelly Plus Plug 두 개가 벽면 전력 소비를 모니터링해서 실제 비용을 더 잘 파악할 수 있게 해준다. RTX 6000 Pro는 추론 중 600W를 끌어가고 비교적 조용한 편이며, 두 장의 3090은 합쳐서 750W에 가깝고 엄청 시끄럽다.
잘못된 비교
측정할 수 있게 되면 빠지기 쉬운 함정은 입력/출력 백만 토큰당 비용을 GPT-5.5의 OpenAI API 가격과 비교하는 것이다. 현재 능력 수준에서는 그것이 올바른 비교가 아니다. 더 중요한 것은 지속적인 비용을 이해하는 일이다. 이 머신이 내 집에 있기 때문에, 클라우드 모델에 적합하지 않은 작업을 위해 그 비용은 내가 개인적으로 부담하고 있다.
바로 여기서 "로컬 AI"는 운영 문제로 바뀐다. 신원, 접근 제어, 계량, 할당량, 모델 라우팅, 전력 모니터링이 필요하다. 우리가 계속 다시 마주치는 더 어려운 부분은 에이전트/모델 조합의 신뢰성, MTP 같은 혁신을 따라가는 일, 그리고 사람들이 모델 가용성에 의존하기 시작한 뒤 충분한 업타임을 보장하는 일이다.
로컬 Qwen은 "거의 Opus 수준"이 아니며, 이 글에서 충분히 보여줬기를 바란다. 하지만 특정 작업과 워크플로에서는 분명한 가치가 있다. 또한 지금은 매우 이른 시점이고, 앞으로 더 좋아질 수밖에 없다. Qwen 3.5는 아마도 우리가 실제로 쓸 수 있는 결과를 준 첫 번째 모델이었다. 곧 3.7이 나온다는 소문도 있는데, 나는 그것이 혁명적 변화라기보다 점진적 개선일 것이라 본다.
실제로 도움이 되는 구체적인 것들:
slicer CLI의 사용성에 대한 피드백도 줬고, 우리는 그것을 반영했다내가 70B 모델을 언급하지 않았다는 점을 눈치챘을 것이다. 대부분은 이 시점에서 진짜로 오래됐고, 세대가 뒤쳐져 있다. Qwen의 35-A3B 변형이 MacBook에서 더 빨라 보여서 인기가 있는 편인데, 그 이유는 생성 시 활성 파라미터가 3B뿐이기 때문이다. 나는 속도보다 얻을 수 있는 최고 품질을 택하겠다. GLM 5.2, Kimi 2.7, Minimax M3, Deepseek V4 Flash 같은 훨씬 더 큰 모델도 있다. 이런 모델은 어떤 로컬 장비에서는 돌릴 수 있지만, 양자화된 버전조차 로드하려면 보통 RTX 6000 Pro 카드가 4-6장 필요하다는 이야기라, 우리 범위에서는 벗어난다.
소비자 입장에서 다음 단계가 무엇일지는 나도 모르겠다. 엔터프라이즈 하드웨어로 넘어가야 하는지, 아니면 27B 밀집형 모델의 자리가 남아 있는지 말이다. 하지만 오늘의 기준에서 이 모델들은 하루 종일 Go를 쓰도록 내버려둘 정도로 적합하지는 않다. 지식과 주의력의 한계는 코드 리뷰에서 즉시 드러난다. Go 코드는 작성될 수 있고, 동시성도 작동할 수 있지만, 우리의 실험은 매우 빠르게 중단됐다. Qwen이 간결하라는 지시를 따르지 못하고 자동 코드 리뷰에서 쓸데없이 장황해졌고, 동시성 문제와 race condition을 환각했기 때문이다. 비교적 화려하지 않은 Grok Coder Fast 1은 더 저렴하고 더 빨랐으며, 지원 종료되기 전까지 몇 달 동안 우리에게 잘 خدمت했다.
우리의 코드 리뷰 봇은 여기에서, 그리고 OpenFaaS를 위한 고통 없는 고객 지원과 아키텍처 리뷰는 여기에서 더 읽을 수 있다.