AI 추론 성능에 영향을 미치는 보이지 않는 버전 관리 문제

모델이 회귀하지 않았습니다. 버그를 발송하지 않았습니다. 플랫폼이 바뀌었습니다.

프로덕션 AI 애플리케이션은 대부분의 팀이 통제권을 넘겨받았다는 사실을 깨닫지 못하는 것, 즉 엔드포인트 뒤의 모델 동작에 의존합니다. 현실은 모델이 고정된 인공물이 아니라는 것입니다. 움직이는 표적입니다. 경쟁력을 유지하기 위해 플랫폼은 지속적으로 가중치를 업데이트하고, 양자화 수준을 교환하고, 추론 엔진을 업그레이드하고, 하드웨어 간 트래픽 경로를 변경하고, 때로는 엔드포인트 이름을 변경하지 않고도 모델을 완전히 교체합니다.

그런 일이 발생하면 애플리케이션도 이에 따라 변경됩니다. 출력 시프트. 프롬프트가 작동을 멈춥니다. 세심하게 조정된 동작은 저하됩니다. 그리고 일반적으로 변경 로그에서는 알 수 없습니다. 사용자에게서 알 수 있습니다.

이것이 현대 AI 인프라의 숨겨진 위험입니다. 즉, 내일 "동일한 모델"이 오늘 테스트한 모델과 동일하다는 보장 없이 언제든지 변경될 수 있는 시스템 위에 구축하고 있는 것입니다. 이 기사에서는 이러한 현상이 실제로 어떻게 나타나는지, 왜 발생하는지, 왜 거의 플랫폼에서 이를 제대로 해결하지 못했는지, 그리고 이에 대처하기 위해 팀이 무엇을 하고 있는지 살펴봅니다.

함께 배송된 모델은 현재 실행 중인 모델이 아닙니다.

주요 시사점

• '모델 버전 관리'는 설계상 불완전합니다. 단일 모델처럼 보이는 것은 실제로는 가중치, 추론 엔진, 하드웨어, 라우팅, 가드레일 등 움직이는 부품의 스택입니다. 이 모든 부품은 엔드포인트 이름을 변경하지 않고도 독립적으로 변경될 수 있습니다.
• 조용한 변경은 실제 생산 위험을 초래합니다. 이러한 업데이트는 재현성을 손상시키고 즉각적인 조정을 무효화하며 플랫폼 가시성이나 모니터링을 통하지 않고 사용자가 영향을 받은 후에만 팀이 종종 감지하는 회귀를 도입합니다.
• 격차는 기술적인 것이 아니라 투명성과 소유권입니다. 플랫폼은 이미 이러한 변경 사항을 내부적으로 추적하지만 노출하지는 않습니다. AI가 생산에 중요해짐에 따라 전체 스택 버전 관리, 변경 로그 및 재현성 보장이 플랫폼 선택의 주요 기준이 될 것입니다.

버전 관리 문제의 형태

'같은 모델'이 실제로 의미하는 것

모델 엔드포인트는 변경할 수 없는 단일 아티팩트가 아닙니다. 구성은 다음과 같습니다:

• 기본 모델 가중치(원본에서 양자화, 정리 또는 추출되었을 수 있음)
• 이를 실행하는 추론 엔진(vLLM, TensorRT-LLM, SGLang 또는 독점 엔진인지 여부 - 각각 약간씩 다른 출력 생성)
• GPU 생성 및 메모리 레이아웃
• 토큰나이저 버전 및 적용된 채팅 템플릿
• 플랫폼에서 사용자가 볼 수 없는 시스템 프롬프트를 삽입할 수 있습니다.
• 모델 앞에 있는 안전, 절제 또는 가드레일 레이어
• 요청을 처리할 복제본이나 지역을 결정하는 라우팅 논리

모델 이름을 변경하지 않고도 이들 중 하나를 변경할 수 있습니다. 가장 중요한 점은 대부분이 프로덕션 애플리케이션의 수명 동안 정기적으로 변경된다는 것입니다. 이러한 변화는 기본 기술이 일반적으로 각 변화에 따라 향상되기 때문에 AI 제품 개발에 필수적입니다. 이러한 점진적인 변화는 AI 소프트웨어 산업의 핵심 부분입니다.

조용한 변화의 세 가지 범주

첫 번째 범주는 엔드포인트 포인트에 가중치를 부여하는 플랫폼이 변경되는 명시적인 버전 업데이트입니다. 예를 들어 "GPT-4"는 시간이 지남에 따라 여러 가지 모델이었으며 Claude 엔드포인트는 정기적으로 업데이트됩니다. 호스팅된 플랫폼의 오픈 소스 모델 엔드포인트는 업스트림 릴리스를 자동으로 추적하는 경우가 많습니다.

두 번째 범주는 가중치는 동일하게 유지되지만 서비스 스택의 일부가 이동하는 인프라 수준 변경입니다. 이에 대한 몇 가지 예는 다음과 같습니다:

• 추론 엔진이 업그레이드됩니다
• 비용상의 이유로 양자화 수준이 변경됨
• 라우팅 결정은 동일해야 했지만 그렇지 않은 여러 배포 간에 트래픽을 이동시킵니다.

세 번째 범주는 플랫폼 수준 추가로 인한 동작 변경입니다. 즉, 새로운 중재 레이어, 변경된 시스템 프롬프트, 추가된 안전 필터 또는 수정된 채팅 템플릿입니다. 이러한 시나리오에서 모델은 동일하지만 모델이 받는 것과 사용자가 받는 것은 다릅니다.

각 카테고리가 실제로 모델 행동에 미치는 영향

자동 회귀 문제

자동 회귀는 발표되지도, 문서화되지도, 버전 범프와 연결되지도 않은 서빙 스택 어딘가의 변경으로 인해 발생하는 모델 출력 품질의 저하입니다. 엔드포인트의 모델 이름은 동일합니다. API 계약은 동일합니다. 귀하가 보내는 요청은 지난 달에 보낸 요청과 바이트가 동일합니다. 그러나 응답 품질은 때로는 미묘하게, 때로는 급격히 떨어졌으며 플랫폼의 공개 표면에는 그 이유를 알려주는 내용이 없습니다.

메커니즘은 거의 항상 이전의 세 가지 변경 범주 중 하나입니다. 즉, 가중치가 조용히 업데이트되거나, 인프라의 일부가 이동되거나, 플랫폼 수준 계층(새 가드레일, 수정된 시스템 프롬프트, 강화된 조정 필터)이 추가되거나 변경되었습니다. 외부에서 보면 세 가지 모두 동일해 보입니다. 출력이 더 나빴고 플랫폼에서는 이를 알려주지 않았습니다. 내부적으로 보면 근본 원인도 다르고 해결 방법도 다르며, 플랫폼의 협력 없이는 이를 구별할 방법이 없습니다.

자동 회귀가 일반 모델 드리프트와 구별되는 점은 정보의 비대칭성입니다. 플랫폼은 무엇이 바뀌었는지 알고 있습니다. 당신은 그렇지 않습니다. 그리고 모니터링은 골든 데이터 세트의 출력 품질보다는 가동 시간, 대기 시간 및 오류율을 측정하는 것이 거의 확실하기 때문에 회귀 분석은 귀하가 소유한 대시보드에 표시되기 전에 사용자에게 전파됩니다. 회귀가 실제임을 확인하고 이를 자신의 코드가 아닌 모델에 격리하고 지원 티켓을 열었을 때 플랫폼은 일반적으로 이미 다음 자동 변경으로 이동한 것입니다. 정보의 절반만 가지고 움직이는 대상을 디버깅하게 되는 반면, 사용자는 당신이 전혀 듣지 못한 업스트림 어딘가에서 내려진 결정에 대한 비용을 흡수하게 됩니다.

이는 플랫폼이 문제를 즉시 해결할 수 있는 정보를 보유하고 공유하지 않기로 결정하는 유일한 문제이기 때문에 이 섹션의 네 가지 문제 중 최악입니다. 재현성 실패, 즉각적인 부채, 평가에서 제품까지의 드리프트는 모두 팀이 최소한 스스로 진단할 수 있는 증상입니다. 자동 회귀는 필요한 진단 도구가 API 반대편에 있는 회귀입니다.

재현성 문제

널리 사용되는 AI 배포 유형의 훌륭한 예인 GPT 모델은 본질적으로 확률적이지만 동일한 프롬프트로 동일한 모델을 사용하면 유사한 답변을 얻을 수 있습니다. 그러나 앞서 설명한 변경 사항이 발생하면 어제 얻은 출력이 오늘 재현되지 않을 수 있습니다. 이것이 재현성 문제의 핵심입니다. 모델이 어떻게 작동할지에 대한 모든 기대는 이러한 변경으로 인해 무효화될 수 있습니다.

자동화된 평가를 수행하거나 모델 버전을 서로 비교하는 애플리케이션의 경우 이는 동일한 시드가 주어지면 동일한 입력이 동일한(또는 확률 모델의 경우 유사한) 출력을 생성한다는 기본 가정을 깨뜨립니다. 온도 0은 기본 스택이 아래로 이동하는 경우 실제로 결정성을 제공하지 않습니다. 즉각적인 엔지니어링 부채 문제

팀은 종종 특정 모델의 특징에 대한 프롬프트를 조정하고 사용자의 요구 사항을 더 잘 충족할 수 있도록 최적화하는 데 몇 주를 소비합니다. 해당 모델이 자동으로 교체되거나 업데이트되면 모든 튜닝 작업이 부분적인 부채로 변합니다. 한 모델의 실패 모드를 처리하기 위해 신중하게 구성된 프롬프트가 이제 약간 다른 실패 모드를 가진 약간 다른 모델을 접하게 되면 사용자가 직면하게 되는 최종 행동이 변경됩니다.

평가에서 프로덕션으로의 드리프트 문제

또 다른 일반적인 시나리오는 다음과 같습니다. 테스트 세트를 기준으로 모델 버전을 평가한 후 프로덕션으로 출시합니다. 그러나 엔드포인트의 이름이 동일하더라도 프로덕션 엔드포인트는 더 이상 평가한 모델을 사용하지 않습니다. 다시 한 번 말하지만, 이는 최종 제품의 동작에 눈에 띄는 영향을 미칠 수 있습니다.

플랫폼이 실제로 하는 일

이 섹션에서는 주요 추론 플랫폼이 공개 문서와 관찰 가능한 동작을 기반으로 버전 관리를 처리하는 방법을 안내합니다.

OpenAI 스타일 버전 관리

OpenAI는 스냅샷을 명시적으로 고정하고(gpt-4-0613, gpt-4o-2024-08-06) 이를 대상으로 지정할 수 있습니다. 별칭이 지정된 끝점(gpt-4, gpt-4o)은 시간이 지남에 따라 변경되는 현재 기본값을 가리킵니다. 스냅샷을 고정하는 방법을 모르는 팀은 최신 버전을 얻을 수 있으며 별칭은 그 아래로 이동할 수 있습니다.

OpenAI는 다양한 이유로 모델을 변경합니다. 이에 대한 한 가지 예는 Sycophancy 사건입니다. GPT-4o는 '지나치게 아첨하거나 기분 좋은 것'으로 알려졌으며 OpenAI는 결국 모델을 더 이상 사용하지 않기 전에 일련의 출시 수정 사항을 발표했습니다(출처). 모델의 최종 지원 중단은 사람들이 모델 상실에 대해 한탄하면서 더 많은 파장을 일으켰습니다.

Sycophancy 사건을 유익하게 만드는 것은 성격 변화 자체가 아니라 엔드포인트 계약에 대해 밝혀진 것입니다. 아첨꾼 롤아웃 전, 도중, 후에 gpt-4o를 호출하는 팀은 동일한 엔드포인트 이름을 사용했지만 의미 있는 모델은 달랐습니다. 사전 시코펀시 버전에 맞춰 조정된 고객 지원 봇은 생산 수명 도중에 더 따뜻하고 더 기분 좋은 모델을 접한 다음 OpenAI가 과정을 수정했을 때 세 번째 행동 프로필을 접했고, 모델이 결국 더 이상 사용되지 않을 때 네 번째 행동 프로필을 접했을 것입니다. 이러한 전환 중 어느 것도 고객 측에서 코드 변경이 필요하지 않았습니다. 그 중 어느 것도 엔드포인트 문자열에서 버전 범프를 유발하지 않았습니다. 동일한 두 줄 API 호출은 몇 달 동안 네 가지 고유한 행동 방식을 생성했으며 대부분의 팀이 받은 유일한 신호는 사용자가 제품이 다르게 느껴진다고 말하는 것이었습니다. OpenAI의 접근 방식은 OpenAI가 여전히 서비스를 제공하는 한 이전 모델 버전을 사용할 수 있는 옵션을 제공하므로 대부분의 접근 방식보다 낫습니다. 그러나 선택은 수동이며 모델을 이전 버전으로 변경하는 방법을 조사하지 않는 사람들에게는 수행하기 어려울 것이라는 점은 여전히 주목할 가치가 있습니다.

Anthropic의 접근 방식

Anthropic은 날짜가 지정된 모델 식별자(claude-opus-4-5-20251101 스타일)를 사용합니다. 고정 작업. 그러나 플랫폼 수준 시스템 프롬프트 주입 및 안전 계층은 모델 버전과 독립적으로 발전하므로 서로 다른 날짜에 동일한 고정 모델에 대한 두 요청이 모델 내부가 아닌 모델 주변에서 일어나는 일로 인해 다르게 동작할 수 있습니다. 이는 투명성 측면에서 한 단계 뒤떨어진 것이지만 핵심 모델 선택은 OpenAI와 유사합니다.

Anthropic의 자동 회귀의 예는 최근 유명한 Github 문제에서 발생했습니다. 여기서 주요 AI 개발자는 복잡한 엔지니어링 작업에서 Claude Opus 모델의 명백한 "너핑"을 언급했습니다. 그들은 Claude가 요청된 활동과 반대되는 잘못된 "가장 간단한 수정"을 주장하면서 지시를 무시하기 시작했으며 모델이 지시에 따라 완료되었다고 주장했습니다. 이 모든 것은 사용 중인 모델에 대한 보고된 변경 없이 이루어졌습니다. 이 조용한 변경은 같은 스레드에서 Claude의 개발자에 의해 반박되었지만 댓글에 대한 응답을 바탕으로 다른 사용자의 변경이 발생했다는 데는 폭넓은 동의가 있습니다.

'동일 모델'은 항상 마케팅 추상화였습니다.

호스팅 오픈소스 모델

오픈 소스 모델(Baseten, Fireworks, Together, DigitalOcean, Nebius Token Factory, Modal)을 호스팅하는 플랫폼은 특정 양자화, 추론 엔진 버전 또는 실제로 요청을 처리하는 배포 구성을 노출하지 않고 "llama-3.1-70b-instruct"와 같은 기본 모델 뒤에 엔드포인트 이름을 지정하는 경우가 많습니다. 모델의 성능은 동일한 이름을 가지고 있어도 플랫폼마다 다르기 때문에 이는 큰 문제가 될 수 있습니다. 이들 중 하나에 대한 업데이트는 일반적으로 모델 버전 변경으로 전달되지 않습니다. 오픈 소스 호스팅 공급자의 경우 서버리스 추론 시나리오에서 기본 모델 배포에 대한 변경 사항에 대해 조사를 수행할 책임은 사용자에게 있습니다. 맞춤형 배포에서는 상황이 약간 다릅니다.

맞춤 배포

Modal 또는 Baseten과 같은 플랫폼에 자신의 모델을 배포하면 버전 관리 스토리를 소유하게 됩니다. 이는 재현성, 생산 제어, 다운스트림 제품의 모델 변경 관리에 있어 가장 깔끔한 상황이지만 모델 수명주기를 직접 관리해야 하는 운영 부담을 떠맡게 됩니다. 변경 사항을 관리하는 데 필요한 개발자 시간이 급증하므로 확장 시 이러한 절충안을 고려하는 것이 중요합니다.

팀에서는 무엇을 하고 있나요

아래 섹션에서는 팀이 채택한 일반적인 해결 방법을 다룹니다. 그 중 어느 것도 문제를 완전히 해결하지는 못하지만 각각 올바른 방향으로 가는 단계를 제공합니다.가능한 경우 스냅샷 고정

플랫폼이 날짜가 지정된 스냅샷을 공개하면 이를 고정하는 것이 테이블 스테이크입니다. 그러나 모든 플랫폼이 이를 노출하는 것은 아니며 고정된 스냅샷은 결국 더 이상 사용되지 않습니다. AI 제품의 모델을 호스팅할 플랫폼을 신중하게 선택할 때 이 점을 고려하십시오. 그렇지 않으면 백업 계획 없이 모델이 사라지는 상황이 발생할 수 있습니다.

골든 데이터 세트 회귀 테스트

골든 데이터 세트 회귀 테스트는 일정에 따라 프로덕션 엔드포인트를 통해 고정된 입력 세트를 실행하고 출력을 알려진 양호한 기준과 비교하는 곳입니다. 이 프로세스를 사용하면 품질 회귀 및 기타 중요한 모델 동작 변화를 쉽게 포착할 수 있지만 유지 관리 비용이 많이 들고 관찰하려고 생각한 패턴만 다룰 수 있습니다. 정기적인 골든 데이터세트 회귀 테스트를 통해 귀하보다 먼저 제품의 동작 변화를 고객이 발견했다는 무서운 소식을 예방할 수 있습니다.

출력 샘플링 및 로깅

이는 향후 분석을 위해 샘플링된 생산 요청 및 응답 비율을 기록하는 프로세스입니다. 이를 통해 사후에 드리프트를 감지할 수 있지만 여전히 샘플링, 저장 및 분석 인프라를 직접 구축해야 합니다.

섀도 배포

현재 프로덕션 엔드포인트와 후보 새 엔드포인트에 대해 동일한 요청을 동시에 실행하고 출력을 비교하여 모델 동작에 어떤 영향을 미치는지 확인할 수 있습니다. 이는 현재 수행 중인 변경 사항을 평가하는 데 매우 효과적입니다. 플랫폼이 귀하 아래에서 수행하는 변경에는 도움이 되지 않습니다.

모델 자체 호스팅

궁극적인 제어 방식:자신이 제어하는 인프라에서 직접 모델을 실행하세요. 이를 통해 사용 중인 가중치, 추론 엔진, 양자화 및 출력에 영향을 미칠 수 있는 기타 모든 사항을 완벽하게 제어할 수 있습니다. 이는 버전 관리 문제를 모델 호스팅의 운영 부담으로 바꾸므로 대부분의 팀이 이를 수행하지 않습니다.

버전 관리에 실제로 드는 비용

관측 가능성 세금

출력 품질에 관심을 갖는 모든 팀은 플랫폼이 제공하지 않기 때문에 자체 평가 인프라를 구축하고 있습니다. 이는 업계 전반에 걸쳐 발생하는 중복 작업입니다. 신속한 회귀 프레임워크, 출력 비교 도구, 품질 모니터링 시스템 등은 모두 실제 제품을 구축하기를 원하는 애플리케이션 팀에 의해 구축됩니다.신탁세

모델이 자신 아래로 이동하여 AI 기능이 중단되면 사용자는 "AI가 신뢰할 수 없다"와 "플랫폼이 자동으로 모델을 업데이트했습니다"의 차이를 알지 못합니다. 귀하의 제품은 업스트림에서 내려진 결정으로 인한 평판 비용을 흡수합니다.

이민세

플랫폼 전환을 고려하는 팀은 API 차이점뿐만 아니라 다른 플랫폼에 있는 동일한 이름의 모델 간의 동작 차이도 고려해야 합니다. Fireworks의 "Llama 3.1 70B"는 Together의 "Llama 3.1 70B"와 반드시 동일할 필요는 없습니다. 양자화가 다르거나, 다른 추론 엔진을 사용하거나, 완전히 다른 가드레일 스택을 가질 수 있습니다. 이러한 명확성 부족으로 인해 광범위한 테스트 없이 제공업체 간 전환이 어렵습니다.

더 나은 모습

2026년의 진지한 추론 플랫폼은 모델 동작을 클라우드 제공업체가 가동 시간을 처리하는 방식, 즉 블랙박스가 아닌 계약 표면으로 처리해야 합니다.

현재 상태는 기술적 한계가 아니라 공개 격차입니다. 가중치, 엔진, 양자화 수준 및 라우팅 결정을 추적하기 위한 인프라가 이미 존재합니다. 플랫폼에서는 이를 노출하지 않습니다.

실제로는 다음과 같습니다.

1. 완전한 버전 식별자오늘날의 모델 이름은 때때로 가중치를 식별합니다. 전체 제공 구성을 식별해야 합니다. 완전한 버전 문자열은 가중치(양자화 수준 포함), 추론 엔진 및 버전, 하드웨어 생성, 토크나이저 버전, 채팅 템플릿, 플랫폼에 주입된 시스템 프롬프트 또는 가드레일 레이어 등 엔드포인트에서 나오는 내용을 변경할 수 있는 모든 것을 캡처합니다. llama-3.1-70b-instruct.fp8.vllm-0.6.3.h100.tmpl-v2.guardrail-v4와 같은 것은 추악하지만 정직합니다. 팀은 자신이 의존하는 구성 요소를 고정하고 다른 구성 요소가 변경되면 알림을 받을 수 있습니다.

2. 전체 stackPlatforms에 대한 변경 로그 피드는 모델 가중치를 업데이트할 때 릴리스 노트를 게시합니다. vLLM을 업그레이드하거나, 비용상의 이유로 양자화를 변경하거나, 지역 간 트래픽을 다시 라우팅할 때 아무것도 게시하지 않습니다. 적절한 변경 로그 피드(이상적으로는 기계 판독 가능)는 타임스탬프 및 영향을 받는 엔드포인트와 함께 서비스 스택의 모든 계층을 포괄합니다. 팀은 고정된 특정 구성에 대한 변경 사항을 구독하고 사용자가 불만을 제기한 후가 아니라 출시 전에 알림을 받을 수 있어야 합니다.

3. 명시된 보존으로 재현성을 보장합니다. 고정된 스냅샷은 의미가 있습니다. 플랫폼은 명시된 보존 기간(예:12개월 또는 24개월)을 약속해야 합니다. 이 기간 동안 고정된 구성은 가중치뿐만 아니라 전체 스택에 대해 온도 0에서 동일한 입력에 대해 바이트와 동일한 출력을 반환합니다. 해당 기간이 만료되면 팀은 사전 통지와 마이그레이션 경로를 받습니다. 이것이 데이터베이스와 운영 체제가 버전 관리를 처리하는 방식입니다. 추론이 달라야 할 이유는 없습니다.

4. 플랫폼 제공 회귀 테스트모든 진지한 팀은 동일한 평가 인프라를 독립적으로 구축하고 있습니다. 플랫폼은 이를 최고의 기능으로 제공해야 합니다. 즉, 골든 데이터세트를 등록하고, 고정된 엔드포인트에 대해 일정에 따라 이를 실행하고, 출력이 설정한 임계값을 넘어갈 때 경고를 받습니다. 스냅샷 간의 차등 테스트를 위한 보너스 포인트를 통해 팀은 강제로 마이그레이션하기 전에 마이그레이션할지 여부를 평가할 수 있습니다.

5. 변경 내용과 시기에 대한 정직한 문서 이 목록에서 가장 어려운 항목은 플랫폼이 "동일한 모델"이 항상 마케팅 추상화였다는 점을 인정해야 하기 때문입니다. 문서에는 모델 버전과 독립적으로 변경될 수 있는 모든 레이어의 이름을 지정하고, 각 레이어 변경에 대한 플랫폼의 정책을 명시하고, 고객에게 알림을 보내는 방법을 설명해야 합니다. 그러면 팀은 어떤 플랫폼이 위험 허용 범위에 부합하는지 정보에 입각한 결정을 내릴 수 있습니다.

구매자 체크리스트

지금 추론 플랫폼을 평가하고 있다면 서명하기 전에 공급업체에 다음 질문을 하십시오:

• “특정 모델 스냅샷을 고정할 수 있나요? 해당 스냅샷의 사용 가능 기간은 얼마나 되나요?”
• “내가 고정한 버전 문자열이 추론 엔진, 양자화 및 하드웨어를 포괄합니까, 아니면 가중치만 포괄합니까?”
• “서빙 스택의 레이어가 변경될 때 알림 정책은 무엇입니까?”
• "내가 볼 수 없는 시스템 프롬프트, 가드레일 또는 조정 레이어를 삽입합니까? 선택 해제할 수 있나요?"
• “한 달 간격으로 온도 0에서 동일한 요청을 두 번 실행하는 경우 출력 ID에 대해 어떤 보장을 합니까?”
• “회귀 테스트 도구를 제공합니까, 아니면 제가 직접 구축합니까?”
• “고정된 스냅샷이 더 이상 사용되지 않으면 얼마나 많은 알림을 받게 되며 마이그레이션 경로는 무엇입니까?”

플랫폼이 이들 대부분에 대해 명확하게 대답할 수 없다면 그것이 바로 대답입니다. 당신은 변화할 수 있는 인프라를 구축하고 있으며 이를 사용자에게 설명하는 사람은 바로 당신입니다.

상업 현실

위의 어느 것도 기술적으로 어렵지 않습니다. 이를 어렵게 만드는 것은 상업적입니다. 플랫폼은 조용히 상황을 변경할 수 있는 유연성의 이점을 누리며, 대안인 자체 호스팅은 운영상 비용이 많이 들기 때문에 역사적으로 고객은 이를 받아들였습니다. AI 기능이 데모에서 사람들이 의존하는 제품으로 이동함에 따라 이러한 거래는 더욱 악화되기 시작했습니다. 이 문제를 먼저 해결하는 플랫폼은 실제로 신뢰성을 중시하는 시장 부문에서 승리하게 될 것입니다. 그렇지 않은 팀은 사용자로부터 알아낸 팀에 자동 회귀를 계속 발송할 것입니다.

마무리

업계에서는 기존 소프트웨어에서 차용한 가정(이름이 지정된 아티팩트는 안정적인 아티팩트)을 바탕으로 AI 인프라를 구축했습니다. 그 가정은 성립하지 않습니다. 무게, 엔진, 라우팅 및 가드레일은 모두 엔드포인트의 이름과 관계없이 변경되며, "모델 버전"이 의미하는 것과 실제로 보장하는 것 사이의 격차는 프로덕션 AI가 조용히 중단되는 지점입니다.

예측은 다음과 같습니다. 향후 18개월 이내에 자동 버전 관리는 엔지니어링 문제뿐만 아니라 조달 문제가 될 것입니다. 추론 용량을 구매하는 팀은 위 체크리스트에 있는 질문을 하기 시작하고, 이에 답할 수 있는 플랫폼은 다른 팀이 패했는지조차 모르는 거래에서 승리하기 시작할 것입니다. "재현성 SLA", "스택 수준 변경 로그" 및 "스냅샷 보존 기간"이 엔지니어링 위시리스트에서 기업 계약으로 이동하는 것을 볼 수 있을 것으로 예상됩니다. 문서에 대한 자세한 각주가 아닌 전체 스택 버전 문자열을 제품 기능으로 게시하는 최초의 플랫폼은 다른 모든 사람에 대한 고객 기대치를 재설정할 것입니다.

오늘날 추론을 기반으로 구축된 팀의 경우 실질적인 질문은 조용한 변화가 제품에 영향을 미칠지 여부가 아닙니다. 그럴 것이다. 문제는 모니터링을 통해 알아냈는지, 자체 회귀 테스트를 통해 알아냈는지, 아니면 월요일 아침 사용자 불만을 통해 알아냈는지입니다. 세 가지 중 어느 것이 될지는 거의 전적으로 다음 자동 업데이트가 시작되기 전에 지금 내리는 결정에 달려 있습니다.

함께 배송된 모델은 현재 실행 중인 모델이 아닙니다. 그에 따라 구축하세요.

DigitalOcean은 AI 제품을 대규모로 구축하는 데 도움을 줄 수 있습니다.

이 저작물은 Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International에 따라 라이센스가 부여됩니다. 라이센스.