상용 라이선스로 나온 IBM Granite 시계열 PatchTST-FM-r2, SOTA 예측을 가볍게 풀다

IBM Research가 공개한 Granite Time Series PatchTST-FM-r2를 패치 기반 트랜스포머, 제로샷 예측, 상용 친화적 라이선스 관점에서 읽고 기업 예측 파이프라인에 주는 의미를 정리합니다.

원문 논문 보기
'상용 라이선스로 나온 IBM Granite 시계열 PatchTST-FM-r2, SOTA 예측을 가볍게 풀다' 기사 커버 이미지

IBM Research가 Hugging Face 블로그를 통해 공개한 Granite Time Series PatchTST-FM-r2는 시계열 예측을 위한 사전학습 트랜스포머 파운데이션 모델의 두 번째 세대 업데이트입니다. 이 글에서 다루는 원문은 제목 아래에 링크된 IBM Research의 발표 글로, 패치 기반 아키텍처와 상용 친화적 라이선스를 전면에 내세우고 있습니다.

이 발표가 전하는 말은 한 문장으로 정리됩니다. 패치 단위로 시계열을 읽는 작고 효율적인 파운데이션 모델을 상용 친화적 조건으로 공개했으니, 에너지와 금융과 유통과 IT 운영 같은 현장에서 처음부터 학습시키지 않고도 예측을 시작할 수 있다는 것입니다. 오늘은 이 말이 실제로 무엇을 뜻하는지, 그리고 어디까지 조심해서 읽어야 하는지 차례로 짚어보겠습니다.

안녕하세요, 예측 모델 이야기는 왜 매번 피곤할까요

안녕하세요, 패트릭입니다.

현장에서 예측 모델을 한 번이라도 운영해본 분들은 비슷한 피로를 기억하실 겁니다. 전력 수요를 예측하는 모델을 만들면 유통 재고 예측에는 다시 처음부터 데이터를 모으고, 금융 시계열에는 또 다른 모델을 붙여야 하죠. 모델은 늘어나는데, 매번 전처리부터 학습 파이프라인까지 새로 짜야 하니 팀의 체력이 먼저 닳습니다. 그렇다면 시계열에도 언어 모델처럼 한 번 배워두면 여러 곳에 꺼내 쓸 수 있는 기반이 있을 수 있을까요?

제가 이 발표를 그냥 넘기지 않은 이유는 바로 그 질문 때문입니다. IBM의 Granite Time Series 계열은 예측과 시계열 분석을 위해 처음부터 설계된 사전학습 트랜스포머라고 소개되고 있는데, 이번 r2는 그 두 번째 세대로 정확도와 벤치마크 성능을 끌어올렸다고 말합니다. 물론 벤치마크에서 1등을 했다는 말이 늘 현장 성능을 보장하지는 않죠. 그럼에도 저는 이 발표를 읽으면서 운영의 아침을 떠올렸습니다. 밤사이 들어온 결측값을 메우느라 파이프라인이 멈추고, 아침 회의 전에 누군가 수작업으로 숫자를 고치는 장면 말입니다. 그런 아침을 줄여주는 장치라면, 숫자 이전에 구조부터 보고 싶어집니다.

긴 시계열 곡선을 패치 구간으로 나누어 토큰처럼 배열한 다이어그램
긴 시계열 곡선을 패치 구간으로 나누어 토큰처럼 배열한 다이어그램

매번 처음부터 학습시키는 일, 왜 이렇게 지치는 걸까요

시계열 예측의 오래된 습관 중 하나는 도메인마다 별도의 모델을 처음부터 학습시키는 것입니다. 전력 부하는 계절성과 날씨 변수를 먹고, 주식 변동성은 노이즈가 심하고, 유통 판매는 판촉 calendar에 흔들리고, 서버 지표는 장애 순간에 튀니까요. 그래서 현장에서는 도메인 지식을 전처리와 피처에 녹이고, 그 위에 비교적 작은 모델을 올리는 방식이 오래 사랑받았습니다. 그런데 이 방식은 도메인이 바뀔 때마다 같은 수고를 반복하게 만듭니다.

문제는 그다음입니다. 데이터가 부족한 신규 매장이나 새로 생긴 서비스 지표처럼, 처음부터 학습시키기에는 관측치가 너무 짧은 경우가 생각보다 많습니다. 이럴 때 팀은 비슷한 과거 구간을 끌어오거나, 이웃 매장의 데이터를 빌려오거나, 아예 룰 기반으로 버티는데요. 이런 땜질은 당장은 돌아가지만, 계절이 바뀌거나 판촉 방식이 바뀌면 다시 손봐야 합니다. 결국 예측 조직의 시간은 모델을 좋게 만드는 데가 아니라 파이프라인을 붙잡아두는 데 쓰이곤 하죠.

저는 그래서 파운데이션 모델이라는 말이 시계열에서 특히 절실하게 들린다고 봅니다. 언어에서는 이미 낯익은 흐름인데, 시계열에서는 왜 이렇게 늦었을까요? 답은 어느 정도 짐작할 수 있습니다. 언어가 비교적 공통된 토큰 체계를 가진 데 비해, 시계열은 샘플링 주기와 스케일과 노이즈 성격이 도메인마다 완전히 다르니까요. 1분 단위 서버 CPU 사용률과 일단위 전력 수요를 같은 눈으로 읽는 일은, 언어로 치면 서로 다른 문자 체계를 한 모델로 읽는 일에 가깝습니다. 그렇다면 IBM이 말하는 사전학습 기반은 이 간극을 어떻게 메우겠다는 걸까요? 그 이야기는 아키텍처에서 이어집니다.

토큰 대신 구간을 읽는다는 것, 뭐가 달라지나요

제가 이 발표에서 가장 흥미롭게 본 부분은 패치라는 단어의 쓰임새입니다. PatchTST-FM-r2는 시계열을 점 하나하나가 아니라 구간 단위로 잘라서 입력 토큰처럼 다룬다고 소개되는데, 언뜻 보면 단순한 묶음처럼 들리지만 실제로는 계산 구조를 바꾸는 선택입니다.

생각해보면 사람도 시계열을 점으로 읽지 않습니다. 주가 차트를 볼 때 우리는 14시 32분의 한 점을 외우지 않고, 오전 내내 이어진 하락 구간이나 점심 이후의 반등 같은 흐름으로 읽죠. 패치 기반 트랜스포머도 그와 비슷한 선택을 합니다. 연속된 관측값 여러 개를 하나의 패치로 묶으면, 모델은 점 사이의 미세한 흔들림보다 구간이 품은 모양과 추세를 먼저 보게 됩니다. 그리고 구간 수가 점의 수보다 훨씬 적어지니, 긴 구간을 바라볼 때 주의해야 할 관계의 수도 함께 줄어듭니다. 긴 역사를 보고 싶은 모델에게는 이 계산상의 여유가 꽤 큽니다.

여기서 재미있는 질문이 생깁니다. 구간으로 묶으면 세밀한 정보를 잃는 것 아닐까요? 저는 이 대목을 조심해서 읽을 필요가 있다고 봅니다. 패치는 정보를 버리는 대신, 어떤 디테일을 늦게 보고 어떤 추세를 먼저 볼지를 정하는 우선순위에 가깝기 때문입니다. 장애 직전의 날카로운 스파이크처럼 점 단위 이상 징후가 중요한 경우에는 패치 길이나 겹침 같은 설계가 결과를 좌우할 수 있습니다. 반면 계절성과 요일 패턴처럼 긴 호흡의 구조가 중요한 경우에는 패치가 오히려 노이즈를 눌러주고 본질을 드러내줍니다. 그래서 패치 길이를 어떻게 잡았는지, 겹침을 두었는지, 채널을 어떻게 섞었는지는 단순한 하이퍼파라미터가 아니라 모델의 시야를 정하는 결정에 가깝습니다. 발표가 긴 구간 모델링의 효율을 앞세우는 이유도 바로 여기에 있다고 저는 읽었습니다.

패치 기반 트랜스포머와 점별 입력 모델의 처리 방식 비교도
패치 기반 트랜스포머와 점별 입력 모델의 처리 방식 비교도

두 번째 세대라는 말은 어디까지 믿어야 할까요

r2라는 이름은 두 번째 세대를 뜻하는데, 발표는 이 버전이 정확도와 벤치마크 성능에서 한 단계 나아간 결과라고 말합니다. SOTA라는 단어가 들어간 제목을 보면 마음이 먼저 움직이는데요. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. SOTA는 어느 벤치마크 모음에서, 어떤 예측 길이와 어떤 평가 방식으로 잰 1등인지에 따라 뜻이 완전히 달라지기 때문입니다.

시계열 벤치마크는 특히 읽기가 까다롭습니다. 단기 예측에서 강한 모델이 장기 예측에서는 흔들리기도 하고, 결측이 많은 실제 데이터에서는 순위표의 순서가 뒤집히기도 하죠. 게다가 평균 오차를 조금 낮추는 것과 운영에서 체감하는 정확도는 같은 이야기가 아닙니다. 전력 수급처럼 피크를 놓치면 안 되는 업무에서는 평균이 아니라 극단 구간에서의 성능이 훨씬 중요하니까요. 그래서 저는 SOTA라는 말을 성과 자체보다 방향으로 읽는 편입니다. 패치 기반 사전학습이라는 뼈대는 유지한 채, 두 번째 세대에서 학습 데이터 구성이나 학습 방식을 다듬어 일반화 성능을 끌어올렸다는 신호로 말입니다.

(참고로 SOTA 경쟁에서 1등과 2등의 차이는 소수점 아래에서 갈리는 경우가 많은데요. 현장에서는 그 차이보다 결측 처리나 추론 속도가 체감 성능을 더 크게 바꾸곤 합니다.) 그럼에도 두 번째 세대라는 말에는 운영 관점에서 반가운 구석이 있습니다. 첫 버전에서 드러난 약점을 메우는 방향으로 패치가 쌓였다는 뜻이기 때문입니다. 저는 앞으로 보고 싶은 것이 바로 그 대목입니다. 어떤 길이의 예측에서 좋아졌는지, 어떤 도메인에서 편차가 줄었는지, 짧은 관측에서도 안정적인지가 공개되면, SOTA라는 단어의 무게를 가늠할 수 있을 테니까요.

학습 없이 예측한다는 말, 현장에서는 어떻게 들릴까요

이 발표를 둘러싼 말 가운데 현장에서 가장 크게 들리는 것은 아마 제로샷과 퓨샷 예측일 겁니다. 과제별로 처음부터 학습시키지 않아도, 사전학습된 모델을 그대로 두거나 소량의 예시만으로 예측을 시작할 수 있다는 뜻이니까요. 새로 연 매장의 3주치 판매 기록만으로 다음 달을 가늠해야 하거나, 막 붙인 서버의 며칠치 지표로 용량을 정해야 할 때를 떠올리면, 이 말이 왜 반가운지 바로 와닿습니다.

그런데 이 말은 마법이 아니라 조건부 약속에 가깝습니다. 사전학습이 통하려면 모델이 학습 과정에서 본 적 없는 패턴을 만났을 때도 무너지지 않아야 하는데, 시계열의 분포 이동은 생각보다 사납습니다. 판촉 정책이 바뀌거나, 전력 요금제가 바뀌거나, 서비스 구조가 바뀌면 과거의 모양이 더 이상 미래를 설명하지 않죠. 그래서 제로샷이 잘 통하는 경우와 반드시 파인튜닝이 필요한 경우를 가르는 눈이 중요합니다. 저는 이 구분을 이렇게 봅니다. 계절성과 요일성처럼 반복되는 뼈대가 분명한 곳에서는 제로샷이 꽤 멀리 가고,制度나 구조가 바뀐 직후처럼 과거의 문법이 깨진 곳에서는 소량의 최신 데이터로 다듬는 과정이 필요합니다. 여기서 제도라는 한자어를 굳이 쓴 이유는, 시계열의 분포 이동은 숫자만의 문제가 아니라 현장의 규칙이 바뀌는 문제이기 때문입니다.

퓨샷의 미덕도 같은 맥락에서 읽힙니다. 소량의 예시로 방향을 잡아준다는 것은, 긴 학습 파이프라인을 돌리지 않고도 현장의 변화를 모델에게 알려줄 수 있다는 뜻이니까요. 아침에 갑자기 생긴 판촉 행사를 어제와 오늘 데이터 몇 줄로 설명하고 내일 발주를 조정하는 장면을 상상하면, 이 가벼움이 왜 중요한지 분명해집니다. 다만 여기서도 조심할 대목이 남습니다. 예시가 너무 적으면 모델이 예시의 노이즈까지 그대로 외워버릴 수 있기 때문입니다. 그래서 퓨샷을 쓸 때는 예시를 고르는 일이 곧 모델링이 됩니다. 어떤 구간을 보여줄지, 이상 징후가 낀 구간을 뺄지, 길이를 얼마나 줄지가 예측을 좌우하죠. 저는 그래서 제로샷과 퓨샷을 모델의 재능이라기보다 현장과 모델 사이의 대화 방식이라고 부르고 싶습니다.

제로샷과 퓨샷 예측이 동작하는 흐름을 보여주는 개념도
제로샷과 퓨샷 예측이 동작하는 흐름을 보여주는 개념도

작고 효율적인 모델이 오히려 반가운 이유

요즘 모델 발표를 보면 크기를 앞세우는 경우가 여전히 많은데, 이번 발표가 가리키는 방향은 조금 다릅니다. 기업 현장에서 바로 쓸 수 있는 작고 효율적인 열린 모델이라는 쪽에 가깝죠. 저는 이 선택을 꽤 현실적이라고 봅니다. 시계열 예측은 거대 언어 모델처럼 한 번 물어보고 끝나는 작업이 아니라, 매시간 혹은 매분 돌아가는 반복 작업이기 때문입니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 시계열도 마찬가지입니다. 수천 개의 매장과 수만 개의 서버 지표에 대해 예측을 돌려야 하는 조직에게, 추론 비용은 곧 운영비 그 자체입니다. 모델이 조금 작아도 자주 돌릴 수 있고, CPU나 보급형 GPU에서도 부담 없이 돌아간다면, 그 모델은 현장에서 훨씬 오래 살아남습니다. 패치 기반 구조가 긴 구간을 효율적으로 본다는 말도 결국 이 비용 이야기로 이어집니다. 같은 길이의 역사를 더 적은 토큰으로 읽으면, 메모리와 계산이 함께 줄어드니까요.

여기서 좋은 질문이 하나 생깁니다. 작은 모델이 긴 패턴을 놓치지는 않을까요? 언뜻 보면 크기와 기억은 비례할 것 같지만, 시계열에서는 설계가 크기를 어느 정도 보완합니다. 구간 단위로 읽으면 긴 역사도 압축된 형태로 들어가고, 사전학습으로 뼈대를 익혀두면 과제별 파라미터를 많이 두지 않아도 되니까요. 물론 작은 모델이 모든 장기 의존성을 잡아낸다고 장담할 수는 없는데요. 그래서 저는 크기를 스펙이 아니라 운영 조건으로 읽는 편입니다. 밤마다 수만 번 호출되는 배치 예측이라면 작은 쪽이 정답에 가깝고, 드물게 돌리지만 한 번의 정확도가 큰돈과 직결되는 경우라면 더 큰 모델이나 앙상블을 고민할 수 있습니다. 이 발표가 겨냥한 자리는 분명 전자 쪽이고, 그 자리는 생각보다 넓습니다.

라이선스가 기술만큼 화제가 되는 이유

이번 발표에서 기술만큼 눈에 띄는 단어는 상용 친화적 라이선스입니다. Granite 계열의 전통과 같은 방향으로 Apache 2.0 계열의 개방 조건이 언급되는데, 이 한 줄이 현장에서는 아키텍처 설명만큼 무겁게 읽힙니다. 모델이 좋아도 제품에 넣을 수 없으면 그림의 떡에 그치기 때문입니다.

기업에서 모델을 쓴다는 것은 단순히 가중치를 내려받는 일이 아닙니다. 제품에 포함하고, 고객 데이터로 다듬고, 재배포하고, 문제가 생기면 추적하는 과정까지 포함하죠. 라이선스가 모호하면 법무 검토에서 몇 달이 녹고, 그 사이에 현장은 다시 예전 룰 기반으로 돌아갑니다. 반면 상용 이용이 분명한 조건이라면 이야기가 달라집니다. 파일럿을 돌려보고, 내부 데이터로 파인튜닝하고, 서비스 파이프라인에 붙이는 결정이 훨씬 빨라지죠. 그래서 상용 친화적이라는 말은 법률 문구가 아니라 도입 속도의 문제이기도 합니다.

그렇다면 라이선스만 좋으면 다 될까요? 물론 그렇지 않습니다. 열린 가중치와 분명한 조건은 시작을 쉽게 만들 뿐, 운영의 책임까지 대신해주지 않기 때문입니다. 예측이 틀렸을 때 누구에게 설명할지, 편향된 학습 데이터가 특정 매장에 불리하게 작동하지는 않는지, 고객 데이터를 학습에 써도 되는지는 여전히 조직이 답해야 할 질문이죠. 저는 그래서 라이선스를 문이 열리는 소리로 비유합니다. 문이 열렸다고 해서 방 안이 정리되어 있는 것은 아니지만, 적어도 들어가서 살펴볼 수는 있게 되니까요. 이번 발표가 반가운 이유는 그 문을 꽤 활짝 열어두었다는 데 있습니다. 작은 팀도 큰 조직도 같은 출발선에서 만져볼 수 있다는 점은, 시계열처럼 현장이 다양한 영역에서는 특히 큽니다.

작고 효율적인 모델이 기업 서버에서 실행되는 장면
작고 효율적인 모델이 기업 서버에서 실행되는 장면

에너지와 금융과 유통과 IT 운영, 같은 모델이 통할까요

발표가 꼽은 도메인 네 가지는 얼핏 보면 서로 멀어 보입니다. 에너지의 부하 곡선, 금융의 변동성, 유통의 판매 기록, IT 운영의 서버 지표는 주기도 스케일도 노이즈도 다르니까요. 그런데 이 조합을 가만히 보면 시계열 파운데이션 모델이 풀겠다고 나선 숙제가 그대로 드러납니다. 서로 다른 문법을 쓰는 데이터들을 하나의 눈으로 읽을 수 있겠느냐는 것입니다.

이 지점에서 저는 기대와 의심을 함께 품습니다. 기대는 분명합니다. 네 영역 모두 계절성과 추세와 이벤트 반응이라는 뼈대를 공유하니까요. 명절 앞의 전력 수요 상승과 대형 판촉 앞의 유통 판매 상승은 숫자의 단위는 달라도 모양의 문법은 닮았습니다. 사전학습이 이런 모양의 사전을 넉넉히 품고 있다면, 도메인이 바뀌어도 완전히 맨바닥부터 시작하지 않아도 됩니다. 특히 데이터가 짧은 신생 서비스나 신규 지점처럼, 과거가 부족한 곳에서는 이런 전이가 큰 힘이 됩니다.

반면 의심도 버릴 수 없습니다. 금융의 꼬리 위험처럼 드물지만 치명적인 사건은 평균적인 모양 사전만으로는 잡히지 않기 때문입니다. 서버 장애 직전의 미세한 이상 징후도 마찬가지고요. 도메인마다 틀리면 안 되는 지점이 다르다는 말이 바로 이 뜻입니다. 에너지에서는 피크 시간대의 과소 예측이, 금융에서는 변동성 폭발 구간의 과소 예측이, 유통에서는 품절과 과잉 재고가, IT 운영에서는 장애 탐지 지연이 각각 다른 비용으로 돌아옵니다. 그래서 하나의 모델이 네 영역을 모두 다룬다는 말은, 하나의 눈으로 본다는 뜻이지 하나의 기준으로 판단한다는 뜻이 아닙니다. 현장에서는 도메인별 임계값과 후처리와 알람 정책을 따로 두어야 하고, 모델의 역할은 그 앞단에서 좋은 예측 분포를 건네주는 일에 가깝습니다. 저는 이 역할 분담이 분명해질 때 파운데이션 모델이 현장에 안착한다고 봅니다.

에너지와 금융과 유통과 IT 운영 데이터를 하나의 모델이 처리하는 모습
에너지와 금융과 유통과 IT 운영 데이터를 하나의 모델이 처리하는 모습

Hugging Face에서 꺼내 쓰는 흐름은 무엇이 달라지나요

Granite 시계열 모델들이 Hugging Face를 통해 배포되고, 일반적인 예측 워크플로와 파인튜닝을 지원한다는 대목은 짧지만 현장의 감각으로는 길게 읽힙니다. 모델을 어디서 어떻게 꺼내 쓰느냐가 도입의 절반을 정하기 때문입니다.

예전의 시계열 도입을 떠올리면, 논문의 코드를 복원하고 의존성을 맞추고 데이터 로더를 손보는 데만 며칠이 걸리곤 했습니다. 반면 익숙한 허브에서 가중치와 예제 코드를 함께 받고, 자사 데이터 형식에 맞춰 파인튜닝하는 흐름이라면 이야기가 달라집니다. 주말 파일럿이 가능해지고, 월요일 아침 회의에서 실제 자사 숫자로 이야기할 수 있으니까요. 이 속도 차이는 생각보다 중요합니다. 예측 모델의 설득은 보고서가 아니라 돌아가는 데모에서 나오기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 파인튜닝은 얼마나 가벼울까요? 전체를 다시 학습시켜야 하는지, 일부만 다듬어도 되는지, 짧은 관측으로도 안정적인지에 따라 운영의 모양이 달라집니다. 전체 파인튜닝이 필요하다면 GPU 예산을 따로 잡아야 하고, 가벼운 조정으로 된다면 CPU 배치 안에서도 돌릴 수 있죠. 결측과 비정상 구간을 어떻게 다루는지도 관건입니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 매장의 POS가 끊겨도 예측 라인은 멈추면 안 되기 때문입니다. 저는 그래서 허브의 예제 코드에서 데이터 전처리 부분을 가장 먼저 봅니다. 모델 구조보다 그 부분이 운영의 아침을 지키는지 알려주기 때문입니다.

Hugging Face 기반 파인튜닝과 배포 워크플로를 그린 다이어그램
Hugging Face 기반 파인튜닝과 배포 워크플로를 그린 다이어그램

그래서 다음에 물을 질문은 이것입니다

여기까지 읽으면 이런 정리가 남습니다. 패치로 읽는 작고 효율적인 시계열 파운데이션 모델이 두 번째 세대로 나아왔고, 상용 친화적 조건으로 Hugging Face에서 꺼내 쓸 수 있으며, 처음부터 학습시키지 않는 예측이 에너지와 금융과 유통과 IT 운영을 겨냥한다는 것입니다. 그렇다면 이 흐름은 어디에서 더 단단해질까요? 그 이야기는 이제부터가 본론입니다.

제가 앞으로 보고 싶은 것은 크게 세 가지입니다. 첫째는 긴 예측 길이에서의 안정성입니다. 하루 앞 예측과 한 달 앞 예측은 사실상 다른 문제이고, 길어질수록 오차가 쌓이는 방식이 달라지니까요. 둘째는 분포 이동 이후의 회복 속도입니다. 판촉 방식이 바뀌거나 요금제가 바뀌거나 서비스 구조가 바뀐 뒤, 소량의 최신 데이터로 얼마나 빨리 따라잡는지가 현장에서는 순위표의 숫자보다 중요합니다. 셋째는 작은 모델의 한계가 어디인지에 대한 솔직한 기록입니다. 어떤 패턴에서는 큰 모델이 필요하고, 어떤 패턴에서는 패치 설계의 조절이 필요한지가 드러나면, 현장의 선택이 훨씬 쉬워집니다.

(참고로 저는 새로운 모델을 볼 때 잘되는 구간보다 못 미치는 구간의 설명을 먼저 찾는데요. 그 설명이 솔직할수록 모델을 어디에 써야 할지 빨리 감이 옵니다.) 그리고 한 가지 덧붙이면, 평가의 방식도 함께 바뀌어야 합니다. 평균 오차 하나가 아니라 피크 구간의 성능과 결측 상황에서의 강건함과 추론 비용까지 함께 보는 평가가 필요합니다. 그래야 순위표의 1등이 현장의 1등으로 이어집니다.

다 읽고 나면 결국 사람의 질문으로 돌아옵니다. 예측을 잘한다는 것은 숫자를 맞힌다는 뜻일까요, 아니면 결정이 늦지 않게 돕는다는 뜻일까요. 저는 후자에 가깝다고 봅니다. 발주 담당자가 월요일 아침에 망설이지 않고, 전력 운영자가 피크를 앞두고 여유를 갖고, 서버 운영자가 장애 전에 한 발 먼저 움직일 수 있다면, 그 예측은 이미 역할을 다한 셈이니까요. 이번 r2가 그런 아침을 몇 개나 더 지켜줄지, 다음 벤치마크보다 다음 현장 기록이 더 궁금해지는 이유입니다.

참고 자료

  1. IBM releases SOTA Granite Time Series PatchTST-FM-r2 model with commercial-friendly license · huggingface.co

    리뷰 원문

상용 라이선스로 나온 IBM Granite 시계열 PatchTST-FM-r2, SOTA 예측을 가볍게 풀다 | Patty