Performa dan tolok ukur akselerator AI

Mengevaluasi hardware AI untuk digunakan dengan model bahasa besar (LLM) sebagai workload utama memerlukan pendekatan yang konsisten dan netral terhadap vendor. Panduan ini menjelaskan metodologi untuk membandingkan performa chip akselerator AI dari berbagai vendor seperti NVIDIA, AMD, Google, dan AWS. Prinsip dan metodologinya dapat disesuaikan dengan chip atau workload AI apa pun, tetapi contohnya berfokus pada kombinasi umum di industri, yaitu unit pemrosesan grafis (GPU) NVIDIA dan Google Tensor Processing Unit (TPU) yang menjalankan workload LLM.

Model biasanya dioptimalkan untuk platform hardware tertentu, sehingga mengevaluasi performa model saja tidak cukup untuk memahami kemampuan hardware. Saat mengevaluasi chip akselerator untuk LLM, pertimbangkan tiga dimensi utama: microbenchmarking, analisis roofline, dan tolok ukur model untuk pelatihan dan inferensi.

Analisis microbenchmarking dan roofline sangat penting untuk memahami kemampuan dan potensi platform akselerator tertentu. Setelah informasi tersebut diketahui, tolok ukur model di seluruh pelatihan dan inferensi memberikan perbandingan workload nyata di seluruh chip dan insight tentang apakah arsitektur model dioptimalkan untuk platform tertentu.

Dimensi performa

Kami menyarankan evaluator untuk memikirkan performa di tiga dimensi untuk menciptakan pemahaman yang lebih holistik tentang sistem akselerator tertentu:

  • Microbenchmarking: Memiliki spesifikasi hardware tertinggi tidak berarti aplikasi dapat benar-benar memanfaatkan spesifikasi tersebut. Anda dapat menggunakan microbenchmarking untuk mengevaluasi pengaruh operasi floating point per detik (FLOPS), memori bandwidth tinggi (HBM), dan bandwidth jaringan terhadap apa yang dapat dicapai dalam beban kerja dunia nyata.
  • Analisis roofline: Penggunaan hardware yang optimal dapat terhambat oleh bandwidth memori atau kecepatan komputasi. Anda dapat menggunakan model roofline dan intensitas operasional (OI) berbagai komponen sistem untuk melihat seberapa cocok hardware dan beban kerja satu sama lain. Kombinasi microbenchmark dan roofline memberikan penilaian teoretis tentang apa yang dapat dicapai hardware yang dipilih untuk berbagai jenis beban kerja.
  • Tolok ukur model: Tolok ukur di seluruh beban kerja pelatihan dan inferensi untuk mengukur token per detik per chip (TPS/chip) memungkinkan Anda mengevaluasi model yang sama di berbagai platform. Jika hasil awal berbeda dengan analisis microbenchmarking dan roofline, hal ini menunjukkan bahwa diperlukan pekerjaan software tambahan untuk mencapai roofline yang diidentifikasi sebelumnya. Misalnya, pekerjaan ini mungkin melibatkan perubahan strategi sharding atau penggunaan kernel kustom.

Ingatlah bahwa tolok ukur model adalah pendekatan snapshot dalam waktu untuk model, skala, dan platform tertentu. Pengguna yang berpengalaman juga mempertimbangkan tren industri (seperti arsitektur model), microbenchmarking, dan hasil roofline saat mengevaluasi performa.

Desain bersama model dan hardware

Evaluasi performa harus mempertimbangkan dengan cermat arsitektur model dalam konteks hardware yang sedang diuji. Model yang dirancang secara efisien sering kali dirancang bersama untuk platform hardware tertentu guna memanfaatkan nuansa platform tertentu. Akibatnya, model ini mungkin tidak sepenuhnya memanfaatkan platform lain atau bahkan generasi platform yang sama. Misalnya, model yang dirancang untuk GPU NVIDIA Hopper mungkin tidak sepenuhnya memanfaatkan GPU AMD atau GPU NVIDIA Blackwell.

Pertimbangan ini sangat penting saat berpindah antar-platform hardware yang mungkin berbeda kemampuannya karena model yang dirancang untuk satu platform mungkin memerlukan perubahan konfigurasi, perubahan software, atau keduanya untuk mencapai performa puncak di platform lain. Tolok ukur model yang dioptimalkan sangat penting untuk memvalidasi klaim pemasaran vendor tentang performa "teoretis puncak" dan mengukur hasil dunia nyata. Perusahaan analisis independen, SemiAnalysis, mencatat, "Membandingkan FLOPS teoretis hanya menceritakan sebagian kisah. Yang penting adalah FLOPS efektif, karena angka puncak hampir tidak pernah tercapai dalam beban kerja dunia nyata."

Contoh: tantangan gpt-oss-120B

Kesalahan umum dalam tolok ukur adalah mengevaluasi model pada hardware yang tidak dirancang untuk model tersebut. gpt-oss-120B Model open-weight dari OpenAI adalah contoh mengapa arsitektur model harus dipetakan secara cermat ke target silikon. Contoh berikut menunjukkan bahwa desain bersama model sangat penting dan harus dilakukan di awal proses.

Model gpt-oss-120B menggunakan dimensi head atensi sebesar 64. Meskipun ini adalah standar untuk banyak model yang dioptimalkan GPU, hal ini menciptakan ketidakcocokan arsitektur untuk akselerator TPU. TPU seperti Trillium dan Ironwood dioptimalkan untuk dimensi matriks yang merupakan kelipatan 256 untuk sepenuhnya memuaskan unit perkalian matriks (MXU). Karena dimensi head, 64, tidak dioptimalkan untuk TPU, menjalankan gpt-oss-120B pada sistem TPU akan menghasilkan token per detik (TPS) dan pemakaian FLOPS model (MFU) yang lebih rendah. Hardware secara efektif membuang siklus clock dan daya dengan mengisi ruang yang tersisa dengan nol agar sesuai dengan petak eksekusi 256x256.

Menggunakan gpt-oss-120B sebagai tolok ukur untuk TPU dapat secara keliru menandakan kemampuan hardware yang buruk, padahal sebenarnya mencerminkan ketidakcocokan arsitektur software. Untuk menilai "batas" akselerator secara akurat, uji dengan model yang didesain bersama untuk geometri spesifiknya. Misalnya, model dengan dimensi head 128 atau 256 seperti Gemma 4. Anda dapat meningkatkan performa model ini dengan kernel kustom yang menghindari pengisihan nol dan "mengisi" MXU, yang memerlukan keahlian dan tidak mencapai tingkat performa yang sama seperti pada GPU. Anda juga dapat mengubah dimensi head agar lebih dioptimalkan untuk TPU, tetapi perubahan ini membatalkan validitas bobot model yang ada, sehingga memerlukan pelatihan ulang.

Prinsip tolok ukur

Untuk memberikan evaluasi yang adil dan siap untuk masa depan, pertimbangkan prinsip-prinsip berikut untuk menjalankan benchmark di seluruh akselerator:

  • Berfokus pada performa per dolar: Beberapa vendor berfokus pada performa mentah chip tunggal, tetapi performa per dolar tingkat sistem lebih mewakili nilai dan total biaya kepemilikan (TCO) secara keseluruhan. Jika chip A 20% lebih berperforma dan 50% lebih mahal daripada chip B, evaluator harus mengenali peningkatan performa per dolar dari chip B. Pertimbangkan juga performa per watt sebagai bagian dari biaya.
  • Mewakili workload AI modern: Berfokus pada model berbasis transformer populer, cluster besar, dan framework terbaru sambil mempertimbangkan tren industri. Misalnya, peralihan industri ke model mixture of experts (MoE) yang lebih jarang membuat pengoptimalan FLOPS sepenuhnya menjadi lebih sulit sekaligus menuntut bandwidth biseksi yang lebih tinggi dari jaringan.
  • Memastikan dukungan luas untuk persyaratan developer: Pertimbangkan performa, fleksibilitas, dan skalabilitas di berbagai workload: pelatihan, penyesuaian, dan penayangan di berbagai LLM dan model lainnya.
  • Pilih model dan alat yang tidak bergantung pada vendor: Pilih model dan mesin yang berjalan di seluruh akselerator untuk mempermudah evaluasi lintas akselerator. Misalnya, gunakan model terbuka seperti Qwen dan Gemma serta mesin inferensi open source yang berjalan di GPU dan TPU, seperti vLLM. Hindari stack PyTorch/CUDA khusus hardware. Untuk tolok ukur pelatihan model, framework khusus vendor (seperti MaxText untuk TPU dan Megatron untuk GPU) adalah yang paling berguna saat model tetap konstan di seluruh platform.
  • Desain bersama model: Pengguna berpengalaman mendesain bersama model mereka untuk mendapatkan hasil maksimal dari platform hardware. Jangan berharap model yang dilatih di chip A akan memiliki performa "langsung pakai" yang baik di chip B.
  • Pertimbangkan seluruh sistem hardware: Beberapa akselerator dapat mengiklankan performa tinggi di satu area seperti FLOPS. Namun, hambatan di area lain, seperti bandwidth memori, dapat membatasi kemampuan akselerator secara signifikan. Aspek lain dari sistem yang perlu dipertimbangkan adalah spesifikasi chip, jaringan chip, dan arsitektur scale-out.
  • Keandalan hardware dan software: Gangguan selama pelatihan skala besar atau operasi inferensi penting dapat sangat merugikan. Demikian pula, akselerator AI hanya berguna jika software yang berjalan di atasnya memanfaatkannya. Tumpukan software yang matang dan andal, yang terbukti dalam skala besar, sangat penting untuk memaksimalkan nilai.

Microbenchmark

Dalam konteks benchmark akselerator, microbenchmark mengisolasi komponen hardware tertentu seperti core komputasi, memori, dan interkoneksi untuk mengukur batas absolutnya tanpa gangguan dari stack software yang kompleks. Banyak vendor menyoroti "FLOPS puncak chip tunggal", tetapi AI di dunia nyata adalah masalah sistem terdistribusi. Microbenchmarking membantu Anda memahami apakah chip hanya berperforma tinggi secara terpisah atau apakah chip tersebut dirancang untuk skala pusat data.

Gunakan microbenchmarking untuk mengukur performa puncak hardware dan mempelajari batas sistem di dunia nyata, terlepas dari arsitektur model. Microbenchmarking sangat berharga saat mengevaluasi akselerator terhadap kasus penggunaan dan arsitektur model yang belum ditentukan atau akan datang.

Untuk melakukan microbenchmark akselerator secara efektif, evaluasi hal berikut:

Benchmark Penjelasan
Penggunaan perkalian matriks umum (GEMM) padat Jalankan kernel GEMM yang sangat dioptimalkan di berbagai presisi untuk mengukur kemampuan matematika mentah dan berkelanjutan dari unit komputasi inti akselerator.
Streaming High Bandwidth Memory (HBM) Jalankan microbenchmark bandwidth memori untuk mengukur kecepatan baca, tulis, dan salin berkelanjutan dari memori bawaan akselerator. Arsitektur yang mempertahankan rasio byte-ke-FLOP yang sehat mencegah core komputasi tidak digunakan.
Kolektif terdistribusi (all-reduce dan all-gather) Menjalankan pengujian komunikasi kolektif standar di ribuan chip untuk mengukur seberapa parah penurunan bandwidth dan latensi jaringan saat cluster diskalakan.
Kecepatan transfer host ke perangkat (H2D) dan perangkat ke host (D2H) Dorong aliran data besar dan berkelanjutan antara memori sistem CPU host dan akselerator untuk mengukur kecepatan transfer di seluruh bus PCIe atau interkoneksi kustom.
Throttling termal dan penarikan daya berkelanjutan Jalankan loop GEMM penggunaan maksimum secara terus-menerus selama 48 jam sambil memantau penarikan daya tingkat rak untuk mengevaluasi stabilitas termal berkelanjutan dan efisiensi daya di dunia nyata.

Contoh perbandingan microbenchmark

Berikut perbandingan ilustratif antara dua chip, di mana chip A hipotetis mungkin tampak lebih baik daripada chip B hipotetis, tetapi berperforma lebih buruk dalam praktiknya:

Nama tolok ukur Hasil pengujian Chip A Spesifikasi Chip A Rasio Pengujian / Spesifikasi Hasil pengujian Chip B Spesifikasi Chip B Rasio Pengujian / Spesifikasi
Jaringan chip-ke-chip 800 GBps 1.000 GBps 80,0% 850 GBps 900 GBps 94,4%
gemm/peakTOPS 1.800 TFLOPS 2.500 TFLOPS 72,0% 1.800 TFLOPS 2.000 TFLOPS 90,0%
Bandwidth memori 6.000 GBps 8.000 GBps 75,0% 6.500 GBps 7.500 GBps 86,7%
Host ke perangkat 58 GBps/chip 70 GBps/chip 82,9% 60 GBps/chip 65 GBps/chip 92,3%
Perangkat ke host 55 GBps/chip 70 GBps/chip 78,6% 55 GBps/chip 65 GBps/chip 84,6%

Analisis garis atap

Analisis roofline (atau model roofline) dapat memberi Anda visualisasi untuk menganalisis intensitas operasional (OI) berbagai komponen sistem dan seberapa baik desain tertentu sesuai dengan platform tertentu.

Throughput chip akselerator AI dibatasi oleh tiga faktor utama:

  1. Kapasitas komputasi: Throughput matematika puncak chip (FLOPS).
  2. Bandwidth memori: Kecepatan transfer data ke atau dari High Bandwidth Memory (HBM) lokal chip.
  3. Bandwidth jaringan: Kecepatan data dapat dibagikan di beberapa chip menggunakan jaringan chip selama pelatihan atau inferensi terdistribusi. Misalnya, kecepatan transfer ICI (untuk TPU) atau NVLink (untuk GPU).

Untuk mengetahui informasi selengkapnya tentang garis atap, lihat Semua Tentang Garis Atap.

Plot batas performa standar terdiri dari dua sumbu:

  • Sumbu X (intensitas operasional): Intensitas operasional adalah rasio kerja komputasi (FLOPS) terhadap traffic memori (byte yang ditransfer), yang dinyatakan sebagai FLOPS per byte. Metrik ini merepresentasikan jumlah pekerjaan komputasi yang dilakukan untuk setiap byte data yang diambil dari memori.
  • Sumbu Y (performa yang dapat dicapai): Performa yang dapat dicapai dinyatakan sebagai FLOPS per detik. Metrik ini merepresentasikan throughput komputasi aktual yang dicapai.

Grafik model roofline yang menunjukkan bagaimana performa puncak hardware dibatasi oleh bandwidth memori dan kapasitas komputasi

"Atap" dibentuk oleh dua garis yang berpotongan yang merepresentasikan maksimum hardware:

  1. Atap miring (terikat memori): Performa yang Dapat Dicapai = Bandwidth Memori Puncak × Intensitas Operasional. Pada jalur ini, performa dibatasi secara ketat oleh seberapa cepat data dapat dimasukkan ke unit komputasi.
  2. Atap datar (terikat komputasi): Performa yang Dapat Dicapai = Kapasitas Komputasi Puncak. Pada baris ini, data disediakan cukup cepat sehingga unit komputasi berjalan pada kapasitas maksimum.

Titik tempat kedua garis ini berpotongan dikenal sebagai titik punggungan. Opsi ini menentukan OI minimum yang diperlukan workload untuk mencapai penggunaan hardware maksimum.

Pada gambar sebelumnya, Algo 1 berada di bagian grafik yang berlabel "terikat memori" dan tidak sepenuhnya memanfaatkan unit komputasi. Sebaliknya, Algo 2 memiliki OI yang lebih tinggi dan berada di bagian grafik yang diberi label "terikat komputasi". Untuk mengoptimalkan Algo 1, pengguna akan mencoba mengubah algoritma untuk melakukan lebih banyak komputasi dengan lebih sedikit pergerakan data (meningkatkan OI) untuk menggeser performa ke kanan, menuju titik puncak.

Contoh workload OI rendah dan tinggi

  • Intensitas operasional HBM rendah (terikat memori): Workload seperti operasi per elemen (fungsi aktivasi seperti ReLU atau GeLU), Normalisasi Lapisan, dan decoding autoregresif (inferensi ukuran batch = 1).
  • Intensitas operasional HBM tinggi (terikat komputasi): Workload seperti GEMM atau jaringan neural konvolusional batch besar. Perkalian matriks menggunakan kembali data yang diambil berkali-kali (mengalikan baris dengan kolom), sehingga OI sangat tinggi dan workload berada di bawah batas komputasi datar.

Pembuatan tolok ukur model

Tolok ukur model mengukur performa model yang sebenarnya. Tolok ukur pelatihan dan inferensi memungkinkan Anda membandingkan performa untuk model populer pada titik waktu tertentu.

Tabel berikut membandingkan insight yang bisa Anda dapatkan dari tolok ukur model untuk workload pelatihan dan inferensi:

Insight Workload pelatihan Workload inferensi
Skala Sering kali pengujian skala yang lebih besar (10 ribu+ chip, hingga 100 ribu+ untuk model terbesar). Memberikan insight tentang workload terdistribusi, overhead komunikasi, dan batas jaringan tingkat cluster. Sering kali pengujian yang lebih kecil (1-64+ chip). Memberikan insight tentang cara platform menangani pengguna serentak dan peningkatan skala cepat saat terjadi beban.
Performa Sering kali lebih terikat komputasi. Mengukur token yang diproses per detik per chip dan Model FLOPS Utilization (MFU). Sensitif terhadap latensi. Mengukur Waktu hingga Token Pertama (TTFT), latensi antar-token, dan token keseluruhan yang dibuat per detik per pengguna.
Latensi Latensi I/O dan interkoneksi yang menyoroti hambatan penyimpanan saat memuat set data besar dan latensi jaringan antar-node selama update gradien sinkron. Latensi respons end-to-end yang menyoroti penundaan antrean, latensi endpoint, dan waktu tunggu yang dihadapi pengguna.

Pembandingan pelatihan

Untuk menentukan efisiensi hardware dan jaringan yang sebenarnya, Anda harus menormalisasi performa ke satu metrik yang dapat dibandingkan di seluruh akselerator: Token per detik per chip (TPS/chip), sambil mempertahankan arsitektur model tertentu yang representatif. Dengan melacak perilaku TPS/chip saat Anda menskalakan ukuran cluster, Anda akan mengungkap "pajak penskalaan" tersembunyi dari sistem.

Untuk menormalisasi performa dengan biaya akselerator, bagi lebih lanjut TPS/chip dengan biaya setiap chip untuk menghasilkan TPS/chip/$, yang menjadi titik perbandingan lainnya.

Untuk setiap model yang di-benchmark, evaluasi hal berikut:

Benchmark Penjelasan
Mengukur TPS/chip dan TPS/chip/$ dasar

Jalankan model target pada cluster yang layak terkecil. Mencatat throughput pelatihan global (total token yang diproses per detik) dan membaginya dengan jumlah chip untuk menentukan TPS/chip dasar. Membagi dengan biaya akselerator untuk mendapatkan TPS/chip/$.

Sebagai opsi lain, amati pemanfaatan FLOP model (MFU) selama pelatihan untuk mengukur rasio throughput yang diamati relatif terhadap maksimum teoretis. Hal ini berguna untuk memahami seberapa dekat performa hardware dengan tolok ukur. Namun, TPS/chip tidak memberikan perbandingan chip-ke-chip yang sama bermanfaatnya dengan TPS/chip.
Mengevaluasi penurunan performa penskalaan Menskalakan cluster menjadi 256, 1024, dan 4096 chip, yang menjalankan model yang sama persis. Hitung ulang TPS/chip di setiap skala.
Akun untuk goodput

TPS/chip mentah hanya penting jika model benar-benar belajar. Hitung goodput untuk mengukur kecepatan komputasi yang berguna yang secara langsung meningkatkan status pelatihan LLM, dengan secara eksplisit mengecualikan waktu dan energi yang terbuang karena kesalahan hardware, gangguan jaringan, atau pemulihan checkpoint.

Saat mengevaluasi akselerator AI dalam skala besar, goodput memberikan gambaran yang lebih realistis tentang laba atas investasi Anda daripada throughput teoretis mentah, karena mengungkapkan seberapa efektif hardware mempertahankan performa dalam cluster dunia nyata yang rentan terhadap kesalahan.

Tabel berikut mencantumkan model yang direkomendasikan untuk tolok ukur pelatihan:

Ukuran Arsitektur Model Alasan
Kecil (8 M) Padat Llama 3.1 8B Llama 3 telah menjadi model standar, yang populer dengan standar benchmark seperti MLPerf selama beberapa tahun.
Sedang (70B) Padat Llama 3.1 70B Llama 3 telah menjadi model standar, yang populer dengan standar benchmark seperti MLPerf selama beberapa tahun.
Besar (671 B) MoE DeepSeek-V3 671B DeepSeek-V3 menetapkan standar baru untuk ukuran dan performa pada tahun 2025, dan dioptimalkan dengan baik di banyak platform multi-chip.

Contoh: Menormalisasi ke performa per dolar

Pertimbangkan perbandingan tolok ukur antara Chip_A, Chip_B, dan Chip_C tempat Anda menjalankan tolok ukur pelatihan untuk model umum guna melihat performa dalam TPS. Kemudian, Anda melihat rasio performa Chip_A terhadap performa Chip_B dan Chip_C untuk model yang sama:

Benchmark TPS Chip_A sebagai pecahan TPS Chip_B TPS Chip_A sebagai pecahan TPS Chip_C
Padat kecil: Llama 3.1 8B 0.82 0,62
MoE: Mixtral 8x7B 0,72 0,55
Kepadatan besar: Llama 3.1 405B 0,77 0,61
MoE Besar: DeepSeek-V3 0,85 0,62
Nilai rata-rata 0,79 0,60

Berdasarkan data dalam tabel sebelumnya, performa Chip_A rata-rata 0,79 dari performa Chip_B dan 0,60 dari performa Chip_C. Tanpa informasi lebih lanjut, kesimpulannya adalah Chip_C lebih unggul.

Namun, jika Chip_A berharga $100, Chip_B berharga $180, dan Chip_C berharga $200, maka menormalisasi performa per dolar (perf/$) akan mengubah hasilnya:

Benchmark Chip_A perf/$ sebagai pecahan Chip_B perf/$ Chip_A perf/$ sebagai pecahan Chip_C perf/$
Padat kecil: Llama 3.1 8B 1,48 1.24
MoE: Mixtral 8x7B 1,30 1.10
Padat besar: Llama 3.1 405B 1,39 1,22
MoE Besar: DeepSeek-V3 1,53 1.24
Nilai rata-rata 1.42 1,20

Jika Anda mempertimbangkan perf/$ sebagai titik perbandingan, Chip_A mengungguli Chip_B dengan rata-rata 42% dan Chip_C dengan rata-rata 20%.

Tolok ukur inferensi

Pelatihan adalah belanja modal di muka yang sangat besar, tetapi penayangan (dan dengan demikian inferensi) mewakili belanja operasional jangka panjang. TPS/chip yang lebih tinggi berarti Anda memerlukan lebih sedikit server fisik untuk mendukung workload operasional yang sama, sehingga secara drastis mengurangi konsumsi energi dan jejak pusat data.

Dalam inferensi, tujuannya adalah memaksimalkan throughput tanpa melanggar persyaratan latensi untuk memastikan pengalaman pengguna yang responsif. Dengan menstandardisasi evaluasi pada TPS/chip untuk model tetap, Anda dapat langsung membandingkan performa di berbagai chip.

Saat melakukan tolok ukur inferensi, lakukan normalisasi ke performa dengan menghitung TPS/chip/$:

Benchmark Penjelasan
Menetapkan SLA latensi

Pertama, tetapkan SLA yang ketat untuk pengalaman pengguna. Misalnya, latensi ekor (P99) yang dapat diprediksi sebesar 100 milidetik. Ukur pengalaman pengguna responsivitas menggunakan TTFT (kurang dari 500 md) dan Waktu Per Token Output (TPOT).
Mendorong ukuran batch Tingkatkan jumlah permintaan serentak (ukuran batch) secara bertahap terhadap hardware. Seiring bertambahnya ukuran batch, throughput meningkat, tetapi latensi pada akhirnya akan menurun.
Mencatat TPS/chip berkelanjutan maksimum

Jika hardware melanggar SLA latensi P99, hentikan. Mencatat throughput sistem total pada ukuran batch yang tepat tersebut, dan membagi dengan jumlah chip. Ini adalah nilai TPS/chip Anda.

Perhatikan bahwa beberapa akselerator serbaguna mengalami masalah dengan "latensi ekor" (lonjakan acak dalam waktu pemrosesan) di bawah beban batch yang tinggi, sehingga operator harus menjalankannya dengan pemakaian yang lebih rendah agar pengguna tetap merasa senang.

Pastikan untuk mengukur di dua fase pengisian otomatis yang berbeda (terikat komputasi) dan dekode (terikat bandwidth memori)
Menghitung TCO per seribu atau sejuta token Membagi biaya modal dan energi yang diamortisasi dari satu chip dengan TPS/chip berkelanjutan maksimumnya. Hal ini menerjemahkan tolok ukur teknis menjadi metrik keuangan, yang mengungkapkan biaya sebenarnya.

Tabel berikut mencantumkan model yang direkomendasikan untuk tolok ukur inferensi:

Ukuran Arsitektur Model Alasan
Kecil (8 M) Padat Llama 3.1 8B Llama 3 telah menjadi model standar, yang populer dengan standar benchmark seperti MLPerf selama beberapa tahun.
Sedang (70B) Padat Llama 3.1 70B Llama 3 telah menjadi model standar, yang populer dengan standar benchmark seperti MLPerf selama beberapa tahun.
Besar (480B) MoE Qwen3 Coder 480B Qwen3 480B adalah model coding OSS terkemuka.

Langkah berikutnya