GPT-OSS pada Hari ke-0

Dukungan Hari‑0 untuk GPT‑OSS pada H200 dengan mengadaptasi ROSE menggunakan FP8, atensi sink, dan pengoptimalan MoE

PenulisPerplexity Engineering

Perplexity berkomitmen untuk menyediakan model AI terbaik bagi orang-orang penasaran yang menuntut jawaban akurat dan tepercaya serta tindakan agen. OpenAI baru-baru ini mengumumkan model bobot terbuka mereka (gpt-oss-20b dan gpt-oss-120b). Seperti banyak model terkemuka lainnya, Perplexity adalah salah satu organisasi pertama yang mengevaluasi gpt-oss-20b dan gpt-oss-120b.

Dalam postingan ini, kami membagikan keputusan infrastruktur dari tumpukan inferensi internal kami yang memungkinkan dukungan Hari-0. Kami berfokus pada penyediaan model-model ini pada GPU NVIDIA H200, merinci perubahan kernel, pilihan penerapan, dan pertukaran kecepatan-biaya.

GPT-OSS pada Hopper

Model bobot terbuka dikirimkan menggunakan kuantisasi MXFP4, yang membantu model tersebut pas dalam memori pada perangkat keras tingkat konsumen atau mencapai throughput puncak pada NVIDIA Blackwell. Namun, untuk evaluasi awal, kami ingin menjalankannya pada kluster Hopper H200 yang ada dengan perubahan mesin inferensi minimal. Hopper tidak memiliki inti tensor FP4 khusus, yang diperkenalkan oleh Blackwell. Akibatnya, kami memutuskan untuk melayani model dengan presisi FP8 sebagai gantinya untuk meminimalkan kebutuhan kernel kustom dan memanfaatkan perangkat keras yang tersedia sebaik-baiknya.

Pada tingkat tinggi, LLM transformer secara struktural sederhana:

Penyematan input

Urutan lapisan transformer. Masing-masing berisi blok perhatian, dan blok MLP padat atau MoE jarang.

Proyeksi logit output

Saat menerapkan model transformer baru, kami terutama tertarik untuk mempelajari sejauh mana model tersebut cocok dengan model yang ada guna mengidentifikasi perubahan yang diperlukan. OpenAI dengan baik hati membagikan ikhtisar model mereka sebelumnya, memungkinkan kami untuk menyesuaikan pengaturan inferensi kami. Kami menemukan bahwa model tersebut memang memerlukan sejumlah kecil perubahan.

Atensi: GQA dengan Sink Atensi

Setiap kepala atensi memiliki parameter sink pra-latih yang diperhitungkan ke dalam Softmax

Pengodean posisional YaRN, mirip dengan DeepSeek-V3

Proyeksi QKV memiliki bias, mirip dengan Qwen 2

Proyeksi output memiliki bias

MLP: Sparse Mixture-of-Expert (MoE)

Fungsi aktivasi SwiGLU, berbeda dari sebagian besar model bobot terbuka

Softmax setelah Top-K untuk bobot ahli

Ahli memiliki bias

Mengharapkan jumlah parameter berada di sekitar 100B-200B, kami memutuskan untuk:

Memperluas FlashInfer untuk mendukung sink atensi

Menggunakan kembali implementasi MoE yang telah dibangun untuk keluarga model DeepSeek-V3

Memilih penskalaan blok FP8 128x128 sebagai skema kuantisasi, memperluas kernel DeepGEMM untuk mendukung suku bias.

Mesin Inferensi Internal

Upaya inferensi kami didukung oleh mesin inferensi internal kami, ROSE. Kami membangun ROSE menjadi kerangka kerja yang fleksibel yang memungkinkan model baru untuk segera diterapkan. Selain itu, begitu kami berkomitmen untuk melayani model dalam skala besar, ROSE menyediakan platform untuk mengoptimalkan dan meningkatkan kinerja guna mencapai kecanggihan mutakhir.

ROSE mengekspos mesin LLM, yang dapat memuat model dan menghasilkan token yang didekodekan untuk model tersebut melalui beberapa decoder, termasuk decoder spekulatif dan MTP. Model itu sendiri terdiri dari serangkaian lapisan kustom, yang mendukung berbagai konfigurasi untuk kuantisasi dan paralelisme. Di bawah lapisan-lapisan tersebut, ROSE menggabungkan kernel Triton dan CUDA yang secara efisien mengimplementasikan dan menggabungkan komputasi yang dilakukan oleh masing-masing lapisan.

ROSE terutama dibangun dengan Python dan mengandalkan PyTorch untuk definisi model. Meskipun Python memungkinkan kami untuk menjadi fleksibel dan beradaptasi dengan model baru, kami memigrasikan sebagian besar komponen yang sensitif terhadap kinerja, seperti penayangan dan penjadwalan batch, ke Rust.

Untuk menerapkan model baru, kami pertama-tama menentukan hierarki model dan membangun konverter bobot untuk model tersebut. Setelah semua bobot diperhitungkan, kami menentukan jalur maju (forward pass) untuk kasus penggunaan TP=1 yang paling sederhana dan memastikan model tersebut berfungsi dari ujung ke ujung (end-to-end). Terakhir, kami mengimplementasikan dan menguji dukungan untuk berbagai bentuk paralelisme sebelum kami merilis kontainer baru dan menerapkan model pada kluster untuk evaluasi. Kami kemudian mengiterasi kinerja, mengandalkan umpan balik dari dasbor dan tolok ukur yang lebih mendetail.

ROSE beroperasi pada token numerik, dengan sedikit pengetahuan tentang format chat di luar pengujian integrasi. Secara paralel, kami harus menyelidiki penyesuaian infrastruktur di sekitarnya untuk mendukung tokenizer Harmony dan memetakan permintaan ke urutan token input secara benar.

Dengan model GPT OSS, kami mendapati bahwa tidak ada perubahan yang diperlukan pada decoder kami, perangkat grafik CUDA, atau infrastruktur di sekitarnya, sehingga kami dapat memfokuskan upaya kami untuk menyempurnakan kernel yang mendasari model tersebut.

Kernel untuk GPT-OSS

Atensi Sink

Atensi sink memperkenalkan faktor bias tambahan sebelum softmax, yang diakumulasikan dengan produk Q dan K:

plaintext
attn = softmax(q @ k^T * sm_scale + sink) * V

Meskipun implementasi naif tergolong cukup sederhana, implementasi atensi yang efisien, seperti FlashInfer, memparalelkan komputasi atensi di seluruh kepala independen dan di seluruh panjang urutan KV. Selain itu, untuk stabilitas numerik, Softmax dihitung secara daring sekaligus mengurangkan elemen maksimal untuk stabilitas numerik:

plaintext
softmax(x) = e^x / sum(e^x) = e ^ (x - max(x)) / sum(e ^ (x - max(x))

Implementasi daring melacak maksimum yang berjalan m yang diinisialisasi ke -inf dan skala d ke 1. Dengan menginisialisasi maksimum ke nilai sink dari kepala saat ini, kami akan memastikan bahwa nilai tersebut terakumulasi ke dalam Softmax dengan benar. Kami harus berhati-hati untuk memastikan bahwa maksimum ini hanya disertakan dalam potongan pertama jika atensi dibagi di beberapa blok di sepanjang panjang urutan.

Kami telah menyesuaikan templat kernel FlashInfer FA2, yang digunakan untuk pra-pengisian (prefill) dan pengkodean (decode), untuk menyertakan parameter sink.

MoE

Perbedaan utama antara lapisan MoE dari berbagai model biasanya adalah skema perutean. Mengingat variabilitas yang substansial, ROSE mengimplementasikan kernel ini di Triton, memungkinkan kami beradaptasi dengan mudah ke model baru. Dalam kasus GPT-OSS, kami harus menyesuaikan penilaian bobot untuk melakukan softmax hanya di seluruh ahli pilihan Top-K, tidak seperti beberapa model gaya DeepSeek yang menghitung softmax di seluruh ahli. Kami menganggap sangat penting untuk akurasi guna menghitung bobot ahli dalam presisi bfloat16.

Tantangan dengan lapisan MoE adalah karena keputusan kami untuk menggunakan kembali kernel DeepGEMM yang ada, yang tidak memiliki dukungan untuk suku bias. Untungnya, dari waktu ke waktu kami terintegrasi secara mendalam dengan kernel tersebut, membuat perubahan untuk menghubungkannya lebih baik dengan kernel pengiriman all-to-all kustom kami. Kami menambahkan dukungan bias ke DeepGEMM dengan menginisialisasi register akumulator WGMMA ke nilai bias yang dimuat dari memori. Ini adalah proses satu kali selama pemrosesan blok MN, sehingga biayanya kemungkinan besar dapat diabaikan dan tembolok (cache) L2 memastikan akses yang efisien ke nilai-nilai ini.

Karena model-model ini tidak secara langsung mendapat manfaat dari Paralelisme Data, kami menggunakan kembali kernel pengiriman dan penggabungan khusus TP. Input untuk pengiriman direplikasi di semua peringkat, sehingga pengiriman memilih token untuk ahli yang tersedia secara lokal. Penggabungan melakukan akumulasi tertimbang di seluruh NVLink.

Penyetelan Kinerja

Meskipun tujuan kami adalah menghadirkan model dengan cepat, kami ingin memastikan kinerjanya tetap wajar. Setelah memastikan kebenarannya terhadap implementasi referensi yang disediakan oleh OpenAI, kami membuat profil implementasi kami menggunakan pembuat profil PyTorch bawaan, mengawasi alokasi blok dan utas di seluruh kernel. Fungsionalitas yang kami gunakan kembali dibangun untuk model yang memiliki dimensi tersembunyi yang lebih besar yaitu 7168, jauh lebih besar daripada 2880 pada model GPT-OSS. Kami mengkhususkan peluncur kernel untuk memilih dimensi kisi yang lebih baik, sehingga secara signifikan meningkatkan throughput.

Tokenisasi dan saluran

Format chat Harmony memiliki beberapa konsep penting untuk menyusun percakapan, konten penalaran, dan pemanggilan fungsi. Dalam format ini, setiap pesan terdiri dari tajuk (header) dan konten:

plaintext
<|start|>{header}<|message|>{content}<|end|>

Tajuk membawa metadata — yang terpenting adalah peran (sistem, pengembang, pengguna, asisten, alat), saluran, dan penerima seperti to=functions.<function-name> saat memanggil pemanggilan alat.

Saluran (seperti analisis, komentar, dan jawaban akhir) membuat output model lebih transparan dan tersegmen. Karena format ini menegakkan pemisahan tersebut, model dapat bernalar secara transparan (dan diperiksa untuk debugging) tanpa membocorkan rangkaian pemikiran (chain-of-thought) ke produksi. Tag penerima (tajuk to=) memberi tahu runtime secara persis aktor mana yang harus menerima payload berikutnya — apakah itu fungsi, model itu sendiri, atau pengguna akhir.

Mesin inferensi kami, ROSE, bersifat agnostik format. Mesin ini menerima sekumpulan token input dan melakukan streaming kembali token output. Dalam tumpukan inferensi kami, tugas memformat input menjadi prompt yang ditokenisasi dan mengurai hasil LLM kembali ke dalam pesan terstruktur ditangani oleh layanan frontend API JSON khusus. Kami mengintegrasikan Harmony dengan menambahkan pemformat/pengurai yang dapat dicolokkan (pluggable) baru ke frontend ini, memungkinkan backend tetap tidak berubah sementara frontend mengelola aturan format chat, pemanggilan alat, dan streaming secara bersih. Pemisahan kepedulian ini menjaga arsitektur tetap modular, memungkinkan adopsi cepat dari format baru, fitur respons dengan perubahan backend minimal.

Biaya dan Kinerja

Mengingat ukuran model GPT-OSS yang relatif kecil, kami membatasi penerapan replika ke satu simpul tunggal untuk menghindari overhead komunikasi antarsimpul. Implementasi kami mendukung kombinasi fleksibel dari paralelisme ahli (EP), paralelisme data (DP), dan paralelisme tensor (TP). Untuk menentukan pengaturan penerapan yang optimal, kami menguji semua kombinasi strategi sharding di berbagai ukuran batch dari 1 hingga 128. Berkat Disagregasi Pra-pengisian dan Pengodean, kami dapat mendiskusikan pertukaran kinerja-biaya secara terpisah untuk pra-pengisian dan pengodean.

Untuk perkiraan biaya, kami berasumsi tingkat pasar nominal H200 adalah $3,00/jam (catatan: ini bukan harga GPU aktual kami).

Kami menemukan bahwa pengaturan batch_size=1 dan DP=1 menghasilkan kinerja pra-pengisian terbaik. Konfigurasi TP yang berbeda kemudian memberikan pertukaran yang bervariasi antara latensi token pertama dan biaya. Tabel di bawah ini menyajikan latensi pra-pengisian dan biaya per juta token input untuk berbagai konfigurasi dan panjang input.

GPT-OSS 120B:

Panjang Input

8192

32768

65536

128000

EP1 DP1 TP1

0.364s, $0,037

2.421s, $0,062

7.375s, $0,094

23.902s, $0,156

EP2 DP1 TP2

0.190s, $0,039

1.245s, $0,063

3.786s, $0,096

12.116s, $0,158

EP4 DP1 TP4

0.165s, $0,067

0.900s, $0,092

2.449s, $0,125

7.165s, $0,187

EP8 DP1 TP8

0.179s, $0,145

0.839s, $0,171

2.003s, $0,204

5.119s, $0,267

Latensi prefill GPT-OSS 120B dan biaya per satu juta token input menurut konfigurasi paralelisme dan panjang input.

GPT-OSS 20B:

Panjang Input

8192

32768

65536

128000

EP1 DP1 TP1

0.239s, $0,024

1.610s, $0,041

4.895s, $0,062

16.037s, $0,104

EP2 DP1 TP2

0.127s, $0,026

0.833s, $0,042

2.522s, $0,064

8.143s, $0,106

EP4 DP1 TP4

0.108s, $0,044

0.593s, $0,060

1.616s, $0,082

4.766s, $0,124

EP8 DP1 TP8

0.116s, $0,094

0.547s, $0,111

1.310s, $0,133

3.365s, $0,175

Latensi prefill GPT-OSS 20B dan biaya per satu juta token input menurut konfigurasi paralelisme dan panjang input.

Untuk pengodean, kami menemukan bahwa EP4 DP1 TP4 adalah konfigurasi terbaik untuk sebagian besar kasus. Keempat diagram di bawah ini mengilustrasikan pertukaran antara kecepatan pengodean dan biaya per juta token output untuk model 120B dan 20B pada panjang urutan 8192 dan 32768.

Biaya decode-only per satu juta token output versus kecepatan decoding untuk GPT-OSS 120B pada panjang urutan 8.192, membandingkan konfigurasi EP1, EP2, EP4, dan EP8.
Biaya decode-only per satu juta token output versus kecepatan decoding untuk GPT-OSS 120B pada panjang urutan 32.768, membandingkan konfigurasi EP1, EP2, EP4, dan EP8.
Biaya decode-only per satu juta token output versus kecepatan decoding untuk GPT-OSS 20B pada panjang urutan 8.192, membandingkan konfigurasi EP1, EP2, EP4, dan EP8.
Biaya decode-only per satu juta token output versus kecepatan decoding untuk GPT-OSS 20B pada panjang urutan 32.768, membandingkan konfigurasi EP1, EP2, EP4, dan EP8.

Kami juga telah mempertimbangkan penggunaan model 20B yang lebih kecil sebagai model draf pengodean spekulatif untuk model 120B yang lebih besar. Namun, karena jumlah parameter yang diaktifkan serupa (3B vs. 5B), peningkatan kecepatan yang dihasilkan sangat kecil.

Referensi

Pra-pengisian dan Pengodean Terdisagregasi

Mempercepat Sonar Melalui Spekulasi​

Latensi Lebih Rendah dan Throughput Lebih Tinggi dengan Penerapan DeepSeek Multisimpul

​Komunikasi Mixture-of-Experts yang Efisien dan Portabel

​pplx-kernels

DeepGEMM

FlashInfer: Mesin Atensi yang Efisien dan Dapat Disesuaikan untuk Penyediaan Inferensi LLM

Model Bahasa Streaming Efisien dengan Sink Atensi

Laporan Teknis DeepSeek-V3​

​Format Respons OpenAI Harmony | Buku Masak OpenAI​

Kutipan

BibTeX
@online{perplexity2025GptOssOnDay0,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Vladimir Zaytsev and Kevin Hu and Lauren Kolm and Jesse Dwyer},
  title = {{GPT-OSS on day 0}},
  date = {2025-08-08},
  url = {https://www.perplexity.ai/hub/blog/gpt-oss-on-day-0}
}