10개 코딩 에이전트와 하나의 Qwen 3.8 27B, 동일한 llama-server 사용: 통과율보다 토큰 및 캐시 재사용률의 차이가 더 크다

제 에이전트 테스트 파트 2입니다 (파트 1은 4B 모델을 사용했습니다).

사용한 하드웨어: MacBook Pro M5 Max, 64 GB. Qwen 3.8 27B Q4를 llama.cpp에서 사용하여 사고(thinking) 과정을 확인했습니다. 모든 사람에게 동일한 모델과 서버를 설정했습니다.

설정: 작은 코딩 작업 5가지로 구성되었으며, 각 작업에는 약간의 함정이 포함되어 있었습니다. 각 에이전트는 샌드박스에 격리되어 자체 폴더만 건드릴 수 있고 모델과만 대화할 수 있도록 제한되었습니다. 자동 승인(auto-approve)은 켜고, 원격 측정(telemetry)은 껐으며, 시간 제한은 5분으로 설정했습니다.

결과:

토큰 및 캐시:
Pi는 매우 효율적이어서, 모든 작업에서 개당 약 9k 토큰으로 가장 적게 사용했습니다. Qwen Code가 에이전트 중 가장 많은 토큰을 사용하여 작업당 약 108k에 달했습니다.

Atomic Agent는 작동 방식 면에서 독특합니다. 이 에이전트는 도구 호출(tool calls)을 형태로 강제하는 문법을 가진 llama.cpp의 네이티브 엔드포인트와 유일하게 통신했습니다. 나머지 아홉 개는 모두 OpenAI 스타일 API를 거쳤습니다. 또한, 프롬프트를 단계별로 동일하게 유지하도록 설계되어 있어 캐시의 86% (10개 중 2번째)를 재사용할 수 있었습니다. 이 에이전트는 전체 시간 동안 오프라인 상태를 유지했으며 5/5를 달성했습니다.

DeepSeek Harness는 놀라웠습니다. 아직 알파 버전이지만, 5/5를 기록했고 온라인에 접속을 시도한 적이 없었으며, Atomic Agent 다음으로 최고의 캐시 재사용률을 보였습니다.

함정과 네트워크:
The 로그 작업에는 세 개의 에이전트가 투입되었습니다. 이들은 'ERROR'를 검색했지만, 일반 라인에서도 오류를 언급하기 때문에 64개 대신 244개를 얻었습니다. Codex, Cline, goose, OpenCode는 원격 측정(telemetry)을 꺼 놓았음에도 불구하고 매번 실행에서 인터넷에 접속하려고 시도했습니다. 샌드박스가 이를 차단했기 때문에, 무엇을 호출하고 있었는지 알 수 없습니다. OpenClaw와 Qwen Code가 '불분명'한 이유는 일반 노드로 실행되었고 제가 그들을 구분할 수 없었기 때문입니다.

llama.cpp 관련 내용: Codex는 이제 llama-server의 /v1/responses가 필요하며, Hermes는 최소 64K 컨텍스트(context)를 요구합니다. Cline과 Qwen Code는 기본적으로 사용 통계(usage stats) 기능을 활성화하고 있고, DeepSeek Harness는 세션 로그를 업로드합니다 (자료에 따르면). 저는 이 모든 것을 꺼버렸습니다. Qwen 3.8 27B와 같은 로컬 모델을 위해 에이전트를 선택할 때 어떤 항목(열)이 가장 중요합니까? 통과율(passing), 속도(speed), 토큰(tokens), 아니면 오프라인 유지 여부(staying offline)? /u/latent_lurker8587 님이 제출함 [link] [comments]