Tasteam Tech Blog

[AI] DeepFM 추천 시스템 성능 향상(+트러블 슈팅)

jayvi.oh — Sat, 28 Mar 2026 15:49:07 +0900

1. 추천 시스템 성능 테스트 시, 랜덤 추천 성능 메트릭보다는 높지만, 인기순 추천 성능 메트릭보다는 낮은 상황 발생. → 따라서 성능 향상을 위해 파생 피처 추가 진행했으나 성능 메트릭이 오히려 0으로 나오는 상황 발생.

[문제상황/원인분석]

문제상황

목표 성능 미달 → 파생 피처 추가 후 성능 메트릭 0

{
  "auc": 0.5060968660968661,
  "ndcg@5": 0.0,
  "ndcg@10": 0.0,
  "recall@5": 0.0,
  "recall@10": 0.0,
}

원인 분석
1. 목표 성능 미달
  1. 피처 수는 많지만 피처에 실제로 모델이 학습할 수 있는 preference signal의 부족.
2. 파생 피처 추가 후 성능 메트릭 0
  1. 새 feature들이 너무 한쪽으로 치우쳐 있고(train/test 분포도 다르고), 그 결과 모델이 거의 모든 샘플을 positive처럼 보는 방향으로 무너진 것

[대처 방안/해결]

대처 방안
1. 전체 추가 피처 중 몇개의 피처만 추가해서 성능 측정 진행
```
기존 baseline +

* `user_category_match`
* `user_region_match`
* `price_diff`
```

해결 (해결 완료)

목표 성능 달성 및 성능 메트릭 0 문제 해결

{
  "auc": 0.6426139601139602,
  "ndcg@5": 0.22093023283013208,
  "ndcg@10": 0.22093023283013208,
  "recall@5": 0.22093023283013208,
  "recall@10": 0.22093023283013208,
}

목표 성능 달성 및 이전 모델 baseline보다 향상.

* 이전 모델 baseline: `recall@10 ≈ 0.058`
* popularity baseline: `recall@10 ≈ 0.186`
* 이번 실험 1: `recall@10 ≈ 0.221`

[AI] evidence 학습이 LLM의 JSON 구조화 능력에 미치는 영향

jayvi.oh — Sat, 28 Mar 2026 13:19:17 +0900

배경 Qwen2.5-0.5B를 GPT-4o-mini로 Knowledge Distillation할 때, 학습 라벨에 evidence(근거 문장) 필드를 포함시켰다. 그런데 모델은 evidence를 제대로 출력하지 못했고 — bullets와 매칭되지 않거나 0으로 채우는 경우가 많았다. 프롬프트 제약, few-shot 변경, 후처리 로직 추가 등 다양한 시도를 해봤지만 성능 변화가 없었다.

가설 그렇다면 처음부터 evidence 없는 라벨로 학습시키는 게 낫지 않을까? 티처 모델도 evidence 생성에 capacity를 쓰지 않으면 나머지 태스크 품질이 더 높아질 것이고, 학생 모델도 그걸 더 잘 학습할 것이다.

실험 설계

A: evidence 포함 라벨로 학습 → 추론/후처리/최종 출력에서 evidence 제거
B: evidence 제외 라벨로 학습 → evidence 없이 추론

결과

JSON 파싱률스키마 정확도

A (evidence 포함 학습)	100%	100%
B (evidence 제외 학습)	52%	52%

가설이 틀렸다.

인사이트 모델이 evidence를 제대로 '출력'하지 못하더라도, evidence를 도출하려는 학습 과정 자체가 JSON 구조화 능력을 강화하는 regularization 역할을 한다. 정확한 메커니즘은 불명확하지만, 결과는 명확했다. 이 비교 실험을 수행하지 않았다면 최적 셋팅을 놓쳤을 것이다.

Metrics

1. evidence 라벨 학습, evidence 관련 프롬프트 제거, evidence 관련 후처리 제거, 최종 출력에서 evidence 키 제거 후 평가
ROUGE,BERTscore

LLM as a Judge

Structure Metrics

2. evidence 라벨 학습 x, evidence 관련 프롬프트 제거, evidence 관련 후처리 제거, 최종 출력에서 evidence 키 제거 후 평가 x

ROUGE,BERTscore

LLM as a Judge

Structure Metrics

[AI] 고빈도 동시 처리 상황에서 Model Load 초기화 Race로 인한 hard-death를 해결하자!

jayvi.oh — Tue, 3 Mar 2026 17:22:23 +0900

배경

아키텍쳐 선택을 위해 동기, 비동기 파이프라인 각각에 대해 부하테스트(ramp-up test)를 수행.

new_sync 파이프라인 요약 (완전 동기)

배치 내 단일 파이프라인 내 동기, 배치 내 단일 파이프라인 간 동기

new_async 파이프라인 요약 (완전 비동기)

배치 내 단일 파이프라인 내 비동기, 배치 내 단일 파이프라인 간 비동기

결과

sync와 async가 다운된 이유(로그 분석)

1) new_sync: “모델 파일이 없어서” 바로 예외로 터짐 (NoSuchFile)

new_sync는 요청 처리 중 get_vector_search → VectorSearch → fastembed(TextEmbedding) → onnxruntime.InferenceSession으로 가다가,

/tmp/fastembed_cache/.../onnx/model.onnx 파일이 없어서
onnxruntime ... NoSuchFile 예외
그 결과 POST /api/v1/sentiment/analyze/batch 가 500으로 떨어지고
“Unhandled exception”으로 찍혀 있음.

이건 전형적으로 다운로드/캐시가 아직 완성되기 전에 로드하려 했거나, 캐시가 깨졌거나, 경로가 휘발(/tmp)이라 컨테이너 생명주기/동시성에 취약할 때 나옴.

2) new_async: NoSuchFile은 안 보이는데 “로드가 여러 번” 일어남 (중복 초기화/동시 초기화 정황)

new_async 로그에는 같은 임베딩 모델이

Dense 벡터 모델 로드 완료가 여러 번 반복.

즉, new_async는 “파일이 없어서 즉시 폭발”보다는,

여러 요청/태스크가 동시에 들어오면서 VectorSearch(또는 임베딩 모델)가 중복 초기화되는 정황이 더 강해 보임.
이 상태도 결국 캐시 다운로드/로드 race를 만들기 쉬워서, 타이밍 나쁘면 new_sync처럼 NoSuchFile로도 이어질 수 있음(이번 로그에선 그 전에 “운 좋게” 로드가 성공했을 가능성이 큼).

결론: “로그가 다르다” = 파이프라인 문제가 아니라, 공통 원인(임베딩 모델 캐시/초기화 레이스)가 다른 형태로 표출된 것

new_sync는 첫 로드 타이밍이 더 공격적/동시성에 더 취약해서 “파일 없음”으로 터진 흔적이 명확하고
new_async는 중복 로드(동시 초기화)가 보이고 , 당장 NoSuchFile은 안 찍혔지만 구조적으로 안전하다고 보긴 어려움.

아키텍쳐 선택에 대한 현실적인 답

이 로그만으로 “new_async가 더 낫다/ new_sync가 더 낫다”를 아키텍처 선택 근거로 쓰긴 약함.
대신 이 로그로는 “선택 전에 반드시 고쳐야 할 공통 결함”이 드러났다고 보는 게 정확함:

반드시 고칠 것 (둘 다 해당)

VectorSearch(임베딩 모델)도 sentiment처럼 싱글톤 초기화 락(DCL) 적용
→ 초기화 구간에 동시 진입을 막는 락/세마포어로 중복 로드·캐시 race 제거.
서버 시작 시 preload/warm-up
→ 모델 + 토크나이저 + 첫 inference까지 강제 warm-up해서 “첫 요청에서 다운로드/로드”가 일어나지 않게.
캐시 경로를 /tmp가 아니라 볼륨으로 고정
→ HF/ONNX 캐시가 공유 볼륨(또는 이미지 bake-in)으로 안정적으로 존재하도록 (컨테이너 재시작/동시성에 덜 취약).
readiness(준비됨) 되기 전까지 트래픽을 안 받음
→ K8s readinessProbe 등으로 준비 완료 시점을 명시하고, 그 전에는 LB/트래픽이 들어오지 않게.
(옵션) HF 토큰 설정해서 rate limit/불안정 다운로드 가능성 줄이기 (로그에도 unauth 경고가 보임).

이걸 한 뒤에야 “sync vs async” 성능/안정성 비교가 의미 있게 됌.

코드로 전부 반영했을 때의 이점

1. 안정성 (ramp-up·재시작)

조치	이점
싱글톤 락 + 초기화 락	ramp-up 시 여러 요청이 동시에 임베딩/모델 로드를 트리거하지 않음 → 중복 로드·캐시 race 제거 → NoSuchFile/ONNX 에러 감소.
warm-up(모델+토크나이저+첫 inference)	첫 실제 요청에서 로드가 일어나지 않음 → 첫 요청 타임아웃/500 가능성 감소.
캐시 볼륨/이미지 고정	`/tmp` 휘발·재시작 시 캐시 소실 방지 → 재시작 후에도 즉시 서빙, 다운로드 재시도로 인한 불안정 감소.
readiness 전까지 트래픽 차단	모델/캐시 준비 전에 요청이 들어오지 않음 → "아직 준비 안 된 서버"에 부하가 걸리는 상황 자체가 사라짐.

→ ramp-up/재시작 시 크래시·soft-death 확률 감소, 로그에서 보이던 실패 패턴이 재현되기 어려워짐.

2. 실서비스 측면 이점

관점	이점
가용성·SLA	롤링 배포·스케일아웃 시 “준비 안 된 인스턴스”에 트래픽이 가지 않음 → 500/타임아웃 감소. 피크/갑작스런 트래픽에서도 중복 초기화로 인한 크래시 가능성 감소.
사용자 체감(UX)	첫 요청에서 cold start가 발생하지 않음 → 첫 요청 지연·간헐적 500·재시도 감소.
운영·배포	“언제 트래픽 받을 수 있는지”가 명확해져 롤링 업데이트·오토스케일 시 동작이 예측 가능. 재시작 후 캐시 유지로 복구 시간(RTO) 단축. 레이스 컨디션 성 장애 감소.
비용·리소스	캐시 재다운로드 감소 → 네트워크·스토리지·기동 시간 절감. 준비 전 트래픽 차단으로 불필요한 재시도·CPU 사용 감소.

→ 실서비스에서도 가용성, 체감 품질, 운영성, 비용 측면에서 이득이 있음.

new_async가 다운된 이유 (요약)(로그+코드 포함 분석)

원인: new_sync와 같은 임베딩 모델 캐시/초기화 레이스인데, async 구조 때문에 동시 진입이 더 많이 일어나서 더 빨리/같이 죽은 것.

1) 로그에서 보인 것 (new_sync와의 차이)

new_sync: NoSuchFile (onnx 파일 없음) → 바로 크래시.
new_async:
- NoSuchFile이 안 보이거나,
- Dense 벡터 모델 로드 완료가 여러 번 반복 (같은 모델이 중복 로드되는 정황).

즉, new_async는 “한 번에 파일 없음으로 터진다”기보다 여러 요청이 동시에 get_vector_search / VectorSearch 초기화를 타면서 중복 초기화·캐시 race가 난 상황.

2) 왜 async에서 더 심해졌나

async → ramp-up 시 여러 요청이 동시에 들어옴.
그때 VectorSearch 싱글톤에 락이 없었음 → 여러 코루틴이 동시에 “아직 없네?” 하고 여러 번 생성 시도 또는 동시에 같은 캐시/모델 로드.
그 결과:
- 캐시 다운로드/캐시 쓰기 race 발생,
- 타이밍 나쁘면 new_sync처럼 NoSuchFile/로딩 실패 → 프로세스 크래시로 이어짐.

문서 표현 그대로면, “구조적으로 async가 더 빨리 죽었을 가능성 높음”.

3) 한 줄로 정리

new_async가 다운된 이유
= 임베딩(및 HF/ONNX) 캐시·초기화 레이스가 근본 원인이고,
async라서 동시에 많은 요청이 초기화를 트리거해 그 레이스가 더 잘 걸리고, 결국 로딩 실패/크래시(hard-death) 로 이어진 것.

그래서 문서에서 VectorSearch DCL 락, warm-up, 캐시 경로, readiness를 “반드시 고칠 것”으로 넣고, 그걸 코드에도 반영한 상태.

문서와 로그 해석 기준으로 보면, “왜 new_async에서는 NoSuchFile이 안 떴는지”는 두 가지로 설명할 수 있음.

1. 타이밍/운 — “그 전에 로드가 성공했을 가능성”

문서에 나온 대로:

이 상태도 결국 캐시 다운로드/로드 race를 만들기 쉬워서, 타이밍 나쁘면 new_sync처럼 NoSuchFile로도 이어질 수 있어(이번 로그에선 그 전에 "운 좋게" 로드가 성공했을 가능성이 큼).

new_sync: 요청이 순차로 들어와서, 첫 요청이 너무 일찍 모델 로드를 시도 → 캐시 다운로드가 끝나기 전에 model.onnx를 열려다 → NoSuchFile.
new_async: 요청이 동시에 많이 들어와서,
- 여러 코루틴이 동시에 초기화를 트리거하고
- 그중 어느 하나가 먼저 다운로드/로드를 끝내고
- 나머지는 그 뒤에 로드를 시도해, 그때는 이미 파일이 있어서 NoSuchFile이 안 나온 경우.

즉, 같은 race가 있어도 “파일 없을 때 로드”를 누가 먼저 겪느냐가 sync/async 타이밍에 따라 달라져서,
이번 new_async 로그에서는 NoSuchFile이 발생하기 전에, 어떤 요청이 “운 좋게” 로드에 성공한 타이밍이었을 수 있다는 뜻.

2. 다른 이유로 먼저 죽었을 수 있음

new_async는 중복 초기화(Dense 벡터 모델 로드 완료 여러 번)가 보이고, 그 과정에서:
- 다른 예외(중복 로드, 리소스 부족, 레이스로 인한 다른 에러)로 프로세스가 먼저 죽었거나
- NoSuchFile이 나올 경로(예: 나중에 오는 요청이 아직 캐시가 안 된 상태에서 로드 시도)까지 가지 못하고 크래시했을 수 있음.
그러면 로그에는 NoSuchFile이 안 찍히고, “여러 번 로드 완료”만 보이다가 그다음에 죽은 형태가 됨.

정리

구조적으로는 new_async도 new_sync와 같은 캐시/초기화 레이스 때문에 NoSuchFile이 날 수 있는 상황.
이번 로그에서 NoSuchFile이 안 보인 이유는:
1. 타이밍 — 동시 요청 중 일부가 “캐시 준비된 뒤” 로드를 시도해서, 이번 런에서는 NoSuchFile이 안 나왔을 가능성(문서의 “운 좋게 로드 성공”),
2. 또는 그 전에 중복 초기화/다른 예외로 프로세스가 죽어서, NoSuchFile이 발생할 기회가 없었을 가능성,

둘 다 설득력 있습니다. 그래서 문서에서 “당장 NoSuchFile은 안 찍혔지만 구조적으로 안전하다고 보긴 어려워”라고 한 것.

new_sync vs new_async — 죽는 방식 비교

구분	new_sync	new_async
로그에 보이는 것	`NO_SUCHFILE`, `Load model ... onnx/model.onnx failed. File doesn't exist` → Unhandled exception	`Dense 벡터 모델 로드 완료`가 여러 번 반복 (중복 초기화). NoSuchFile은 안 보일 수 있음
트리거	(상대적으로) 순차 요청 중, 너무 이른 요청이 모델 로드를 시도	동시에 많은 요청이 들어와서 여러 코루틴이 한꺼번에 VectorSearch/모델 로드 트리거
직접 원인	캐시 다운로드 끝나기 전에 한 요청이 `model.onnx` 로드 시도 → 파일 없음 → 예외	여러 요청이 동시에 초기화 → 중복 로드·캐시 race → 그 과정에서 실패/크래시
결과	Hard-death: unhandled exception → 프로세스 종료 → 컨테이너 사라짐	Hard-death: 같은 근본 원인(캐시/초기화 레이스)으로 역시 프로세스 종료. “더 빨리” 죽었을 가능성

한 줄로 정리

new_sync:
“한 요청이 너무 일찍 로드 시도 → NoSuchFile로 바로 터짐”이 로그에 그대로 찍힌 명백한 크래시.
new_async:
“여러 요청이 동시에 초기화를 타서 로드가 여러 번 돌고, 그 레이스로 같은 종류의 크래시”가 나지만,
로그에는 중복 로드가 먼저 보이고, NoSuchFile은 안 보이거나 다른 예외로 죽을 수 있음.

즉, 근본 원인(캐시/초기화 레이스)은 같고,

new_sync = “너무 이른 한 번의 로드” → NoSuchFile로 확실히 죽음.
new_async = “동시에 여러 번 로드” → 중복 초기화 정황으로 죽음.
죽는 방식(로그·트리거)만 다르고, 둘 다 hard-death*.

최종 결론

1. 아키텍쳐 선택

new_async 선택. 왜냐면, 비동기 아키텍쳐가 프로세스가 OOM으로 죽지 않게 해주기 때문에 비동기 아키텍쳐를 선택했다. 그러고, 위에서 말한 현재 비동기 아키텍쳐의 문제점을 해결하면 된다.

1. new_async 메커니즘 변경

Race Condition이 원인이라는 걸 알았으니 결론은 하나, 위에서 말했듯, 모델을 start-up 단계에서 로드하는 식으로 변경해. 앱이 모델 다운로드를 먼저 진행하고, 켜지는 방식이다. 이를 통해 콜드 스타트로 인한 Race Condition을 막는다.

2. 추가적으로 비동기에서 최대한 OOM으로 죽지 않게 하려는 여러 조치

우선 비동기 방식으로 이벤트 루프가 돌 때, 동기 호출이 안에 있다면, 루프는 반드시 막히고, 결국 그게 OOM으로 이어진다.

따라서 추가적인 조치를 취했다.

a. 스레드 블로킹을 LLM에게도 적용.

기존엔 스레드 블로킹이 sentiment 모델만 필요한 줄 알았지만, 모델은 기본적으로 sync 연산이다. 따라서, LLM도 마찬가지고, 따라서, LLM에 대해서도 to_thread()를 적용해 스레드 블로킹을 적용한다.

b. 비동기큐 설정과 워커 설정과 세마포 설정

현재 세마포는 설정이 안되어 있었다. 비동기 루프로 돌거면, 세마포는 사실 필수다. 왜냐면, 만약 세마포가 없다면, 동시처리 수가 늘어나는데, 그 처리가 감당 가능한 양을 벗어난다면, OOM이 발생한다. 비동기큐는 개인적으로는 요청을 비동기 루프에서 명시적으로 관리할 수 있기에 필수라고 생각한다. 또한, 비동기 루프 안에 sync 연산인 sentiment 모델이나, LLM이 있다면, async 연산처럼 볼수가 없기 때문에, 처리 성능에 대한 명시적 관리가 필요하다. 그 역할을 비동기큐가 한다고 생각한다. 구체적으로 말하면, 현재 LLM의 태스크는 리뷰 요약 태스크이기 때문에, 길이에 따라 연산의 양이 달라진다. 그럼, 큐이기 때문에 Starvation 문제가 발생할 가능성이 높다. 이에 대해 기본 셋팅인 FIFO말고 라운드로빈 방식을 적용해 볼수도 있고, 필요하면 리뷰 길이에 따라 큐의 순서를 다르게 하는 커스텀 메커니즘을 짜는 것도 가능하다. 워커는 동시처리를 위해 존재한다. 워커가 있어야 sync 연산인 모델 연산도 동시처리가 가능해진다.

[AI] GC(Garbage Collection)과 Batch size 변경으로 GPU 메모리 확보를 해보자!

jayvi.oh — Tue, 3 Mar 2026 16:03:02 +0900

0. GC(Garbage Collection)란?

GC(Garbage Collection)는 프로그램이 더 이상 참조하지 않는 객체를 자동으로 메모리에서 해제하는 메모리 관리 메커니즘이다.
Python은 기본적으로 Reference Counting 방식을 사용하며, 순환 참조는 별도의 GC가 주기적으로 회수한다.
이 특성 때문에 객체 참조가 남아 있으면 메모리가 즉시 반환되지 않을 수 있다.

1. Trouble Shooting

총 문제가 3개 발생했다.

1. Eval 단계에서 OOM (가장 빈번)

2026-03-01T00:35:51.150992577Z torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 9.27 GiB. GPU 0 has a total capacity of 23.52 GiB of which 7.48 GiB is free. Including non-PyTorch memory, this process has 16.03 GiB memory in use. Of the allocated memory 15.09 GiB is allocated by PyTorch, and 483.26 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

CUDA가 Out Of Memory가 발생했다. 현재 GPU는 23.52 GiB가 총 수용량이고, 7.48 GiB가 Free 지만, 9.27 GiB를 할당하려고 한다. 어떠한 파이토치 메모리도 포함되어 있지 않다면, 이 프로세스는 16.03 GiB 메모리를 사용 중이다. 할당된 15.09 GiB 메모리는 파이토치에 의해 할당 됐고, 483.26 MiB는 파이토치로 부터 예약됐지만, 할당되지는 않았다. 만약, 예약됐지만, 할당되지 않은 메모리가 크다면, 파편화를 피하기 위해, PYTORCH_CUDA_ALLOC)CONF=expandable_segments를 설정해라. 메모리 관리에 대한 문서는 이러하다. https://pytorch.org/docs/stable/notes/cuda.html#environment-variables

CUDA semantics — PyTorch 2.10 documentation

CUDA semantics Created On: Jan 16, 2017 | Last Updated On: Dec 09, 2025 torch.cuda is used to set up and run CUDA operations. It keeps track of the currently selected GPU, and all CUDA tensors you allocate will by default be created on that device. The sel

docs.pytorch.org

- **발생**: step 100 근처 첫 eval 시

- **메시지**: `Tried to allocate 9.27 GiB. GPU 0 has a total capacity of 23.52 GiB of which 7.48 GiB is free.`

- **원인**: eval 시 gradient checkpointing 미적용, 기본 batch_size로 학습과 동일하게 사용 → 추가 ~9GB 필요

**적용한 대응**: `per_device_eval_batch_size=1` 설정 (train_qlora.py)

2. 이전 run OOM 이후 "Some modules dispatched on CPU"

2026-03-01T00:36:12.384434846Z ValueError: Some modules are dispatched on the CPU or the disk. Make sure you have enough GPU RAM to fit the quantized model. If you want to dispatch the model on the CPU or the disk while keeping these modules in 32-bit, you need to set `llm_int8_enable_fp32_cpu_offload=True` and pass a custom `device_map` to `from_pretrained`. Check https://huggingface.co/docs/transformers/main/en/main_classes/quantization#offload-between-cpu-and-gpu for more details.

몇몇 모듈이 디스크의 CPU에서 디스패치 됐다. 너의 양자화된 모델에 맞는 충분한 GPU 램을 확보해라. 이 모듈들이 32 비트를 지키면서 CPU나 디스크에서 디스패치 하고 싶다면, 너는 'llm_int8_enable_fp32_cpu_offload=True'를 설정하거나, 커스텀 'device_map'을 'from_pretrained'로 넘겨라. 더 많은 세부 사항을 알고 싶으면 https://huggingface.co/docs/transformers/main/en/main_classes/quantization#offload-between-cpu-and-gpu

Quantization

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

을 확인해보라.

- **발생**: OOM 후 같은 프로세스에서 다음 run 시작 시 `from_pretrained(..., device_map="auto")`

- **원인**: GPU 메모리 비정상/파편화 → device_map이 일부 CPU로 보냄, 4bit BNB는 CPU 오프로드 미지원

**적용한 대응**: run_train 시작 시 `gc.collect()` + `torch.cuda.empty_cache()` (train_qlora.py)

3. batch_size=4 + max_seq_length=2048 조합 OOM

2026-03-01T00:35:58.459956338Z torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 3.79 GiB. GPU 0 has a total capacity of 23.52 GiB of which 391.75 MiB is free. Including non-PyTorch memory, this process has 23.12 GiB memory in use. Of the allocated memory 22.35 GiB is allocated by PyTorch, and 314.64 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

1번과 동일

- **발생**: 학습 첫 스텝에서 `22.35 GiB allocated`, 24GB 초과

**적용한 대응**: sweep에서 `batch_size`를 `[1, 2]`로 제한 (wandb_sweep_qlora.yaml)

적용 요약

| 원인 | 적용 |

|------|------|

| Eval OOM | per_device_eval_batch_size=1 |

| 연쇄 실패 (CPU 디스패치) | run_train 시작 시 gc + empty_cache |

| batch_size 4 OOM | batch_size values: [1, 2] |

[AI] Prefect로 지식증류(Knowledge Distillation) 파이프라인을 완전 자동화 해보자!

jayvi.oh — Mon, 2 Mar 2026 15:05:51 +0900

0. Prefect란?

https://www.prefect.io/

Prefect - Workflow Orchestration & AI Infrastructure

Orchestrate workflows with Prefect. Build AI applications with Horizon. Open-source foundations, production-ready platforms.

www.prefect.io

Airflow, Dagster와 동일한 워크플로우 완전 자동화 오케스트레이션 프레임워크이다. 하지만, prefect만의 장점은 Pythonic한 점이고, 데코레이터 기반 동작이라 셋팅이 매우 가볍다. 이러한 특성 때문에, 복잡한 워크플로우와 파이썬 환경에 해당하는 ML 워크플로우에서 가장 사용하기 좋은 오케스트레이션 프레임워크이다.

Airflow와 Dagster에 대한 비교는 후술하겠다.

(Prefect 공식에도 이 비교에 대한 문서가 존재한다.)

https://www.prefect.io/compare/airflow

Prefect vs Airflow - Modern Workflow Orchestration

Learn why engineering teams are choosing Prefect over Airflow. 60-70% cost savings, Python-first simplicity, and hybrid architecture that keeps your data in your infrastructure.

www.prefect.io

https://www.prefect.io/compare/dagster

Prefect vs Dagster - Python-First Workflow Orchestration

Learn why engineering teams are choosing Prefect over Dagster. 60-70% cost savings, days to value vs months, and Python-first simplicity without forced asset restructuring.

www.prefect.io

1. 지식증류란?

작은 파라미터의 모델에 큰 파라미터의 모델을 학습시켜, 작은 파라미터 모델이 큰 파라미터 모델처럼 행동하게 만드는 기법이다. 즉, 경량화기법이지만, 단순 양자화의 추론 능력 감소에 대한 문제를 발생시키지 않는 방법이다.

지식증류의 과정

큰 모델로 라벨링을 진행한다. -> 작은 모델이 이 큰 모델이 만든 라벨을 라벨로 삼아 학습을 진행한다 (SFT(Supervised Fine-tunning))

2. 지식증류 파이프라인(+Wandb)

a. Labelling

처음 고민은, Teacher 모델을 뭐로 할지였다. Student 모델은 Qwen2.5-0.5B-instruct로 정했지만, Teacher 모델은 Openai gpt 모델이어야 할까? 아니면, opensource 모델이지만, 다른 계열인 LLama,Gemma를 써야할까? 아니면, 같은 계열인 Qwen 계열 모델을 사용해야할까?

고민의 사고는 이렇다.

Qwen에 같은 Qwen을 학습 시키면, 학습이 편향되지 않을까? Qwen모델은 Alibaba에서 학습 데이터,학습 방식,아키텍쳐를 매번 다르게 쓴다기 보다 기존 데이터에서 확장, 학습 방식,아키텍쳐도 약간의 변경만 발생할텐데, 학습의 편향이 일어나지는 않을까? 즉, 오히려 과적합이 발생하는거 아닐까? 라는 걱정이었다.

Openai gpt 모델은 한국어 도메인에 대한 학습이 다른 모델 대비 잘되어 있고, 모델 자체의 성능이 현재 기준 상당히 하이엔드이다. 따라서, 사용하는게 좋은 선택이라는 생각은 들었지만, 내가 기존에 아는 지식증류와는 다른거 같아서 일단 바로 선택을 하지는 않았다.

다른 계열 LLama, Gemma에 대한 고려를 진행했지만, 한가지 문제점은, 현재 서빙 프레임워크로 vllm을 사용하는데, 이번에 성능 측정을 진행할때, Qwen모델은 애초에 vllm에 맞게 학습되어 vllm에서 추론이 잘되는 모습을 보였지만, llama, gemma는 vllm과의 호환성이 매우 떨어져 추론 속도도 늦고, 아예 에러를 내놓는 경우도 있었다. 따라서, Qwen의 vllm에 호환성있게 학습된 이 특성이 llama gemma로 부터 학습할때 해쳐지면 어떡하지? 라는 걱정이었다.

결론은 이러하다.

알아본 바론, 내가 우려한대로 Qwen 모델에 대한 과적합 문제는 발생하지만, 그게 그렇게 치명적인 영향을 주지는 않았다. 또한, 위에서 말한대로 Qwen 모델이 가진 vllm 호환성에 대한 유지를 위해서도, 같은 Qwen 모델을 사용하는게 맞았다. 과적합에 대한 문제를 방지하는 목적으로, 그리고 고품질 라벨을 위한 목적으로, Openai-gpt-4o-mini를 통해 라벨을 생성하되, qwen2.5-7B-instruct 모델도 훈련 라벨을 생성하는 쪽으로 변경했다. Validation label, Test label은 당연히 고품질 라벨인 Openai label을 사용했다.

따라서, 현재 라벨의 구성은 이러하다.

Train data split

Train 500 gpt-4o-mini label

Train 1302 Qwen2.5-7B-instruct

Val data split

Val 944 gpt-4o-mini label

Test data split

Test 1277 gpt-4o-mini label

b. Train

이제 훈련을 시작해야 한다. 훈련은 이 라벨을 학습루프에 돌려 모델이 Loss를 줄여가며, 선생 모델의 사고방식을 어느정도 학습하게 해야한다. 학습에 대한 추적이 필요하다. 현재 학습이 잘되고 있는지, 모니터링이 필요하다고 느꼈다. 모니터링을 위해 Wandb를 도입했다.

https://wandb.ai/site/ko/

Weights & Biases: The AI Developer Platform

Weights & Biases는 모델을 학습 및 파인튜닝하고, 실험부터 생산까지 모델을 관리하며, LLM으로 구동되는 GenAI 애플리케이션을 추적 및 평가할 수 있는 선도적인 AI 개발자 플랫폼입니다.

wandb.ai

모니터링 목적으로 도입을 했지만, 좀 더 알아보다 보니, wandb의 sweep 기능과 artifact 기능이 존재했다. sweep이 모델 학습의 편의를 제공해주었고, artifact가 데이터/모델 버전 관리를 제공해 주었다.

Wandb의 모니터링에 대해 알아보자.

현재는 Runpod의 pod 컨테이너에 띄워서 학습이 돌고 있고, 내부에서 Wandb API에 메트릭을 전달해주는 중이다. Wandb의 특이한 점은, matplotlib 같은 정적 그래프 시스템이 아닌, Grafana처럼 실시간 시각화를 지원한다는 점이다. 따라서, 학습의 실시간 추적이 가능하다.

Eval(이걸 기준으로 Earlystopping을 결정한다.)

Train

GPU Metric

GPU Metric, Network Traffic

Disk, CPU, Memory 등 기본 지표

Memory, CPU 등 기본 지표

태블로처럼 인터랙티브 기능을 제공한다

좌측에 Run들이 표시된다. 좌측의 모든 Run이 우측에 모든 선에 해당한다. 초록색 불이 들어와있는건 현재 학습이 진행중인 Run을 의미한다. 현재 Run이 2개가 같이 진행중인건, 현재 학습 시간 단축을 위해 멀티 Pod을 이용해 학습을 진행중이기 때문이다.

이런식으로 필터 기능이 존재한다. running,finisihed, failed, crashed 등 다양한 run의 상태에 대해 필터링이 가능하다.

이런식으로 태블로처럼 인터랙티브 기능을 지원한다.

참고로 GPU 및 시스템 메트릭은 내가 전혀 설정하지 않았다. wandb API가 알아서 수집을 진행해주는 것이다. 나는 처음에 단순 학습 모니터링 목적으로만 사용했던건데, 이 기능 때문에 wandb의 편리성에 매우 놀랐다.

Wandb의 장점 중 하나는 Sweep 기능이다. 위 사진을 보면 많은 run이 존재하는걸 볼 수 있다. 즉, run=학습 사이클 단위이고, sweep으로기능을 사용하면, 학습 사이클만큼 돌리고, 그게 다가 아니고, yaml 파일로 학습 자체의 관리를 수행해준다. 현재 yaml 파일 설정은 이러하다.

# wandb Sweep 설정: QLoRA SFT 하이퍼파라미터 탐색 (cap_strategy.md 반영)

# 사용: wandb sweep scripts/wandb_sweep_qlora.yaml

# 실행: WANDB_SWEEP_LABELED_PATH=... WANDB_SWEEP_OUTPUT_DIR=... wandb agent <sweep_id>

# 환경변수(필수): WANDB_SWEEP_LABELED_PATH, WANDB_SWEEP_OUTPUT_DIR, WANDB_API_KEY, WANDB_PROJECT

program: scripts/run_qlora_sweep.py

method: bayes

metric:

name: eval_loss

goal: minimize

run_cap: 50

parameters:

# 핵심 하이퍼 6개 (cap_strategy §3)

learning_rate:

distribution: log_uniform_values

min: 1.0e-5

max: 5.0e-5

batch_size:

values: [1, 2]

grad_accum:

values: [1, 2, 4, 8]

num_epochs:

values: [1, 2, 3]

warmup_ratio:

distribution: uniform

min: 0.0

max: 0.1

weight_decay:

distribution: log_uniform_values

min: 1.0e-7

max: 1.0e-3

max_seq_length:

values: [512, 1024, 2048]

# 고정 (탐색 공간 축소)

student_model:

value: "Qwen/Qwen2.5-0.5B-Instruct"

gold_oversample_ratio:

value: 0.25

target_modules:

value: "q_proj,v_proj,k_proj,o_proj,gate_proj,up_proj,down_proj"

value: 8

alpha:

value: 16

c. Eval,Test

학습이 끝난 모든 모델은 Wandb의 Artifact라는 저장소에 저장된다. 그 Artifact에서 Best run을 자동으로 로컬에 다운로드를 진행한다. Sweep은 또한 Best Run 즉, 가장 학습이 잘된 모델을 자동으로 선택해주는 기능이 존재한다. 이 Sweep이 선택해준 Best run 모델을 다운로드 한다.

학습 기준은 ROUGE,BERTscore를 사용한다. 왜냐하면 현재 하는건 SFT이기 때문에, 라벨 문장과 student 모델의 유사도를 측정해, student 모델이 잘 추론하는지를 평가해야 하기 때문이다.

3. Prefect를 기반한 지식증류 완전 자동화 파이프라인 구축

자, 이제 이 모든 과정을 자동화 하면서, 워크플로우를 쉽게 구축해볼까?

Prefect는 한마디로 말해 상태(State)를 관리하는 오케스트레이터이다.

Prefect는 크게 Flow, task가 존재한다. Flow는 분기이고, Task는 분기 안에 있는 동작에 해당한다.

현재 파이프라인의 아키텍쳐

Raw 데이터 데이터 증강 - wandb artifact에 데이터 업로드 - 데이터 train/val/test 분할 - wandb artifact에 업로드 - train/val 라벨링 데이터를 pod의 네트워크 볼륨으로 업로드(Runpod S3 compatible을 이용) - pod on - 데이터 라벨링 - pod off - pod on - wandb의 sweep으로 학습 진행 - wandb에서 모니터링 - 모든 학습된 모델을 wandb artifact에 저장 - pod off - wandb artifact에서 sweep이 골라준 best run을 로컬로 다운로드 - 로컬에서 val,test 라벨 데이터에 대해 ROUGE로 평가 수행.

2026.03.28

--> 이렇게 한번에 돌아가게 구성했지만, 아티팩트 다운로드 이후 평가 단계가 돌아가지 않았다.

따라서 현재는,

1. sweep on pod -> download artifact

2. evaluation 으로 진행된다.

(현재 도커 컴포즈도 이렇게 나누어 놨다.)

이 구성이 위에서 말한 문제점 해소가 가능하면서, 학습과 추론 이렇게 명확히 나뉘어 더 관리에 용이하다.

도메인은 정상인데 왜 접속이 안 될까? — ISP DNS 캐시가 만든 SERVFAIL 트러블슈팅

clay.kim — Sun, 22 Feb 2026 14:39:01 +0900

도메인은 정상인데 왜 접속이 안 될까? — ISP DNS 캐시가 만든 SERVFAIL 트러블슈팅

안녕하세요, Tasteam에서 Cloud 팀을 맡고 있는 clay입니다.

"저는 접속이 되는데, 다른 팀원은 접속이 안 돼요."

인프라를 운영하다 보면 이런 제보를 종종 받게 됩니다. 도메인 설정은 분명히 끝냈는데, 특정 사용자만 접속이 안 되는 상황.

가비아에서 구매한 tasteam.kr 도메인을 Cloudflare에 연결한 직후, 저희도 정확히 이 문제를 마주했습니다.

특히 KT 네트워크 환경에서 nslookup tasteam.kr을 실행하면 IP 주소를 찾지 못하고 SERVFAIL 오류를 반환했어요. 모든 설정은 정상이었는데, 대체 무엇이 문제였을까요?

오늘은 이 문제를 어떻게 진단하고 해결했는지, 그 과정을 공유해 드리겠습니다.

환경

먼저 당시 저희의 환경 구성입니다. 가비아에서 도메인을 구매하고, DNS는 Cloudflare를 통해 운영하고 있었어요.

항목 내용

도메인 레지스트라	가비아 (Gabia)
DNS	Cloudflare
문제 발생 네트워크	KT
정상 동작 네트워크	SKT, LG U+, Google DNS 등

처음엔 컴퓨터 문제인 줄 알았습니다

이상했던 건 클라우드 팀원들은 전원 정상 접속이 되는데, 백엔드 팀원들만 접속이 안 된다는 점이었어요. 같은 도메인, 같은 시간인데 팀마다 결과가 다르니 처음엔 개인 PC 문제를 의심했습니다.

그래서 맥북의 로컬 DNS 캐시를 삭제해 봤습니다.

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

하지만 캐시를 비워도 증상은 그대로였어요. 로컬 캐시가 원인이 아니라면, 그 위 단계에서 무언가 막고 있다는 뜻이었습니다.

이후 확인해 보니, 클라우드 팀원들은 공용 DNS(8.8.8.8 등)를 사용하고 있었고, 백엔드 팀원들은 ISP 기본 DNS(KT)를 그대로 쓰고 있었던 거예요. 사람의 차이가 아니라 네트워크 설정의 차이였습니다.

증상 확인

이 단서를 바탕으로, KT 네트워크 환경에서 nslookup을 실행해 봤습니다.

nslookup tasteam.kr

nslookup-kt-servfail

KT DNS 서버(168.126.63.1, 168.126.63.2)가 SERVFAIL을 반환하고 있었습니다.

반면, 같은 시간에 다른 네트워크에서는 정상적으로 IP가 반환됐어요. 도메인 자체의 문제라기보다는 특정 DNS 서버의 문제가 의심되는 상황이었습니다.

가설 수립

SERVFAIL 오류와 "일부 사용자에게만 발생"이라는 조건을 바탕으로 세 가지 가설을 세워 봤습니다.

가설 1. DNS 전파 지연

가비아에서 Cloudflare로 네임서버를 변경한 직후이므로, 변경 정보가 전 세계 DNS 망에 아직 전파되지 않았을 가능성이 있었습니다.

가설 2. 설정 오류

가비아의 네임서버 설정 또는 Cloudflare의 DNS 레코드(A, CNAME 등)가 잘못 구성되었을 가능성도 있었어요.

가설 3. DNSSEC 서명 불일치

SERVFAIL의 가장 흔한 원인 중 하나인데요. 가비아에 남아있는 이전 DNSSEC 서명 정보와 Cloudflare의 새 서명 정보가 일치하지 않아, 보안 검사를 수행하는 DNS 서버가 응답을 거부하는 경우입니다.

검증 과정

1단계 — 네임서버 전파 확인

dnschecker.org를 통해 tasteam.kr의 NS 레코드를 조회했습니다.

Cloudflare의 네임서버(dakota.ns.cloudflare.com, gigi.ns.cloudflare.com)가 전 세계적으로 정상 전파된 것을 확인할 수 있었어요.

dnschecker-ns-정상전파

결과: 정상 → 가설 1 기각

2단계 — Cloudflare 설정 확인

Cloudflare 대시보드에서 다음 내용을 확인했습니다.

A 레코드가 정확한 서버 IP를 가리키고 있음
프록시(주황색 구름) 상태가 활성화됨

결과: 정상 → 가설 2 기각

3단계 — DNSSEC 설정 확인

가비아: DNSSEC 관련 설정 메뉴를 찾을 수 없었습니다.
Cloudflare: DNSSEC 기능이 비활성화("Enable DNSSEC" 버튼 표시) 상태였어요.

결과: 양쪽 모두 비활성화 상태 → 가설 3의 일반적인 시나리오와 불일치

4단계 — DNS 경로 정밀 분석

dnsviz.net을 사용하여 루트(.)에서부터 tasteam.kr까지의 전체 DNS 신뢰 체인을 시각적으로 분석했습니다.

분석 결과, 어떠한 오류(빨간색 Error/Bogus)도 발견되지 않았어요.

dnsviz-신뢰체인-정상

결과: 도메인 자체의 기술적인 설정은 완벽한 상태

모든 설정이 정상인데 왜 SERVFAIL인가?

여기서 관점을 전환했습니다.

도메인 설정에는 문제가 없다면, 문제는 DNS 해석(Resolution) 단계에 있을 수밖에 없었어요.

DNS가 동작하는 과정

사용자 브라우저
    ↓ tasteam.kr 요청
사용자 PC의 DNS 설정 (예: KT DNS)
    ↓ 재귀 질의
KT DNS 서버 (Recursive Resolver)
    ↓ 캐시에 있으면 캐시 응답, 없으면 상위 질의
루트 DNS → .kr DNS → Cloudflare NS
    ↓ 응답
최종 IP 반환

여기서 핵심은 Recursive Resolver의 캐시입니다.

KT DNS 서버가 도메인 설정 변경 과정 중에 발생한 일시적인 오류 응답을 캐시에 저장해 둔 거예요. 이후 정상적인 설정이 완료되었음에도 캐시가 만료되기 전까지 계속 오래된 오류 응답을 반환하고 있었습니다.

결정적 검증

사용자 PC에서 DNS 서버를 KT → Google 공용 DNS로 변경한 후 다시 조회해 봤습니다.

nslookup tasteam.kr 8.8.8.8

nslookup-google-dns-정상

즉시 정상적인 IP 주소가 반환됐어요.

dig 명령으로 더 정밀하게 비교하면 차이가 명확합니다.

dig-google-vs-kt-비교

dig tasteam.kr @8.8.8.8 → status: NOERROR, A 레코드 2개 정상 반환
dig tasteam.kr @168.126.63.1 → status: SERVFAIL, ANSWER 0개

이것으로 원인이 확정됐습니다. KT DNS 서버의 캐싱 문제였어요.

해결 조치

단기 해결 — 개별 사용자

문제가 발생하는 사용자의 DNS 서버를 공용 DNS로 변경하는 방법입니다.

DNS 서비스 Primary Secondary

Google	8.8.8.8	8.8.4.4
Cloudflare	1.1.1.1	1.0.0.1

장기 해결 — 전체 사용자

두 가지 방법이 있었습니다.

1. 수동적 대기

KT DNS 서버의 캐시가 TTL 만료로 자연 갱신될 때까지 기다리는 방법이에요. (수 시간 ~ 최대 2일 소요)

2. 능동적 캐시 갱신 유도

Cloudflare 대시보드에서 DNSSEC 기능을 켰다가 1분 후 다시 끄는 조치를 수행했습니다.

이 작업은 Cloudflare가 DNS 망에 구성 변경 신호를 보내, KT와 같은 하위 DNS 서버들이 캐시를 더 빨리 새로고침하도록 유도하는 효과가 있어요.

돌아보며

1. SERVFAIL ≠ 설정 오류

SERVFAIL을 보면 본능적으로 "내 설정이 잘못됐나?"를 먼저 의심하게 됩니다. 하지만 이번 케이스처럼 설정은 완벽한데 중간 경로의 캐시가 원인인 경우도 있어요.

2. ISP DNS 캐시는 통제 불가 영역

KT, SKT, LG U+ 등 ISP의 DNS 서버는 우리가 직접 제어할 수 없습니다. 캐시 만료를 기다리거나, 간접적으로 갱신을 유도하는 수밖에 없어요.

3. 문제 격리가 핵심

"일부 사용자만 안 된다"는 증상에서 네트워크 환경 차이를 빠르게 캐치하는 것이 중요했습니다. DNS 서버를 바꿔보는 것만으로 원인을 좁힐 수 있었어요.

도메인 마이그레이션 후 체크리스트

마지막으로, 도메인 연결이나 네임서버 변경 후 아래 항목을 순서대로 확인하면 대부분의 DNS 문제를 빠르게 진단할 수 있습니다.

NS 레코드 전파 확인 — dnschecker.org에서 전 세계 NS 응답 확인
DNS 레코드 확인 — A/CNAME 레코드가 올바른 IP/도메인을 가리키는지 확인
DNSSEC 상태 확인 — 레지스트라와 DNS 제공자 양쪽의 DNSSEC 설정이 일치하는지 확인
DNS 신뢰 체인 검증 — dnsviz.net에서 오류 없는지 확인
다른 DNS 서버로 테스트 — nslookup 도메인 8.8.8.8로 ISP DNS 문제 여부 격리
TTL 대기 또는 캐시 갱신 유도 — 문제가 ISP 캐시라면 시간 경과 또는 DNSSEC 토글로 대응

마치며

"설정은 다 맞는데 왜 안 되지?"라는 상황은 인프라를 운영하다 보면 정말 자주 마주치게 됩니다. 이번 트러블슈팅에서 얻은 가장 큰 교훈은 내가 통제할 수 있는 영역과 없는 영역을 구분하고, 체계적으로 가설을 세워 하나씩 검증해 나가는 것의 중요성이었어요.

비슷한 문제를 겪고 계신 분이 있다면 이 글이 도움이 되었으면 좋겠습니다. 읽어 주셔서 감사합니다.