순위와 함께 남겨두고 싶은 것은 모델을 고르고 실행 환경을 구성하는 과정에서 했던 고민이다. 큰 모델을 쓰면 좋을 것 같았지만, 실제로 실행하려면 GPU 메모리와 처리 시간, 입력 형식과 평가 방법부터 살펴봐야 했다.

이 글은 9월 21~22일의 고민메모를 바탕으로 정리한 준비·환경 검증 회고다. 순위는 Public Leaderboard 기준이다. 최종 제출 모델, 정확한 점수, 방법별 성능 개선 수치는 이 글에 포함하지 않았다. 아래에서 검토한 학습·앙상블 전략이 최종 제출에 적용되었다는 뜻은 아니다.

1. 먼저 정리해야 했던 것은 평가 방식이었다

이미지와 질문을 받는다고 해서 곧바로 모델 학습부터 시작할 수 있는 것은 아니었다. 모델마다 이미지 전처리를 맡는 processor와 대화 입력 형식이 달랐고, 질문과 선택지를 어떻게 전달하고 답을 어떻게 읽어낼지부터 맞춰야 했다.

초반에 확인하려 했던 항목은 다음과 같다.

• 이미지와 질문을 모델 입력으로 구성하는 방식
• chat template과 정답 label의 형식
• 네 선택지에 대한 출력과 평가 스크립트의 일관성
• 작은 모델로 먼저 입력·출력 흐름을 확인하는 방법

처음부터 가장 큰 모델을 실행하기보다, 작은 기준 모델로 입력과 평가 과정을 먼저 확인한 뒤 확장하는 순서로 계획을 잡았다.

2. 큰 모델을 먼저 쓸 것인가

H100과 RTX 5060 Ti 환경을 고려하면서, 처음부터 큰 모델에 집중할지 고민했다. 메모에 남긴 방향은 7~9B 규모를 기준선으로 두고, 성능·VRAM·시간을 측정한 뒤 더 큰 모델과 QLoRA를 검토하는 것이었다.

이때 모델 선택 기준을 단순한 파라미터 수로만 잡을 수는 없었다. 같은 모델이라도 이미지 해상도와 배치 크기, 양자화 방식에 따라 실행 조건이 달라질 수 있기 때문이다.

내가 세운 실험 순서는 데이터와 평가 확인 → baseline → QLoRA 검토 → 앙상블 검토였다. GRPO는 우선순위를 뒤로 두었다. 이 순서는 당시의 계획이며, 각 단계를 모두 완료했다는 의미는 아니다.

3. GPU 세 대의 메모리를 어떻게 활용할 것인가

분산 환경에서 고민한 장비는 RTX 5060 Ti 16GB 세 대였다. 처음 부딪힌 질문은 세 대를 연결하면 큰 모델을 바로 올릴 수 있는지였다.

여기서 DDP와 모델 샤딩을 구분해야 했다. DDP는 일반적으로 각 GPU에 모델을 복제해 데이터를 나누어 처리한다. 따라서 GPU가 세 대라고 해서 한 모델이 사용할 수 있는 메모리가 자동으로 48GB가 되는 것은 아니다. 큰 모델의 메모리를 나누려면 FSDP나 ZeRO 같은 별도 전략을 검토해야 한다. PyTorch DDP 문서, FSDP 문서

학습에서는 파라미터·그래디언트·옵티마이저 상태를 어떻게 나눌지, 추론에서는 모델을 어떻게 배치할지 따로 생각해야 했다. GPU 개수를 늘리는 것과 내가 필요한 실행 방식을 만드는 것은 서로 다른 작업이었다.

4. 먼저 확인한 결과: NCCL 통신

9월 22일 기록에서 실제로 확인한 것은 세 노드 사이의 기본 GPU 통신이다. 노드별 PyTorch·CUDA·NCCL 버전을 맞추고 all_reduce 결과를 확인했다.

초기에는 GPU lost 상태가 발생했지만 재부팅 후 복구되었다. 이후 결과를 통해 기본 NCCL 통신이 동작하는 것을 확인했다.

다만 통신이 된다는 것과 큰 모델의 분산 학습이 성공했다는 것은 다르다. 메모에는 다음 단계로 작은 모델의 샤딩과 forward, 짧은 학습, 체크포인트 저장·재개를 검증하는 계획이 남아 있다. 이 글에서는 그 후속 실험의 완료 여부까지 주장하지 않는다.

5. 이미지 보정과 앙상블을 검토한 이유

이미지 보정이 VQA에 도움이 될지도 고민했다. 원본, 약한 밝기 조정, 약한 어둡기 조정, 밝기 채널 CLAHE를 각각 독립적으로 추론하고 선택지 확률을 결합하는 방안을 정리했다.

이때 주의하려 했던 점은 보정이 항상 좋은 방향으로 작용하지는 않는다는 것이었다. 밝기를 바꾸는 과정에서 정답에 필요한 시각 단서가 달라질 수 있다. 그래서 다음과 같은 평가 방안을 설계했다.

1. 빠른 검증용 데이터에서 보정 강도와 결합 가중치를 탐색한다.
2. 최종 후보를 탐색에 사용하지 않은 별도 검증셋에서 확인한다.
3. 원본과 보정별 선택지 점수를 저장해, 가중치를 바꿀 때 재추론 비용을 줄인다.

앙상블도 같은 모델의 양자화 버전을 늘리는 데서 끝내기보다, 다른 모델이나 프롬프트가 서로의 오류를 보완하는지 확인하려 했다. 이 내용은 평가 방안과 검토 사항이다. 실제 정확도가 얼마나 올랐는지를 보여주는 실험 결과는 현재 기록에 없다.

6. 내가 맡은 작업과 확인한 범위

이번 기록에서 정리할 수 있는 내 작업은 세 가지다.

• 실행 환경 구성과 검증: 세 노드의 환경을 맞추고 NCCL 통신 결과 확인
• 모델 실행 전략 검토: 메모리와 시간을 고려한 모델 규모·양자화·분산 방식 검토
• 평가 방안 설계: 이미지 보정별 점수 결합, 별도 검증셋, 캐시를 활용한 TTA·앙상블 검토

대회의 결과는 Public Leaderboard 2위다. 하지만 순위만으로 위 작업 각각의 기여도를 설명할 수는 없다. 어떤 방법이 얼마나 도움이 되었는지를 말하려면 기준 모델과 변경 후 결과, 동일한 검증 조건이 필요하다.

7. 다음에는 실험 기록을 더 구체적으로 남기고 싶다

고민메모에는 선택 이유와 다음 계획은 남아 있지만, 최종 제출 구성을 재현할 만큼의 결과는 정리되어 있지 않다. 회고를 쓰면서 이 차이가 드러났다.

다음 대회에서는 각 실험에 모델·입력 해상도·양자화·검증셋·점수·시간·최대 메모리 사용량을 함께 남기고 싶다. 계획과 실행 결과도 구분해서 적으려고 한다. 그래야 시도한 방법과 실제로 도움이 된 방법을 나중에 다시 구분할 수 있다.

이번 대회는 모델 선택만큼이나, 모델이 실행되는 환경과 결과를 확인하는 과정에 많은 판단이 필요했던 경험이었다. 다음에는 그 판단을 재현 가능한 실험 기록으로 남기는 데 더 신경 쓰고 싶다.