모델 별칭(Alias)은 버전이 아닙니다: 무료 모델 접근을 위한 드리프트 카나리

계속해서 나타나는 주장

'내 쪽에서는 아무것도 변경되지 않았어요.' 저는 모든 평가 회귀 스레드에서 이 말을 봅니다.

설정(config)의 모델 문자열은 동일합니다. 프롬프트 파일도 건드리지 않았습니다. 그러니 원인은 무작위성 때문인 거죠, 그렇죠?

그렇지 않습니다. 모델 이름은 포인터일 뿐입니다. 체크섬이 아닙니다.

개발자들이 반복하는 다섯 가지 사항이 있습니다. 각각은 합리적으로 들립니다. 하지만 각각은 일주일간의 디버깅 비용을 청구할 수 있습니다.

1. '저는 설정에 model-x를 고정(pin)했으니, 제 결과도 고정되어 있어요.'
2. 'Temperature 0이면 동일한 입력이 동일한 출력을 반환해요.'
3. '답변들이 여전히 좋아 보인다면, 모델은 같은 거예요.'
4. '훌륭한 데모 하나가 엔드포인트가 정상임을 증명해요.'
5. '제 무료 서버는 이 검사들을 사람이 관리하지 않아도 영원히 돌릴 수 있어요.'

이것들을 하나씩 분해해 보겠습니다.

Q1: 고정된 모델 이름이 가중치(weights)를 고정하나요?

간단한 답변: 아닙니다. 제공업체의 문서를 확인하여 두 가지 별개의 개념을 알아보세요.

• 별칭(Aliases). 현재 스냅샷을 가리키는 움직이는 레이블입니다. 제공업체들은 의도적으로 이것들을 순환시킵니다(rotate).
• 날짜가 지정된 스냅샷(Dated snapshots). 날짜 접미사가 붙은 이름입니다. 보통 고정되어 있지만, 여전히 사용 중단 기간 내에 있습니다.

실제 설정에 무엇을 넣었는지 스스로에게 물어보세요. 대부분의 프로젝트는 별칭을 고정하고 그것을 버전이라고 부릅니다.

모든 실행마다 로깅해야 할 것들:

• 요청한 모델 문자열(the model string you requested)
• 응답이 반환하는 경우, 그 모델 문자열(the model string the response echoed, if it echoes one)
• UTC 타임스탬프
• 엔드포인트 기본 URL(endpoint base URL)

마지막 것이 중요합니다. 같은 별칭이라도 시간이 지남에 따라 다른 백엔드로 라우팅될 수 있습니다.

수정된 사고 모델

별칭은 DNS 레코드입니다. 날짜가 지정된 스냅샷은 IP 주소입니다. 둘 다 움직일 수 있지만, 하나는 훨씬 더 자주 움직입니다.

제공업체의 문서에서 현재 매핑을 확인하세요. 이 글을 포함하여 블로그 게시물에 의존하지 마세요.

Q2: Temperature 0은 재현 가능한가요?

아무도 묻지 않는 질문이 있습니다: temperature=0이 샘플링(sampling)을 비활성화하나요? 아닙니다. 이것은 하나의 노브를 돌리는 것일 뿐입니다.

다른 변동성 원인들이 여전히 작용합니다:

• 배치 추론(batched inference)은 호출마다 요청을 다르게 처리합니다.
• 부동 소수점 누적 순서가 고정되어 있지 않습니다.
• Mixture-of-Experts 라우팅 및 Speculative Decoding은 지터(jitter)를 추가합니다.
• 하나의 별칭(alias)이 여러 백엔드 풀(backend pools)에 의해 제공될 수 있습니다.

1분 안에 이를 테스트해 볼 수 있습니다. 동일한 프롬프트를 20번 반복하여 실행하고 고유한 출력 개수를 세어보세요.

# unexecuted example, plug in your own client
outs = {client.chat(prompt, temperature=0) for _ in range(20)}
print(len(outs), "distinct outputs")

만약 그 숫자가 1보다 크다면, 정확히 일치하는 값에 대한 단언(assertion)은 이미 깨진 것입니다.

수정된 모델: 모델 버전은 이진값(binary)이 아니라 분포(distribution)입니다. 비교해야 하는 것은 단일 문자열이 아니라 분포입니다.

Q3: 드리프트를 육안으로 확인할 수 있나요?

아닙니다. 유창성(Fluency)은 최악의 감지기입니다.

스냅샷이 변경될 때, 출력물은 보통 나빠지기보다는 '더 좋아 보이게' 읽힙니다. 더 짧아지거나, 더 친근해지거나, 더 구조화됩니다. 아무것도 잘못된 것처럼 보이지 않습니다. 그것이 바로 문제입니다.

대신 측정할 수 있는 저렴한 것들:

• 자기 일관성(Self-consistency): 하나의 프롬프트에 대해 K개의 샘플이 얼마나 자주 일치하는지.
• 출력 길이 분포(Output length distribution): 안정적인 모델은 안정적인 모양을 유지합니다.
• 문자 n-그램 중복도(Character n-gram overlap): 저장된 기준선(baseline)에 대한 거칠지만 효과적인 지문입니다.
• 오류 및 거부율(Error and refusal rate): 별도로 추적하며, 드리프트에 절대 섞지 않습니다.

이 중 어느 것도 가중치(weights)가 동일함을 증명하지는 못합니다. 하지만 이들을 함께 사용하면 당신을 무너뜨리는 변경 사항을 포착할 수 있습니다.

아티팩트: 두 개의 명령어로 구성된 드리프트 카나리

레이블: 환경에서 제안되었으며 실행되지 않음. 표준 라이브러리만 사용하며, OpenAI와 호환되는 엔드포인트입니다.

프롬프트 파일로 시작하세요. 의도적으로 작고 지루하게 유지합니다.

{"id":"p01","prompt":"정확히 다음으로 답하세요: OK"}
{"id":"p02","prompt":"세 가지 기본 색상을 나열하세요. 소문자, 쉼표로 구분하여."}
{"id":"p03","prompt":"17 * 23은 무엇인가요? 숫자만 답하세요."}
...

12개의 프롬프트는 합리적인 시작 세트입니다. 제약된 작업들은 포맷 변경을 빠르게 노출시킵니다.

이제 기록기(recorder)와 비교기(comparer)가 있습니다:

#!/usr/bin/env python3
"""canary.py - OpenAI 호환 채팅 엔드포인트 지문 인식(fingerprint). 

...
"""

record를 알려진 좋은 주간에 한 번 실행하세요. 그 파일이 기준선(baseline)입니다. 그런 다음 설명할 수 없는 메트릭 변화가 있을 때 다시 실행하세요.

임계값(thresholds)은 자신만의 노이즈 플로어에 맞게 조정하세요. 0.90과 15%는 시작 추측일 뿐, 법칙이 아닙니다.

무료 서버에서 스케줄링하기

캐나리(canary)는 작은 워크로드입니다. 사이클당 몇 개의 짧은 요청만으로 충분합니다.

이는 무료 서버가 스케줄러의 합법적인 호스트가 될 수 있게 합니다. MonkeyCode는 무료 모델 접근과 무료 서버 옵션을 제공하여 이 루프의 양쪽을 모두 커버합니다.

공개 고지: 본 문서는 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 작성되었습니다.

자신의 할당량(quota)에 맞춰 주기(cadence)를 설정하세요. 저는 당신의 제한 사항을 알려드릴 수 없으며, 30분마다 12개의 프롬프트 x 5개 샘플을 실행하는 것은 빠르게 쌓입니다. 시간당 3개 샘플이 더 차분한 기본값입니다.

# /etc/cron.d/canary
17 * * * * runner cd /opt/canary && flock -n .lock ./run.sh >> canary.log 2>&1

#!/usr/bin/env bash
set -euo pipefail
cd /opt/canary
...

무료 서버의 주의사항들이 여기서 중요합니다:

• **유휴 슬립(Idle sleep)**은 시간당 약속을 깨뜨립니다. 간격이 안정성의 증거는 아닙니다.
• **임시 디스크(Ephemeral disk)**는 재시작 시 실행 기록을 잃습니다. 매 사이클마다 결과를 외부로 전송하세요.
• **아웃바운드 및 할당량 제한(Egress and quota limits)**은 실행을 중간에 잘라냅니다. n_ok를 로깅하여 알아차릴 수 있게 하세요.
• SLA 없음은 모니터의 가동 시간 역시 상수(constant)가 아닌 변수(variable)라는 의미입니다.

출력 읽기: 의사결정표

The 마지막 행이 중요합니다. 깨끗한 캐나리 실행은 거의 아무것도 증명하지 못합니다. 단지 이번 시간에 변화를 포착하지 못했다는 것만을 의미할 뿐입니다.

이 워크플로우가 실패하는 지점

• 가중치(weights)가 동일함을 증명할 수 없습니다. 오직 행동만을 관찰합니다.
• 12개의 프롬프트는 회귀 테스트 스위트(regression suite)가 아니라 연기 테스트(smoke test)입니다.
• 임계값(Thresholds)은 사용자가 자체 분산(variance)을 측정하기 전까지는 추측일 뿐입니다.
• 오류(Errors)와 드리프트(drift)를 분리하지 않으면 오류가 드리프트로 위장합니다.
• 기준선(Baselines)은 조용히 저하됩니다. 계획된 업그레이드 후에는 반드시 다시 측정해야 합니다.

이 글을 건너뛰어도 되는 경우

• 모델 교체 비용이 전혀 들지 않는 프로토타입.
• 변경 로그와 통지 기간(notice windows)을 보장하는 계약을 가진 팀.
• 기준선을 무료 박스 외부에서 저장할 수 없는 사람.
• 감지기(detector)가 아닌 재현성(reproducibility) 보장을 필요로 하는 사람.

수정된 사고 모델

1. 모델 이름은 포인터이며, 포인터는 움직입니다.
2. Temperature 0은 분포를 좁힐 뿐, 절대 수렴시키지 않습니다.
3. 단일 출력(single outputs)이 아닌 분포를 비교해야 합니다.
4. 오류와 드리프트는 다른 신호입니다. 별도로 라벨링하세요.
5. 모든 기준선에는 만료일이 있습니다. 의도적으로 다시 측정하세요.

자, 그래서 여러분께 질문을 드립니다. 세트에 어떤 12개의 프롬프트를 넣으시겠습니까?

조용히 변경되었을 때 가장 큰 피해를 입을 작업을 고르세요. 오늘 적어두십시오. 그리고 카나리가 포인터가 움직였음을 알려주도록 하세요.