Midnight AI Groove 26-06-22

DJ 미오:

안녕하세요, Midnight AI Groove. 내비게이터 DJ 미오입니다.

DJ 렌:

안녕하세요, DJ 렌입니다. 오늘 밤은, "오늘은 그렇게 큰 뉴스가 없었다"라고 말해지는 날에, 사실은 무엇이 일어나고 있었는지를 차근차근 풀어가 보겠습니다.

DJ 미오:

맞아요. "not much happened today"라는 언뜻 평온해 보이는 제목이지만, 내용을 읽어보면 전혀 조용하지 않더라고요.

오히려 AI의 진화가 **단일 모델 경쟁에서 에이전트(Agent) 운용, 평가, 인프라, 거버넌스(Governance), 그리고 로컬 구현(Local Implementation)**으로 확장되고 있는 것이 아주 잘 보이는 날이었습니다.

DJ 렌:

오늘은 그 전체상을,

• OpenAI의 사이버 영역 확장
• Sakana의 Fugu와 "오케스트레이션(Orchestration)" 논쟁
• GLM-5.2의 대두
• 에이전트 기반으로서의 Google 및 Hermes
• 추론 인프라와 "owned intelligence"
• 벤치마크(Benchmark) 및 평가 방법의 재점검
• Reddit에서 보이는 로컬 LLM 실천
• Anthropic의 본인 확인과 프런티어 모델(Frontier Model) 루머

라는 흐름으로 이야기해 보겠습니다.

DJ 미오:

먼저 전제부터 말씀드리자면. 이 요약에서는 며칠 동안 12개의 subreddit, 544개의 Twitter 계정을 체크했고, Discord는 이날을 기점으로 액세스 종료되었습니다. 즉, 정보원의 관측 범위가 상당히 넓습니다.

DJ 렌:

그럼에도 불구하고 "오늘은 조용한 날이었다"라고 말하고 있습니다. 하지만 조용한 날이기 때문에 오히려 정말로 중요한 구조적 변화가 보이기 쉽습니다.

화려한 신규 모델 발표뿐만 아니라,

• 모델을 어떻게 조합할 것인가
• 현장에서 어떻게 평가할 것인가
• 누가 어떤 인프라를 장악할 것인가
• 어디까지 본인 확인이나 규제가 개입할 것인가

그러한 "AI 구현 사회학" 같은 이야기가 전면에 나오고 있습니다.

DJ 미오:

네. 모델 단일의 IQ 스코어 경쟁이라기보다, 시스템으로서 AI를 어떻게 돌릴 것인가가 주전장이 되고 있는 느낌이네요.

DJ 렌:

첫 번째 큰 화제는 OpenAI입니다.

OpenAI는 사이버 보안을 위한 노력을 강화하여, Daybreak 프로그램의 확장, Codex Security 플러그인, 그리고 GPT-5.5-Cyber를 신뢰할 수 있는 방어 측에 제공하는 흐름을 내세웠습니다.

DJ 미오:

여기서 중요한 것은 방향성이 명확하게 바뀌고 있다는 점이죠.

이전에는 "취약점을 찾는" 이야기가 중심이었다면, 이번에는 "수정까지를 폐루프(Closed-loop)로 돌리는" 방향으로 나아가고 있어요.

DJ 렌:

맞아요. 기사에서는 상당히 구체적인 숫자도 나오고 있는데요,

3,000만 건 이상의 커밋(Commit) 스캔3만 개 이상의 코드베이스 커버7만 건 이상의 인간 리뷰 완료 수정-
여기에 더해 50만 건 이상의 추가 수정 자동 탐지

라는 규모감입니다.

DJ 미오:

대상 프로젝트도 cURL, Go, Python, Sigstore, pyca/cryptography와 같이 상당히 중요한 OSS(Open Source Software)가 포함되어 있습니다.

게다가 플러그인이 하는 일이,

• 딥 스캔(Deep Scan)
• 위협 모델링(Threat Modeling)
• 패치 생성(Patch Generation)
• 기존 워크플로우로의 내보내기(Export)

와 같이 상당히 실무적입니다.

DJ 렌:

즉, 단순한 "취약점 발견 AI"가 아니라, 보안 운용에 들어가는 AI가 되어온 것입니다.

다만, 여기서 한꺼번에 불거진 것이 정책·규제와의 정합성 문제입니다.

DJ 미오:

맞아요. OpenAI 측은 Sam Altman을 포함하여 GPT-5.5-Cyber가 CyberGym에서 SOTA(State-of-the-Art)다라고 주장하고 있습니다.

반면, Anthropic의 Mythos나 Fable의 액세스 제한을 둘러싼 논의가 계속되고 있어, "만약 OpenAI 쪽이 더 강력하다면, 왜 동일한 제한을 걸지 않는가?"라는 의문이 나오고 있습니다.

DJ 렌:

@BlackHC의 지적이 바로 그 부분이었습니다.

나아가 @shashj는 Mythos에 대해 퍼져 있던 "NSA 시스템에 몇 시간 만에 침입했다"라는 이야기에 중요한 보충을 하고 있습니다.

그것은 초기 액세스(Initial Access)를 전제로 한 레드팀(Red Team) 문맥이며, 게다가 그 레드팀은 현재 이미 Mythos에 액세스할 수 없다고 합니다.

DJ 미오:

이 부분이 중요하죠. 센세이셔널한 문구만 독자적으로 퍼지고 있지만, 무엇을 전제로 한 능력인지, 그리고 현재도 동일한 액세스 조건인지가 모호하면 거버넌스 논의도 엉망이 됩니다.

DJ 렌:

기사를 정리하는 방식도 그 부분이 핵심이었습니다.

모델 능력의 보고와 일관된 거버넌스 기준 사이에 격차가 벌어지고 있다는 점이죠.

요컨대, "강하다"라고 말하는 것은 좋지만, 그렇다면 어디서부터 규제할 것인지, 누구에게 어떤 조건으로 사용하게 할 것인지가 정립되지 않았습니다.

DJ 미오:

다음은 Sakana AI Labs의 Fugu입니다. 이것도 흥미로워요.

Fugu는 "단일 모델의 신작"이라기보다, 여러 프론티어 모델 (Frontier Model)을 학습 완료한 오케스트레이션 (Orchestration)으로 다루는 단일 API로서 제시되었습니다.

DJ 렌:

즉, Fugu가 하는 일은

• 모델 선택 (Model Selection)
• 위임 (Delegation)
• 검증 (Verification)
• 통합 (Integration)

을 한꺼번에 처리하는 것입니다.

단일 거대 모델을 한 번 호출하는 것이 아니라, 최적의 모델로 분배하면서 다단계로 답을 구성하는 발상입니다.

DJ 미오:

Vercel이 즉시 Fugu Ultra를 AI Gateway에 추가한 것도 상징적이죠.

현재 실무에서는 모두가 은연중에 "결국 가치가 높은 것은 단일 모델 그 자체보다, **라우팅 계층 (Routing Layer)이나 오케스트레이션 계층 (Orchestration Layer)**이 아닐까"라고 느끼기 시작했습니다.

DJ 렌:

Box의 Aaron Levie도 그런 **고부가가치 레이어 (High-value Layer)**가 될 것으로 보고 있고, Audrey Tang도 Fugu Ultra를 planner/advisor로서 고속 드라이버 루프 (Driver Loop)와 결합하여 사용하는 방식이 좋았다고 보고하고 있습니다.

DJ 미오:

Sakana 측도 자동 연구, 금융, 블라인드 체스, CAD와 같은 유스케이스 (Use case)를 제시하며, 긴 시간 축의 태스크 (Task)에서는 테스트 시의 협조 (Cooperation at test-time)가 단발 호출을 넘어설 수 있다고 주장하고 있습니다.

DJ 렌:

하지만 비판도 상당히 강했습니다.

특히 상세했던 것이 @eliebakouch의 분석이었는데, Fugu는 본질적으로

**라우터/분류기 (Router/Classifier) + 사전 설계된 다단계 워크플로우 (Multi-stage Workflow)**에 가깝지 않느냐는 것이었습니다.

DJ 미오:

게다가 평가 측면에서도 논점이 많더라고요.

• SWE-Bench Pro에서는 Opus에 약 10점 뒤처진다.
• 비교 대상이 "Model A/B/C"와 같이 익명화되어 있다.
• best-of-N 방식의 오케스트레이션임에도 토큰량이나 비용이 나와 있지 않다.
• 비교해야 할 것은 순수 베이스 모델 (Base Model)이 아니라, 다른 테스트 시간 스케일링 (Test-time scaling) 구성이 아니냐

라는 지적입니다.

DJ 렌:

나아가 @BlancheMinerva는 과거의 사례를 바탕으로 Sakana의 신뢰성 자체에 의구심을 제기하며, "이전 연구에서 불가능해 보이는 성능 주장이 있었다"라고까지 말했습니다.

DJ 미오:

즉, Fugu의 기술적인 방향성 자체는 많은 사람이 인정하고 있습니다.

하지만 논의는 이제 "오케스트레이션이 도움이 되는가?"가 아니라,

**"오케스트레이션 시스템을 어떻게 평가하고, 어떻게 공개해야 하는가"**로 옮겨가고 있습니다.

DJ 렌:

이것은 굉장히 큰 전환점입니다.

AI 시스템이 복잡해지면, 단일 모델의 벤치마크 (Benchmark) 방식만으로는 부족합니다.

몇 번을 호출했는지, 무엇을 라우팅했는지, 비용은 얼마인지, 실패 시의 동작은 어떠한지—그 부분까지 보지 않으면 비교가 되지 않습니다.

DJ 미오:

이번에 가장 열기가 뜨거웠던 것은 역시 GLM-5.2일지도 모르겠네요.

DJ 렌:

그렇습니다. GLM-5.2는 에이전트 (Agent) 용도로 프론티어급에 가까운 오픈 웨이트 (Open-weight) 모델로 간주되기 시작했습니다.

Artificial Analysis에서는 GDPval-AA에서 종합 3위, 1524 Elo를 기록했습니다. 상위에는 Claude Fable 5와 Opus 4.8 정도가 있으며, 오픈 웨이트 모델 중에서는 최상위입니다.

DJ 미오:

게다가 AA-Briefcase의 **비용/성능 프론티어 (Cost/Performance Frontier)**에서도 강력한 위치에 있습니다.

Nat Lambert는 "에이전트에게 있어 DeepSeek moment일지도 모른다"라고 말했고, Arav Srinivas는 "일상적인 실무 지식 노동에서 블라인드 테스트를 통과한다"라고까지 말했습니다.

DJ 렌:

하지만 이 기사가 강조했던 점은, 추상적인 벤치마크보다 실제 하네스 (Harness) 결과가 더 설득력 있다는 점이었습니다.

Cline은 자신들의 리포지토리 (Repository)에 있는 실제 버그를 사용하여, GLM-5.2와 Opus 4.8을 동일한 하네스에서 비교했습니다.

DJ 미오:

결과가 흥미로워요.

GLM-5.2는

• 속도는 다소 느림
• 툴 콜 (Tool call)은 많음

하지만,

• 저렴함: 0.41달러 vs 0.81달러
• 검증이 확실함: 데드 코드 (Dead code)를 정리함, 프로덕션 빌드 (Production build)를 확인함

반면 Opus는 테스트를 통과하더라도 타입 에러 (Type error)가 남아 있었다.

DJ 렌:

즉, 단순히 “답을 내놓았다”가 아니라, 끝까지 검증해내는 힘에서 GLM이 강했다는 뜻이죠.

이것은 에이전트 (Agent) 용도에서는 매우 중요합니다.

왜냐하면 실무에서는, 한 번 그럴싸한 코드를 작성하는 것보다 끝까지 망가지지 않았음을 확인하는 능력의 가치가 더 높기 때문입니다.

DJ 미오:

@askalphaxiv도, GLM-5.2는 처음으로 진정한 autoresearch를 수행할 수 있는 오픈 웨이트 (Open-weight) 모델이라고 말하고 있더라고요.

게다가 2대의 8xH100 노드를 사용한, 비동기인지 동거인지 모를 RL (강화학습) 훈련 실험까지 진행했고요.

DJ 렌:

툴링 (Tooling) 계층의 이야기도 상당히 중요합니다. @_xjdr는 GLM을 **ncode의 기본 모델 (Default model)**로 승격시켰습니다.

하지만 그 이면에는,

• 주말을 들여 용량 강화
• 툴 스트림 (Tool stream) 파서 (Parser) 고도화
• 일반 세션과 100만 컨텍스트 세션의 엔드포인트 (Endpoint) 분리

등, 상당한 구현 공수가 투입되었습니다.

DJ 미오:

이 지점에서 오픈 소스 모델의 현실이 보이네요.

성능이 좋아도, 깔끔하게 통합하기 위해서는 모델 고유의 파서나 하네스 (Harness) 정비가 대량으로 필요합니다.

하지만 역설적으로 말하면, 그럼에도 불구하고 할 가치가 있을 정도로 GLM-5.2가 강력해졌다는 뜻이기도 하죠.

DJ 렌:

게다가 배포 및 서빙 (Serving) 속도가 비정상적으로 빠릅니다.

AWS Marketplace, Baseten, Fireworks를 통한 Droid, LangChain의 deepagents, 그리고 셀 수 없이 **20개 이상의 프로바이더 (Provider)**로 확장되었습니다.

Baseten에서는 280 tok/s 초과, TTFT 0.8초 미만이라는 수치까지 나오고 있습니다.

DJ 미오:

심지어 Baseten의 OpenAI 호환 엔드포인트를 통해, Claude Code 안에서 GLM-5.2를 사용하는 실전 가이드도 나오고 있어요.

즉, 지금 일어나고 있는 현상은 오픈 모델의 질이 마침내

**“벤더나 에이전트 툴 개발자들이 진심으로 최적화에 뛰어들 만한 임계값”**을 넘었다는 것입니다.

DJ 렌:

이어서 에이전트 기반(Infrastructure) 자체에 대한 이야기입니다.

Google은 Interactions API를 Gemini를 위한 주요 인터페이스로 GA (General Availability) 했습니다.

DJ 미오:

이것의 핵심도 단순한 모델 API가 아니라는 점이에요.

• 모델과 에이전트를 하나의 API로 취급
• 백그라운드 비동기 실행
• 확장 툴 지원
• 멀티모달 (Multimodal) 생성
• 매니지드 에이전트 (Managed Agent)
• 그리고 격리된 원격 Linux 샌드박스(Sandbox)인 Antigravity까지 포함합니다.

DJ 렌:

Google이 단순한 “모델 제공자”가 아니라, 퍼스트 파티 (First-party) 에이전트 하네스 기반을 구축하러 왔다는 인상을 주네요.

DJ 미오:

게다가 이전을 돕기 위해 Gemini Interactions skill까지 내놓았습니다.

요컨대 코딩 에이전트에게 새로운 SDK 패턴이나 현재 모델 버전을 “가르치기” 위한 설치 가능한 스킬이죠.

DJ 렌:

동시에 오픈 소스 에이전트 간 통신 프로토콜의 정리도 화제가 되고 있었습니다.

Omar Sar0가 9종류의 OSS 에이전트 통신 프로토콜 서베이를 소개했는데, 현재는

• 하이브리드 페이로드 (Payload)
• 세션 상태의 영속화 (Persistence)

등이 표준화되어 가는 반면, 분산적인 발견 메커니즘 (Discovery mechanism)은 아직 미성숙하다고 지적하고 있습니다.

DJ 미오:

이것은 현재의 위치를 아주 잘 보여주네요.

모두가 장시간 작동하며, 툴을 사용하고, 상태를 유지하는 에이전트를 만들고 싶어 합니다.

하지만 이를 위한 프로토콜 스택 (Protocol stack) 전체는 아직 확립되지 않았죠.

DJ 렌:

Hermes의 업데이트도 같은 흐름입니다.

Hermes는 로컬/퍼스널 에이전트 기반으로서,

• Mac 없이 iMessage 액세스
• 공유 워크스페이스에서 외부 에이전트로서 Raft 통합
• 나아가 Windows나 Linux의 데스크톱 GUI를
  임의의 모델로 조작 가능

하게 만드는 확장을 보여주었습니다.

DJ 미오:

게다가 리포지토리(Repository)의 스타(Star) 수가 20만을 넘어섰습니다.

이것은 개발자들의 관심이 단순히 "베이스 모델의 질"뿐만 아니라, 에이전트 UX(User Experience) 및 하네스(Harness)의 사용 편의성에도 대량으로 향하고 있다는 증거지.

DJ 미오:

다음은 돈과 인프라 이야기. 이 부분도 상당히 커.

DJ 렌:

Baseten이 15억 달러 규모의 Series F를 조달한 건 상징적이었어.

Baseten과 CEO인 Amir Ghazvinian의 주장은 명확해. 기업들은 앞으로 자사의 지능 레이어(Intelligence Layer)를 소유하고 싶어 할 것이라는 점이야.

DJ 미오:

즉,

• 오픈 모델(Open Model)이나 특화 모델을 구동하고
• 자사 데이터와 자사 평가(Eval)로 포스트 트레이닝(Post-training)을 수행하며
• 지속 학습(Continual Learning)도 자사의 관리하에 두는

그런 방향이지.

DJ 렌:

고객사로는 Abridge, Cursor, Decagon, Harvey, Notion, OpenEvidence 등이 나열되어 있는데, 이는 이제 가설이 아니라 앱 기업의 능력으로서 현실화되고 있어.

DJ 미오:

이날의 전체 테마와 아주 깔끔하게 일치하네.

강력한 오픈 모델 + 이를 돌리기 위한 좋은 인프라가 갖춰지면서, 포스트 트레이닝이 "연구소만의 특수 기술"이 아니게 된 거야.

DJ 렌:

더 흥미로운 건, 연산 자원(Compute Resource) 리스 시장 자체가 전략 계층이 되고 있다는 점이야.

Reflection이 SpaceX와 63억 달러 규모의 연산 계약을 맺었다는 보도가 널리 논의되었지.

DJ 미오:

만약 이것이 사실이라면, GB300 액세스를 둘러싸고 GPU 중개나 네오 클라우드(Neo-cloud)의 존재감이 점점 더 커질 거야.

@jaminball은 SpaceX/xAI가 Anthropic이나 Google과도 큰 연산 계약을 맺고 있는 맥락 속에서,

• Blackwell 가격이
  1시간에 10달러 초과를 시사하며 -
  90일 내 해지 가능한 조항

등도 지적했어.

DJ 렌:

즉, AI 경쟁은

• 모델을 만드는 것
• 모델을 배포하는 것

뿐만 아니라,
누가 GPU 공급을 중개하고, 유연한 연산 계약을 따낼 수 있는가

라는 계층까지 확장되고 있어.

DJ 미오:

다음은 평가 이야기. 여기, 교육 프로그램으로서 상당히 중요합니다.

DJ 렌:

먼저, LLM-as-a-Judge에 대한 재점검.

@dair_ai가 21종의 Judge, 9개사, 약 54.1만 건의 판정을 대상으로 한 감사를 요약했는데, 중요한 포인트는 Exact Match(완전 일치)로 보면 판정 품질을 과대평가하게 된다는 것이었어.

DJ 미오:

Cohen’s kappa로 전환하면, MT-Bench에서의 일치도가 33~41포인트나 하락해서 Judge의 순위도 상당히 바뀌거든.

즉, "이 Judge 모델은 인간과 잘 일치한다"라는 주장 중 상당수가 측정 방식에 따라 무너질 가능성이 있다는 거지.

DJ 렌:

평가 기반으로서 Judge 모델을 사내에서 사용하고 있는 팀에게는 꽤 큰 경고야.

DJ 미오:

더 큰 흐름은, 에이전트는 챗봇으로서가 아니라 시스템으로서 평가하라는 거야.

Jules는 지향해야 할 모델이 "반응만 하는 에이전트"가 아니라, 인지하고, 앞서 나가며, 파트너가 되는 에이전트라고 말하고 있어.

DJ 렌:

@rseroter도 코딩 에이전트를 사용하는 것과 자율적인 코딩 하네스(Coding Harness)를 설계하는 것은 전혀 다르다고 강조하고 있지.

이날의 주요 토픽――GLM의 실제 하네스 검증, OpenAI Daybreak, Fugu 비판――를 봐도 초점은 전부

• 도구(Tool)
• 메모리(Memory)
• 검증(Verification)
• 장시간 실행(Long-running execution)

여기에 있어.

DJ 미오:

즉, "단발적인 일문일답에서 똑똑함"만으로는 불충분해.

지금 요구되는 것은 실제 워크플로우 속에서 무너지지 않고 가치를 낼 수 있는가인 거지.

DJ 렌:

여기서부터는 Reddit 이야기.

먼저 LocalLlama 커뮤니티에서는 역시 GLM-5.2가 뜨거워.

DJ 미오:

DeepSWE의 비용 대비 스코어 차트에서는 GLM-5.2 [max]가 44%, 평균 비용은 태스크당 3.92달러야.

GPT-5.x나 Claude 계열의 탑 모델에는 미치지 못하지만, 가격 대비 성능 면에서는 상당히 좋은 위치에 있어.

DJ 렌:

게다가 독자들의 반응이 흥미로워.

「체감상 Sonnet이나 Kimi보다 강력하게 느껴진다」, 「하지만 Opus 4.8이나 GPT-5.5에는 아직 미치지 못한다」라는 목소리가 있으며, 실제 체감과 벤치마크(Benchmark)가 크게 어긋나지 않고 있다.

DJ 미오:

그리고 무엇보다, “이것이 오픈 웨이트(Open weights)이며, 자체 호스팅(Self-hosting)이 가능하다”는 점이 크다.

토큰 단가는 사라지는 대신 하드웨어 비용과 운영 난도는 늘어나지만, 그 트레이드오프(Trade-off)를 고려하더라도 가치가 있다고 여겨지고 있다.

DJ 렌:

한편으로는 도표를 보여주는 방식에 대한 비판도 있었다.

비용 축이 반전되어 0이 오른쪽에 있는 등, 시각적으로 오해를 불러일으킨다는 지적이다.

이런 세세한 그래프 설계도 기술 토론에서는 의외로 중요하다.

DJ 렌:

다음은 상당히 “DIY 정신”이 넘치는 이야기.

어떤 사용자가 RTX 3090 4장, DDR5 192GB의 컨슈머(Consumer)급 PC를 약 6,000달러로 조립하여, GLM-5.2를 로컬(Local)에서 운용하고 있다는 보고다.

DJ 미오:

Linux에서 각 GPU를 **200W로 전력 제한(Power cap)**하는 동시에, RAM을 5200에서 5600 MT/s로 오버클럭(OC).

용도로는,

• GLM 5.2를 플래너(Planner)로 사용 시
  약 7 tok/s
• MiniMax 2.7을 코딩용으로 사용 시
  약 45 tok/s
• Qwen3.6 27B q8를 확인 및 테스트용으로 사용 시
  약 50 tok/s
• Flux2Klein으로 2GPU 배치(Batch) 시
  6초에 1장 정도

와 같은 운용 방식이다.

DJ 렌:

댓글란에서는,

• 어떤 양자화(Quantization)를 사용했는지
• MiniMax M3가 아니라 왜 2.7인지
• 메인보드는 무엇인지
• 4GPU 연결에 라이저(Riser)나 PCIe 분기가 필요한지
• 쿨링은 어떻게 하고 있는지

등, 상당히 실무적인 질문들이 쏟아졌다.

DJ 미오:

이런 부분은 로컬 LLM(Large Language Model) 업계가 정말 “연구”와 “자작 PC 문화”가 섞여 있는 것 같다.

DJ 미오:

다음은 로컬파에게 피할 수 없는 이야기, 토크노믹스(Tokenomics).

DJ 렌:

어떤 게시물에서는, 예를 들어 2만 달러의 하드웨어로 20 tok/s를 낸다고 가정했을 때, GLM-5.2 API 가격(입력 1.40달러 / 출력 4.40달러당 100만 토큰 정도)과 비교하면 손익분기점까지 5.5년이 걸린다는 추산이 나왔다.

DJ 미오:

하지만 댓글에서는 “숫자의 근거가 모호하다”, “전제가 적절하지 않다”라며 상당한 반박을 받았다.

게다가 논점은 단순한 토큰 단가가 아니었다.

DJ 렌:

맞다. 로컬 운용의 의의로 언급된 것은,

• 프라이버시(Privacy)
• 중단되지 않는 것
• 자유로운 제어
• 취미성
• 파인튜닝(Fine-tuning) 및 실험
• 고가동 SME(중소기업) 용도

등이다.

클라우드는 배치(Batch)를 통해 높은 가동률을 실현할 수 있기 때문에, 단순한 비용 싸움에서는 유리해지기 쉽다.

DJ 미오:

하지만 로컬 측에도,

• 하드웨어는 매각 가치가 남는다
• API 요금은 사용하면 사라진다
• API 가격이 미래에도 같으리라는 보장이 없다

라는 반론이 있다.

따라서 결론적으로는, **“싸니까 로컬을 쓰는 것”이 아니라, “필요한 제어와 지속성을 원하기 때문에 로컬을 쓰는 것”**에 가깝다.

DJ 렌:

다음은 상당히 실전적이다.

llama.cpp를 위한 로컬 추론 최적화 가이드가 화제가 되고 있는데, 내용은 다음과 같다.

• VRAM 피팅(Fitting)
• KV-cache의 크기와 양자화(-ctk / -ctv q8_0)
• 플래시 어텐션(Flash Attention)
• MoE(Mixture of Experts)의 레이어 배치
• MTP / 투기적 디코딩(Speculative decoding)
• CPU 및 P-core 튜닝
• XMP/EXPO
• OOM(Out of Memory) 및 로드 실패 대처

등이다.

DJ 미오:

특히 댓글에서 중요했던 것은, 멀티모달(Multimodal) 특유의 함정이다.

비전(Vision) 계열의 경우,

• mmproj는 로드 시 연속된 VRAM이 필요함
• --fit-target을 너무 과하게 설정하면 추론 시가 아니라 로드 시에 오류가 발생함
• 이미지가 수백 토큰에 달하므로, --ubatch-size가 이미지 토큰 수보다 작으면 어서트(Assert) 오류가 발생함

이라는 이야기다.

DJ 렌:

즉, 단순히 텍스트 모델을 돌리는 것과는 달리, 멀티모달에서는 메모리 단편화나 배치 설정이 더욱 까다롭다.

DJ 미오:

벤치마크 환경도 공유되었는데, RTX 4070 12GB, i5-12600K, DDR5-6000 32GB라는 꽤 현실적인 구성이었다.

한편 「문장이 AI 같아서 읽기 어렵다」라는 불만도 있어서, 내용은 유용하지만 가독성 문제는 남아있는 듯하다.

DJ 렌:

그리고 ik_llama.cpp에 대한 표현이 부정확하지 않느냐는 기술적 지적도 있었습니다.

"아직 upstream 되지 않았다"가 아니라, 애초에 공식 llama.cpp에 들어갈 전제가 아니다라는 이해가 더 가깝다는 이야기죠.

DJ 미오:

다음은 Gemma 4의 QAT와 KV 캐시 (KV cache) 양자화 이야기.

WikiText 16k 문맥에서 Gemma 4 26B에 대해, KV 캐시 (KV cache) 양자화 시의 KL 발산 (KL divergence)이 비교되었는데, **QAT 모델 쪽이 상당히 견고하다 (robust)**는 결과가 나왔어.

DJ 렌:

비 QAT 버전에서는 99.9% KLD가

18.815 / 17.256 / 14.576

였던 것에 반해, QAT 버전에서는

4.409 / 3.436 / 2.385

까지 떨어져.

즉, Q8_0 KV cache가 다시 현실적이 될 수도 있다는 시사야.

DJ 미오:

다만 댓글에서는,

• 그 KLD가 실제 운용상 무엇을 의미하는지 알기 어렵다
• 재현용 코드가 필요하다
• 24GB GPU로 시도해보고 싶다

같은 반응도 있었어.

DJ 렌:

게다가 반례도 있어서, Gemma 31B의 비전 태스크 (vision task)에서는 q8 KV cache가 bf16보다 나빴다는 보고도 있어.

그러니까 이것은, 모든 태스크와 모든 모델에 보편적인 개선은 아닐 가능성이 높아.

DJ 미오:

"QAT의 부작용으로 KV 양자화 내성이 높아진 것 아니냐"는 시각도 있었고, QAT Gemma 자체에 알려진 문제가 있는 것 아니냐는 우려도 남아 있었지.

DJ 렌:

나아가, RTX 5090 32GB에서 Qwopus3.6 27B v2 MTP를 구동하는 LM Studio 구성에 대한 보고도 있었습니다.

문맥 길이는 약 16만 토큰 (tokens), GPU 오프로드 (offload)와 KV cache offload, Flash Attention, VRAM 한계치 설정이었죠.

DJ 미오:

여기서의 실무적인 결론은 흥미로운데, 로컬 LLM에서는

• 거대한 "영웅 프롬프트 (hero prompt)" 한 방보다는
• 작게 나눈 태스크
• 체크포인트 (checkpoint)
• 단계별 진행
• rules/skills 파일의 지속적인 관리

가 더 잘 통한다는 이야기야.

DJ 렌:

굉장히 에이전트 (agent) 운용 방식이네요.

또한, Q5_1의 V-cache 양자화나, Evaluation Batch Size / Physical Batch Size를 2~4배로 늘려 속도를 높이는 제안도 있었습니다.

다만 LM Studio 상에서의 결과는, 개선되는 부분도 있지만 만만치 않다는 느낌이야.

DJ 미오:

그리고 마지막에는 심플하게 "llama.cpp를 쓰면 되잖아?"라는 댓글도 있어서, 로컬 커뮤니티의 정석 같은 느낌이 들었어.

DJ 미오:

다음은 하드웨어 마니아라면 참을 수 없는 이야기.

중국의 한 하드웨어 모더 (modder)가 NVIDIA Tesla V100의 패키지/기판 인터페이스인 2963핀을 1년에 걸쳐 분석하여, 단일 슬롯 하프 하이트 (half-height) 형태의 "Tesla V100 v4" 기판으로 재구성했다는 이야기야.

DJ 렌:

게다가 NVLink 대응이라서 8-way 구성도 염두에 두고 있다고 합니다.

가격도 충격적인데,

• 16GB 버전이 1499 RMB (약 220달러)
• 32GB 버전이 3999 RMB (약 590달러)
• NVLink 어댑터가 2-way용 199 RMB, 8-way용 799 RMB

등입니다.

DJ 미오:

댓글에서는 32GB 카드 4장을 NVLink로 연결해 128GB HBM 같은 꿈 같은 구성을 기대하는 목소리가 많았어.

게다가 MCIO 스타일의 연결로 4-GPU 간 100 GB/s급이라는 이야기도 나오고 있어.

DJ 렌:

다만 최대의 문제는 신뢰성입니다.

중고 V100의 BGA 재작업(rework)에서는 인접한 HBM을 손상시킬 리스크가 높습니다.

그러므로 정말 중요한 것은 수율, 장기 안정성, 그리고 보증의 신뢰성입니다.

DJ 미오:

그리고 "정말로 클린룸 수준의 리버스 엔지니어링 (reverse engineering)이야? 기존의 PCB 파일이 유통되고 있었던 거 아니야?"라는 의구심도 있었지.

하지만 그럼에도 소형화와 재구현을 해낸 작업 능력에 놀라워하는 목소리는 컸어.

DJ 렌:

또 하나는, 유럽의 DDR5 가격 트래킹입니다.

25일간의 관측 결과, 독일, 네덜란드, 스페인, 벨기에 등에서 상당히 하락했다는 보고입니다.

DJ 미오:

예를 들면,

• G.Skill DDR5 Aegis 2x16GB 6000: 579→419유로
• Kingston FURY Beast RGB 2x16GB 6000: 499→369유로
• G.Skill Trident Z Neo 2x32GB 6000: 1200→927유로

와 같이, 20~30%에 가까운 하락입니다.

DJ 렌:

특히 동일 EAN(European Article Number)인 G.Skill Trident Z5 RGB 2x32GB DDR5-6400이,

독일의 NBB에서 799유로,

네덜란드의 Megekko/Azerty에서 1180유로,

라는 상당히 큰 가격 차이가 소개되었습니다.

DJ 미오:

게시자는 로컬 LLM (Local LLM) 입문용으로는, DDR5-6000 2x16GB가 스위트 스팟 (Sweet Spot)이 되어가고 있다고 말하고 있습니다.

DJ 렌:

반면, 미국의 registered/server DDR5는 반대로 급등하여, 64GB DDR5-4800 RDIMM이 1530달러에서 1800달러로 올랐다는 이야기도 있습니다.

즉, EU 소비자용 DDR5는 하락하고 있지만, 서버용은 그렇지 않다는 것입니다.

DJ 미오:

게다가 댓글에서는 "시스템 RAM에 의존한다면, 오래된 DDR4 워크스테이션이 더 저렴하고 빠를 수도 있다"라는 논쟁도 있었습니다.

예를 들어 6채널의 오래된 Xeon DDR4-2400이, 듀얼 채널 DDR5-7000보다 실효 대역폭 (Effective Bandwidth) 면에서 이기는 케이스도 있을 수 있다고 합니다.