Mano-CUA 2.0: 4B GUI 에이전트를 1년간 구축하며 발견한 병목 현상은 모델 크기가 아니었다

Mano-P는 저희가 작업해 온 오픈 소스 (open-source) 프로젝트입니다. 이 프로젝트는 MacBook에서 4B 파라미터 시각-언어 모델 (vision-language model)을 실행하며, 스크린샷을 관찰하여 컴퓨터를 제어합니다. 클릭, 타이핑, 단축키 사용 — 모델은 각 스크린샷을 보고 다음에 무엇을 할지 결정합니다. 모든 과정은 온디바이스 (on-device)에서 이루어지며, 클라우드 API 호출은 없습니다. 저희는 얼마 전 1.0 버전을 출시했고, 최근 100개의 실제 macOS GUI 작업 벤치마크 (benchmark)를 다시 실행하며 2.0 버전으로 반복 개선했습니다. 그 결과 중 일부는 저희를 놀라게 했습니다.

저희가 주로 4B 모델을 선택한 이유는 16GB MacBook의 메모리 제약 때문이었습니다. 범용 VL 모델들도 시도해 보았으나, 저희 벤치마크에서 약 39%의 점수를 기록했으며 중국어 입력 포커스, 비 브라우저 앱 지원, 긴 작업에서의 단계 제한 절단 (step-limit truncation) 등의 문제를 보였습니다. 일반적인 VL 능력과 GUI 에이전트 능력은 상당히 다른 것이라는 점이 드러났습니다. 내부적으로 MoE (Mixture of Experts)에 대해서도 논의했지만, 온디바이스 추론 (inference)은 연산 (compute) 중심보다는 메모리 제한 (memory-bound)적이며, MoE는 모든 전문가 가중치 (expert weights)를 메모리에 상주시켜야 합니다. 이는 Mac에서는 좋지 않은 거래입니다. 저희는 MLX를 유지했습니다. 이는 Apple Silicon의 통합 메모리 (unified memory)에 직접 매핑되며, 이 칩셋들에서 로컬 추론을 수행하기에 최상의 방법입니다.

이것이 배경입니다. 흥미로운 부분은 2.0에서 일어난 일입니다.

중국어 GUI 성능이 대폭 향상됨

저희는 4B 모델이 너무 작아서 GUI 에이전트를 잘 처리할 수 없다고 가정해 왔습니다. 하지만 2.0을 완성한 후, 그것이 핵심이 아니라는 것을 깨달았습니다. 첫 번째 진짜 병목 현상은 중국어 GUI 학습 데이터였습니다.

버전 1.0은 중국어 UI 요소 처리에 꽤 취약했습니다. 모델은 문자 수준의 인식 오류를 계속 범하며, 시각적으로 유사한 한자를 혼동하곤 했습니다. 이러한 실수들은 사소하게 들릴 수 있지만, GUI 에이전트에게는 치명적입니다. 버튼을 찾을 수 없다면, 그 이후의 모든 과정은 의미가 없기 때문입니다.

영어 인터페이스에서는 이런 문제가 없었습니다. "Settings"와 "Settinas"는 매우 다르게 보이니까요. 중국어는 다릅니다. 글자 간의 시각적 유사성이 더 높고, "确定"(확인)이나 "取消"(취소)와 같은 버튼들은 좁은 영역에 밀집된 획을 담고 있어 모델이 구별하기 더 어렵게 만듭니다. 당시 우리는 이것이 4B 모델의 용량 문제라고 생각했습니다. 중국어 글자가 영어 알파벳보다 그냥 더 어려워서, 작은 모델이 이를 처리하지 못하는 것이라고 말이죠.

2.0 버전에서 더 많은 중국어 GUI 학습 데이터를 추가한 결과, 사실이 아니라는 것이 밝혀졌습니다. 해결책은 거창한 것이 아니었습니다. 그저 학습 세트에서 중국어 인터페이스 스크린샷의 양을 늘리는 것이었습니다. 결과는 기업용 IM(Instant Messaging) 카테고리에서 즉각적으로 나타났습니다. 1.0 버전의 33%에서 2.0 버전의 83%로 상승했습니다. WeChat(위챗)은 33%에서 67%로 올랐습니다.

50%포인트 차이입니다. 돌이켜보면 1.0의 데이터 커버리지는 단순히 불충분했습니다. 이는 더 많은 데이터로 해결 가능한 문제였습니다. 아키텍처 변경도, 더 큰 모델도 필요하지 않았습니다. 병목 현상은 데이터에 있었는데, 우리는 모델 선정에 대해 너무 많은 시간을 소비하며 논쟁했습니다. 솔직히 말해서 조금 창피한 일입니다.

브라우저 작업 성능 저하

2.0 버전에서 브라우저 및 웹 작업 성능은 74%에서 68%로 떨어졌습니다. 이 문제가 내부적으로 제기되었을 때, 우리가 중국어 데이터를 과하게 넣은 것이 아닌지에 대한 논쟁이 있었습니다.

세부 내역을 살펴보면, 성능 저하는 영어 웹 요소 인식(web element recognition)에 집중되어 있었습니다. 중국어 웹 작업은 거의 변하지 않았습니다. 학습 혼합(training mix)을 중국어 쪽으로 재조정하면서, 모델의 영어 UI 요소에 대한 민감도가 약간 떨어졌습니다.

샘플 크기가 아주 크지는 않기 때문에, 이것이 실제 능력의 퇴보(regression)를 나타낸다고 생각하지는 않습니다. 하지만 이는 우리가 아직 해결하지 못한 문제, 즉 중국어와 영어 GUI 데이터 사이의 균형을 맞추는 문제를 드러냈습니다. 4B 모델은 용량이 제한적입니다. 너무 많은 것을 밀어 넣으면 서로 간섭이 일어납니다. 현재 우리는 중국어가 많아지면 영어가 적어지는 방식의 양적 제어(volume-based control)를 하고 있습니다. 이상적으로는 둘 다 충분해야 하겠지만, 이 정도 모델 크기에서는 그것이 달성 불가능한 과제입니다.

단기적으로는 단순히 언어에만 의존하는 대신, 작업 유형(task type)과 UI 복잡도(UI complexity)에 따라 가중치를 두는 더 세밀한 샘플링 전략(finer-grained sampling strategies)을 계획하고 있습니다. 이것이 효과가 있을지는 아직 확실하지 않습니다. 이를 수행하기 위해서는 충분한 여유 공간을 확보할 수 있는 더 큰 모델이 필요할 수도 있습니다.

장기 작업(Long-horizon tasks)은 여전히 30%에 머물러 있음

1.0과 2.0 모두 10단계 이상의 과정이 필요한 장기 작업(long-horizon tasks)에서 30%의 점수를 기록했습니다. 개선이 없었습니다. 앱 간 작업(Cross-app tasks)은 0%에서 20%로 상승하여, 5개 중 1개를 통과했습니다.

우리가 테스트한 결과에 따르면, 이는 4B 모델의 용량 제한(capacity constraint)에 더 가까워 보입니다. 10단계 이상의 작업은 전체 과정 동안 문맥(context)을 유지해야 하며, 각 단계의 결과가 다음 결정으로 올바르게 이어져야 합니다. 4B 모델의 작업 기억(working memory)은 제한적입니다. 10단계쯤 되면 모델은 이미 초반 몇 단계에서 무슨 일이 일어났는지 모호하게 인지합니다. 데이터만으로는 이 한계를 돌파할 방법을 찾지 못했습니다.

앱 간 작업(Cross-app)은 훨씬 더 어렵습니다. 누군가 WeChat으로 보낸 파일을 찾아 Finder로 전환하여 데스크톱에 저장하는 식입니다. 창을 한 번만 전환해도 4B 모델은 이전 문맥을 놓치는 경향이 있습니다. 더 큰 모델이 도움이 될 것으로 예상하지만, 아직 검증되지는 않았습니다.

내부적으로 우리는 두 가지 경로를 검토하고 있습니다. 하나는 4B 모델에 더 많은 추론 체인(reasoning-chain) 학습 데이터를 추가하여 어디까지 갈 수 있는지 확인하는 것입니다. 다른 하나는 64GB RAM을 탑재한 M5 Pro에서 실행 가능한 더 큰 모델(7B 또는 8B)을 구축하는 것입니다. 아직 결정하지 못했습니다. 솔직히 어떤 경로가 투자할 가치가 있는지 여전히 확신이 서지 않습니다.

Cider: 지연 시간(latency) 문제

위의 모든 내용은 모델의 능력에 관한 것입니다. Cider는 다른 문제를 해결합니다. 바로 사용자는 기다려주지 않는다는 점입니다.

GUI 에이전트는 독특한 성능 특성을 가집니다. 모든 동작 후에 새로운 스크린샷을 찍고 전체 이미지의 토큰(tokens)을 모델에 입력합니다. 이 프리필(prefill) 단계가 사용자가 기다려야 하는 시간을 직접적으로 결정합니다. M5 Pro에서 MLX의 네이티브 W8A16 모드를 사용하면 프리필에 2.839초가 소요됩니다.

2.8초가 별로 길게 느껴지지 않을 수도 있습니다. 하지만 10단계 작업 동안 매 단계마다 거의 3초씩 기다린다면 총 30초에 달하게 됩니다. 사용자들은 이를 매우 느리다고 느낍니다. 디코딩 속도(Decode speed)가 문제는 아닙니다. 동작 명령을 생성하는 데 80 tokens/s는 충분한 속도입니다.

문제는 MLX가 온라인 활성화 양자화 연산자(online activation quantization operators)를 제공하지 않는다는 점이었습니다. 가중치(Weights)는 정적이며 오프라인으로 양자화할 수 있습니다. 하지만 활성화(Activations)는 동적입니다. 모든 스크린샷은 네트워크를 통과할 때마다 서로 다른 중간값(intermediate values)을 생성합니다. MLX는 이 기능을 제공하지 않기 때문에, 저희가 직접 구현했습니다.

가장 까다로운 설계 결정은 양자화 입도(quantization granularity)였습니다. 입도가 너무 거칠면 이상치 활성화 값(outlier activation values)이 전체 정확도를 떨어뜨립니다. 반대로 너무 미세하면 연산 오버헤드(compute overhead)가 증가합니다. 저희는 토큰별 입도(per-token granularity)를 선택했습니다. 즉, 각 토큰의 활성화 벡터가 독립적으로 계산된 고유의 양자화 파라미터를 갖게 됩니다. 텐서별(per-tensor) 방식보다는 오버헤드가 크지만, 정확도 손실은 관리 가능한 수준으로 유지됩니다.

결과: W8A8 프리필(prefill) 시간이 2.839초에서 2.519초로 단축되어 약 12.7% 빨라졌습니다. 피크 메모리(Peak memory) 또한 감소했는데, 이는 사용자의 다른 애플리케이션과 메모리 상에서 공존해야 하는 GUI 에이전트에게 중요한 요소입니다. 정확한 메모리 절감량을 아직 측정하지는 못했습니다.

M5 칩은 하드웨어 가속을 지원하므로 개선 효과가 상당합니다. M4 이하 모델은 순수 Python으로 폴백(fall back)되어 속도 향상이 제한적입니다. M4에 특화된 최적화를 검토했으나, 투입되는 노력 대비 얻을 수 있는 이득이 크지 않다고 판단했습니다. Cider는 Mano-P 전용이 아니며, 모든 MLX 모델에서 사용할 수 있습니다.

향후 계획

모호한 설명(Fuzzy descriptions)과 앱 간 작업(cross-app tasks)이 가장 명확한 약점이며, 두 가지 모두 4B 모델의 추론 능력(reasoning capacity) 문제를 시사합니다. 따라서 더 큰 규모의 버전을 구축할 가능성이 높습니다. Cider는 안정성 및 호환성 작업을 계속 진행할 예정입니다.

전체 카테고리별 상세 분석은 아래와 같습니다. 테스트 하드웨어: MacBook Pro M5 16GB. 클라우드 모델: Claude Sonnet 4.5. 로컬 모델: Mano-CUA-4B W8A16.

카테고리	작업	1.0	2.0	클라우드
브라우저/웹	31	74%	68%	90%
...
https://github.com/Mininglamp-AI/Mano-P