검수된 문제
BigCodeBench 148, BIRD 140, FinanceReasoning 224개다.
ELI5 · 우리 실험의 vLLM
쉽게 말하면 질문 상자를 모델에게 차례로 전달하고, 답을 빠짐없이 받아 적는 컨베이어 벨트다. 생각하고 답하는 주체는 HyperCLOVA X·Llama·Qwen·EXAONE 같은 모델이다.
vLLM은 같은 모델에 여러 요청을 묶어 전달하고 GPU 메모리를 관리한다.
결과는 JSONL로 저장되고, 벤치마크별 채점기(evaluator)가 정답 여부를 확인한다.
지금 적용하는 흐름
번역과 MIX 문장은 이미 고정돼 있다. vLLM 단계에서는 문장을 다시 고치지 않는다. 같은 문제 세트를 각 오픈소스 모델에 넣고, 나온 답을 저장하는 일만 맡는다.
BigCodeBench 148, BIRD 140, FinanceReasoning 224개다.
EN, KO, C12만 바꾼 MIX1, C3만 바꾼 MIX2, 둘 다 바꾼 MIX3다.
Hugging Face 모델 하나를 GPU에 올리고, 요청을 chunk 단위로 처리한다.
코드는 실행 테스트, SQL은 execution accuracy, 금융은 생성한 Python 결과로 확인한다.
세 역할 구분
vLLM과 모델을 같은 것으로 보면 설정의 의미가 헷갈린다. 셋은 서로 다른 역할이다.
HyperCLOVA X, Llama, Qwen, EXAONE이 실제로 코드·SQL·계산 프로그램을 생성한다.
바꾸면: 비교할 모델이 달라진다.
모델 로드, GPU 메모리, batch 처리, chat template 적용, 출력 수집을 담당한다.
바꿔도: 같은 모델 자체가 더 똑똑해지는 것은 아니다.
생성된 코드나 SQL을 실행하고, 기대한 결과와 맞는지 benchmark 규칙으로 채점한다.
바꾸면: 점수의 의미가 달라질 수 있다.
현재 고정한 설정
decoding 설정은 모델이 답을 고르는 방식이다. chunk나 GPU 메모리 설정은 실행 속도와 안정성에 관한 값이다. 둘을 구분해야 결과를 잘못 해석하지 않는다.
한 줄 요약: temperature=0은 답을 일정하게 만들기 위한 설정이고, chunk_size=32는 일을 여러 개 묶어서 빨리 처리하기 위한 설정이다.
temperature=0
sampling 없이 greedy 방식으로 한 번 생성한다.
n=1 · seed 고정
조건마다 답 하나만 받고, 가능한 한 같은 실행을 재현한다.
BF16
AWQ 양자화본 대신 원본 checkpoint를 GPU에 올릴 때 쓰는 숫자 정밀도다.
chunk=5 / 32
smoke는 한 샘플의 5조건을 함께 확인하고, 작은 모델 full run은 32개씩 처리한다.
GPU memory=0.85
vLLM이 GPU 메모리의 최대 85%를 쓰도록 잡아, 나머지는 실행 중 여유 공간으로 둔다.
heartbeat=20s
20초마다 살아 있다는 기록을 남긴다. chunk가 끝나면 출력과 중간 저장점(checkpoint)도 남긴다.
현재 확인된 실행 증거
HyperCLOVA X SEED 0.5B에서 세 태스크 한 문제씩, 각 5조건을 실행했다. 모두 정상 종료(STOP)했고 약 39초가 걸렸다. 이는 모델 성능 점수가 아니라, 입력부터 출력 저장까지 작동했다는 확인이다.
“모델명만 바꾸면 되나?”
입력·저장·채점 코드는 그대로 재사용한다. 다만 모델마다 Hugging Face revision, chat template, system preamble, context 길이, 라이선스, GPU 메모리 요구량이 다르다. 그래서 모델명과 함께 이 설정도 설정표(manifest)에 고정하고, 각 모델마다 smoke test를 먼저 통과시킨다.