엔비디아, RTX PC와 DGX 스파크에서 로컬 AI 에이전트 ‘헤르메스’ 가속

로컬 AI 에이전트 판이 하드웨어 싸움으로 넘어가는 중

• 엔비디아가 RTX PC, RTX PRO 워크스테이션, DGX 스파크에서 누스 리서치의 AI 에이전트 ‘헤르메스’를 로컬로 지원한다고 밝힘

  • 헤르메스는 특정 벤더나 모델에 묶이지 않는 구조를 내세우고, 로컬에서 24시간 켜져 있는 에이전트를 목표로 함
  • 엔비디아가 강조하는 포인트는 명확함. “이런 에이전트는 결국 GPU 성능과 메모리빨을 탄다”는 얘기임

• 헤르메스는 출시 3개월도 안 돼 깃허브 스타 14만 개를 넘긴 에이전트로 소개됨

  • 오픈라우터 기준으로는 지난주 전 세계에서 가장 많이 사용된 에이전트였다고 함
  • 오픈클로 이후 오픈소스 에이전틱 프레임워크를 커뮤니티가 빠르게 받아들이는 흐름에 올라탄 셈

• 헤르메스의 차별점은 “한 번 답하고 끝”이 아니라 계속 돌아가는 로컬 작업자에 가깝다는 점임

  • 메시징 앱과 연동하고, 로컬 파일과 애플리케이션에 접근하고, 24시간 실행되는 구조를 전제로 함
  • 단순 래퍼(wrapper)가 아니라 작업을 나누고 조율하는 능동형 오케스트레이션 계층이라고 설명됨

헤르메스가 내세우는 4가지 포인트

• 첫 번째는 자체 진화 기술임

  • 복잡한 작업을 수행하거나 피드백을 받을 때마다 결과를 기술(skill) 형태로 저장함
  • 시간이 지날수록 같은 유형의 작업에 더 잘 적응하는 구조를 노림

• 두 번째는 독립형 서브 에이전트임

  • 하위 작업마다 짧게 살아 있는 작업자를 만들고, 각 작업자에게 필요한 컨텍스트와 도구만 줌
  • 이 방식은 전체 컨텍스트 윈도우를 크게 잡지 않아도 되니 로컬 모델 환경에 특히 유리함

• 세 번째는 안정성임

  • 누스 리서치는 헤르메스에 포함된 기술, 도구, 플러그인을 검증하고 스트레스 테스트한다고 밝힘
  • 기사에서는 300억 파라미터급 로컬 모델에서도 안정적으로 작동한다고 소개함

• 네 번째는 같은 모델을 써도 프레임워크에 따라 결과가 달라진다는 주장임

  • 여러 프레임워크에서 동일 모델을 비교했을 때 헤르메스가 일관적으로 더 나은 성능을 냈다고 함
  • 결국 LLM 자체만이 아니라, 작업 분해와 도구 호출을 어떻게 오케스트레이션하느냐가 품질 차이를 만든다는 얘기임

큐웬 3.6과 RTX 조합이 미는 숫자들

• 알리바바의 큐웬 3.6은 로컬 에이전트 실행에 최적화된 오픈 웨이트 LLM 시리즈로 소개됨

  • 큐웬 3.6 27B와 35B가 이전 세대의 120B, 400B급 모델보다 나은 성능을 낸다고 주장됨
  • 작은 모델이 더 큰 모델을 이긴다는 메시지는 로컬 AI 쪽에서 꽤 큰 떡밥임. 메모리 요구량이 바로 비용이기 때문임

• 큐웬 3.6 35B는 약 20GB 메모리만으로 70GB 이상이 필요한 120B 파라미터 모델을 넘는 성능을 제공한다고 함

  • 이 수치가 사실이라면 고급 소비자용 GPU나 워크스테이션에서도 꽤 현실적인 로컬 에이전트 구성이 가능해짐
  • 큐웬 3.6 27B는 큐웬 3.5 397B 같은 400B급 모델 정확도를 16분의 1 크기로 제공한다고 소개됨

• 엔비디아는 RTX GPU의 텐서 코어가 이런 워크로드에서 처리량과 지연 시간을 낮춘다고 강조함

  • 헤르메스가 다단계 작업을 수행하거나 자체 기술을 개선하는 작업을 몇 초 안에 끝낼 수 있다는 설명이 붙음
  • RTX PRO GPU는 라마.cpp에서 큐웬 3.6 모델 실행 시 최대 3배 빠른 토큰 생성 속도를 제공한다고 함

DGX 스파크는 ‘상시 실행 에이전트 박스’ 포지션

• DGX 스파크는 하루 종일 돌아가는 에이전틱 워크플로우용 소형 독립 시스템으로 소개됨

  • 128GB 통합 메모리와 1페타플롭급 AI 성능을 갖췄다고 함
  • 120B 파라미터 규모의 전문가형 혼합(Mixture-of-Experts, MoE) 모델을 상시 실행할 수 있는 장비로 포지셔닝됨

• 엔비디아가 말하는 사용 시나리오는 꽤 직접적임

  • 개인 사용자는 로컬 AI 애호가처럼 자신의 PC에서 에이전트를 계속 돌릴 수 있음
  • 개발자는 워크플로우 자동화용 로컬 툴링을 만들고, 클라우드 API 의존도를 낮출 수 있음

• 실행 경로도 익숙한 로컬 LLM 생태계를 탄다고 설명됨

  • 헤르메스 깃허브 저장소에서 시작해 원하는 로컬 모델과 런타임을 연결하는 방식임
  • 라마.cpp, LM 스튜디오, 올라마를 통해 큐웬 3.6과 함께 실행할 수 있고, 헤르메스는 LM 스튜디오와 올라마를 기본 지원함

RTX AI PC 업데이트도 같이 쏟아짐

• 구글 젬마 4 26B와 31B 모델은 NVFP4 체크포인트로 제공돼 블랙웰 GPU에서 더 빠르게 돈다고 소개됨

  • 멀티 토큰 프리딕션 드래프터와 결합하면 동일한 출력 품질에서 최대 3배 빠른 추론 속도를 제공한다고 함

• 미스트랄 미디엄 3.5는 라마.cpp와 올라마 호환성 업데이트가 포함됨

  • RTX PRO와 DGX 스파크 시스템에서 실행할 수 있는 쪽으로 로컬 배포 경로를 맞춘 셈

• 엔비디아는 오픈클로 환경 최적화를 위한 오픈소스 스택 ‘네모클로’도 공개함

  • 보안성과 로컬 모델 지원을 강화하고, WSL2도 지원해 윈도우 개발자에게도 열려 있다고 설명됨

---

기술 맥락

• 이번 얘기의 핵심은 LLM을 어디서 돌릴 거냐예요. 클라우드 API로 에이전트를 만들면 시작은 쉽지만, 로컬 파일과 앱을 오래 붙잡고 작업하는 구조에서는 지연 시간, 비용, 권한 관리 문제가 계속 따라오거든요.

• 헤르메스가 서브 에이전트를 쪼개는 이유도 로컬 실행 제약 때문이에요. 큰 컨텍스트 하나에 모든 걸 밀어 넣으면 메모리와 추론 비용이 커지니, 하위 작업자에게 필요한 도구와 문맥만 주는 방식이 더 현실적이에요.

• 큐웬 3.6 35B가 약 20GB 메모리로 더 큰 모델을 대체한다는 메시지는 개발자 입장에서 꽤 중요해요. 로컬 AI에서는 파라미터 수보다 실제로 내 장비에서 응답 가능한 속도로 도는지가 제품 경험을 가르거든요.

• DGX 스파크의 128GB 통합 메모리와 1페타플롭급 성능은 개인용 챗봇보다 팀 내부 자동화나 상시 실행 에이전트를 겨냥한 숫자에 가까워요. 에이전트가 하루 종일 파일을 읽고 작업을 나누고 다시 실행하려면, 순간 처리량보다 지속 실행 안정성이 더 중요해져요.