벤치마크에서 이긴 설정이 실전에서는 오히려 손해였던 이유를 추적했고, 별도로 진행 중이던 통계 경보 하나도 최종 종결했습니다
로컬 대형모델로 100종목을 10시간 안에 처리하기
최근 들인 여분 그래픽카드와 기존 메인 카드를 같이 써서, 오픈소스 대형 언어모델 하나를 로컬에서 종목분석 파이프라인에 얹어보는 실험을 오늘 하루 종일 진행했습니다.
이 모델은 전체 파라미터는 크지만 실제 추론에 쓰이는 활성 파라미터는 훨씬 작은 구조(MoE)입니다. 목표는 "100개 종목을 10시간 안에 처리"였습니다.
요청을 하나씩 순차로 처리하면 목표보다 40% 넘게 오래 걸렸습니다. 여러 요청을 동시에 처리하면 빨라질 거라 기대했는데, 실제로는 오히려 느려지거나 아예 응답이 멈추는 현상이 나타났습니다.
처음엔 이 실패를 "일시적인 네트워크 오류"로 넘겼습니다. AI에게 시스템 로그 분석을 맡겨보니, 실제로는 그래픽카드 자체가 멈춰버리는 하드웨어급 오류였다는 게 드러났습니다. 이후로는 이 오류가 재현되지 않는 안전한 범위 안에서만 동시처리 실험을 이어갔습니다.
별도 벤치마크로 확인해보니 동시처리 엔진 자체에는 문제가 없었습니다. 진짜 병목은 두 가지였습니다. 프롬프트를 미리 읽는 단계가 순번을 오래 차지해 다른 요청의 처리를 정체시키는 것, 그리고 대화가 길어질수록 메모리 참조 범위가 계속 늘어나 느려지는 구조였습니다.
가장 유망해 보였던 방법은 계산의 일부(전문가 계층)를 통째로 보조 그래픽카드로 옮기는 방식이었습니다. 단일 요청 벤치마크에서는 확실히 더 빨랐고, 요청이 길어질수록 이득도 커졌습니다.
그런데 실제로 여러 요청을 동시에 넣는 상황으로 재검증하니 정반대 결과가 나왔습니다. 벤치마크에서 이겼던 설정이 실전에서는 오히려 더 느렸습니다.
AI에게 원인 진단을 다시 맡겼습니다. 순수 디코딩 속도는 여전히 이 방식이 더 빨랐지만, 프롬프트를 미리 읽는 구간에서는 정반대로 손해를 보고 있었습니다. 두 그래픽카드를 오가는 전환이 훨씬 잦아진 데다, 여러 요청을 겹쳐 처리하는 최적화 자체가 이 방식에서는 통째로 꺼져 있었습니다.
결국 이 방식은 완전히 폐기하고, 원래 쓰던 단순한 방식(계산을 층 단위로 나눠 두 카드에 고르게 배분)이 최선이라는 결론으로 되돌아왔습니다.
대신 다른 축에서 개선을 찾았습니다. 여러 종목을 처리할 때 프롬프트 앞부분을 공유하도록 순서를 재배치하는 패치와, 모델이 불필요하게 장황하게 답하지 않도록 유도하는 패치를 적용해 처리시간을 줄였습니다.
다만 이 패치가 실제 종목 등급 판정 자체에 영향을 주는지, 아니면 원래도 있던 표본 변동성인지는 아직 구분이 안 돼서 판정을 보류했습니다.
모델 압축(양자화) 수준도 따로 검토했습니다. 지금 쓰는 압축 단계가 다소 공격적이라는 점은 확인했습니다. 다만 품질을 더 높인 단계로 가면 용량이 그래픽카드 메모리를 넘어서서 오히려 크게 느려진다는 것도 함께 확인해, 그 단계로는 넘어가지 않기로 했습니다. 중간 단계 하나를 받아서 소규모로 대조해보기로 했습니다.
하루 끝 결론은 이렇습니다. 서버 설정만으로 짜낼 수 있는 최선까지는 도달했고, 목표(10시간)에 꽤 가까워졌지만 아직 살짝 못 미칩니다. 남은 격차를 메우려면 코드 쪽을 더 손봐야 하는데, 이건 별도 승인을 받은 뒤 진행하기로 했습니다.
통계 경보 하나, 재론 끝에 최종 종결
며칠째 재론 중이던 통계 이상신호 하나를 오늘 마무리 지었습니다.
최근 쓰는 모델을 바꾸면서 하룻밤에 나오는 비교 표본 자체가 예전보다 늘었습니다. 그런데 경보가 울리는 문턱값은 예전 절대 건수 기준 그대로 남아 있었습니다.
그래서 실제로는 이상이 없어도 문턱을 쉽게 넘어 경보가 울리는 구조였습니다. 비율 기준으로 다시 계산해보니, 평소 수준과 통계적으로 구분이 안 되는 수준이었습니다.
이번 건은 조치 없이 종결했습니다. 앞으로는 절대 건수 대신 비율 기준으로 경보 문턱을 다시 정의해서 적용하기로 했습니다.
이 조사 과정에서 부수적으로 관측 전용 트랙(정보계수 측정용)의 버그 두 건도 함께 발견해 고쳤습니다. 실거래 로직과는 무관한 경로라 이번 판정 자체에는 영향이 없었습니다.
그 외 마무리된 일들
며칠 전 메인보드를 교체하고 재부팅하는 과정에서 시스템 시계가 잠깐 과거로 잘못 설정됐다가, 시간 서버가 바로잡는 순간 "이미 지나간 일정을 아직 안 지난 걸로" 착각해 정기 재훈련이 예정에 없던 날 잘못 발동한 사고가 있었습니다.
오늘 이 사고의 뒷수습으로 재훈련 파이프라인에 안전장치 두 가지를 추가했습니다. 정해진 시점이 아니면 실제 배포 대신 시험모드로 자동 강등시키는 장치, 그리고 마지막 배포로부터 너무 짧은 간격이면 배포 자체를 보류하는 장치입니다.
여분 그래픽카드의 전력 제한값도 팬 소음 문제로 낮춰 재조정했고, 이 카드에서 두 가지 구동 방식을 최종 대조한 결과 기존 방식이 더 빨라 그대로 채택을 확정했습니다.
최근 하드웨어를 통째로 교체한 사실이 문서에 반영되면서, 예전 하드웨어에 대해 내려뒀던 판정 몇 건은 전제 자체가 사라져 무효 처리됐습니다.
Top comments (0)