지난주 이곳의 누군가가 에이전트(agentic) 작업에 있어 ThinkingCap과 Fable Fusion이 "정말로 오리지널(OG)을 이긴다"고 말했기에, 직접 테스트를 진행했습니다: 6개의 자기 평가(self-grading) 작업, 5회 반복, 3개의 모델, 총 90회의 독립적인 실행. 테스트 환경(Tooling)에 대해 설명하자면, 전체 과정의 절반을 차지하는 중요한 부분입니다. 각 실행은 제 k8s 클러스터 상의 새로운 Coder 워크스페이스에서 제가 매일 사용하는 하네스(harness)인 Hermes 에이전트를 헤드리스(headless)로 구동하여 진행되었습니다. 모델은 5090 한 장에서 llama-swap을 통해 llama.cpp로 서빙되었으며, 모든 모델 호출은 OTel 심(shim)을 통해 SigNoz로 추적되었고, 실행당 전체 트랜스크립트(transcript)를 보관했습니다. 모든 비교군에 대해 동일한 샘플링과 131k 컨텍스트를 적용했으며, 가설은 첫 실행 전에 사전 등록되었습니다. 모든 실행이 통과되었으므로, 통과율만으로는 승자를 가릴 수 없습니다. 비용 측면을 보면: ThinkingCap은 순정 모델보다 사고 토큰(thinking tokens)을 34% 적게 사용했으며 6개 작업 중 5개에서 가장 빨랐습니다. Fable는 동일한 결과를 내는 데 순정 모델보다 24% 더 많은 모델 호출을 수행했습니다. 그 후 90개의 트랜스크립트를 모두 읽게 했으며(1차로 AI 분석가가 읽고, 제가 원본 파일과 대조하여 주장을 검증), 여기서 흥미로운 결과가 나왔습니다. ThinkingCap의 효율성은 실재하지만 양봉형(bimodal) 분포를 보였습니다. 가장 성적이 좋았던 실행은 테스트 중 가장 저렴했지만, 가장 나빴던 두 번의 실행은 가장 비용이 많이 들었습니다. 그중 한 번은 순정 모델이 단 한 번의 API 호출로 처리할 유령 llama.cpp 릴리스 태그를 쫓느라 약 10번의 도구 호출(tool calls)을 낭비했습니다. 또한 ThinkingCap의 효율성은 행동 횟수를 줄이기보다는 추론 산문(reasoning prose)에서 나타났습니다. 도구 사용 횟수는 다른 모델과 동일했지만, 단어 수는 40% 적었습니다. Fable는 최고의 조사관이었지만 가장 신뢰할 수 없는 화자였습니다. 깨진 설정이 실제로 라이브 설정인지 확인한 유일한 모델이었으며, 최고의 조사 데이터를 추출해냈습니다(소매업체의 임베디드 JSON을 파싱하여 변형 가격을 확인하고, GitHub 사용자 API를 통해 llama-swap의 유지 관리자를 식별함). 하지만 한 실행에서 llama-swap의 유지 관리자가 "전 Red Hat 엔지니어인 Matthew Garrett"라고 작성했습니다. Garrett은 실존 인물(실제로는 mjg59, 전 Red Hat 소속)이지만 llama-swap과는 아무런 관련이 없습니다. llama-swap의 유지 관리자는 mostlygeek인 Benson Wong입니다. 모델은 두 명의 실제 신원을 결합하고 실제 리포지토리를 인용했음에도 불구하고, 평가기(grader)를 통과해 버렸습니다.

다른 실행(run)에서는 하나의 가격 질문에 94회의 도구 호출 (tool calls)을 사용했습니다. Stock은 가장 지루하면서도 가장 절제된 모습을 보였습니다. 균일한 패치 (uniform patches), 자신의 출력을 다시 읽기 (read its own output back), 조작된 사실 (invented facts) 제로, 그리고 태도 면에서 대부분의 작업을 승리했습니다. 저의 결론은 다음과 같습니다: 베이스 모델 (base model)이 기본값으로 유지됩니다. 파인튜닝 (Finetunes) 모델들은 대개 그들의 베이스 모델보다 나은 모습을 보여주지 못하며, 90회의 실행 결과도 저에게는 그 사실을 바꾸지 못했습니다. ThinkingCap은 사고 토큰 지연 시간 (thinking-token latency)이 병목 현상인 경우에만 살펴볼 가치가 있습니다. 레인 설정 (lane configs), 평가 설계 (eval design), 그리고 작업별 트랜스크립트 분석 (per-task transcript analysis)을 포함한 전체 보고서는 다음에서 확인할 수 있습니다: https://kmarble.dev/posts/qwen-post-train-bakeoff/ . /u/IvGranite에 의해 제출됨 [link] [comments]