ArkNill
3노드 로컬 LLM 랩을 운영하는 백엔드 엔지니어. 벤더가 말하지 않는 것을 직접 측정합니다 — 42K API 콜 분석, 양자화 손실, 추론 비결정성. 마케팅이 아닌 데이터.
Claude Code vs 로컬 35B 모델: 크로스체크 하네스를 만들며 배운 것들
월 20만원 내고 쓰는 Claude Code, 로컬 35B 모델이 대체할 수 있을까? 저는 Claude Code (Opus 4.6)를 주력 코딩 도구로 사용합니다. 동시에 DGX Spark 2대와 RTX 5090에서 Qwen 3.5/3.6 35B를 로컬로 돌립니다. 매달 $200(약 27만원)을 내면서 자연스럽게 궁금해졌습니다. 이 돈값을 하는 건가? 로컬 모델로 충분하지 않을까? 답을 찾기 위해 10일간 벤치마크 하네스를 3개 만들었습니다. 결론부터 말하면 — 모델보다 하네스가 더 많이 틀렸습니다. 평가 도구를 만드는 과정에서, 모델 성능보다 평가 방법론에 대해 훨씬 더 많이 배웠습니다. ...
3노드 홈 LLM 랩을 만들었습니다. 실제로 필요한 것들.
집에서 3노드 LLM 추론 클러스터를 운영하고 있습니다. NVIDIA DGX Spark 2대(각 128GB 통합 메모리)와 RTX 5090 데스크탑(32GB VRAM) 1대. 세 노드 모두 Qwen 3.5/3.6 35B MoE 모델을 24/7 로컬 네트워크에서 서빙합니다. 주말 실험이 아닙니다. 매일 쓰는 개발 인프라입니다. 코드 리뷰, 리서치 쿼리, 벤치마크 — 전부 이 노드들 위에서 돌아갑니다. 왜 3대가 필요한가 “128GB면 모델 하나 올리기 충분하지 않나요?” 맞습니다. 1대로 모델은 돌아갑니다. 그런데 **역할 분리(role specialization)**를 하면 클러스터가 단일 노드의 합보다 강해집니다. ...
양자화, 결정론, Thinking 토큰: 오픈소스 LLM 프로덕션 운용기
저는 Qwen 3.5와 3.6 (35B MoE, 활성 파라미터 3B)을 3개 노드에서 프로덕션으로 운용하고 있습니다. DGX Spark 2대(FP8, vLLM)와 RTX 5090 1대(Q4, llama.cpp) 구성입니다. 100개 이상의 벤치마크 시나리오와 수천 회의 추론 호출을 거치면서, 디버깅 시간의 대부분을 차지한 문제는 딱 세 가지였습니다. 양자화 손실은 균일하지 않습니다 — MoE 모델의 Q4는 CJK 태스크에서 16%를 잃습니다 vLLM은 비결정적입니다 — 동일한 프롬프트에서 다른 출력이 나옵니다 Thinking 토큰은 이득 없는 태스크에서 예산의 60~90%를 먹습니다 이 세 가지 모두 표준 벤치마크에서는 드러나지 않습니다. 그런데 프로덕션에서는 전부 문제를 일으킵니다. ...
tok/s가 알려주지 않는 것: 실제로 체감되는 LLM 속도 측정법
tok/s 숫자만 보고 GPU를 고르면 실패합니다. 저는 Qwen 3.6 35B를 3대의 머신에서 운영하고 있습니다. RTX 5090은 204 tok/s를 뽑습니다. DGX Spark 2대는 각각 65 tok/s입니다. 벤치마크 리더보드 기준으로 5090이 3배 빠릅니다. 그런데 thinking을 켜고 멀티스텝 코딩을 시키면, DGX 조합이 더 먼저 끝납니다. 반면 단순 질문에는 5090이 2초 만에 답하고, DGX는 8~12초 걸립니다. tok/s 하나로는 실제 사용 경험을 전혀 예측할 수 없었습니다. 3노드 벤치마크를 직접 만들면서 배운 것을 정리합니다. 역설: 3배 빠른 GPU가 더 느린 순간 제 3노드 구성입니다. ...
Anthropic 포스트모템, 진실의 절반만 말했습니다
배경: Postmortem이란 무엇인가 소프트웨어 업계에서 postmortem(포스트모템)은 장애 발생 후 작성하는 공식 분석 보고서입니다. “무엇이 잘못되었고, 왜 발생했으며, 어떻게 재발을 방지할 것인가"를 투명하게 기술하는 것이 핵심입니다. Google, AWS, Cloudflare 등 대형 서비스가 장애 때마다 발행하며, 업계에서는 기업의 엔지니어링 성숙도를 보여주는 지표로 받아들입니다. 4월 23일, Anthropic은 포스트모템을 발행했습니다. 3월 4일부터 4월 20일까지 Claude Code 성능이 저하된 원인으로 세 가지 제품 레이어 버그를 인정한 문서입니다. 결론부터 말합니다. 인정한 세 가지 버그는 사실입니다. 수정도 사실입니다. 하지만 이 포스트모템은 전체 그림의 절반만 보여줍니다. ...
Opus 4.7 포스트모템: CHANGELOG가 말하지 않은 것
배경 소프트웨어 회사가 장애를 공식 인정하는 문서를 postmortem(포스트모템)이라고 합니다. “무엇이 잘못되었고, 왜 발생했으며, 어떻게 재발을 막을 것인가"를 공개하는 투명성 관행입니다. 그리고 CHANGELOG는 버전별 변경사항을 사용자에게 알리는 공식 기록입니다. 사용자가 “이번 업데이트에서 무엇이 바뀌었는지” 확인할 수 있는 유일한 통로이기도 합니다. 4월 23일, Anthropic이 포스트모템을 발행했습니다. 3월 4일부터 4월 20일까지, Claude Code에서 제품 계층(harness/product layer) 버그 3건이 성능을 저하시켰다는 내용입니다. 모델 가중치 변경은 없었습니다 — 세 건 모두 모델을 감싸는 제품 레이어의 문제였습니다. ...
Claude Code API 42,363건을 전수 추적해봤습니다 — 쿼터는 대체 어디로 가는 걸까요
70분 만에 쿼터 100% — 시작은 여기였습니다 Claude Code Max 20은 월 $200 구독 요금제로, Anthropic이 “최고 사용량 사용자"를 위해 만든 플랜입니다. 5시간 윈도우 단위로 쿼터가 리셋되는 구조인데, 4월 1일 평범한 코딩 중에 **70분 만에 100%**를 찍었습니다. 원인은 두 가지 캐시 버그였고, Anthropic이 v2.1.90~91에서 수정한 뒤 실제로 개선되었습니다. 하지만 “수정 이후에도 쿼터가 체감보다 빨리 소진된다"는 느낌이 남았습니다. 그래서 직접 측정하기로 했습니다. 이슈를 올리고, 커뮤니티 스레드를 파헤치고, 모든 API 호출을 기록하는 투명 프록시를 만들었습니다. ...