로컬 Qwen 27B에서 코딩 하네스 9종 비교, OpenCode 첫 응답 226초·Chad 26초
- M4 MacBook Pro 24GB에서 3비트 양자화 Qwen 3.8 27B를 구동해 8개 Exercism 과제, 총 24회로 비교했을 때 OpenCode의 첫 토큰 대기 시간은 225.7초, Chad의 llama.cpp 모드는 25.6초였음
- 하네스의 시스템 프롬프트와 도구 스키마가 첫 요청 지연을 좌우했으며, OpenCode는 18,046토큰을 읽어야 했고 pi는 2,008토큰이었음. 초당 90토큰 prefill 환경에서 저자는 각각 226초와 22초를 측정했음
- 32,000토큰 정도의 로컬 컨텍스트 예산에서 pi는 초기 프롬프트 뒤 94%를 작업에 남긴 반면, OpenCode는 18,046토큰을 써서 44%만 남았음
- OpenCode는 24개 작업 중 세션 제목과 요약 같은 부가 요청을 33회, crush는 51회 보내며 에이전트 턴과 거의 항상 겹쳤음. 단일 GPU에서 OpenCode와 crush의 모델 바쁨 시간은 실제 경과 시간의 각각 125%, 114%였음
- 통과율은 난도가 낮은 Python Exercism 과제라 순위로 해석하지 말아야 하며, Chad llama.cpp는 24/24를 통과했고 goose는 22/24, OpenCode는 15/24였음
Hacker News 의견들
chad가 흥미로워 보여도 AI가 쓴 마크다운과 거대한 커밋을 보니 읽을 마음이 사라졌음. 코드가 바이브 코딩이어도 사람이 읽을 문서만큼은 직접 썼으면 함
32GB RAM 노트북에서 llama.cpp로 ls를 물으면 거의 바로 단어당 1개 정도로 답하는데, 같은 계열 모델로 opencode에 작업 디렉터리를 물으니 응답까지 20분 걸렸음
opencode도 시스템 프롬프트가 길지만 oh-my-pi의 긴 프롬프트는 2023년 LLM이 환각한 쓰레기처럼 보이더라
밤마다 수치가 최대 50% 퍼진다거나 lean harness 사이 차이는 결론이 아니라는 문장이 무슨 뜻인지 모르겠음. 측정했다고 말하기보다 데이터를 보여줬어야 함
노트북이나 작은 VPS, 싱글보드 컴퓨터용이라면 hax도 볼 만함. 동적 링크된 네이티브 C 바이너리가 0.7MB이고, 실행 RAM은 수 MB이며, 실행 중인 llama-server 설정을 자동 발견하고 프롬프트와 도구도 작게 유지함
나도 JS 런타임 의존성이 싫어서 clm을 만들었는데 비슷한 방향임. Solaris와 ESP32도 지원하니 협업해볼 만함
이런 용도로 maki.sh를 만들었음
로컬 모델은 안 쓰지만 내 워크로드에서 codex, pi, omp를 비교했더니 codex가 pi와 omp보다 빠르고 토큰도 적게 썼음. pi가 더 빠르거나 싼 경우는 하나도 없었음
harness가 계속 바뀌니 이런 평가는 자주 다시 해야 함. 누구나 자기 하드웨어에서 전 harness를 돌려 프리픽스 토큰, 첫 토큰 시간, 체감 tok/s, prefill, 캐시 재사용률, 작은 결정적 과제의 통과율을 비교하는 재현 가능한 저장소가 있으면 좋겠음