TimesFM: Google Research : 시계열도 AI로 가능?

LLM이 텍스트를 범용적으로 다루기 시작한 뒤, 개발자들은 자연스럽게 같은 질문을 던지게 됐습니다. “시계열에도 GPT 같은 기반 모델이 가능할까?” TimesFM은 그 질문에 꽤 실용적인 답을 내놓은 프로젝트입니다. 전통적인 예측 모델처럼 데이터셋마다 새로 학습시키는 대신, 이미 사전학습된 시계열 파운데이션 모델을 가져와 바로 예측에 쓰는 흐름을 보여줍니다. (GitHub)

이 저장소는 Google Research가 공개한 시계열 예측용 오픈소스 구현체입니다. 최신 공개 버전 기준으로 TimesFM 2.5를 중심으로 하고 있고, PyTorch와 Flax 백엔드를 모두 염두에 둔 구조를 가지며, Hugging Face에서 사전학습 체크포인트를 불러와 추론하는 방식으로 사용됩니다. 저장소 README는 이것을 “time-series forecasting”용 pretrained foundation model로 소개하고, 최신 모델 2.5는 200M 파라미터, 최대 16k 컨텍스트 길이, 최대 1k horizon의 continuous quantile forecast를 지원한다고 설명합니다. (GitHub)

 

timesfm/README.md at master · google-research/timesfm

 

프로젝트 소개

TimesFM은 한마디로 말해 시계열판 범용 사전학습 모델입니다. 개발자는 개별 데이터셋마다 모델 구조를 고르고, feature engineering을 하고, 학습 파이프라인을 따로 짜기보다, 먼저 사전학습된 모델을 불러와 zero-shot 또는 최소한의 추가 설정만으로 예측을 시작할 수 있습니다. 논문과 Google Research 설명에서도 핵심 가치는 “다양한 도메인과 시간 해상도에서 out-of-the-box zero-shot 성능”에 있습니다. (Proceedings of Machine Learning Research)

이 프로젝트를 만든 주체는 Google Research이고, 저장소 메타데이터와 패키지 정의에는 Rajat Sen, Yichen Zhou, Abhimanyu Das 등 저자 정보가 포함되어 있습니다. 패키지는 Python 3.10 이상을 요구하고, 기본 의존성으로 NumPy, Hugging Face Hub, safetensors를 사용하며, 선택적으로 PyTorch, Flax/JAX, 그리고 XReg용 scikit-learn을 붙이는 구조입니다. 즉, 연구용 모델 공개에 그치지 않고, 실제 Python 애플리케이션 안에서 가져다 쓰기 좋은 배포 형태로 정리돼 있습니다. (GitHub)

왜 이 프로젝트가 등장했을까

TimesFM이 등장한 배경은 꽤 분명합니다. 기존 시계열 예측은 보통 데이터셋별 최적화에 강했습니다. 문제는 이 방식이 서비스 관점에서 비싸다는 점입니다. 리테일 수요예측, 트래픽, 센서, 재무 지표처럼 예측 대상이 바뀔 때마다 모델을 다시 고르고 학습해야 했기 때문입니다. TimesFM 논문은 이런 한계를 NLP의 파운데이션 모델 흐름과 연결해, 대규모 시계열 코퍼스로 미리 학습된 단일 모델이 다양한 unseen 데이터셋에서도 경쟁력 있는 zero-shot 성능을 낼 수 있는지를 탐색합니다. (Proceedings of Machine Learning Research)

여기서 중요한 건 TimesFM이 “시계열 전용 GPT”처럼 모든 걸 생성형으로 포장한 프로젝트가 아니라는 점입니다. 초점은 명확하게 forecasting입니다. Google Research 블로그에 따르면 이 모델은 약 100B real-world time-points로 사전학습되었고, patched decoder 스타일 attention 아키텍처를 사용합니다. 즉, 텍스트 토큰 대신 시계열 패치를 다루는 방식으로, LLM의 스케일링 아이디어를 예측 문제에 맞게 번역한 셈입니다. (Google Research)

핵심 기능

1. 사전학습 모델을 바로 불러오는 zero-shot 예측

가장 먼저 눈에 띄는 건 사용 방식이 매우 단순하다는 점입니다. README 예제 그대로 from_pretrained()로 체크포인트를 불러오고, compile() 후 forecast()를 호출하면 됩니다. 즉, 모델 학습 코드보다 추론 API가 중심입니다. 저장소의 공개 API도 ForecastConfig, TimesFM_2p5_200M_torch, TimesFM_2p5_200M_flax를 노출하는 형태로 정리돼 있습니다. (GitHub)

import torch
import numpy as np
import timesfm

torch.set_float32_matmul_precision("high")

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)

model.compile(
    timesfm.ForecastConfig(
        max_context=1024,
        max_horizon=256,
        normalize_inputs=True,
        use_continuous_quantile_head=True,
        force_flip_invariance=True,
        infer_is_positive=True,
        fix_quantile_crossing=True,
    )
)

point_forecast, quantile_forecast = model.forecast(
    horizon=12,
    inputs=[
        np.linspace(0, 1, 100),
        np.sin(np.linspace(0, 20, 67)),
    ],
)

print(point_forecast.shape)      # (2, 12)
print(quantile_forecast.shape)   # (2, 12, 10)

이 예제에서 보듯 TimesFM은 점 예측만 주는 모델이 아닙니다. 평균과 분위값을 함께 반환할 수 있어, 운영 환경에서 불확실성까지 같이 다루기 좋습니다. README는 quantile forecast 결과가 mean과 10th~90th quantiles를 포함한다고 설명합니다. (GitHub)

2. 긴 컨텍스트를 처리하는 patched decoder 구조

TimesFM 2.5 정의를 보면 context_limit = 16384, input_patch_len = 32, output_patch_len = 128로 설정돼 있습니다. 이 말은 긴 시계열을 한 포인트씩 읽는 대신, 일정 길이의 패치 단위로 압축해 처리한다는 뜻입니다. 논문도 이를 patched-decoder style attention model이라고 설명합니다. 긴 히스토리를 다뤄야 하는 수요예측이나 인프라 메트릭 예측에서 이 접근은 계산 효율 면에서 꽤 중요합니다. (GitHub)

3. 확률 예측을 위한 quantile head

2.5 버전의 큰 변화 중 하나는 continuous quantile forecast입니다. README는 optional 30M quantile head를 통해 최대 1k horizon까지 continuous quantile forecast를 지원한다고 밝히고, 코드에서도 use_continuous_quantile_head 옵션과 별도 quantile projection head가 존재합니다. 단순히 “다음 값 하나”만 맞추는 모델이 아니라, 실제 서비스에서 더 유용한 예측 구간을 다룰 수 있게 한 것입니다. (GitHub)

4. 입력 안정화와 추론 후처리 옵션

ForecastConfig를 보면 TimesFM은 추론 안정화를 위한 옵션을 꽤 많이 제공합니다. normalize_inputs는 입력 크기 차이에 따른 수치 문제를 줄이기 위한 것이고, infer_is_positive는 입력이 nonnegative이면 출력도 nonnegative가 되도록 보장하려는 옵션입니다. 또 force_flip_invariance, fix_quantile_crossing 같은 플래그는 예측 결과의 일관성과 해석 가능성을 높이는 데 초점이 있습니다. 이건 단순 모델 공개보다, 실제 추론 품질을 다듬는 데 꽤 신경 쓴 API라는 신호입니다. (GitHub)

5. 공변량 결합용 XReg 지원

2025년 10월 업데이트에서 covariate support가 XReg를 통해 다시 추가됐고, 실제 코드에도 forecast_with_covariates()가 구현돼 있습니다. 이 메서드는 동적/정적, 수치형/범주형 covariate를 받아 선형 XReg와 TimesFM을 결합합니다. 흥미로운 점은 두 가지 모드가 있다는 것입니다. timesfm + xreg는 TimesFM 예측 잔차에 선형 모델을 맞추고, xreg + timesfm는 먼저 xreg를 적합한 뒤 잔차를 TimesFM이 예측합니다. 즉, 이 프로젝트는 “파운데이션 모델 하나로 끝”이 아니라, 고전적인 회귀 성분과의 하이브리드 운용까지 고려합니다. (GitHub)

프로젝트 아키텍처 분석

TimesFM 저장소를 보면 구조가 의외로 깔끔합니다. 최상위 패키지는 설정과 공개 API를 담당하고, 실제 모델 구현은 timesfm_2p5 아래에서 PyTorch/Flax로 나뉘며, 공통 설정은 base 정의에 있습니다. 또 torch 디렉터리에는 dense block, normalization, transformer, util이 따로 분리돼 있어 모델 레이어를 재사용 가능한 부품으로 관리합니다. (GitHub)

1. 공개 API 계층

__init__.py는 아주 얇습니다. 여기서 ForecastConfig를 내보내고, 설치된 백엔드에 따라 Torch/Flax용 TimesFM 2.5 클래스를 조건부 import합니다. 즉, 개발자가 보는 인터페이스는 단순하지만 내부적으로는 백엔드 의존성을 느슨하게 분리해 둔 구조입니다. 패키지 optional dependency 설계와 잘 맞물립니다. (GitHub)

2. 모델 정의 계층

TimesFM_2p5_200M_Definition은 사실상 모델의 설계도입니다. 여기서 컨텍스트 한계, 입력 패치 길이 32, 출력 패치 길이 128, quantile 목록, 그리고 transformer 설정이 정의됩니다. transformer는 20개 레이어, 16개 헤드, model dimension 1280, RMS norm, rotary positional embedding, swish activation, fused QKV 설정을 사용합니다. 이 설정만 봐도 TimesFM이 시계열 전용이지만 상당히 정통적인 decoder transformer 문법을 따른다는 걸 알 수 있습니다. (GitHub)

3. 추론 전처리 계층

실제 forecast()는 먼저 입력 시계열을 정리합니다. 코드상으로는 leading NaN을 제거하고, 남은 NaN은 선형 보간으로 채운 뒤, 컨텍스트 길이에 맞춰 truncate 또는 left padding을 수행합니다. 그리고 padding 위치를 마스크로 넘깁니다. 이런 전처리는 프로덕션 데이터에서 아주 중요합니다. 실서비스 시계열은 결측과 길이 불일치가 기본값에 가깝기 때문입니다. (GitHub)

4. 토크나이저와 transformer 본체

PyTorch 구현을 보면 입력값과 mask를 concat한 뒤 ResidualBlock 기반 tokenizer에 통과시키고, 그 뒤 20개의 transformer layer를 ModuleList로 순차 적용합니다. 각 layer는 RMSNorm, MultiHeadAttention, feed-forward 블록으로 구성되며, attention 쪽은 rotary positional embedding과 decode cache를 활용합니다. 이 decode cache는 autoregressive 추론에서 과거 key/value를 재사용해 계산량을 줄이는 역할을 합니다. (GitHub)

5. 출력 헤드와 디코딩

Transformer 출력을 받은 뒤에는 point forecast용 head와 quantile spread용 head가 분리됩니다. 이후 decode()는 패치 단위로 autoregressive하게 horizon을 생성하고, 필요하면 continuous quantile head를 사용해 분위 예측을 보정합니다. 여기서 force_flip_invariance, fix_quantile_crossing, normalize_inputs의 역정규화 같은 후처리도 함께 이뤄집니다. 즉, TimesFM의 추론은 “Transformer 한 번 통과”로 끝나지 않고, 예측 안정성을 위한 후처리 파이프라인까지 포함한 구조입니다. (GitHub)

6. 컴파일 단계가 따로 있는 이유

이 저장소에서 compile()이 별도 단계인 것도 흥미롭습니다. PyTorch 구현은 이 단계에서 max_context를 patch size 배수로, max_horizon을 output patch size 배수로 조정하고, 전체 context + horizon이 모델의 context_limit를 넘지 않는지 검증합니다. 즉, compile은 단순 최적화 스위치가 아니라 모델 구조 제약에 맞는 실행 계획을 고정하는 단계에 가깝습니다. 대량 배치 추론이나 반복 호출이 많은 환경에서 꽤 합리적인 선택입니다. (GitHub)

개발자가 이해해야 할 핵심 포인트

TimesFM을 일반적인 시계열 라이브러리처럼 보면 약간 오해하기 쉽습니다. 이것은 Prophet이나 ARIMA 같은 전통 모델 대체재라기보다, 사전학습된 범용 forecaster를 서비스 코드에서 바로 소비하는 SDK에 더 가깝습니다. 그래서 이 저장소를 읽을 때도 “학습 파이프라인”보다 “추론 인터페이스”와 “입력/후처리 규약”을 먼저 보는 편이 이해가 빠릅니다. (GitHub)

또 하나 중요한 점은, 이 저장소가 최신 공개 모델 버전은 2.5라고 안내하면서도 pyproject.toml 버전 표기는 2.0.0으로 남아 있다는 점입니다. 즉, 패키지 버전과 README의 모델 버전은 같은 의미가 아닙니다. 실무에서는 “패키지 버전”, “모델 체크포인트 이름”, “문서상 모델 세대”를 구분해서 봐야 헷갈리지 않습니다. (GitHub)

언제 사용하면 좋을까

1. 빠르게 baseline을 만들고 싶을 때

새로운 시계열 문제를 받았는데, 아직 어떤 모델이 맞는지 모를 때 TimesFM은 아주 좋은 첫 출발점입니다. 모델 학습 인프라를 붙이기 전에 zero-shot baseline을 빠르게 만들 수 있기 때문입니다. 특히 여러 도메인 데이터를 한 팀이 함께 다루는 조직이라면, “데이터셋마다 다른 모델” 대신 “일단 TimesFM으로 먼저 본다”는 운영 패턴이 가능합니다. (Proceedings of Machine Learning Research)

2. 불확실성까지 같이 보고 싶을 때

서비스에서 point estimate만으로는 부족한 경우가 많습니다. 재고 보충, 용량 계획, 이상 상황 대비에서는 P10/P50/P90 같은 구간 정보가 훨씬 중요합니다. TimesFM 2.5는 quantile forecast를 기본적인 사용 흐름 안에 포함하고 있어서 이런 상황에 잘 맞습니다. (GitHub)

3. 긴 히스토리와 다양한 길이 입력을 다뤄야 할 때

최대 16k 컨텍스트와 패치 기반 처리 구조는 장기 이력의 계절성이나 반복 패턴을 보려는 문제에 유리합니다. 게다가 forecast() 자체가 입력 길이가 제각각인 리스트를 받아 내부에서 패딩과 마스킹을 처리하므로, 실무 데이터처럼 길이가 균일하지 않은 경우에도 다루기 편합니다. (GitHub)

4. 공변량과 결합한 하이브리드 예측이 필요할 때

가격, 프로모션, 지역, 카테고리 같은 covariate가 중요한 문제에서는 foundation model 하나만으로 부족할 수 있습니다. 이때 XReg 지원은 꽤 현실적인 절충안입니다. TimesFM의 일반화 능력과 선형 회귀의 설명 가능성을 함께 가져가는 방식이기 때문입니다. (GitHub)

실제 사용 예시

예를 들어 이커머스 팀이 일별 주문량을 예측한다고 해보겠습니다. 가장 빠른 시작은 지난 주문량만 넣어서 zero-shot 예측을 보는 것입니다.

import numpy as np
import timesfm

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)

model.compile(
    timesfm.ForecastConfig(
        max_context=512,
        max_horizon=64,
        normalize_inputs=True,
        use_continuous_quantile_head=True,
        fix_quantile_crossing=True,
    )
)

sales_history = np.array([
    120, 118, 130, 140, 160, 155, 162, 171, 169, 180,
    176, 190, 201, 210, 208, 220, 225, 219, 230, 240
], dtype=float)

point_fcst, quantile_fcst = model.forecast(
    horizon=14,
    inputs=[sales_history],
)

next_14_days = point_fcst[0]
p10 = quantile_fcst[0, :, 1]
p90 = quantile_fcst[0, :, 9]

조금 더 실무적으로 가면 프로모션 여부나 가격 같은 covariate를 함께 넣고 싶어집니다. 이때는 return_backcast=True로 컴파일한 뒤 forecast_with_covariates()를 쓰는 흐름이 자연스럽습니다. 저장소 코드상 이 메서드는 적어도 하나 이상의 동적/정적 covariate가 있어야 하고, XReg 사용 시 return_backcast=True가 필수입니다. (GitHub)

import timesfm

model = timesfm.TimesFM_2p5_200M_torch.from_pretrained(
    "google/timesfm-2.5-200m-pytorch"
)

model.compile(
    timesfm.ForecastConfig(
        max_context=512,
        max_horizon=14,
        normalize_inputs=True,
        return_backcast=True,
    )
)

inputs = [
    [120, 118, 130, 140, 160, 155, 162, 171, 169, 180]
]

dynamic_numerical_covariates = {
    "price": [[100, 100, 98, 98, 95, 95, 95, 97, 97, 96, 96, 96, 97, 97]],
}

dynamic_categorical_covariates = {
    "promo": [["N", "N", "N", "Y", "Y", "Y", "N", "N", "N", "N", "Y", "Y", "N", "N"]],
}

point_outputs, quantile_outputs = model.forecast_with_covariates(
    inputs=inputs,
    dynamic_numerical_covariates=dynamic_numerical_covariates,
    dynamic_categorical_covariates=dynamic_categorical_covariates,
    xreg_mode="timesfm + xreg",
)

이 저장소를 보며 느끼는 장점과 한계

장점은 분명합니다. TimesFM은 “시계열 파운데이션 모델”이라는 다소 추상적인 개념을 꽤 사용 가능한 SDK로 떨어뜨렸습니다. 사전학습 체크포인트, 단순한 Python API, quantile forecast, covariate 결합, PyTorch/Flax 경로 분리까지, 오픈소스로서 개발자 경험을 생각한 흔적이 있습니다. Google Cloud BigQuery에도 TimesFM이 제품화되어 있다는 점은 이 모델 계열이 단순 연구 데모에 머물지 않았다는 신호이기도 합니다. (GitHub)

반면 한계도 있습니다. 이 저장소 자체가 README에서 “officially supported Google product”는 아니라고 밝히고 있고, 2.5 전환 과정에서 문서와 API가 한동안 공사 중이라고 적어 둔 흔적도 있습니다. 즉, 프로덕션에 곧바로 넣기 전에는 버전 호환성과 체크포인트 이름, API 변경을 반드시 확인해야 합니다. 파운데이션 모델이라고 해서 모든 도메인에서 파인튜닝 모델을 항상 이긴다고 기대하는 것도 위험합니다. TimesFM의 강점은 범용성과 빠른 출발이지, 모든 문제에서 자동 SOTA를 보장하는 마법은 아닙니다. (GitHub)

마무리

TimesFM을 한 문장으로 정리하면 이렇습니다. 시계열 예측을 “학습 중심 작업”에서 “사전학습 모델 소비 작업”으로 옮겨 놓은 프로젝트입니다. 이 저장소의 진짜 가치는 모델 성능 숫자 하나보다도, 개발자가 시계열 예측을 다루는 방식 자체를 바꾸려 한다는 데 있습니다. 텍스트에서 LLM이 그랬듯, 시계열에서도 “일단 pretrained model부터 써본다”는 습관이 점점 일반화될 가능성이 큽니다. TimesFM은 그 변화의 가장 실용적인 출발선 중 하나입니다. (Google Research)