#가중치 파일 옆에 필요한 것
기존 마이크로그리드 예측 실험 모델을 공개용 패키지로 정리했다. 새 모델을 학습해 성능을 높이는 작업은 아니었다. 이미 있던 가중치를 받아 작은 CPU 예제로 실행할 수 있게 만드는 것이 범위였다.
모델은 Transformers의 PatchTSMixerModel에 별도 회귀 출력층을 붙인 구조다. PatchTSMixer가 만든 표현을 마지막 선형층에서 65개 값으로 바꾸고, 출력별 범위에 따라 sigmoid나 tanh를 적용한다. PatchTSMixer 공식 문서는 기반 모델의 설명이고, 이 패키지의 출력층은 고정 revision의 model.py에 있다.
가중치만 올리면 입력을 어떤 모양으로 넣어야 하는지, 출력이 무슨 단위인지, 어떤 환경에서 실행했는지가 빠진다. 모델 정의와 설정, 추론 코드, 합성 입력 예제, 평가 결과를 함께 준비했다. 원본 데이터와 내부 로그, 학습을 계속하기 위한 파일은 공개 대상에서 제외했다.
공개 범위와 권리 확인도 실행 검증과 따로 정리했다. 모델 카드, LICENSE와 NOTICE에는 공개 독자가 알아야 할 사용 조건과 한계를 남겼다.
#4×290을 넣고 65개 값을 받는다
입력은 시간순 관측 4개, 관측마다 특성 290개다. 행렬 모양만 맞는다고 충분하지 않았다. contract_id와 feature_order가 설정과 같아야 하고, 모든 값이 유한한지도 확인했다. 실제 설비 원시값을 임의로 290개 나열해 넣는 인터페이스는 아니다.
추론 코드는 NumPy로 입력을 FP32 배열로 바꾸고, 설정에 든 평균과 scale로 표준화한 뒤 −10~10 범위로 제한한다. PyTorch에서 inference_mode()로 실행한 출력은 65개인지 다시 검사한다. 응답 JSON에는 target_order와 단위, 네트워크 출력 network, 역변환한 normalized와 물리 단위 값 physical을 함께 반환한다. 출력 숫자만 떼어 받아 단위를 추측할 필요가 없게 했다.
가중치는 safetensors로 저장했다. 로더는 실행 전에 설정·모델 코드·추론 코드·가중치의 SHA-256을 manifest와 대조하고, CPU에서 가중치를 읽는다. 고정 revision의 infer.py에서 입력 검사와 로딩 순서를 볼 수 있다.
공개 패키지 디렉터리에서 쓰는 명령은 다음과 같다. 합성 입력 예제를 사용하는 실제 CLI 형식이며, 이번 글을 보강하면서 재실행한 명령은 아니다.
python infer.py --input example_input.json
당시 직접 의존성은 PyTorch 2.11.0, Transformers 4.40.2, NumPy 1.26.4, safetensors 0.8.0으로 고정했다. 전체 환경을 새로 설치해 검증했다는 뜻은 아니다. 버전은 공개 패키지의 requirements.txt에 남겼다.
#작은 출력 차이부터 맞췄다
먼저 원본 모델과 패키지의 출력을 비교했다. 세 종류의 합성 입력으로 중간 출력과 최종 값을 맞춰 보고, 형식이 틀린 입력을 거절하는지도 확인했다.
처음 CLI 실행에서는 작은 차이가 났다. 비교 대상은 CPU 스레드 하나를 사용했고 CLI는 기본 스레드 수를 사용하고 있었다. 스레드 조건만 맞춘 비교에서 차이가 사라지는 것을 확인한 뒤, CPU·FP32·한 스레드로 실행 조건을 고정하고 다시 검증했다. infer.py의 torch.set_num_threads(1)도 이 비교 조건을 맞추기 위한 코드다.
차이가 작다는 이유로 넘어가지 않았다. 원본을 추론용으로 옮기는 작업이었으므로, 먼저 같은 입력과 같은 조건에서 출력이 일치하는지 확인해야 했다. 이것은 예측 성능이 좋아졌다는 검증과는 다르다.
#업로드 이후에 한 확인
공개한 것은 가중치와 실행 예제, 문서 등을 포함한 12개 파일이었다. 게시 후 해당 revision의 파일을 다시 내려받고 크기와 SHA를 대조했다. 받은 파일로 CPU 추론을 실행해 원본과의 출력 비교, CLI 실행, 잘못된 입력 거절을 확인했다.
나중에 모델 카드를 영어로 고쳤을 때는 문서와 manifest가 바뀌었다. 새 revision의 12개 파일을 익명으로 내려받아 해시와 링크를 확인했다. 실행에 쓰는 나머지 파일이 앞선 검증본과 같았으므로, 문구를 고쳤다는 이유만으로 CPU 추론을 다시 돌리지는 않았다.
GitHub의 README·LICENSE·NOTICE 3개를 복구 게시한 후에도 준비본과 해시가 같은지 확인했다. 파일 게시, 다운로드 대조, 실행 검증을 각각 기록해 두니 어느 단계에서 무엇을 확인했는지 다시 찾을 수 있었다.
공개 대상은 Hugging Face 모델 패키지와 GitHub 소개 저장소다. 실행 코드·설정·가중치·입력 예제는 Hugging Face에 있고, GitHub는 README·LICENSE·NOTICE로 패키지를 소개한다. 10월 28일 로그인과 쿠키 없이 두 페이지를 다시 열어 HTTP 200을 확인했다. 공개 API에서도 두 저장소가 공개 상태인 것을 확인했다.
Hugging Face의 현재 revision은 기록에 남긴 영어 카드 보정본과 같았다. 이번에는 접근 상태와 revision을 대조한 것이고, 파일 다운로드·해시 대조·CPU 추론은 앞선 게시 검증의 결과다.
#재현했다고 말할 수 있는 범위
CPU 검증은 기존 환경과 정해진 합성 입력에서 수행했다. 새 컴퓨터에 처음부터 설치하는 과정, 실제 설비 원시값의 전처리, 외부 사용자의 실행은 확인하지 않았다. 소규모 실험 모델이며 실제 설비 제어용으로 검증한 결과도 없다.
기존 연구 인계 글에는 인계받은 사람이 직접 써 봤다는 피드백을 적었다. 이번 공개 작업에서는 아직 그런 피드백이 없다. 그때의 고객 사용 결과를 이번 모델의 사용 성과로 옮겨 적지 않았다.
이번에 끝낸 것은 받아 갈 파일과 시작할 예제를 정리하고, 공개된 실행본이 검증한 후보와 같은지 확인하는 일이었다. 다른 사람이 같은 과정을 따라 실행하는지는 다음 확인으로 남았다.