Model Showdown: Benchmarking Local vs Cloud LLMs on a Real Coding Task

개요

로컬 LLM이 실제 코딩 작업에서 클라우드 LLM만큼 정확하고 빠른지 여부를 벤치마킹하기 위해 Python CLI Todo 앱 개발을 기준으로 Sonnet, Opus, Codestral, DeepSeek R1, Devstral, Qwen 모델의 성능과 품질을 비교했습니다.

주요 내용

• 벤치마크 설정: Six 모델 (클라우드: Sonnet 4.6, Opus 4.6; 로컬: Codestral 22B, DeepSeek R1 14B, Devstral, Qwen 3.5B MoE)과 하나의 프롬프트 (SQLite 지속성, CRUD 기능, 타임스탬프, 오류 처리 등을 갖춘 Python CLI Todo 앱 개발)를 사용했습니다.
• 측정 항목: 첫 토큰까지의 시간 (TTFT), 총 생성 시간, 출력 토큰 수, 초당 토큰 수, 그리고 생성된 코드의 구문 유효성, 기능 충족도, 실제 기능 테스트 통과 여부를 측정했습니다.
• 성능 결과: Devstral이 총 생성 시간에서 가장 빨랐으며 (10.26초), Qwen 3.5B는 초당 토큰 수에서 월등히 높았습니다 (1,510.2 tok/s). 클라우드 모델인 Sonnet 4.6은 TTFT가 가장 빨랐습니다 (0.87초).
• 품질 결과: Sonnet 4.6, Opus 4.6, Devstral 세 모델이 완벽한 점수 (100/100)를 받았습니다. Codestral 22B와 DeepSeek R1은 기능은 충족했지만 CLI 인자 파싱 대신 인터랙티브 입력을 가정하여 자동화 테스트를 통과하지 못했습니다. Qwen 3.5B는 토큰 제한으로 인해 코드가 중간에 잘려 구문 오류가 발생했습니다.
• 주요 문제점:
• 인터랙티브 메뉴 문제: Codestral 22B와 DeepSeek R1은 "명령"을 인터랙티브 메뉴로 해석하여 CLI 인자 파싱 대신 input()을 사용했습니다.
• 토큰 제한 트랩: Qwen 3.5B는 MoE 아키텍처로 인해 빠른 속도를 보였으나, 4,096 토큰 제한에 걸려 코드 생성이 중단되었습니다.
• DeepSeek R1의 사고 과정: <think> 블록에 많은 토큰을 사용하여 문제 해결 과정을 기록했으나, 단순한 코드 생성 작업에는 비효율적이었습니다.
• Devstral의 강점: Mistral에서 개발한 코딩 특화 모델로, 빠른 TTFT, 뛰어난 총 생성 시간, 완벽한 품질 점수를 보여주며 클라우드 모델과 견줄 만한 성능을 입증했습니다.
• 코드 비교: 완벽 점수를 받은 세 모델 (Sonnet, Opus, Devstral)은 모두 CLI 인자 기반 패턴을 사용했으나, Sonnet은 클래스 기반 디자인과 풍부한 기능, Opus는 sys.argv 파싱과 오류 처리, Devstral은 간결한 함수 기반 디자인을 사용했습니다.
• 속도 분석: TTFT는 클라우드 모델이 우세했지만, 로컬 모델은 일단 로드되면 빠른 토큰 처리 속도를 보여주었습니다. Devstral은 응답성과 생성 속도, 품질의 균형을 잘 맞췄습니다.
• 최종 판결: 프로덕션 코딩 작업에는 Sonnet 4.6 또는 Devstral이 적합하며, Devstral은 API 비용 없이 동일한 품질과 속도를 제공합니다.
• 향후 계획: 더 복잡한 멀티 파일 프로젝트, 테스트 포함, 모호한 요구사항을 가진 작업으로 Round 2 벤치마크를 수행할 예정이며, Kimi K2.6과 Gemma 4 모델을 추가로 테스트할 계획입니다.

시사점

로컬 LLM은 더 이상 타협점이 아니라, 특히 Devstral과 같은 모델의 등장으로 인해 프로덕션 코딩 작업에서 클라우드 LLM과 동등하거나 더 나은 선택지가 될 수 있으며, 프롬프트의 명확성과 설정이 모델 성능에 중요한 영향을 미칩니다.