OpenAI GPT-OSS: Jak uruchomić go lokalnie lub hostować samodzielnie w chmurze, wymagania sprzętowe

GPT-OSS jest wyjątkowo dobrze zaprojektowany pod kątem dostępności: gpt-oss-20B wariant jest przeznaczony do uruchomienia na pojedynczym procesorze graficznym (~16 GB VRAM) lub najnowszych laptopach z najwyższej półki, wykorzystujących skwantyzowane kompilacje GGUF, podczas gdy gpt-oss-120B—pomimo 117 mld parametrów — jest dostarczany z trikami MoE/aktywnymi parametrami i kwantyzacją MXFP4, która pozwala mu działać na pojedynczych procesorach graficznych klasy H100 (≈80 GB) lub w konfiguracjach wieloprocesorowych. Wdrożenie modelu open source w stylu GPT (często nazywanego „GPT OSS”) — niezależnie od tego, czy jest to kompaktowy model 6–7 mld dla aplikacji lokalnych, czy model 70 mld+ dla usług produkcyjnych — rodzi to samo zasadnicze pytanie: jak uruchomić GPT-OSS lokalnie lub samodzielnie hostować w chmurze? Wymagania sprzętowe

Czym są modele GPT-OSS i jakie są ich wymagania sprzętowe?

Czym jest GPT-OSS?

GPT-OSS to niedawno wydana przez OpenAI rodzina modeli językowych o dużej pojemności (w momencie premiery dwa główne warianty: wersje o parametrach ~20B i ~120B). Modele te są dostępne z zoptymalizowanymi opcjami (mieszanka ekspertów, natywna kwantyzacja MXFP4 w dystrybucji OpenAI, innowacje o rozproszonej/gęstej architekturze), które pozwalają tym stosunkowo dużym liczbom parametrów działać przy znacznie mniejszej ilości pamięci niż wymagałyby tego proste kopie FP32/FP16. Wydanie to miało na celu zwiększenie możliwości uruchamiania i dostosowywania zaawansowanych modeli poza systemami hiperskalerów.

Najważniejsze informacje o produkcie (nośność):

gpt-oss-20B jest przeznaczony do uruchomienia na pojedynczym procesorze graficznym typu GPU z ~16 GB pamięci VRAM (i może być używany na komputerach stacjonarnych/laptopach z kwantyzacją GGUF).
gpt-oss-120B (≈117B parametrów, ~5.1B aktywny parametry w projekcie MoE OpenAI) został zaprojektowany tak, aby model ten zmieścił się w pojedynczej obudowie H100 / A100 o pojemności 80 GB podczas korzystania z MXFP4 i obsługi określonego środowiska uruchomieniowego lub w konfiguracjach z wieloma procesorami graficznymi.

Czynniki sprzętowe określające wymagania

Rozmiar i architektura modelu – MoE i warstwy rzadkie/gęste mogą zmieniać aktywację i pamięć roboczą. (GPT-OSS wykorzystuje komponenty w stylu mieszanym z ekspertami).
Precyzja i kwantyzacja – FP32, FP16, BF16, 8-bitowy, 4-bitowy (GPTQ/AWQ/MXFP4). Niższa precyzja zmniejsza zużycie pamięci, ale może wpływać na opóźnienie i dokładność numeryczną. OpenAI zapewnia skwantyzowane wagi MXFP4 dla GPT-OSS.
Długość kontekstu (długość sekwencji) – dłuższe konteksty proporcjonalnie zwiększają wykorzystanie pamięci podręcznej aktywacji; GPT-OSS obsługuje wyjątkowo długie konteksty (nawet bardzo duże okna tokenów w swojej konstrukcji), co zwielokrotnia zapotrzebowanie na pamięć.
Rozmiar partii i współbieżność – obsługa wielu równoczesnych użytkowników zwiększa zapotrzebowanie na pamięć przeznaczoną na aktywacje i pamięć podręczną. Platformy takie jak vLLM, DeepSpeed i Triton starają się efektywnie grupować i udostępniać aktywacje w ramach żądań.
Narzut struktury serwującej – różne serwery wnioskowania (vLLM, text-generation-inference, llama.cpp, ONNX Runtime) powodują różne obciążenia i optymalizacje.

Co gdzie „pasuje”: zasady pamięci

Przy planowaniu sprzętu istotne są dwie koncepcje:

Całkowita liczba parametrów — górna granica rozmiaru modelu (117B vs. 21B).
Zestaw aktywowany/działający — w MoE lub w pewnych precyzyjnych ustawieniach pamięć aktywna potrzebna do wnioskowania może być znacznie mniejsza niż surowe bajty parametrów.

Praktyczne zasady:

Laptopy z procesorami graficznymi klasy 16 GB/edge → możliwe dla gpt-oss-20b jeśli użyjesz konfiguracji zapewniającej efektywne wykorzystanie pamięci w modelu (lub agresywnie kwantyzujesz do 4-bitów/NF4/AWQ).
80 GB H100 / A100 80 GB → hosting z jednym GPU gpt-oss-120b w zalecanej konfiguracji. Aby zapewnić przepustowość produkcyjną, nadal możesz potrzebować wielu procesorów GPU do przetwarzania wsadowego, redundancji lub mniejszych opóźnień w trybie współbieżnym.
Duże konfiguracje wieloprocesorowe (klastry A100/H100) → wymagane, jeśli chcesz uruchomić wielu użytkowników jednocześnie z niskim opóźnieniem lub przeprowadzić zaawansowane dostrajanie/szkolenie. DeepSpeed/ZeRO i automatyczny paralelizm tensorowy umożliwiają dzielenie dużych modeli na procesory graficzne.

Krótki wniosek: do eksperymentów i lekkiego użytku lokalnego zaplanuj kartę graficzną o pojemności 16–24 GB (lub procesor CPU + mocna kwantyzacja). Do produkcyjnego wnioskowania na jednym GPU w dużym modelu GPT-OSS, docelowo użyj karty H100 z 80 GB, w przeciwnym razie skorzystaj z partycjonowania wieloprocesorowego.

Jaka moc obliczeniowa jest wymagana do wdrożenia GPT-OSS w praktyce?

Wnioskowanie kontra szkolenie: zupełnie różne budżety

Wnioskowanie: dominującym kosztem jest pamięć GPU (VRAM) i zoptymalizowane jądra. Dzięki zoptymalizowanym środowiskom wykonawczym (vLLM, TensorRT, DeepSpeed-Inference) i kwantyzacji, wnioskowanie na gpt-oss-20b jest wykonalne na konsumenckim GPU z 16 GB pamięci; model MoE 120B jest zaprojektowany tak, aby pasował do karty H100 z 80 GB pamięci.
Dostrajanie / szkolenie na pełną skalę: o rzędy wielkości większe — będziesz potrzebować wielu procesorów GPU lub wyspecjalizowanych instancji szkoleniowych (wielowęzłowych klastrów H100/A100, budżetu DFLOP i operacji wejścia/wyjścia pamięci masowej). Ten artykuł koncentruje się głównie na wnioskowaniu/samodzielnym hostingu i lekkich recepturach dostrajających (QLoRA/LoRA), a nie na wielotygodniowym szkoleniu wstępnym.

CPU kontra GPU kontra akceleratory specjalistyczne

Tylko procesor: możliwe z GGUF/llama.cpp i małymi kwantyzowanymi kompilacjami, rezygnacja z opóźnień na rzecz niższych kosztów. Uruchamianie 20B na procesorze bez kwantyzacji jest niepraktyczne. Używaj procesora, gdy prywatność lub praca lokalna w trybie offline są kluczowe, a zapotrzebowanie na przepustowość jest niskie.
GPU: preferowany ze względu na opóźnienia i przepustowość. Nowoczesne procesory graficzne ML (A100/H100/4090/4080) różnią się znacznie pod względem pamięci HBM/VRAM i struktury międzyprocesorowej. Dokumentacja gpt-oss zaleca klasę H100 dla wariantu 120B.
TPU / AMD MI300X:obsługiwane przez niektóre środowiska uruchomieniowe (kompilacje vLLM/ROCm) i może być opłacalne w niektórych chmurach — sprawdź dokumentację dostawcy przy wyborze sprzętu.

Jak uruchomić GPT-OSS lokalnie przy ograniczonym budżecie? (kod + instrukcja krok po kroku)

Poniżej przedstawiono dwa praktyczne podejścia: () Laptop/komputer stacjonarny z GPU i pamięcią VRAM ~16–24 GB, wykorzystujący kwantyzację 4-bitową i (B) CPU/niskie obciążenie GPU (offline) z wykorzystaniem llama.cpp (GGUF) lub małych kompilacji kwantyzowanych. Oba są szeroko stosowane przez programistów, gdy pieniądze i moc obliczeniowa są ograniczone.

Uwaga: te instrukcje zakładają, że posiadasz działające środowisko Pythona (Linux zalecany dla najlepszej obsługi CUDA). W systemie Windows użyj WSL2, aby zapewnić najlepszą kompatybilność z łańcuchami narzędzi GPU.

A. Trasa GPU (zalecana dla uzyskania najlepszego opóźnienia przy ograniczonym budżecie) — kwantyzacja + ładowanie za pomocą bitów i bajtów (4 bity)

Ta ścieżka ma na celu bieganie openai/gpt-oss-20b na pojedynczym procesorze graficznym (np. 24 GB 4090 lub 16 GB 4080). Wykorzystuje 4-bitową kwantyzację bitsandbytes i technologię Hugging Face. transformers mapa urządzeń/przyspieszenie.

Krok 1 — Zainstaluj podstawowe elementy

# Linux + CUDA (example); pick the correct torch CUDA wheel for your driver

python -m pip install -U pip
pip install torch --index-url https://download.pytorch.org/whl/cu121  # pick your CUDA version

pip install -U transformers accelerate bitsandbytes safetensors

(Jeśli używasz Conda, utwórz środowisko i zainstaluj koło Torch zgodne ze standardem CUDA dla swojej platformy.)

Krok 2 — (Opcjonalnie) Zaloguj się do Hugging Face, aby pobrać duże pliki

huggingface-cli login

Krok 3 — przykład w Pythonie (ładowanie skwantyzowanego modelu 4-bitowego)

# save as run_gptoss_4bit.py

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig

model_id = "openai/gpt-oss-20b"

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type="nf4"   # or "fp4"/"nf4" depending on support

)

tokenizer = AutoTokenizer.from_pretrained(model_id, use_fast=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map="auto",                 # let transformers pick GPU + CPU offload if needed

    quantization_config=bnb_config,
    torch_dtype=torch.float16,
    trust_remote_code=True
)

prompt = "Write a concise summary of quantization for LLMs."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(out, skip_special_tokens=True))

Notatki i wskazówki

Zastosowanie device_map="auto" so transformers automatycznie korzysta z odciążenia CPU/GPU. Jeśli masz pojedynczy GPU, device_map="auto" zwykle przenosi wszystko na GPU i odciąża CPU, co musi być na nim zainstalowane.
Jeśli zabraknie Ci pamięci VRAM, dodaj --offload_folder ./offload (lub ustaw offload_folder in from_pretrained) w celu przeniesienia tensorów do NVMe.
Podejście Hugging Face + bitsandbytes jest szeroko udokumentowane; szczegóły można znaleźć w przewodniku po 4-bitowych transformatorach.

B. Procesor / trasa o małym budżecie (llama.cpp / GGUF)

Jeśli nie masz procesora graficznego lub masz bardzo mały procesor graficzny, llama.cpp Kompilacje GGUF (oraz skwantyzowane pliki AWQ/GPTQ) umożliwiają uruchamianie modeli na procesorze z akceptowalnym opóźnieniem dla pojedynczych użytkowników.

Krok 1 — Zainstaluj llama.cpp / powiązania Python

# Download and build (Linux)

git clone --recursive https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
make
# Python bindings (optional)

pip install llama-cpp-python

Krok 2 — Konwersja safetensorów → GGUF (jeśli skrypty konwersji są dostępne dla gpt-oss)
OpenAI/Hugging Face zapewniają bezpieczne tensory, konwertery społecznościowe (lub skrypty w llama.cpp) konwertuj do GGUF. Dokładne polecenie zależy od bieżącego llama.cpp narzędzia; sprawdź plik README w repozytorium convert.py/convert-safetensors-to-gguf. (Wątki społeczności omawiają konwersję na nowe modele.)

Krok 3 — Uruchom model za pomocą llama.cpp

# basic inference (example)

./main -m ./gpt-oss-20b.gguf -p "Explain GGUF and quantization in one paragraph." -n 256

Uwagi i kompromisy

Procesor działa znacznie wolniej. Użyj tej ścieżki do testowania, prywatności lub agentów lokalnych o bardzo niskiej współbieżności.
Generowanie długich wyników lub obsługa wielu równoczesnych użytkowników przy użyciu procesora nie jest praktyczna; w celu realizacji produkcji należy skorzystać z procesora graficznego.

Skwantyzowane kompilacje na dysku (GPTQ/AWQ)

Jeśli trzeba zmieścić duży model na małym procesorze graficznym (np. 8–12 GB), wyniki społeczności pokazują, że kwantyzacja w stylu GPTQ/AWQ może sprawić, że niektóre modele 20B będą działać na procesorach graficznych o małej pamięci VRAM — ale konwersja często wymaga jeszcze Pamięć RAM procesora i jeden pośredniczący procesor graficzny podczas konwersji. Narzędzia: GPTQ-for-LLaMa, AutoGPTQ (zarchiwizowane), AWQ, QLLM.

Praktyczne wskazówki dla osób z ograniczonym budżetem

Preferuj 4-bitowe punkty kontrolne kwantyzowane (GPTQ/AWQ/MXFP4) — często różnica między „działa na 12 GB” a „wymaga 80 GB”.
Ogranicz długość kontekstu W przypadku wnioskowania budżetowego: długie konteksty powodują rozsadzenie pamięci podręcznej aktywacji. Jeśli musisz przechowywać długie konteksty, rozważ strategie odciążania.
Używaj pamięci ujednoliconej/odciążania NVMEM ostrożnie — frameworki mogą oferować odciążenie procesora/NVMe (DeepSpeed ZeRO-Offload / ZeRO-Infinity), ale zwiększa to opóźnienie.

Jak samodzielnie hostować GPT-OSS u dostawców chmury (praktyczny przewodnik i wskazówki dotyczące kosztów)?

Jaki sprzęt chmurowy wybrać?

Pojedynczy GPU 80 GB H100:Dobry do hostowania gpt-oss-120b dla małego i średniego ruchu. W terminologii AWS, instancje P5 zapewniają sprzęt H100; warianty z pojedynczym GPU (zapowiedziane w 2025 roku) obniżają koszty dopasowania rozmiaru do inferencji. W zależności od dostawcy, należy używać rodziny P5/ND H100.
Multi-GPU (8× H100):dla wysokiej przepustowości i redundancji użyj klastra p5.48x, p5dn lub porównywalnego. NVidia NVLink/NVSwitch w tym samym przypadku zmniejsza obciążenie komunikacji między procesorami graficznymi.
Alternatywne chmury: CoreWeave, Lambda Labs, Paperspace, Runpod — często tańsze wynajmy GPU na żądanie/spot do wnioskowania impulsowego. Wykorzystaj je do celów deweloperskich, zanim zdecydujesz się na długoterminową infrastrukturę.
Nowoczesna / ciężka produkcja: AWS p5 (H100) (8 × H100 80 GB na instancję) — dla najwyższej przepustowości na węzeł i potrzeb 80+ GB dla pojedynczego GPU lub dla 120+ B z mniejszym podziałem. P5 zapewnia H100 i dużą lokalną pamięć masową NVMe.

kontenery TGI (generowanie tekstu i wnioskowanie)/NVIDIA TGI lub konfiguracja wnioskowania DeepSpeed.

Zapewnij szybką lokalną pamięć NVMe jeśli planujesz odciążyć duże stany aktywacji (ZeRO-Infinity), węzły P4/P5 często mają lokalny NVMe i bardzo dużą przepustowość sieci. ()
Bezpieczeństwo i sieci — umieść punkty końcowe wnioskowania za modułami równoważenia obciążenia, użyj grup automatycznego skalowania dla front-endów i oddziel kwestie (obsługa modeli kontra routing żądań).
Monitorowanie i SLO — śledź wykorzystanie GPU, pamięć, tokeny/sek., opóźnienie p95 i błędy; do metryk użyj Prometheus + Grafana.

Przykładowy przepływ pracy w chmurze z własnym hostingiem (AWS P4/P5)

Wybierz instancję (p4d/p5) w zależności od zapotrzebowania na pamięć modelu. W przypadku gpt-oss-20B wystarczy pojedyncza instancja o pojemności 16–32 GB; w przypadku gpt-oss-120B należy wybrać instancję HBM o pojemności 80 GB lub multi-GPU.
Przygotuj AMI / obraz — użyj obrazu AMI dostawcy zawierającego CUDA, cuDNN i zoptymalizowany PyTorch (lub obrazów dostawcy ze sterownikami NVIDIA).
Zainstaluj stos obsługujący: vLLM, transformatory, kontenery generujące tekst i wnioskowanie (TGI)/NVIDIA TGI lub konfiguracja wnioskowania DeepSpeed.
Zapewnij szybką lokalną pamięć NVMe jeśli planujesz odciążyć duże stany aktywacji (ZeRO-Infinity), węzły P4/P5 często mają lokalny NVMe i bardzo dużą przepustowość sieci.
Bezpieczeństwo i sieci — umieść punkty końcowe wnioskowania za modułami równoważenia obciążenia, użyj grup automatycznego skalowania dla front-endów i oddziel kwestie (obsługa modeli kontra routing żądań).
Monitorowanie i SLO — śledź wykorzystanie GPU, pamięć, tokeny/sek., opóźnienie p95 i błędy; do metryk użyj Prometheus + Grafana.

Przykładowy plan samodzielnego hostingu (gpt-oss-20b, produkcja na małą skalę)

Cel: obsługuje ok. 20 jednoczesnych użytkowników, docelowy czas reakcji 1–2 s, wrażliwa na koszty.

Instancja: 1× A10G / 1× 24 GB GPU (np. G5 / A10G / RTX 6000) dla modelu + 1× mały serwer bootstrapowy CPU.
Czas pracy:vLLM jako serwer modelowy (ciągłe przetwarzanie wsadowe) + brama CometAPI.
Automatyczne skalowanie:użyj grupy automatycznego skalowania z GPU AMI i ALB + poziomego automatycznego skalowania według metryk CPU/GPU.
Magazynowanie: Lokalny interfejs NVMe do buforowania modeli; magazyn obiektów (S3) do przechowywania modeli na zimno.
Monitorowanie:Prometheus + Grafana, śledzenie wykorzystania GPU, opóźnień, długości kolejki.
Ochrona: VPC, prywatne podsieci, role IAM dla pamięci masowej modeli, certyfikaty TLS.

Przykładowy plan samodzielnego hostingu (gpt-oss-120b, produkcja)

Cel: niskie opóźnienie dla wielu jednoczesnych użytkowników / przedsiębiorstwo.

Instancja:1× H100 80 GB (pojedynczy GPU) jako punkt odniesienia; skalowanie poziome lub użycie instancji p5 z wieloma GPU dla uzyskania przepustowości. Aby uzyskać wysoką przepustowość, należy replikować usługę pojedynczego GPU (równoległe przetwarzanie danych) lub podzielić model na kilka GPU za pomocą DeepSpeed (tensor/pipeline).
Czas pracy:DeepSpeed-Inference z automatycznym TP lub NVIDIA TensorRT (jeśli dostępne). Przydatna może okazać się również obsługa MoE/Multi-GPU i dostrojonych jąder przez vLLM.
Kubernetes:użyj K8 z wtyczkami urządzeń i lokalnym NVMe; przeprowadź testy chaosu w celu sprawdzenia dostępności.
Optymalizacja kosztów: zarezerwowane instancje dla przewidywalnego obciążenia; instancje spot dla obciążeń wsadowych.

Przykład: uruchom kontener obsługujący vLLM dla gpt-oss-20b

# assume vllm is installed and CUDA is set up

vllm serve --model openai/gpt-oss-20b --port 8000 --num-gpus 1

Następnie skieruj swój front-end na http://<host>:8000/v1/chat/completions (vLLM obsługuje API zgodne ze standardem OpenAI).

Wskazówki dotyczące optymalizacji kosztów

Maszyny wirtualne typu spot/z możliwością wywłaszczenia są o 50–80% tańsze, ale wymagają stosowania punktów kontrolnych lub strategii szybkiego odradzania się.
Kwantyzacja modelu zmniejsza zapotrzebowanie na typy instancji (np. skwantyzowane 120B może być obsługiwane na mniejszej liczbie procesorów GPU, jeśli silniki obsługują dekwantyzację w locie).
Użyj rodzin instancji zoptymalizowanych wyłącznie pod kątem wnioskowania (P5/P4/A2 Ultra) z wysokim współczynnikiem NVLink/NVSwitch podczas wykonywania paralelizmu modeli wieloprocesorowych; przepustowość sieci ma znaczenie w przypadku partycjonowania międzyprocesorowego.

Jak zrównoważyć koszty, opóźnienia i jakość modelu

Kwantyzacja: prędkość kontra jakość

Agresywna kwantyzacja (2-4 bity, AWQ/GPTQ) → Ogromne oszczędności pamięci i często niewielka utrata jakości w przypadku wielu zadań. Używaj AWQ/GPTQ w środowisku produkcyjnym, jeśli testujesz konkretne obciążenie. Konwersja może wymagać dużej ilości pamięci procesora podczas kwantyzacji.

Mieszana precyzja i optymalizacje jądra

Zastosowanie Fp16, bf16 tam, gdzie jest to obsługiwane; połącz ze specjalistycznymi jądrami CUDA (FasterTransformer, TensorRT) dla maksymalnej przepustowości. Nvidia/TensorRT oferuje dekodowanie spekulatywne i zoptymalizowane jądra dla wielu transformatorów (NVIDIA zapewnia zoptymalizowane adaptery GPT-OSS).

Bezpieczeństwo i obserwowalność

Modele Open-weight oznaczają, że odpowiadasz za monitorowanie niewłaściwego użycia, wycieku danych i dryfu. Wdrażaj rejestrowanie żądań, filtry treści, ograniczanie przepustowości i moderację z udziałem człowieka. Informacje o wydaniu i karta modelu OpenAI podkreślają wewnętrzne testy i zewnętrzne oceny — ale hosting własny przesuwa granicę bezpieczeństwa na Ciebie.

Końcowe przemyślenia

GPT-OSS zmienia sytuację: modele, które wcześniej wymagały ogromnej, niestandardowej infrastruktury, są teraz bardziej przystępne dzięki przemyślanym wyborom architektonicznym i skwantyzowanym dystrybucjom. Ale wdrażanie pozostaje dyscypliną:Dobór rozmiaru sprzętu musi uwzględniać precyzję modelu, długość kontekstu i profil współbieżności aplikacji. Użyj małych platform testowych (kwantyzowanych 20B) do pomiaru tokenów/s i opóźnienia p95, a następnie przemnóż je, aby oszacować moc obliczeniową w chmurze i koszt produkcji.

Jak uzyskać dostęp do interfejsu API GPT-OSS

CometAPI to ujednolicona platforma API, która agreguje ponad 500 modeli AI od wiodących dostawców — takich jak seria GPT firmy OpenAI, Gemini firmy Google, Claude firmy Anthropic, Midjourney, Suno i innych — w jednym, przyjaznym dla programistów interfejsie. Oferując spójne uwierzytelnianie, formatowanie żądań i obsługę odpowiedzi, CometAPI radykalnie upraszcza integrację możliwości AI z aplikacjami. Niezależnie od tego, czy tworzysz chatboty, generatory obrazów, kompozytorów muzycznych czy oparte na danych potoki analityczne, CometAPI pozwala Ci szybciej iterować, kontrolować koszty i pozostać niezależnym od dostawcy — wszystko to przy jednoczesnym korzystaniu z najnowszych przełomów w ekosystemie AI.

Deweloperzy mogą uzyskać dostęp GPT-OSS-20B oraz GPT-OSS-120B przez Interfejs API CometNajnowsze wersje modeli podane są na dzień publikacji artykułu. Na początek zapoznaj się z możliwościami modelu w Plac zabaw i zapoznaj się z Przewodnik po API aby uzyskać szczegółowe instrukcje. Przed uzyskaniem dostępu upewnij się, że zalogowałeś się do CometAPI i uzyskałeś klucz API. Interfejs API Comet zaoferuj cenę znacznie niższą niż oficjalna, aby ułatwić Ci integrację.