OpenAI GPT-OSS: Cara Menjalankannya Secara Lokal atau Hosting Sendiri di Cloud, Persyaratan Perangkat Keras

GPT-OSS dirancang dengan sangat baik untuk aksesibilitas: gpt-oss-20B Varian ini dirancang untuk berjalan pada satu GPU konsumen (~16 GB VRAM) atau laptop kelas atas terbaru yang menggunakan build GGUF terkuantisasi, sementara gpt-oss-120B—meskipun total parameternya 117 GB—dilengkapi dengan trik MoE/parameter aktif dan kuantisasi MXFP4 yang memungkinkannya berjalan pada GPU kelas H100 tunggal (≈80 GB) atau pada pengaturan multi-GPU. Menerapkan model bergaya GPT sumber terbuka (sering disebut "GPT OSS") — baik model ringkas 6–7 GB untuk aplikasi lokal maupun model 70 GB+ untuk layanan produksi — memunculkan pertanyaan inti yang sama: Bagaimana Menjalankan GPT-OSS Secara Lokal atau Hosting Mandiri di Cloud, Persyaratan Perangkat Keras

Apa itu model GPT-OSS dan apa saja persyaratan perangkat kerasnya?

Apa itu GPT-OSS?

GPT-OSS adalah keluarga model bahasa besar berbobot terbuka yang baru-baru ini dirilis OpenAI (dua varian utama pada saat rilis: versi parameter ~20B dan ~120B). Model ini hadir dengan pilihan yang dioptimalkan (campuran pakar, kuantisasi asli MXFP4 dalam distribusi OpenAI, inovasi sparse/dense) yang memungkinkan jumlah parameter yang relatif besar ini berjalan dengan memori yang jauh lebih sedikit daripada yang dibutuhkan salinan FP32/FP16 naif. Rilis ini secara eksplisit dimaksudkan untuk membuat model yang kuat lebih mudah dijalankan dan dikustomisasi secara luas, di luar hyperscaler saja.

Fakta utama produk (daya tampung beban):

gpt-oss-20B dimaksudkan untuk berjalan pada GPU konsumen tunggal dengan VRAM ~16 GB (dan dapat digunakan pada desktop/laptop dengan kuantisasi GGUF).
gpt-oss-120B (≈117B parameter, ~5.1B aktif parameter dalam desain MoE OpenAI) direkayasa agar model dapat masuk dalam H100 / A100 80 GB tunggal saat menggunakan MXFP4 dan dukungan runtime tertentu, atau pada pengaturan multi-GPU.

Faktor perangkat keras yang menentukan persyaratan

Ukuran dan arsitektur model – MoE dan lapisan jarang/padat dapat mengubah aktivasi dan memori kerja. (GPT-OSS menggunakan komponen bergaya campuran pakar.)
Presisi & kuantisasi – FP32, FP16, BF16, 8-bit, 4-bit (GPTQ/AWQ/MXFP4). Presisi yang lebih rendah mengurangi memori tetapi dapat memengaruhi latensi dan fidelitas numerik. OpenAI menyediakan bobot terkuantisasi MXFP4 untuk GPT-OSS.
Panjang konteks (panjang urutan) – konteks yang lebih panjang meningkatkan penggunaan cache aktivasi secara proporsional; GPT-OSS mendukung konteks yang sangat panjang (hingga jendela token yang sangat besar dalam desainnya), yang melipatgandakan kebutuhan memori.
Ukuran batch & konkurensi – melayani beberapa pengguna secara bersamaan akan melipatgandakan memori untuk aktivasi dan cache. Kerangka kerja seperti vLLM, DeepSpeed, dan Triton mencoba untuk mengelompokkan dan berbagi aktivasi secara efisien di seluruh permintaan.
Melayani kerangka kerja overhead – server inferensi yang berbeda (vLLM, text-generation-inference, llama.cpp, ONNX Runtime) menambahkan overhead dan pengoptimalan yang berbeda.

Apa yang “cocok” di mana: aturan memori kasar

Dua konsep penting untuk perencanaan perangkat keras:

Jumlah parameter total — batas atas ukuran model (117B vs 21B).
Set yang diaktifkan/berfungsi — dalam MoE atau pengaturan presisi tertentu, memori aktif yang dibutuhkan pada inferensi bisa jauh lebih kecil daripada byte parameter mentah.

Aturan praktis:

GPU kelas 16 GB/laptop edge → mungkin untuk gpt-oss-20b jika Anda menggunakan konfigurasi hemat memori yang disediakan model (atau mengkuantisasi secara agresif ke 4-bit/NF4/AWQ).
80 GB H100 / A100 80 GB → hosting GPU tunggal untuk gpt-oss-120b dalam pengaturan yang direkomendasikan. Untuk throughput produksi, Anda mungkin masih memerlukan beberapa GPU untuk batching, redundansi, atau latensi yang lebih rendah dalam konkurensi.
Pengaturan multi-GPU besar (kluster A100/H100) → diperlukan jika Anda ingin menjalankan banyak pengguna bersamaan dengan latensi rendah atau melakukan fine-tuning/pelatihan yang intensif. DeepSpeed/ZeRO dan paralelisme tensor otomatis memungkinkan Anda membagi model besar di beberapa GPU.

Kesimpulan: untuk eksperimen dan penggunaan lokal yang ringan, rencanakan GPU 16–24 GB (atau CPU + kuantisasi berat). Untuk inferensi GPU tunggal produksi model gpt-oss besar, Anda akan menargetkan H100 80 GB, jika tidak, gunakan partisi multi-GPU.

Berapa banyak daya komputasi yang dibutuhkan untuk penerapan GPT-OSS dalam praktik?

Inferensi vs pelatihan: anggaran yang sangat berbeda

KesimpulanBiaya yang dominan adalah memori GPU (VRAM) dan kernel yang dioptimalkan. Dengan runtime yang dioptimalkan (vLLM, TensorRT, DeepSpeed-Inference) dan kuantisasi, inferensi pada gpt-oss-20b dapat dilakukan pada GPU konsumen 16 GB; model MoE 120 GB dirancang agar sesuai dengan H100 80 GB.
Penyempurnaan / pelatihan skala penuh: kali lipat lebih besar — Anda akan membutuhkan banyak GPU, atau instans pelatihan khusus (kluster H100/A100 multi-node, anggaran DFLOP, dan I/O penyimpanan). Artikel ini berfokus terutama pada inferensi/self-hosting dan resep fine-tuning ringan (QLoRA/LoRA), bukan pra-pelatihan multi-minggu.

CPU vs GPU vs akselerator khusus

Hanya CPU: dimungkinkan dengan GGUF/llama.cpp dan build terkuantisasi kecil, menukar latensi dengan biaya lebih rendah. Menjalankan 20B pada CPU tanpa kuantisasi tidaklah praktis. Gunakan CPU ketika privasi atau operasi offline lokal sangat penting dan kebutuhan throughput Anda rendah.
GPU: lebih disukai untuk latensi dan throughput. GPU ML modern (A100/H100/4090/4080) sangat berbeda dalam hal HBM/VRAM dan struktur antar-GPU. Dokumen gpt-oss merekomendasikan kelas H100 untuk varian 120B.
TPU / AMD MI300X: didukung oleh beberapa runtime (build vLLM/ROCm) dan dapat hemat biaya di cloud tertentu — periksa dokumen penyedia saat memilih perangkat keras.

Bagaimana cara menjalankan GPT-OSS secara lokal dengan anggaran terbatas? (kode + langkah demi langkah)

Berikut adalah dua pendekatan praktis: (A) Laptop/desktop GPU dengan VRAM ~16–24 GB menggunakan kuantisasi 4-bit, dan (B) CPU/GPU rendah (offline) menggunakan llama.cpp (GGUF) atau build terkuantisasi kecil. Keduanya banyak digunakan oleh praktisi ketika dana dan daya terbatas.

Catatan: Petunjuk ini mengasumsikan Anda memiliki lingkungan Python yang berfungsi (Linux direkomendasikan untuk dukungan CUDA terbaik). Untuk Windows, gunakan WSL2 untuk kompatibilitas terbaik dengan toolchain GPU.

A. Rute GPU (disarankan untuk latensi terbaik dengan anggaran terbatas) — kuantisasi + muat dengan bit dan byte (4-bit)

Jalur ini bertujuan untuk berjalan openai/gpt-oss-20b pada satu GPU konsumen (misalnya, 24 GB 4090 atau 16 GB 4080). Ini menggunakan kuantisasi 4-bit bit dan byte dan Hugging Face transformers device-map/accelerate.

Langkah 1 — Instal dasar-dasarnya

# 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

(Jika Anda menggunakan conda, buat env dan instal roda obor yang kompatibel dengan CUDA untuk platform Anda.)

Langkah 2 — (Opsional) Login Hugging Face untuk mengunduh file besar

huggingface-cli login

Langkah 3 — Contoh Python (model 4-bit terkuantisasi beban)

# 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))

Catatan & tips

penggunaan device_map="auto" so transformers menggunakan CPU/GPU offload secara otomatis. Jika Anda memiliki satu GPU, device_map="auto" biasanya akan menaruh semuanya di GPU dan memindahkan apa yang seharusnya ada di CPU.
Jika Anda kehabisan VRAM, tambahkan --offload_folder ./offload (atau atur offload_folder in from_pretrained) untuk memindahkan tensor ke NVMe.
Pendekatan Hugging Face + bitsandbytes didokumentasikan secara luas; lihat panduan transformer 4-bit untuk detailnya.

B. Rute CPU / anggaran kecil (llama.cpp / GGUF)

Jika Anda tidak memiliki GPU atau GPU yang sangat kecil, llama.cpp / Build GGUF (dan file terkuantisasi AWQ/GPTQ) memungkinkan Anda menjalankan model pada CPU dengan latensi yang dapat diterima untuk pengguna tunggal.

Langkah 1 — Instal llama.cpp / pengikatan 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

Langkah 2 — Konversi safetensor → GGUF (jika skrip konversi tersedia untuk gpt-oss)
OpenAI/Hugging Face menyediakan safetensor; konverter komunitas (atau skrip di llama.cpp) dikonversi ke GGUF. Perintah yang tepat bergantung pada kondisi saat ini llama.cpp alat; periksa repo README untuk convert.py/convert-safetensors-to-gguf(Utas komunitas membahas konversi untuk model baru.)

Langkah 3 — Jalankan model dengan llama.cpp

# basic inference (example)

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

Catatan & tradeoff

Proses CPU jauh lebih lambat. Gunakan rute ini untuk pengujian, privasi, atau agen lokal dengan konkurensi sangat rendah.
Menghasilkan keluaran yang panjang atau melayani banyak pengguna bersamaan pada CPU tidaklah praktis; beralihlah ke GPU untuk produksi.

Build terkuantisasi pada disk (GPTQ/AWQ)

Jika Anda perlu memasukkan model besar ke dalam GPU kecil (misalnya, 8–12 GB), hasil dari komunitas menunjukkan kuantisasi gaya GPTQ/AWQ dapat membuat beberapa model 20B berjalan pada GPU VRAM rendah — tetapi konversi seringkali memerlukan lebih CPU RAM dan satu GPU perantara selama konversi. Alat: GPTQ-for-LLaMa, AutoGPTQ (diarsipkan), AWQ, dan QLLM.

Tips praktis untuk anggaran terbatas

Lebih suka titik pemeriksaan terkuantisasi 4-bit (GPTQ/AWQ/MXFP4) — sering kali menjadi perbedaan antara “berjalan dalam 12 GB” dan “membutuhkan 80 GB”.
Batasi panjang konteks untuk inferensi anggaran: konteks yang panjang menghabiskan cache aktivasi. Jika Anda harus menyimpan konteks yang panjang, pertimbangkan strategi offloading.
Gunakan memori terpadu / pembongkaran nvmem dengan hati-hati —kerangka kerja mungkin menawarkan pembongkaran CPU/NVMe (DeepSpeed ZeRO-Offload / ZeRO-Infinity), tetapi ini meningkatkan latensi.

Bagaimana cara menghosting sendiri GPT-OSS pada penyedia cloud (panduan praktis & petunjuk biaya)?

Perangkat keras cloud mana yang harus dipilih?

GPU Tunggal 80 GB H100Cocok untuk hosting gpt-oss-120b untuk lalu lintas kecil hingga menengah. Dalam istilah AWS, instans P5 menyediakan perangkat keras H100; varian GPU tunggal (diumumkan pada tahun 2025) membuatnya lebih murah untuk menyesuaikan ukuran untuk inferensi. Gunakan keluarga P5/ND H100 tergantung penyedianya.
**Multi-GPU (8× H100)**Untuk throughput dan redundansi tinggi, gunakan p5.48x, p5dn, atau klaster yang sebanding. NVidia NVLink/NVSwitch dalam satu instans mengurangi overhead komunikasi antar-GPU.
Awan alternatifCoreWeave, Lambda Labs, Paperspace, Runpod — seringkali menawarkan sewa GPU spot/ondemand yang lebih murah untuk inferensi bursty. Gunakan mereka untuk pengembangan sebelum berkomitmen pada infrastruktur jangka panjang.
Produksi mutakhir / berat: AWS p5 (H100) (8 × H100 80GB per instans) — untuk throughput tertinggi per node dan kebutuhan GPU tunggal 80+ GB, atau untuk 120GB+ dengan pemisahan yang lebih sedikit. P5 menyediakan H100 dan penyimpanan lokal NVMe yang besar.

rmers, kontainer text-generation-inference (TGI)/NVIDIA TGI, atau menyiapkan inferensi DeepSpeed.

Menyediakan NVMe lokal yang cepat Jika Anda berencana untuk memindahkan status aktivasi yang besar (ZeRO-Infinity), node P4/P5 seringkali memiliki NVMe lokal dan bandwidth jaringan yang sangat tinggi. ()
Keamanan & jaringan — tempatkan titik akhir inferensi di belakang penyeimbang beban, gunakan grup penskalaan otomatis untuk ujung depan, dan pisahkan masalah (penyajian model vs perutean permintaan).
Pemantauan & SLO — melacak pemanfaatan GPU, memori, token/detik, latensi p95 dan kesalahan; gunakan Prometheus + Grafana untuk metrik.

Contoh alur kerja hosting mandiri cloud (AWS P4/P5)

Pilih contoh (p4d/p5) berdasarkan kebutuhan memori model. Untuk gpt-oss-20B, satu instans 16–32 GB sudah cukup; untuk gpt-oss-120B, pilih instans HBM 80 GB atau multi-GPU.
Siapkan AMI / gambar — gunakan AMI vendor yang menggabungkan CUDA, cuDNN, dan PyTorch yang dioptimalkan (atau gambar vendor dengan driver NVIDIA).
Instal tumpukan penyajian: vLLM, transformer, kontainer text-generation-inference (TGI)/NVIDIA TGI, atau menyiapkan inferensi DeepSpeed.
Menyediakan NVMe lokal yang cepat Jika Anda berencana untuk memindahkan status aktivasi yang besar (ZeRO-Infinity), node P4/P5 seringkali memiliki NVMe lokal dan bandwidth jaringan yang sangat tinggi.
Keamanan & jaringan — tempatkan titik akhir inferensi di belakang penyeimbang beban, gunakan grup penskalaan otomatis untuk ujung depan, dan pisahkan masalah (penyajian model vs perutean permintaan).
Pemantauan & SLO — melacak pemanfaatan GPU, memori, token/detik, latensi p95 dan kesalahan; gunakan Prometheus + Grafana untuk metrik.

Contoh rencana self-host (gpt-oss-20b, produksi skala kecil)

Tujuan: melayani ~20 pengguna bersamaan, target respons 1–2 detik, sensitif terhadap biaya.

Contoh: 1× A10G / 1× GPU 24 GB (misalnya, G5 / A10G / RTX 6000) untuk model + 1× server bootstrap CPU kecil.
Runtime: vLLM sebagai server model (batching berkelanjutan) + gateway CometAPI.
Skala otomatis: gunakan grup penskalaan otomatis dengan GPU AMI dan ALB + penskalaan otomatis horizontal berdasarkan metrik CPU/GPU.
Storage: NVMe lokal untuk model caching; penyimpanan objek (S3) untuk penyimpanan model dingin.
Pemantauan: Prometheus + Grafana, melacak penggunaan GPU, latensi, panjang antrean.
Security: VPC, subnet privat, peran IAM untuk penyimpanan model, sertifikat TLS.

Contoh paket self-host (gpt-oss-120b, produksi)

Tujuan: latensi rendah untuk banyak pengguna bersamaan / perusahaan.

Contoh1× H100 80 GB (GPU tunggal) untuk baseline; skalakan secara horizontal atau gunakan instans p5 multi-GPU untuk throughput. Untuk throughput tinggi, replikasi layanan GPU tunggal (data paralel) atau sharding model di seluruh GPU menggunakan DeepSpeed (tensor/pipeline).
Runtime: DeepSpeed-Inference dengan TP otomatis atau NVIDIA TensorRT (jika tersedia). Dukungan vLLM untuk MoE/Multi-GPU dan kernel yang disetel mungkin juga berguna.
Kubernetes: gunakan K8s dengan plugin perangkat dan NVMe lokal; gunakan pengujian kekacauan untuk ketersediaan.
Optimalisasi biaya: instans yang dicadangkan untuk beban yang dapat diprediksi; instans spot untuk beban kerja batch.

Contoh: memulai kontainer penyajian vLLM untuk gpt-oss-20b

# assume vllm is installed and CUDA is set up

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

Kemudian arahkan ujung depan Anda ke http://<host>:8000/v1/chat/completions (vLLM mendukung API yang kompatibel dengan OpenAI).

Tips pengoptimalan biaya

VM Spot/Preemptible harganya 50–80% lebih murah tetapi memerlukan checkpointing atau strategi respawn cepat.
Kuantisasi model mengurangi kebutuhan jenis instans (misalnya, 120B terkuantisasi dapat dilayani pada lebih sedikit GPU jika mesin mendukung dekuantisasi on-the-fly).
Gunakan keluarga instans yang dioptimalkan hanya untuk inferensi (P5/P4/A2 Ultra) dengan NVLink/NVSwitch tinggi saat melakukan paralelisme model multi-GPU; bandwidth jaringan penting untuk sharding antar-GPU.

Cara menyeimbangkan biaya, latensi, dan kualitas model

Kuantisasi: kecepatan vs kualitas

Kuantisasi agresif (2-4 bit, AWQ/GPTQ) → penghematan memori yang sangat besar dan penurunan kualitas yang seringkali kecil untuk banyak tugas. Gunakan AWQ/GPTQ untuk produksi jika Anda melakukan benchmark beban kerja tertentu. Konversi mungkin memerlukan memori CPU yang besar selama kuantisasi.

Optimasi presisi & kernel campuran

penggunaan fp16, bf16 Jika didukung; kombinasikan dengan kernel CUDA khusus (FasterTransformer, TensorRT) untuk throughput maksimal. Nvidia/TensorRT menawarkan dekode spekulatif dan kernel yang dioptimalkan untuk banyak transformer (NVIDIA menyediakan adaptor GPT-OSS yang dioptimalkan).

Keamanan & Observabilitas

Model bobot terbuka berarti Anda bertanggung jawab untuk memantau penyalahgunaan, kebocoran data, dan penyimpangan. Terapkan pencatatan permintaan, filter konten, pembatasan kecepatan, dan moderasi yang melibatkan manusia. Catatan rilis dan kartu model OpenAI menekankan pengujian internal dan evaluasi eksternal mereka — tetapi hosting mandiri mengalihkan perimeter keamanan kepada Anda.

Pesan terakhir

GPT-OSS menggerakkan jarum: model yang sebelumnya membutuhkan infrastruktur khusus yang masif kini lebih mudah diakses berkat pilihan arsitektur yang cermat dan distribusi terkuantisasi. Namun penempatan tetap menjadi sebuah disiplin: Ukuran perangkat keras harus mempertimbangkan presisi model, panjang konteks, dan profil konkurensi aplikasi Anda. Gunakan testbed kecil (terkuantisasi 20B) untuk mengukur latensi token/detik dan p95, lalu kalikan untuk memperkirakan komputasi cloud dan biaya produksi.

Cara Mengakses API GPT-OSS

CometAPI adalah platform API terpadu yang menggabungkan lebih dari 500 model AI dari penyedia terkemuka—seperti seri GPT OpenAI, Gemini Google, Claude Anthropic, Midjourney, Suno, dan lainnya—menjadi satu antarmuka yang ramah bagi pengembang. Dengan menawarkan autentikasi yang konsisten, pemformatan permintaan, dan penanganan respons, CometAPI secara drastis menyederhanakan integrasi kapabilitas AI ke dalam aplikasi Anda. Baik Anda sedang membangun chatbot, generator gambar, komposer musik, atau alur kerja analitik berbasis data, CometAPI memungkinkan Anda melakukan iterasi lebih cepat, mengendalikan biaya, dan tetap tidak bergantung pada vendor—semuanya sambil memanfaatkan terobosan terbaru di seluruh ekosistem AI.

Pengembang dapat mengakses GPT-OSS-20B dan GPT-OSS-120B melalui API Komet, versi model terbaru yang tercantum adalah versi per tanggal publikasi artikel. Untuk memulai, jelajahi kemampuan model di tempat bermain dan konsultasikan Panduan API untuk petunjuk terperinci. Sebelum mengakses, pastikan Anda telah masuk ke CometAPI dan memperoleh kunci API. API Komet menawarkan harga yang jauh lebih rendah dari harga resmi untuk membantu Anda berintegrasi.