로컬 Qwen은 더 나쁜 Opus가 아니라 다른 도구다

이 모델들을 오래 써보면 단순히 “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 장비를 사서 만들고 싶은 사람들에게는, 먼저 여러 추론 제공자 중 하나에 연결해 다양한 모델을 한동안 직접 써보길 권함
비용은 거의 안 들지만, 자기 장비로 무엇을 얻을 수 있을지 꽤 괜찮은 미리보기가 됨. 그냥 친절한 팁임