dohaii040603 님의 블로그

1. LLM 서비스에서 스케줄링이 곧 제품 품질이 되는 이유대규모 언어 모델을 서비스 환경에 올리는 순간, 모델의 성능은 더 이상 파라미터 수나 벤치마크 점수로만 설명되지 않는다. 실제 사용자가 체감하는 품질은 응답의 정확성 못지않게 지연시간과 안정성에 의해 결정된다. 특히 피크 트래픽이 몰리는 순간, 모델의 추론 능력보다 더 중요한 것은 요청을 어떻게 받아들이고, 어떤 순서로 처리하며, 어떤 요청을 먼저 밀어 넣고 어떤 요청을 잠시 보류할 것인가를 판단하는 스케줄링 전략이다. 이 지점에서 큐 구조는 단순한 대기열이 아니라, 서비스 품질을 결정하는 핵심 인프라가 된다.LLM은 일반적인 웹 요청과 다르게 추론 시간이 길고 자원 소모가 크다. 동일한 API 호출이라도 토큰 길이, 컨텍스트 크기, 모델 종류에..

1. 평가셋이 망가지는 순간은 ‘정답’을 믿기 시작할 때다대부분의 평가셋은 처음부터 선한 의도로 만들어진다. 모델이 잘 작동하는지 확인하고, 이전 버전과 비교하며, 품질이 나아졌는지 판단하기 위해서다. 그러나 시간이 지나면 평가셋은 이상한 권위를 갖게 된다. 점수가 오르면 “좋아졌다”고 말하고, 점수가 떨어지면 “나빠졌다”고 단정하는 기준이 된다. 이때부터 평가셋은 도구가 아니라 판사가 된다. 그리고 바로 이 지점에서 평가셋은 제품을 망가뜨리기 시작한다.문제의 핵심은 평가셋이 ‘정답’을 담고 있다고 믿는 태도다. 많은 팀이 평가셋의 레이블을 현실의 정답으로 간주한다. 하지만 실제 제품 환경에서 정답은 거의 존재하지 않는다. 사용자의 질문은 모호하고, 기대는 사람마다 다르며, 맥락은 매 순간 바뀐다. 그럼..

1. 모델 드리프트는 왜 항상 ‘늦게’ 발견되는가모델 드리프트는 대부분 문제가 이미 발생한 뒤에야 인식된다. 사용자 불만이 늘어나거나, KPI가 서서히 하락하거나, 특정 기능의 신뢰도가 떨어졌다는 정성적 신호가 먼저 등장한다. 그리고 나서야 “혹시 모델이 변한 것 아닐까”라는 질문이 뒤따른다. 이 순서는 거의 모든 조직에서 반복된다. 이유는 단순하다. 모델 드리프트를 **사건(event)**으로 보기 때문이다. 무엇인가 크게 어긋났을 때 감지해야 할 예외 상황으로 인식하는 순간, 드리프트는 항상 늦게 발견될 수밖에 없다.실제로 모델 드리프트는 갑작스럽게 폭발하지 않는다. 대부분 아주 미세한 변화로 시작한다. 입력 분포가 조금 달라지고, 사용자 행동이 서서히 변하며, 외부 환경이 천천히 이동한다. 이 변화..