Inferencja LLM na AWS - Bedrock vs SageMaker vs self-hosting na EKS

Kiedy wybrać poszczególne opcje - framework decyzyjny

Zanim porównamy cenniki, architekturę i narzut operacyjny, kluczowe pytanie brzmi: co optymalizujesz?

• Bedrock - chcesz zerowego zarządzania infrastrukturą, płacisz tylko za zużycie i potrzebujesz dostępu do topowych modeli (Claude Sonnet 4.6/5, Opus 4.6/4.8, Llama 3, Mistral) bez zarządzania GPU
• SageMaker - potrzebujesz dostrojonych modeli, własnych kontenerów lub dedykowanej wydajności z gwarancjami opóźnienia
• Self-hosting na EKS - wymagasz pełnej kontroli nad stosem inferencji, uruchamiasz modele open-source (Llama 4, Mixtral, Qwen, Phi) lub musisz minimalizować koszt per token przy dużym wolumenie

W praktyce wiele zespołów stosuje kombinację: Bedrock do prototypowania i niskowolumenowej produkcji, SageMaker dla dostrojonych modeli, a EKS dla wysoko-przepustowej inferencji wsadowej. Te architektury nie wykluczają się wzajemnie.

AWS Bedrock - architektura, cennik i ograniczenia

Jak działa Bedrock

Bedrock to w pełni zarządzana usługa. Wysyłasz zapytanie (prompt + parametry), AWS kieruje je do infrastruktury dostawcy modelu i otrzymujesz odpowiedź. Nie ma instancji do tworzenia, GPU do zarządzania ani cold startów przy inferencji on-demand.

Przepływ zapytania:

1. Twoja aplikacja wywołuje API Bedrock InvokeModel lub Converse
2. AWS kieruje zapytanie na odpowiedni endpoint modelu (w tym samym regionie lub w innych regionach w UE)
3. Model przetwarza prompt i zwraca tokeny
4. Płacisz za każdy przetworzony token wejściowy i wygenerowany token wyjściowy

Cennik Bedrock - zestawienie per model

Bedrock rozlicza się za 1000 tokenów (w przybliżeniu 750 słów). Ceny różnią się znacząco w zależności od modelu:

Dla Provisioned Throughput Bedrock oferuje dedykowaną wydajność rozliczaną za jednostkę modelu na godzinę. Ma to sens przy przewidywalnych, wysokowolumenowych obciążeniach wymagających gwarancji przepustowości bez ograniczania przepustowości.

Przykład kalkulacji: chatbot obsługi klienta obsługujący 10 000 konwersacji dziennie ze średnio 500 tokenami wejściowymi i 200 tokenami wyjściowymi na turę, używając Claude 3.5 Haiku:

• Wejście: 10 000 x 500 / 1 000 x $0.0008 = $4.00/dzień
• Wyjście: 10 000 x 200 / 1 000 x $0.004 = $8.00/dzień
• Miesięcznie: ok. 1 450 PLN (ok. $360)

To wyjątkowo niska kwota za produkcyjny system AI bez jakiejkolwiek infrastruktury do zarządzania.

Kiedy Bedrock to właściwy wybór

• Wolumen inferencji poniżej 50 000 zapytań/dzień
• Potrzebujesz jakości topowych modeli bez zarządzania sprzętem
• Szybkie prototypowanie, gdzie czas do produkcji jest ważniejszy niż koszt per token
• Zespoły bez ekspertyzy w zakresie infrastruktury ML

Ograniczenia

• Brak fine-tuningu dla większości modeli - Bedrock wspiera fine-tuning tylko dla wybranych modeli (Titan, niektóre warianty Llama). Dla własnych modeli potrzebny jest SageMaker.
• Dostępność regionalna - najnowsze modele (Sonnet 5, Opus 4.8, Haiku 4.5) wymagają routingu EU Geographic (dane pozostają w UE, ale mogą być przetwarzane we Frankfurcie, Irlandii lub Paryżu). Modele in-region to Claude Sonnet 4.6, Opus 4.6, Claude 3.5 Haiku i Llama 3.
• Limity przepustowości - domyślne kwoty mogą ograniczać produkcyjne obciążenia. Wnioskuj o zwiększenie limitów proaktywnie.
• Brak kontroli nad streamingiem - ograniczona możliwość dostrajania rozmiarów paczek (batch), kwantyzacji czy parametrów inferencji poza tym, co eksponuje API.

Oficjalna dokumentacja cennika Bedrock: aws.amazon.com/bedrock/pricing

Endpointy SageMaker - architektura, cennik i kiedy wybrać

Typy endpoint inferencji

SageMaker oferuje trzy wzorce inferencji:

1. Endpointy real-time - instancje działające ciągle, obsługujące synchroniczne zapytania. Najlepsze dla produkcyjnych API o niskim opóźnieniu.
2. Inferencja serverless - automatycznie skaluje się do zera, tworzy pojemność na żądanie. Dobre dla sporadycznego ruchu, ale z kosztem zimnego startu (10-60 sekund).
3. Inferencja asynchroniczna - kolejkuje zapytania i przetwarza je w tle. Idealne dla zadań wsadowych i długich generacji.

Model cenowy

SageMaker rozlicza za godzinę działania instancji dla endpoint real-time. Płacisz za instancję niezależnie od tego, czy przetwarza zapytania, czy jest bezczynna.

Przykład kalkulacji: uruchomienie dostrojonego Llama 3 8B na ml.g5.xlarge 24/7:

• $1.41/h x 720 godzin = $1 015/miesiąc
• Miesięcznie: ok. 4 100 PLN (ok. $1 015)

Porównaj z Bedrock: jeśli przetwarzasz więcej niż ~250 000 zapytań/miesiąc ze średnio 500-tokenowymi promptami, SageMaker staje się tańszy od Bedrock w przeliczeniu na zapytanie.

Kiedy SageMaker wygrywa

• Masz dostrojony model i musisz go serwować
• Przewidywalny, stały ruch (instancja pracuje efektywnie przy 60-80% wykorzystaniu)
• Potrzebujesz kontroli nad rozmiarem paczki (batch), kwantyzacją (GPTQ, AWQ) i frameworkiem serwowania
• SLA opóźnienia wymaga dedykowanej wydajności bez cold startów
• Zgodność regulacyjna wymaga uruchomienia w VPC bez współdzielonej infrastruktury

Konfiguracja autoskalowania

SageMaker wspiera autoskalowanie z śledzeniem celu. Praktyczna konfiguracja:

# Autoskalowanie endpoint SageMaker na podstawie wywołań per instancja
import boto3

client = boto3.client("application-autoscaling")

# Rejestracja wariantu endpoint jako celu skalowalnego
client.register_scalable_target(
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/llm-production/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    MinCapacity=1,
    MaxCapacity=8,
)

# Skalowanie na podstawie wywołań per instancja (cel: 100 równoczesnych)
client.put_scaling_policy(
    PolicyName="llm-invocations-scaling",
    ServiceNamespace="sagemaker",
    ResourceId="endpoint/llm-production/variant/AllTraffic",
    ScalableDimension="sagemaker:variant:DesiredInstanceCount",
    PolicyType="TargetTrackingScaling",
    TargetTrackingScalingPolicyConfiguration={
        "TargetValue": 100.0,
        "PredefinedMetricSpecification": {
            "PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"
        },
        "ScaleOutCooldown": 60,   # sekundy przed kolejnym skalowaniem w górę
        "ScaleInCooldown": 300,   # sekundy przed skalowaniem w dół (konserwatywnie)
    },
)

Oficjalna dokumentacja cennika SageMaker: aws.amazon.com/sagemaker/pricing

Self-hosting na EKS - architektura dla zespołów wymagających pełnej kontroli

Dlaczego self-hosting?

Self-hosting inferencji LLM na EKS ma sens, gdy:

• Uruchamiasz modele open-source (Llama 4, Mixtral, Qwen, Phi) i chcesz całkowicie wyeliminować koszty API per token
• Wolumen zapytań jest na tyle duży (>100 tys. zapytań/dzień), że koszt obliczeniowy per token spada poniżej cennika usług zarządzanych
• Potrzebujesz własnych frameworków serwowania (vLLM, Text Generation Inference, Triton)
• Serwowanie wielu modeli na współdzielonej infrastrukturze GPU obniża łączny koszt
• Już operujesz EKS i masz ekspertyzę w uruchamianiu GPU

Komponenty architektury

Produkcyjny stos self-hosted LLM na EKS typowo obejmuje:

• Pule węzłów GPU - managed node groups lub węzły tworzone za pomocą Karpenter z GPU NVIDIA
• Serwer inferencji - vLLM, Hugging Face TGI lub NVIDIA Triton serwujący model
• Autoskaler - Karpenter do skalowania na poziomie węzłów, HPA/KEDA na poziomie podów
• Load balancer - ALB/NLB ze wsparciem gRPC lub HTTP/2
• Storage modelu - S3 + FSx for Lustre lub EBS dla szybkiego ładowania modelu
• Monitoring - Prometheus + Grafana śledzące wykorzystanie GPU, głębokość kolejki, percentyle opóźnienia

Koszty instancji GPU na EC2 (dla węzłów EKS)

Przewaga kosztowa self-hostingu wynika z dwóch czynników: (1) instancje GPU spot z rabatem 60-70% i (2) wysokie wykorzystanie dzięki grupowaniu zapytań (batching) i serwowaniu wielu modeli.

Karpenter NodePool dla instancji GPU spot

# Karpenter NodePool dla węzłów GPU do inferencji LLM
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: llm-inference-gpu
spec:
  template:
    metadata:
      labels:
        workload-type: llm-inference
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: gpu-nodes
      requirements:
        - key: "karpenter.k8s.aws/instance-family"
          operator: In
          values: ["g5", "g6"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]  # preferuj spot, fallback na on-demand
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
      taints:
        - key: nvidia.com/gpu
          effect: NoSchedule    # tylko obciążenia GPU lądują tutaj
  limits:
    cpu: "128"
    memory: "512Gi"
    nvidia.com/gpu: "16"        # max 16 GPU na wszystkich węzłach
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 5m        # szybko odzyskuj bezczynne węzły GPU
  weight: 10                    # preferuj tę pulę dla podów GPU

Deployment vLLM na EKS

# Kubernetes Deployment dla vLLM serwujący Llama 4 Scout 17B
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama-scout
  namespace: inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-llama-scout
  template:
    metadata:
      labels:
        app: vllm-llama-scout
    spec:
      nodeSelector:
        workload-type: llm-inference
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "meta-llama/Llama-4-Scout-17B-Instruct"
            - "--tensor-parallel-size"
            - "1"
            - "--max-model-len"
            - "8192"
            - "--gpu-memory-utilization"
            - "0.9"
          ports:
            - containerPort: 8000
              name: http
          resources:
            limits:
              nvidia.com/gpu: "1"
              memory: "32Gi"
            requests:
              nvidia.com/gpu: "1"
              memory: "24Gi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 120   # ładowanie modelu zajmuje czas
            periodSeconds: 10
          env:
            - name: HUGGING_FACE_HUB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-token
                  key: token

Model kosztowy dla self-hosted inferencji

Przykład: serwowanie Llama 4 Scout 17B na 2x g5.xlarge spot (24/7):

• 2 x $0.40/h x 720 godzin = $576/miesiąc
• Opłata za klaster EKS: $73/miesiąc
• ALB: ~$25/miesiąc
• Miesięcznie: ok. 2 700 PLN (ok. $674)

Przy typowej przepustowości 30 tokenów/sekundę na GPU, obsługuje to ok. 50 000-80 000 zapytań/dzień ze średnio 200-tokenowymi odpowiedziami. Koszt per zapytanie wynosi efektywnie 0,00003 PLN - o rząd wielkości taniej niż Bedrock przy tym wolumenie.

Porównanie kosztów w trzech scenariuszach

Punkt przecięcia, w którym self-hosting staje się tańszy od Bedrock, to typowo 10 000-20 000 zapytań/dzień, w zależności od modelu i długości tokenów. Poniżej tego progu zerowy narzut operacyjny Bedrock jest trudny do pokonania.

Porównanie opóźnienia i wydajności

Opóźnienie Bedrock jest akceptowalne dla większości interaktywnych aplikacji. Dla ścieżek krytycznych pod kątem opóźnienia (sygnały handlowe w czasie rzeczywistym, wymagania sub-100ms) jedyną realną opcją jest self-hosted inferencja z rozgrzanymi pulami GPU.

Macierz decyzyjna

Najczęściej zadawane pytania

Czy Bedrock jest tańszy niż własne GPU?

Przy niskim-średnim wolumenie (poniżej ~20 000 zapytań/dzień ze średniej długości promptami) - tak. Bedrock eliminuje bazowy koszt utrzymania instancji GPU 24/7. Powyżej tego progu self-hosting na instancjach spot staje się znacząco tańszy per token.

Czy mogę używać Bedrock i self-hostingu jednocześnie?

Tak - to częsty wzorzec. Używaj Bedrock do niskowolumenowych zadań wymagających wysokiej jakości (złożone rozumowanie, customer-facing chat) i self-hostingu do wysokowolumenowych, wrażliwych kosztowo zadań (klasyfikacja, ekstrakcja, embeddingi). Kieruj zapytania na podstawie złożoności zadania.

Co z SageMaker Serverless Inference dla LLM?

SageMaker Serverless Inference ma cold starty 10-60 sekund dla obciążeń GPU, co czyni go niepraktycznym do interaktywnego serwowania LLM. Sprawdza się dla przetwarzania wsadowego lub bardzo rzadkiej inferencji, ale dla produkcyjnych scenariuszy chat/API lepsze są endpointy real-time lub Bedrock.

Jak radzić sobie z przerwaniami GPU spot na EKS?

Karpenter automatycznie zastępuje przerwane instancje spot. Dla inferencji (bezstanowej) oznacza to krótki spadek pojemności (30-120 sekund) podczas tworzenia nowego węzła. Strategie mitygacji: uruchamiaj na wielu typach instancji i strefach dostępności, utrzymuj małą bazę on-demand (1-2 węzły) i stosuj Pod Disruption Budgets dla minimalnej liczby replik.

Jaki GPU wybrać na start dla modelu 17B?

Pojedynczy g5.xlarge (A10G, 24GB VRAM) wygodnie obsługuje Llama 4 Scout 17B lub Mistral 7B z kwantyzacją AWQ/GPTQ. Dla większych modeli potrzebujesz g5.12xlarge (4x A10G, 96GB łącznie) z tensor parallelism lub pojedynczej instancji p4d. Zacznij od małego, zmierz przepustowość i skaluj horyzontalnie.

Podsumowanie

• Bedrock to właściwy domyślny wybór dla zespołów rozpoczynających inferencję LLM. Zerowy narzut operacyjny, płatność za token. Najlepszy dla wolumenów poniżej 50 tys. zapytań/dzień.
• SageMaker wypełnia lukę dla dostrojonych modeli i przewidywalnych obciążeń, gdzie potrzebujesz dedykowanej wydajności bez zarządzania Kubernetes. Opłacalny przy średnich wolumenach z autoskalowaniem.
• Self-hosting na EKS zapewnia najniższy koszt per token w skali, ale wymaga ekspertyzy w uruchamianiu GPU, konfiguracji narzędzia Karpenter i dojrzałości operacyjnej. Redukcja kosztów o 60-80% względem usług zarządzanych uzasadnia inwestycję powyżej 100 tys. zapytań/dzień.
• Punkt przecięcia między Bedrock a self-hostingiem to typowo 4 000-6 000 PLN/miesiąc wydatków na Bedrock. Poniżej tej kwoty prostota operacyjna Bedrock wygrywa. Powyżej - zacznij planować infrastrukturę GPU na EKS.
• Dla obciążeń RAG, gdzie inferencja jest tylko jednym komponentem, zobacz nasz przewodnik po infrastrukturze RAG na AWS.

Potrzebujesz pomocy w zaprojektowaniu architektury inferencji LLM lub optymalizacji kosztów istniejącego wdrożenia? Zespół inżynierów Devopsity pomaga organizacjom przejść od prototypu do produkcyjnej infrastruktury AI. Skontaktuj się z nami, aby omówić Twoje wymagania.