Holo3.1 - Fast and Local Computer Use Agents

T. Wu, P.-L. Cedoz, R. Riochet, A. Loison, et al., "Holo3.1: Fast and Local Computer Use Agents," H Company, Hugging Face Blog, 2026. https://huggingface.co/blog/Hcompany/holo31

H Company가 2026년 6월 2일 Holo3.1을 공개했습니다. 화면을 보고 클릭하고 입력하는 컴퓨터 유즈 에이전트인데, 핵심은 이걸 클라우드가 아니라 내 기기에서 돌린다는 점입니다. 4-bit 양자화를 쓰면 12GB VRAM짜리 GPU에서도 에이전트 스택 전체가 돌아가고, RTX 4090에서는 화면 인식부터 행동까지가 140ms 안에 끝납니다. 이번 글은 arXiv 논문이 아니라 H Company의 모델 릴리스 블로그와 모델 카드를 출처로 합니다.

저자

H Company는 파리의 AI 에이전트 스타트업입니다. 2024년 유럽 최대 규모의 시드 라운드를 유치했고, Runner H에 이어 오픈 웨이트 컴퓨터 유즈 VLM인 Holo 라인을 연속으로 내놓았습니다. Holo3.1의 모델링은 피에르루이 스도가 이끕니다. 스탠퍼드와 Google, BenevolentAI를 거쳐 H Company에서 Holo-1부터 Holo3까지 라인을 이어 온 연구자입니다.

이 팀이 Holo3.1에서 풀려던 문제는 성능 자체가 아니라 배포입니다. Holo3은 이미 OSWorld에서 데스크톱 컴퓨터 유즈 SOTA를 찍었습니다. 그런데 그 모델은 클라우드 API로 호출해야 했습니다. 화면을 캡처해 서버로 보내고, 모델이 클릭 좌표를 돌려주고, 그걸 다시 내 기기에서 실행하는 왕복이 매 스텝마다 일어납니다. 컴퓨터 유즈는 한 작업에 수십 스텝이 걸리므로 이 왕복 지연과 비용, 그리고 내 화면이 통째로 외부로 나간다는 프라이버시 문제가 누적됩니다. Holo3.1은 이 루프 전체를 기기 안으로 끌어들이는 데 초점을 맞춥니다.

배경

컴퓨터 유즈 에이전트는 화면 픽셀만 보고 사람처럼 GUI를 조작하는 모델입니다. API가 없는 앱이든 레거시 사내 시스템이든, 사람이 쓰는 화면 그대로를 클릭하고 입력해 작업을 끝냅니다. 이게 되려면 두 가지가 필요합니다. 화면 속 버튼·입력창을 좌표로 정확히 짚어내는 UI 그라운딩, 그리고 "다음에 무엇을 눌러야 목표에 가까워지는가"를 판단하는 추론입니다.

지금까지 강한 컴퓨터 유즈 모델은 거의 다 클라우드에 있었습니다. 모델이 크고, 화면 이미지를 매 스텝 처리해야 해서 추론 비용이 높기 때문입니다. 문제는 컴퓨터 유즈의 성격과 클라우드가 잘 안 맞는다는 점입니다. 한 작업이 수십 스텝이라 지연이 곱셈으로 쌓이고, 화면에는 비밀번호·문서·내부 데이터가 다 들어 있어 프라이버시 부담이 큽니다. Holo3.1이 메우려는 빈자리가 여기입니다. 작은 모델과 양자화로 추론 비용을 떨어뜨려, 강한 컴퓨터 유즈 에이전트를 처음으로 노트북 안에 집어넣습니다.

어떻게 만들었나

Holo3.1의 개선은 세 축으로 정리됩니다. 환경, 에이전트 프레임워크, 배포 타깃입니다.

첫째, 환경을 넓혔습니다. Holo3이 주로 웹과 데스크톱이었다면 Holo3.1은 모바일까지 다룹니다. AndroidWorld 같은 모바일 자동화 벤치마크가 정식 평가 대상에 들어왔습니다.

둘째, 에이전트 프레임워크 호환성입니다. Holo3은 구조화된 JSON 출력으로 행동을 내보냈는데, Holo3.1은 여기에 더해 함수 호출(function-calling) 프로토콜을 네이티브로 지원합니다. 덕분에 모델을 특정 하네스에 묶지 않고 일반적인 툴 호출 에이전트 안에 그대로 꽂을 수 있습니다. H Company는 함수 호출 실행과 네이티브 JSON 실행이 거의 동등한 성능(near-parity)을 낸다고 밝혔습니다.

셋째, 배포 타깃입니다. 이번 릴리스의 본진입니다. 모델을 0.8B, 4B, 9B, 35B-A3B 네 가지 크기로 냈습니다. 35B-A3B는 MoE 구조로, 전체 파라미터는 35B지만 토큰당 활성 파라미터는 약 3B입니다. 베이스는 Qwen3.5 패밀리이고, 라이선스는 Apache 2.0입니다(Qwen 계열). 그리고 프로덕션급 컴퓨터 유즈 모델로는 처음으로 FP8, NVFP4, Q4 GGUF 양자화 체크포인트를 함께 출하했습니다. 양자화 체크포인트가 있어야 일반 소비자 GPU나 맥북에서 모델이 메모리에 올라가고, 비로소 온디바이스 실행이 현실이 됩니다.

무엇으로 구성돼 있나

라인업은 두 가지 의미에서 넓습니다. 크기 스펙트럼과 정밀도 스펙트럼입니다.

크기는 0.8B부터 35B-A3B까지입니다. 0.8B는 초경량 로컬 에이전트용, 4B와 9B는 비용 효율과 프라이버시를 노린 중간급, 35B-A3B는 SOTA 성능용입니다. 같은 모델 패밀리 안에서 기기 사정에 맞게 골라 쓰라는 설계입니다.

정밀도는 BF16 풀프리시전 외에 세 가지 양자화가 있습니다. FP8, NVFP4(NVIDIA Model Optimizer 기반 W4A16), 그리고 llama.cpp용 Q4 GGUF입니다. NVFP4는 가중치 4비트·활성 16비트 구성으로, 정확도를 거의 지키면서 처리량을 끌어올리는 데 초점이 있습니다.

결과

먼저 35B-A3B를 경쟁 모델과 비교한 메인 결과입니다. 모든 수치는 H Company가 자사 하네스 기준으로 측정한 값이고, OSWorld 점수는 자체 구현 기준이라 공식 OSWorld-Verified 수치와는 약간 다를 수 있다고 밝혔습니다. 별표(*)는 원 출처에서 가져온 베이스라인입니다.

35B-A3B는 종합 78.3%로 Holo3(73.3%)을 5점 끌어올렸고, Qwen3.5 397B-A17B, Kimi-K2.5, Claude Sonnet 4.6을 모두 앞섭니다. 자기보다 10배 이상 큰 Qwen3.5 397B를 종합 점수로 이긴다는 점이 눈에 띕니다. 무너지는 곳은 Multi-Apps입니다. 여러 앱을 오가는 작업에서는 Claude Sonnet 4.6(69.0%)에 뒤지고, Collaboration에서는 전작 Holo3에 0.7점 밀립니다.

다음은 같은 Holo3.1 패밀리를 크기별로 본 표입니다. 작은 모델이 어디까지 따라오는지가 이번 릴리스의 진짜 관전 포인트입니다.

4B 모델이 OSWorld 75.8%로 35B-A3B(80.0%)에 4점 차로 붙고, 종합 72.6%로 Qwen3.5 397B(70.9%)를 넘습니다. 즉 4B 한 개로 자기보다 100배 큰 모델급 성능을 내면서 노트북에서 돌릴 수 있다는 뜻입니다. 다만 0.8B는 별개입니다. 단순 그라운딩(ScreenSpot-Pro 54.3%)은 어느 정도 하지만 Multi-Apps는 2.4%로, 긴 멀티스텝 작업은 사실상 못 합니다. 크기를 줄일수록 그라운딩보다 추론·계획 능력이 먼저 무너집니다.

양자화의 효과는 두 그래프로 드러납니다. 먼저 정밀도를 바꿨을 때 정확도와 처리량이 어떻게 거래되는지입니다.

DGX Spark에서 35B-A3B를 잰 결과, BF16은 OSWorld 80.0%에 326 tok/s, NVFP4(W4A16)는 77.8%에 568 tok/s입니다. 정확도를 약 2점 내주는 대신 토큰 처리량을 1.7배 넘게 끌어올립니다. 같은 정확도(77.8%)인 FP8(404 tok/s)과 비교해도 NVFP4가 더 빠릅니다. 4비트로 내려도 품질이 거의 그대로 유지된다는 것이 이 그래프의 핵심입니다.

이게 실제 에이전트 속도로는 어떻게 나타나는지를 보여주는 그래프입니다.

분당 모델 요청 수로 보면, DGX Spark에서 NVFP4(vLLM)는 13.5, 같은 환경의 FP8(vLLM)은 8.9입니다. 빠른 하네스(Fast harness)에서는 NVFP4가 18.1까지 올라갑니다. 맥북 M4 Pro에서 Q4(llama.cpp)는 3.6~5.5로 더 느린데, 이건 llama.cpp가 아직 Qwen 아키텍처의 prefix·이미지 캐싱을 지원하지 않아 처리량이 깎이기 때문이라고 H Company는 설명합니다. 종합하면 양자화와 하네스 최적화를 합쳐 평균 스텝 시간을 6.8초에서 3.3초로, 약 2배 줄였습니다.

회고

H Company가 직접 밝힌 한계가 둘 있습니다.

하나는 맥북에서의 추론 속도입니다. Q4 GGUF로 맥북 M4 Pro에서 돌릴 수는 있지만, llama.cpp가 Qwen 아키텍처의 prefix·이미지 캐싱을 아직 지원하지 않아 처리량이 떨어집니다. 즉 "맥북에서 돈다"와 "맥북에서 쾌적하게 돈다"는 아직 다릅니다. 빠른 온디바이스 경험은 당분간 NVIDIA 쪽 스택(vLLM, NVFP4)에 무게가 실립니다.

다른 하나는 모델을 줄였을 때 무너지는 지점입니다. 결과 표가 그대로 보여주듯, 작은 모델은 단순 그라운딩보다 멀티스텝 추론에서 먼저 한계를 드러냅니다. 0.8B의 Multi-Apps 2.4%가 단적인 예입니다. 온디바이스 에이전트를 쓰려면 작업 복잡도에 맞춰 크기를 신중히 골라야 합니다.

정리

• Holo3.1은 강한 컴퓨터 유즈 에이전트를 처음으로 기기 안에 넣었습니다. 4-bit 양자화로 12GB GPU에서 돌고, RTX 4090에서 140ms 지연을 냅니다.
• 4B 모델이 OSWorld 75.8%, 종합 72.6%로 100배 큰 Qwen3.5 397B를 넘습니다. 다만 0.8B는 멀티스텝 작업에서 한계가 분명합니다.
• 핵심은 FP8·NVFP4·Q4 GGUF 양자화 체크포인트입니다. 정확도를 약 2점 내주고 처리량을 1.7배 이상 얻어, 온디바이스 컴퓨터 유즈를 현실로 만듭니다.