대부분의 경우 개발자는 올바른 AI 인프라를 선택하는 데 어려움을 겪으며, 주요 대화는 AI 시스템을 구축하기 위한 올바른 선택이 무엇인지에 대한 간단한 질문을 중심으로 이루어집니다. 유연성을 위한 서버리스, 제어 전용 , 편의성 대 성능.
실제로 추론 인프라는 한번에 "올바른 선택"을 하는 것이 아닙니다. 시간이 지나면서 제품, 트래픽, 기대치가 발전함에 따라 조용히 잘못된 것이 됩니다.
AI 기반 회의 도우미의 예를 들어보세요. 초기 버전에서는 하루에 몇 건의 회의를 처리하고 한 번에 하나씩 기록하고 요약합니다. 사용법이 불규칙하고 우선순위는 단순히 기능을 작동시키는 것입니다. 서버리스 추론은 여기에 자연스럽게 들어맞습니다.
제품이 주목을 받으면 일상적인 작업 흐름의 일부가 됩니다. 팀은 하루 종일 회의를 처리하기 위해 이를 사용하고 처리 시간에 대한 기대가 강화되기 시작합니다. 전체적인 성능이 허용 가능한 수준이더라도 가끔 지연 시간이 급증하는 것이 중요해지기 시작합니다.
결국 시스템은 예측 가능한 일일 패턴으로 많은 양의 회의를 처리하는 지점에 도달합니다. 이 단계에서는 요구 사항이 일관성과 비용 효율성으로 전환됩니다. 전용 추론이 논리적 기반이 되는 이유는 이전 접근 방식이 잘못되었기 때문이 아니라 시스템이 이를 초과했기 때문입니다.
흥미롭게도 서버리스는 사라지지 않습니다. 이는 극단적인 경우, 예상치 못한 급증 처리, 실험적 기능 실행 또는 빈도가 낮은 작업 지원에 여전히 유용합니다. 고정된 계획보다는 시스템에 필요한 사항에 따라 자연스럽게 두 가지 접근 방식이 혼합됩니다.
이 기사에서는 시스템이 성장함에 따라 서버리스 추론과 전용 추론 사이의 선택이 어떻게 진화하는지 이해하려고 노력할 것입니다. 또한 서버리스 추론이 언제 무너지기 시작하는지, 워크로드 패턴이 올바른 선택을 결정하는 방법, 시스템 규모가 커짐에 따라 전용 인프라로의 전환이 불가피해지는 이유를 이해하기 위한 예로 Modal 및 Together.ai와 같은 매우 인기 있는 두 가지 플랫폼을 살펴보겠습니다.
초기 단계
AI 제품을 구축하는 초기에 가장 큰 제약은 성능, 특히 지연 시간 일관성(각 요청이 응답하는 속도)과 처리량(한 번에 처리되는 요청 수)이 아니라 얼마나 빨리 출시하고, 반복하고, 실제 사용에서 학습할 수 있는지입니다.
초기에는 워크로드가 아직 이해되지 않고, 트래픽이 일관되지 않으며, 모델이 변경되고, 제품 자체가 아직 구체화되고 있습니다. 그러한 경우 서버리스 플랫폼은 개발자의 요구에 거의 완벽하다고 느껴집니다.
속도를 늦추는 결정을 제거합니다. GPU 프로비저닝, 확장 정책 또는 용량 계획에 대해 생각할 필요가 없습니다. 코드를 작성하고 배포하면 시스템은 어떤 수요가 나타나든 이에 맞춰 적응합니다. 프로토타입 챗봇, 문서 요약기 또는 내부 AI 도구와 같은 초기 단계 애플리케이션의 경우 이는 단지 편리하기만 한 것이 아닙니다. 배송이 되는 것과 배송되지 않는 것의 차이입니다.
이 단계에서는 사용량 자체가 불확실하므로 비효율성은 중요하지 않습니다. 인프라 효율성이 아닌 반복 속도를 최적화하고 있습니다.
첫 번째 변화:지연 시간이 제품 문제가 됨
선택한 인프라가 잘못 정렬되기 시작했다는 첫 번째 징후는 청구 대시보드에 거의 나타나지 않습니다. 이는 사용자 경험에 나타납니다. 사용량이 증가함에 따라, 약간이라도 지연 시간은 이론적인 측정 기준이 아니며 가시화되기 시작합니다.
서버리스 시스템은 탄력성을 중심으로 구축되며, 이는 종종 가변성을 수반합니다. 환경이 이미 따뜻하면 요청이 즉시 반환될 수 있고, 콜드 스타트 또는 모델 로드가 트리거되면 훨씬 더 오랜 시간이 걸릴 수 있습니다. 별개로 이는 허용됩니다. 그러나 사용자 대면 시스템에서는 불일치가 평균 성능보다 훨씬 더 눈에 띕니다.
고객 지원 워크플로에 내장된 AI 도우미나 IDE 내부의 코드 생성 기능을 생각해 보세요. 두 경우 모두 사용자는 즉각적이고 예측 가능한 반응성을 기대합니다. 몇 가지 느린 응답은 평균적으로 인식되지는 않지만 눈에 띕니다. 한때 인프라 세부사항이었던 것이 제품 결함이 됩니다.
두 번째 교대조:비용이 추가되기 시작할 때
시스템이 성장함에 따라 사용량이 더욱 규칙적으로 변합니다. 가끔 요청이었던 것이 꾸준한 트래픽으로 바뀌고, 한때 실험적이었던 기능이 일상적인 사용의 일부가 되었습니다. 이때부터 서버리스 가격이 다르게 느껴지기 시작합니다.
서버리스는 무언가 실행될 때만 비용을 지불하므로 사용량을 예측할 수 없을 때 잘 작동합니다. 그러나 시스템이 항상 활성화되어 지속적인 요청을 처리하거나 백그라운드 작업을 실행하면 결국 동일한 작업에 대해 계속해서 비용을 지불하게 됩니다. 시간이 지남에 따라 이러한 편리함은 점점 비싸지기 시작합니다.
이 시점에서는 고정 GPU에서 모델을 실행하는 전용 인프라가 더 이해하기 시작합니다. 리소스를 효율적으로 사용하는 한 성능을 더욱 안정적으로 유지하려면 비용을 더욱 효과적으로 제어해야 합니다.
여기서는 실제로 잘못된 일이 없습니다. 이는 시스템이 더 이상 초기 설정이 가장 비용 효율적인 선택이 아닌 수준까지 성장했음을 의미합니다.
플랫폼 선택이 아닌 워크로드 형태가 결과를 좌우합니다
시간이 지남에 따라 분명해지는 것은 결정이 실제로 두 가지 유형의 플랫폼 중 하나를 선택하는 것이 아니라는 것입니다. 워크로드가 어떻게 동작하고 그 동작이 어떻게 변하는지 이해하는 것입니다.
많은 팀이 저지르는 실수는 현재 워크로드 형태가 영구적이라고 가정하는 것입니다. 실제로 대부분의 시스템은 여러 상태를 거쳐 이동합니다. 애플리케이션은 매우 급증하는 사용량으로 시작하여 반쯤 예측 가능한 일일 주기로 전환한 후 결국 꾸준하고 높은 처리량 패턴으로 정착될 수 있습니다. 각 단계는 서로 다른 접근 방식을 선호합니다.
중간 단계
가장 어려운 단계는 시작이나 끝이 아니라 그 사이의 전환입니다. 아무 문제가 없더라도 시스템이 "꺼진" 느낌을 받는 경우가 바로 여기에 있습니다. 지연 시간 문제는 가끔 나타나지만 일관되지는 않으며 비용이 증가하기 시작하지만 전체 아키텍처 전환을 정당화하기에는 충분하지 않습니다. 개발자는 응답 캐싱, 환경 준비, 동시성 조정과 같은 해결 방법을 추가하기 시작합니다. 이러한 변경 사항은 일시적으로 도움이 되지만 시스템이 원래 설계된 것 이상으로 추진되고 있다는 신호이기도 합니다.
성장하는 AI 고객 지원 도우미의 예를 다시 들어 보겠습니다. 초기 단계에서는 더 적은 수의 쿼리를 처리할 수 있지만 채택이 증가함에 따라 시스템은 피크 시간대에 수백 개의 요청을 처리하기 시작합니다. 대부분의 응답은 여전히 빠르지만 일부 응답은 콜드 스타트 또는 확장 지연으로 인해 눈에 띄게 더 오래 걸립니다. 팀에서는 반복되는 쿼리에 대한 캐싱을 추가하고 대기 시간 급증을 줄이기 위해 사전 가동을 시도합니다. 동시에 시스템이 더욱 일관되게 실행되기 때문에 월별 비용도 증가합니다. 그러나 트래픽은 여전히 전용 GPU로의 전환을 정당화할 만큼 충분히 안정적이지 않으며, 업무 외 시간에는 유휴 상태로 있을 수 있습니다. 이는 시스템이 기술적으로 작동하지만 지속적인 조정이 필요하고 서버리스나 전용 인프라 모두 완벽하게 적합하지 않다고 느끼는 실망스러운 중간 지점을 만듭니다.
대규모
어느 시점에서 시스템이 예측 불가능해지지 않게 됩니다. 대략적으로 얼마나 많은 요청이 들어오는지 알 수 있습니다. 바쁜 시간이 언제인지 알 수 있습니다. 추측은 사라졌습니다.
이제 실행이 중단되지 않는 시스템에서 요청별로 비용을 지불하고 있습니다. 한때 가끔씩 발생했던 콜드 스타트는 이제 용납할 수 없는 것처럼 느껴집니다. 사용자는 빠르고 일관된 응답을 기대하게 되었으며 모든 차이가 눈에 띄게 되었습니다. 처음에는 빠르게 움직일 수 있도록 도와주었던 인프라가 이제는 속도를 늦추는 요소가 되었습니다. 전용 추론이 이를 깔끔하게 해결합니다. GPU를 예약하고 모델이 로드된 상태로 유지되며 모든 요청이 동일한 경험을 얻습니다. 공유도, 가동 지연도, 예상치 못한 일도 없습니다.
경제도 변한다. 시스템이 항상 활성화되어 있으면 예약된 컴퓨팅에 대한 비용을 지불하는 것이 사용량에 따른 비용을 지불하는 것보다 저렴합니다. 예를 들어 Together.ai의 전용 엔드포인트는 H100의 경우 시간당 약 3.99달러부터 시작합니다. 꾸준한 트래픽에서는 서버리스에 지출한 비용보다 적은 경우가 많으며 그에 더해 더 나은 성능을 얻을 수 있습니다. 얻을 수 있는 것은 비용 절감이나 응답 속도 향상뿐만이 아닙니다. 안정성입니다. 인프라 튜닝을 중단하고 이를 신뢰하기 시작합니다. 이때는 제품 아래의 레이어를 관리하지 않고 제품 구축에 전적으로 집중할 수 있습니다. 서버리스는 완전히 사라지지 않습니다. 예상치 못한 급증, 실험적 기능, 빈도가 낮은 작업 등 극단적인 경우를 계속 처리합니다. 하지만 더 이상 핵심 워크로드를 수행하지 않습니다. 이제 전용 인프라가 이를 수행합니다.
개발자가 실제로 서버리스 추론 플랫폼을 경험하는 방법
이러한 시스템의 작동 방식을 이해하는 좋은 방법은 개발자가 일반적으로 사용되는 두 가지 플랫폼인 Modal 및 Together.ai와 상호 작용하는 방식을 살펴보는 것입니다. 둘 다 인프라를 추상화하는 비슷한 아이디어에서 시작하지만 추상화가 실제로 나타나는 방식(특히 가격 책정 및 확장)을 보면 일이 잘 작동하는 부분과 절충이 시작되는 부분이 드러납니다.
모달
Modal은 컴퓨팅 시간에 대해 엄격하게 비용을 지불하는 서버리스 모델을 중심으로 설계되었습니다. 예를 들어, GPU 사용량은 초당 청구됩니다. 소형 GPU(예:L4)의 경우 약 $0.0002/초, H100과 같은 고급 GPU의 경우 약 $0.0011/초(하드웨어에 따라 시간당 약 $0.8~$4)로 계산됩니다. 월간 크레딧이 약 30달러인 무료 등급도 있으므로 초기 비용 없이 쉽게 시작할 수 있습니다. 실제로 이는 사용자가 트리거할 때만 트래픽을 가져오는 이미지 생성 API 또는 하루에 몇 번 실행되는 백그라운드 작업과 같이 급증하는 워크로드에 매우 효과적입니다. 유휴 GPU에 대한 비용을 지불하지 않고 자동으로 확장이 이루어집니다. 그러나 사용이 계속되면서 하루 종일 지속적으로 이미지를 처리하는 실시간 객체 감지 모델을 실행한다고 가정하면 가격 책정 모델에서 장단점이 드러나기 시작합니다. 시스템이 항상 사용되고 있기 때문에 더 이상 "사용할 때만 지불"의 혜택을 누릴 수 없습니다. 대신, 동일한 GPU를 작은 단위로 계속해서 효과적으로 임대하게 되며, 단순히 GPU를 계속 실행하는 것보다 누적 비용이 더 높은 경우가 많습니다. 동시에 콜드 스타트 및 컨테이너 재사용과 같은 성능 특성으로 인해 프로덕션 환경에서 무시하기가 점점 더 어려워지는 가변성이 발생합니다.
투게더.ai
Together.ai는 서버리스 API로 시작하지만, 시스템 성장에 있어 흥미로운 점은 요구 사항이 변함에 따라 플랫폼을 전환하도록 강요하지 않는다는 것입니다. 코드 방식을 변경하지 않고도 기본 API 사용에서 전용 GPU 엔드포인트로 이동할 수 있습니다.
엔트리 레벨에서는 토큰당 비용을 지불합니다. 가격은 모델에 따라 다르며, 백만 토큰당 약 0.10~3달러이며, 트래픽이 적거나 예측할 수 없는 경우에 적합합니다. 자동 확장이 가능하며 관리할 인프라가 없습니다. 이는 대부분의 사용 사례에 대한 합리적인 출발점입니다.
트래픽이 증가하고 대기 시간이 중요해지기 시작하면 Together.ai를 사용하여 전용 엔드포인트로 이동할 수 있습니다. 시간당 약 $3.99의 H100 또는 시간당 약 $5.49의 H200 중에서 하드웨어를 선택하면 해당 GPU가 귀하의 것입니다. 공유 컴퓨팅이 없고 다른 워크로드의 간섭이 없습니다. 모델은 로드된 상태로 유지되며 지연 시간 프로필은 일관되게 유지됩니다.
절충안은 모든 전용 설정에서 직면하는 것과 동일합니다. 근무 외 시간에 트래픽이 감소하더라도 해당 GPU는 계속 실행되고 있는 것입니다. 용량 사용 여부에 관계없이 용량에 대한 비용을 지불하게 됩니다. 작업량이 안정적이면 괜찮습니다.
확장 중인 팀의 경우 Together.ai의 실질적인 이점은 마이그레이션 경로가 내부적이라는 점입니다. 전용 성능을 얻기 위해 통합을 다시 구축하지 않습니다. 끝점 구성을 변경합니다. 이는 전환이 너무 지장을 준다고 느껴서 전환을 지연시키는 대신, 적시에 전환하는 데 방해가 되는 실제 장벽을 제거합니다.
예를 들어, 중간 규모 모델을 실행하는 데는 입력 토큰 백만 개당 약 $0.10~$0.60의 비용이 들 수 있으며 모델에 따라 출력 토큰이 더 높아지는 경우도 있습니다. 따라서 사용량에 따라 비용이 증가하는 챗봇이나 텍스트 생성 API와 같은 사용 사례에 직관적입니다. 예를 들어, 하루에 수백만 개의 토큰을 생성하는 고객 지원 봇은 볼륨에 따라 한 달에 수십 달러에서 수백 달러의 비용이 들 수 있습니다. 동시에 Together.ai는 워크로드가 안정적일 때 H100의 경우 시간당 약 3.99달러부터 시작하는 전용 GPU 엔드포인트를 제공합니다. 이는 일반적인 패턴을 반영합니다. 개발자는 단순한 API 기반 사용으로 시작하지만 트래픽이 안정화되고 예상 대기 시간이 증가함에 따라 더 예측 가능한 성능과 비용을 위해 전용 설정으로 이동하는 경우가 많습니다.
중요한 변화는 플랫폼이 아니라 시간 경과에 따른 플랫폼 사용 방법입니다. :
- 초기 단계 → 간단한 API처럼 사용
- 성장 단계 → 지연 시간과 비용에 대한 걱정이 시작됩니다.
- 확장 → 동일 플랫폼 내 전용 엔드포인트로 이동
따라서 순수한 서버리스 플랫폼과 달리 공급자를 반드시 변경할 필요는 없습니다. 모드를 변경하면 됩니다. .
결정하기 전에 고려해야 할 사항
- 비용은 예상과 다르게 확장됩니다. 서버리스 플랫폼은 컴퓨팅 1초마다 고정된 주문형 요금을 청구합니다. 시스템이 유휴 상태일 때 해당 모델은 효율적입니다. 시스템이 지속적으로 실행되면 동일한 속도가 아무 문제 없이 24시간 내내 실행됩니다. 예약된 용량을 지원하는 인프라는 실제 시간당 비용을 크게 낮출 수 있으며 때로는 절반 이상까지 낮출 수 있습니다. 워크로드가 예측 가능하게 유지되는 기간이 길어질수록 그 차이는 더 커집니다.
- 관리되는 기본값은 시간이 지남에 따라 제약이 됩니다 :관리형 추론 플랫폼은 때때로 사용자를 대신하여 구성 결정을 내립니다. 실행되는 최적화, 메모리 처리 방법, 요청 일괄 처리 방법입니다. 초기 단계에서는 이러한 기본값을 사용하여 시간을 절약할 수 있습니다. 나중에 특정 워크로드에 맞게 추론 계층을 조정해야 할 때 동일한 기본값이 방해가 됩니다. 구성에 액세스할 수 없으면 변경할 수 없습니다. 인프라를 소유한다는 것은 해당 설정이 귀하의 것임을 의미합니다.
- 귀하의 가시성은 플랫폼에 표시되는 내용으로 제한됩니다. :관리형 플랫폼에서는 문제가 발생하거나 비용이 예기치 않게 급증하는 경우 플랫폼에서 구축한 대시보드에서만 조사할 수 있습니다. 무언가 느리거나 비용이 많이 든다는 것을 알 수 있지만 인프라 계층이 도달할 수 없는 경우 정확한 이유를 추적하는 것은 어렵습니다. 전용 인프라는 컴퓨팅, 네트워킹, 스토리지 전반에 걸쳐 완전한 관찰성을 제공합니다. 모든 것을 확인하고 이에 따라 조치를 취할 수 있습니다.
- 더 많은 통제력은 더 많은 책임을 의미합니다. 인프라를 소유하면 비용이 절감되고, 통제력이 강화되며, 완전한 가시성이 확보됩니다. 하지만 이는 관리형 플랫폼이 대신 처리하는 설정 및 운영 작업을 귀하가 맡는다는 의미이기도 합니다. 이는 항상 올바른 선택은 아닙니다. 특히 팀 규모가 작거나 워크로드가 계속 변하는 경우에는 더욱 그렇습니다. 즉, 올바른 플랫폼은 항상 관리형 플랫폼과 자체 관리형 플랫폼 간의 격차를 줄이기 위해 올바른 균형을 유지합니다. 일부 인프라 플랫폼에는 이제 사전 구성된 추론 이미지, 원클릭 GPU 배포, 즉시 사용 가능한 Kubernetes 지원이 함께 제공됩니다. 즉, 처음부터 시작하지 않아도 됩니다. 운영 오버헤드는 실제적이지만 이전보다 훨씬 가벼워졌습니다.
결론
서버리스 추론은 마찰 없이 시작하고, 실험하고, 출시하는 속도를 제공합니다. 그러나 시스템이 성장함에 따라 한때 더 빠르게 움직이는 데 도움이 되었던 바로 그 추상화는 대기 시간 일관성, 처리량 및 비용 효율성과 같은 가장 중요한 것들을 숨기기 시작할 수 있습니다. Modal 및 Together.ai와 같은 플랫폼을 사용하면 초기에 쉽게 구축하고 확장할 수 있으며 많은 경우 나중에도 아키텍처의 일부로 남아 있습니다. 그러나 워크로드가 예측 가능해지고 기대치가 높아짐에 따라 더 많은 제어가 필요해졌습니다. 실제 시스템은 정적으로 유지되지 않습니다. 불확실성에서 예측 가능성으로, 실험에서 생산으로 이동합니다. 그리고 그렇게 하면서 "올바른" 인프라 선택도 함께 이동합니다. 팀이 저지르는 실제 실수는 서버리스를 실제 단계가 아닌 장기적인 기본값으로 간주하는 것입니다. 워크로드가 안정화된 후 전용 인프라로의 이동을 지연하는 시간이 길어질수록 비용, 성능 또는 두 가지 모두에 대해 더 많은 비용을 지불하게 됩니다.
이 저작물은 Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International에 따라 라이센스가 부여됩니다. 라이센스.