Mistral의 Timestral: CPU에서 140ms 만에 예측하는 방법 및 Python 구현

Mistral의 새로운 예측 모델은 209M 개의 파라미터를 가지고 있으며, Mistral에 따르면 이 모델은 8스레드 서버 CPU 환경에서 15분 간격 데이터 하루치 예측을 단 140ms 만에 수행합니다. 모델 카드에 따르면 Timestral-209M은 TimesFM-3와 Chronos-2를 제치고 GIFT-Eval, TIME 및 fev-bench에서도 최고 성능을 기록했습니다. 이는 zero-shot 방식으로 작동하므로 별도의 학습 과정이 필요 없습니다. 시계열 데이터(series)만 입력하면 21개의 분위수(quantiles) 값을 얻을 수 있습니다. 현재 Prophet, ARIMA 또는 Chronos를 사용하는 사람이라면, 이러한 성능이 공급업체의 발표 자료에서 제시된 것과 일치하는지, 그리고 라이선스가 무엇을 허용하는지를 확인해 볼 필요가 있습니다.

저는 며칠 밤 동안 모델 카드(announcement), repo 및 라이선스를 살펴보았습니다. 아래 내용은 실제로 140ms CPU 수치가 무엇을 포함하는지, 그리고 이를 사용하여 CSV 파일을 예측하는 Python 코드 스니펫입니다. 출시 게시물에는 두 가지 내용이 빠져 있습니다: Moirai가 비교 대상에서 누락되었고, 라이선스에 2천만 달러(20M) 매출 조항이 포함되어 있다는 점입니다.

Timestral 사양: 컨텍스트 길이, 호라이즌, 크기

Timestral은 2026년 10월 15일에 출시되었으며, 하나의 아키텍처와 학습 방식을 공유하는 네 가지 크기(5M, 28M, 123M, 209M)로 제공됩니다. 이 수치들은 Hugging Face 모델 카드와 README에서 가져온 209M 체크포인트 기준입니다:

• GIFT-Eval MASE 기준으로, Timestral은 t0-gamma보다 0.003 낮고 TimesFM-3보다 0.009 낮습니다. 이는 사용자의 데이터에 따라 승자가 결정될 수 있는 범위 내의 차이입니다. Chronos-2와 Toto를 능가하는 마진은 더 크며 무시하기 어렵습니다.
• Toto-2.0은 2.5B 파라미터를 가지고 있으며, 모든 행에서 209M 모델보다 낮은 점수를 기록합니다. 추론 비용(inference cost)에 신경을 쓴다면 이 표의 가장 유용한 부분입니다.
• Moirai는 포함되어 있지 않습니다. 모델 카드에도 언급되지 않았고 발표에서도 언급되지 않았습니다. 만약 현재 Moirai를 사용한다면, GIFT-Eval 리더보드를 직접 확인하거나 백테스트(backtest)를 실행해야 할 것입니다.
• 이 모든 점수는 공급업체(vendor)-보고 점수입니다. 이 결과들은 GIFT-Eval 및 TIME 리더보드에 제출되었으며, 출시 다음 날 열린 레포의 두 번째 이슈는 [

가장 어려운 지연 시간(latency) 수치는 announcement에서 나온 것입니다. 이 발표에 따르면, "8 스레드를 가진 표준 서버 CPU"를 사용하여 3주 분량의 15분 간격 기록을 바탕으로 하루 앞을 예측하는 데 5M 모델은 10 ms가 걸렸고, 209M 모델은 140 ms가 걸린다고 합니다. README에는 "CPU 친화적: 추론(inference)에 GPU 불필요"라고 명시되어 있지만, 메모리 수치나 노트북 타이밍은 제공되지 않았습니다.

따라서 "CPU에서 실행 가능"하다는 점은 잘 뒷받침됩니다. "노트북에서 실행 가능"하다는 것은 fp32 가중치와 활성화 값 합계 837 MB를 의미하며, 이는 최근의 개발용 장비라면 어떤 것이든 담을 수 있는 용량입니다. 약 32K 스텝에 달하는 긴 컨텍스트(long contexts)는 이 140 ms보다 더 많은 비용이 들 것이며, 아직 아무도 그 타이밍을 발표하지 않았습니다.

Python에서 Timestral로 CSV 예측하기

GitHub에서 설치합니다 (PyPI 패키지는 언급되지 않음):

pip install git+https://github.com/mistralai/timestral.git

이 API는 NumPy 배열 또는 torch 텐서(tensor)를 사용하며, 형태는 (T,), (B, T) 또는 (B, V, T)여야 합니다. 아직 DataFrame은 지원하지 않으며, issue #1에서는 pandas/Polars 지원을 요청하고 있습니다. 이는 사용자가 직접 pandas를 사용하여 CSV 파일을 로드해야 함을 의미합니다:

import numpy as np
import pandas as pd
import torch
...

이 스크립트는 CUDA 장치가 없을 때 CPU를 선택하며, asfreq("D")는 누락된 날짜(skipped dates)를 NaN으로 변환하여 모델이 이를 짧은 시계열 데이터가 아닌 결측값으로 인식하게 합니다. copy=True가 있는 이유는 최근의 pandas 라이브러리가 읽기 전용 배열(read-only array)을 반환할 수 있기 때문이며, PyTorch는 이를 텐서로 감쌀 때 경고를 발생시킵니다.

이 코드 스니펫에서 Timestral에 특화된 모든 부분(from_pretrained, forecast, .median, .quantile(), 결측값의 NaN 처리)은 모델 카드와 README에서 가져온 것입니다. squeeze() 호출이 있는 이유는 README가 median과 quantile(q)를 형태가 (B, V, horizon)인 것으로 문서화하고 있기 때문에, 1차원 입력이라도 배치 축(batch axis)과 변수 축(variate axis)을 가지고 반환되기 때문입니다.

프로덕션 환경에서 알아두면 좋을 README의 몇 가지 추가 사항들:

• 오프라인으로 실행하기: from_pretrained는 커밋을 고정하는 데 revision=을 받아들이며, 캐시에서 읽으려면 local_files_only=True (또는 HF_HUB_OFFLINE=1)를 사용합니다. CI 환경과 컨테이너 내에서 이 작업을 수행하세요.
• 공변량(Covariates): past_covariates는 형태가 (B, C_past, T)입니다. known_covariates는 형태가 (B, C_known, T + horizon)이며 프로모션, 휴일 또는 생산 일정과 같은 항목을 포함합니다. 범주형 코드는 categorical_known_covariates에 넣습니다 (README에서 pandas.factorize를 제안함).
• 컨텍스트는 32,768 스텝으로 제한되며 가장 최근의 데이터만 유지되므로, 사용자가 직접 자르지 않고 전체 기록을 전달할 수 있습니다.

Timestral 라이선스는 2,000만 달러 매출 상한선을 가집니다

이 모델의 가중치(weights)는 "Modified MIT" 라이선스를 사용합니다. 이 라이선스는 MIT 권한을 유지하면서 한 가지 조건을 추가합니다: 회사의 (또는 고용주의) 전 세계 통합 월별 매출이 직전 달에 2,000만 달러를 초과할 경우 권리를 상실하게 됩니다. 그 기준선을 넘어서면 Mistral로부터 상업적 라이선스를 받거나 호스팅 서비스를 사용해야 하며, 이 제한은 제3자가 만든 파생 모델이나 미세 조정(fine-tunes)에도 적용됩니다.

스타트업이나 개인 프로젝트의 경우에는 상관없습니다. 하지만 대형 소매업체를 위한 예측 시스템을 구축하는 계약직이라면 중요합니다. 클라이언트 스택 내부에 이것을 배포하기 전에 라이선스를 반드시 읽어보세요. 저장소(repo) 코드는 Apache 2.0이지만, 이 코드가 예측 결과를 생성하는 부분은 아닙니다.

Prophet 대신 Timestral을 사용해야 할까요?

아직 아무것도 교체하지 않는 것이 좋겠습니다. Timestral을 도전자로 추가하세요. 자신이 보유한 지표를 사용하여 현재 사용하는 모델과 비교하여 Timestral-28M 및 209M을 롤링 윈도우(rolling windows) 방식으로, MASE와 pinball loss를 이용해 백테스팅(backtest) 해보세요. 만약 Timestral이 승리한다면, 개별 시리즈에 대한 튜닝은 불필요하며, 이는 Prophet이나 ARIMA 설정 비용의 대부분을 차지하는 부분입니다. 만약 가장 중요한 두 개의 시리즈에서 패배한다면, 프로덕션 환경에서가 아니라 단 하루 만에 그 사실을 알게 될 것입니다.

경고(alerts)를 맡기기 전에 제가 주목할 두 가지 징후가 있습니다: 기술 보고서와 독립적인 리더보드 실행 결과입니다. 둘 다 아직 존재하지 않으며, 모델은 출시된 지 며칠밖에 되지 않았습니다.

프로덕션 메트릭에 대해 튜닝된 Prophet이나 ARIMA보다 제로샷(zero-shot) 파운데이션 모델을 신뢰하시겠습니까? 만약 이미 Chronos나 TimesFM을 자체 데이터와 비교 백테스트해 보셨다면, 어떤 것이 이겼고 얼마나 차이 나는지 알려주세요. 특히 지루한 모델(boring model)이 승리했던 사례에 관심이 많습니다.

출처 (Sources)

• Timestral-209M 모델 카드 (Hugging Face)
• Timestral 발표 (Mistral)
• mistralai/timestral GitHub
• Timestral-209M 라이선스
• Timestral 1.0 문서 (Mistral)
• timestral 레포의 열린 이슈