내일의 요청 수를 예측할 때는 ‘나중에 채워진 데이터’와 ‘예측할 때 이미 알던 데이터’를 구분해야 합니다. Mistral의 Timestral은 과거에만 있는 보조 변수와 미래까지 알려진 보조 변수를 따로 받습니다. 작은 팀이 먼저 할 일은 모델을 바꾸는 것보다, 각 입력을 언제 알 수 있었는지 적는 것입니다. 미래의 실제 CPU 사용률을 넣은 좋은 점수는 내일 운영에 쓸 수 있는 예측 성능이 아닐 수 있습니다.
확인: 2026년 10월 16일 UTC. 공식 문서와 공개 소스를 검토한 도입 해설입니다. 모델 설치·다운로드·추론·성능 시험은 하지 않았습니다. 아래 날짜와 서비스는 설명을 위한 가상 사례이고, 비교 절차는 실행 결과가 아닌 제안입니다.
Timestral은 어떤 프로젝트인가요?
Mistral은 10월 15일 Timestral을 발표했습니다. 채팅 모델이 아니라 여러 수치 시계열의 미래 값을 확률적으로 예측하는 모델 계열입니다. 공식 추론 저장소와 모델 가중치가 공개돼 있습니다. 요청 수나 작업 큐 유입량을 예측해 운영자가 용량 계획을 검토하는 용도를 생각할 수 있지만, 이 글에서 그런 효과를 측정한 것은 아닙니다.
공식 모델 문서의 상태는 Timestral 1.0 Public Preview입니다. 검토한 코드 커밋은 10월 15일의 a534bdb이며, 소스 패키지 버전은 1.0.0, 선언된 요구 조건은 Python 3.10 이상과 PyTorch 2.4 이상입니다. 확인 시점에 별도 GitHub Release는 없었습니다. 이 번호를 운영 안정성 검증이나 실행 확인으로 해석하지는 않습니다.
10월 16일 08:36 UTC 공식 GitHub API에서 확인한 별은 누적 130개입니다. 최근 증가량은 검증하지 못했으므로 ‘급성장’이라고 부르지 않겠습니다. 공개 개발자 토론에는 활용처에 관한 질문이 있습니다. 이는 초기 관심의 근거이지 정확도나 실제 도입의 증거는 아닙니다. 여기서는 순위보다 작은 팀이 바로 구분할 수 있는 입력 문제에 집중합니다.
예측 기준 시각을 먼저 고정하세요
가상의 API 서비스에서 2026년 10월 16일 00:00 UTC에, 그날 00:00부터 24:00 전까지의 시간별 요청 수를 예측한다고 하겠습니다. 이미 끝난 10월 15일까지를 과거 구간으로 사용합니다. 각 시간 칸의 집계가 언제 끝나는지와 로그 수집 지연도 함께 정해야 합니다. 00:00에 아직 도착하지 않은 전날 로그까지 즉시 사용할 수 있다고 가정하면 실제 운영과 달라집니다.
이때 입력 후보를 다음처럼 나눌 수 있습니다.
- 요일과 시간대: 예측 기준 시각에 앞으로의 값을 계산할 수 있습니다. 과거와 미래 구간을 같은 UTC 기준으로 만들면 미래 보조 변수 후보가 됩니다.
- 배포 예정 여부: 00:00에 저장해 둔 일정에 한해서 미래 입력 후보입니다. 오후에 취소되거나 새로 잡힌 일정을 과거 실험에 소급해 넣으면 다른 정보 조건의 실험이 됩니다.
- CPU 사용률과 지연 시간: 예측 시각까지 수집된 값은 과거 입력 후보입니다. 10월 16일에 실제로 관측된 값은 아직 모르므로 그날의 미래 입력으로 넣을 수 없습니다.
- 예측 대상인 요청 수: 과거 요청 수는 입력 이력이며, 10월 16일 실제 요청 수는 나중에 예측과 비교할 정답입니다. 미래 입력에 복사하지 않습니다.
파일에 열이 존재한다는 사실만으로 그 열을 사용할 수 있는 것은 아닙니다. 작은 팀이라면 입력마다 ‘값이 가리키는 시각’과 ‘그 값을 확보한 시각’을 구분해 보관하세요. 배포 일정도 최신 표 하나만 남기면 당시 알고 있던 계획을 재현하기 어렵습니다. 이는 Timestral의 결함을 지적하는 것이 아니라, 호출자가 정해야 하는 데이터 준비 기준입니다.
모델의 입력 모양 검사는 정보의 출처까지 검사하지 않습니다
공식 입력 설명에서 과거 구간의 길이를 T, 예측 길이를 H라고 할 때, past_covariates는 T 구간이고 known_covariates는 T+H 구간입니다. 위 사례의 시간별 하루 예측이라면 H는 24입니다. 보조 변수는 예측 대상에 조건을 제공하는 입력이며, 그 보조 변수 자체를 자동으로 예측해 채워 주는 기능은 아닙니다.
공개 구현은 입력 길이와 배열 모양을 확인합니다. 하지만 T+H 크기의 배열에 넣은 CPU 값이 당시의 전망치인지, 나중에 얻은 실제 관측치인지를 배열 모양만으로 알아낼 수는 없습니다. 모델 내부에서 보조 변수가 예측 대상을 읽지 않도록 설계했다는 설명도 호출자의 미래 정보 혼입까지 막아 준다는 뜻은 아닙니다.
앞으로의 CPU 값을 별도 모델로 예측해 넣고 싶다면, 그것은 또 하나의 예측 단계를 추가하는 설계입니다. 과거 실험에서도 각 기준 시각에 만들 수 있었던 CPU 예측을 사용하고, 그 오차까지 포함해 전체 절차를 평가해야 합니다. 실측 CPU를 대신 넣고 두 단계 시스템의 성능이라고 보고하면 안 됩니다.
작은 비교 실험은 세 갈래로 나누면 됩니다
처음부터 실서비스의 자동 증설과 연결하지 말고, 저장된 비민감 집계 자료로 다음 비교를 설계할 수 있습니다. 아래는 권장 절차이며 이 글에서 수행한 시험이 아닙니다.
- 기준선: 같은 요일의 같은 시간 등 서비스의 주기를 반영한 단순 예측을 정합니다. 예를 들어 일주일 전 같은 시간의 요청 수를 사용할 수 있습니다. 휴일이나 구조 변화에 잘 맞는다는 보장은 없으므로 이 역시 비교 대상입니다.
- 목표 이력만 사용: Timestral에 과거 요청 수만 제공하는 경우를 둡니다.
- 당시 알던 보조 변수 추가: 같은 기준 시각과 같은 정답 구간에, 그때 저장된 달력·배포 계획과 사용 가능한 과거 지표만 더합니다.
시간 순서를 지키는 예측 평가처럼 여러 과거 날짜를 차례로 예측 기준 시각으로 옮기되, 각 시각 뒤의 실제 값은 평가 때만 열어 봅니다. 세 경우에 평가 날짜, 집계 간격, 누락 처리와 데이터 도착 조건을 맞추세요. 과거의 일정 사본이나 입력 확보 시각을 복원할 수 없다면, 그 보조 변수는 과거 비교에서 제외하거나 지금부터 실제 기준 시각의 입력과 예측을 기록하는 관찰 운용을 시작하세요. 보조 변수를 추가한 결과가 나아지지 않으면 준비·보관 비용이 더 낮은 방식을 유지할 이유가 있습니다. 공개 벤치마크의 우수한 결과가 이 서비스의 배포 일정 효과를 대신 입증하지는 않습니다.
분위수 예측의 포함 비율을 확인하는 평가와 마찬가지로 Timestral의 분위수 출력도 별도로 평가해야 합니다. 예를 들어 높은 분위수를 용량 계획 후보로 쓰려면 실제 요청 수가 그 선을 얼마나 자주 넘는지, 초과와 과잉 확보의 비용이 무엇인지 확인하세요. 분위수가 정렬돼 있다는 사실만으로 특정 서비스에서 원하는 포함 비율이 달성됐다고 말할 수는 없습니다. 검증 전에는 기존 용량 정책을 유지하고 예측을 참고 화면에만 표시하는 방식으로 시작할 수 있습니다.
라이선스와 운영 범위도 함께 정하세요
추론 코드는 Apache-2.0이지만 모델 가중치는 별도의 Modified MIT 조건을 사용합니다. 해당 가중치 라이선스에는 회사나 고용주의 전월 전 세계 연결 월매출이 미화 2천만 달러를 초과하는 경우 권리 행사에서 제외하는 조건과 별도 상업 라이선스 연락 안내가 있습니다. 일반 MIT와 같다고 가정하지 말고, 도입할 모델과 조직에 적용되는 원문을 확인해야 합니다.
공식 저장소는 CPU와 GPU 추론을 안내하지만, 이 글은 메모리 사용량이나 지연 시간을 측정하지 않았습니다. 모델 파일 크기만으로 필요한 메모리를 판단하지 마세요. 최초 가중치 다운로드, 코드와 가중치의 서로 다른 버전 고정, 집계 데이터 보관과 반복 추론의 자원 비용도 운영 준비에 포함됩니다. 검증 실패 시에는 새 입력 구성을 되돌리고 기존 단순 예측과 운영 정책으로 돌아갈 수 있게 비교 결과와 당시 입력 사본을 남겨 두세요.
도입 전 가장 먼저 물을 질문은 ‘이 열을 예측 시각에 알고 있었나?’입니다. 미래 입력을 더 많이 넣는 것보다, 실제 운영에서도 같은 정보를 확보할 수 있는 예측을 만드는 편이 중요합니다.
댓글
댓글 쓰기