Kemajuan Teknik Machine Learning untuk Machine Learning

• Seiring model ML makin besar, efisiensi eksekusi makin sangat dipengaruhi bukan hanya oleh hardware tetapi juga oleh optimisasi compiler, dan Google Research serta Google DeepMind mengungkap pendekatan untuk kembali meningkatkan area ini dengan ML
• Keputusan compiler yang dibuat di bawah framework seperti TensorFlow, JAX, dan PyTorch dapat sangat mengubah waktu eksekusi dan penggunaan sumber daya bahkan untuk model yang sama
• TpuGraphs adalah dataset yang memuat graph komputasi, konfigurasi kompilasi, dan waktu eksekusi program ML untuk TPU, yang dapat digunakan dalam riset model biaya berbasis pembelajaran
• Untuk mengurangi kendala sulitnya melatih graph komputasi besar sekaligus, Graph Segment Training membagi graph menjadi segmen, menurunkan penggunaan memori, dan memangkas waktu pelatihan hingga 3 kali
• Dalam kompetisi Kaggle, 792 peserta dari 616 tim di 66 negara memvalidasi teknik peningkatan model prediksi biaya nyata seperti kompresi graph, penyesuaian nilai padding, penambahan fitur node, dan attention antar konfigurasi

---

Mengapa compiler ML menentukan performa eksekusi

• Model ML modern menjalankan tugas seperti pemahaman bahasa alami, percakapan, pembuatan gambar, dan pembuatan video, serta ditulis dan dilatih dengan framework pemrograman ML seperti TensorFlow, JAX, dan PyTorch
• Framework menyediakan operasi aljabar linear seperti perkalian matriks dan convolution, serta lapisan jaringan saraf seperti layer convolution 2D dan layer transformer
• Pengguna tidak perlu menangani langsung detail cara menjalankan model secara efisien di hardware, karena compiler di bawah framework akan mengoptimalkan model secara otomatis
• Namun, compiler sering menyelesaikan masalah optimisasi yang kompleks dengan heuristik, sehingga tidak selalu mudah menghasilkan performa terbaik

Graph komputasi dan optimisasi dua tahap

• Compiler ML mengubah instruksi matematis yang ditulis pengguna menjadi instruksi yang dapat dijalankan di hardware nyata
• Program ML dapat direpresentasikan sebagai graph komputasi
  • Node merepresentasikan operasi tensor seperti matrix multiplication
  • Edge merepresentasikan tensor yang mengalir dari satu node ke node lain
• Optimisasi compiler secara umum terbagi menjadi dua jenis
  • Optimisasi tingkat graph: membuat keputusan dengan mempertimbangkan konteks seluruh graph dan mentransformasikan graph secara keseluruhan
  • Optimisasi tingkat kernel: mentransformasikan satu kernel berupa fused subgraph secara independen dari kernel lain

Trade-off performa pada memory layout

• Tensor 2D seperti matriks dapat disimpan di memori dalam bentuk [A B C a b c] atau [A a B b C c], yang masing-masing sesuai dengan layout row-major dan column-major
• Salah satu optimisasi penting compiler ML adalah menetapkan memory layout untuk semua tensor intermediate dalam program
• Layout tertentu bisa paling efisien untuk operasi individual, tetapi jika layout antara add dan convolution tidak cocok, compiler harus menyisipkan operasi copy tambahan
• Sebaliknya, meski performa operasi individual sedikit lebih rendah, konfigurasi yang tidak memerlukan transformasi layout bisa lebih baik untuk eksekusi keseluruhan
• Pada suite benchmark XLA, saat memilih konfigurasi layout optimal alih-alih pengaturan compiler default, terlihat peningkatan kecepatan hingga 32%

Dataset TpuGraphs

• TpuGraphs adalah dataset model biaya berbasis pembelajaran untuk program yang berjalan di TPU kustom milik Google
• Tujuannya adalah melatih model biaya yang menerima program input dan konfigurasi compiler lalu memprediksi waktu eksekusi program
• Dataset ini menargetkan dua konfigurasi compiler XLA
  • layout: konfigurasi yang menggeneralisasi konsep row-major dan column-major pada matriks ke tensor berdimensi lebih tinggi
  • tiling: konfigurasi ukuran tile
• Setiap contoh mencakup graph komputasi dari workload ML, konfigurasi kompilasi, dan waktu eksekusi saat dikompilasi dengan konfigurasi tersebut
• Graph dikumpulkan dari program ML open source dan mencakup arsitektur model seperti ResNet, EfficientNet, Mask R-CNN, dan Transformer
• Cara mengunduh dan kode awal tersedia di TpuGraphs GitHub
• Dibanding dataset graph property prediction terbesar sebelumnya dengan ukuran graph serupa, TpuGraphs memiliki jumlah graph 25 kali lebih banyak, dan dibanding dataset prediksi performa program ML sebelumnya, ukuran graph rata-ratanya 770 kali lebih besar

Model biaya dasar dan arsitektur GNN

• TpuGraphs juga menyediakan model biaya berbasis pembelajaran dasar, dan karena program input direpresentasikan sebagai graph, model ini menggunakan GNN
• Fitur node terdiri dari dua bagian
  • opcode id: informasi node terpenting yang menunjukkan jenis operasi tensor
  • fitur node lainnya
• Model dasar mengubah opcode id menjadi opcode embedding melalui embedding lookup table
• Opcode embedding digabungkan dengan fitur node lainnya untuk digunakan sebagai input GNN
• Node embedding yang dibuat GNN digabungkan menjadi graph embedding berukuran tetap melalui graph pooling reduction sederhana seperti sum dan mean
• Graph embedding akhir kemudian diubah menjadi satu output scalar melalui feedforward layer

Melatih graph besar dengan Graph Segment Training

• Graph Segment Training adalah teknik penskalaan pelatihan GNN untuk menangani graph besar pada perangkat dengan kapasitas memori terbatas
• Metode ini ditujukan untuk situasi graph-level prediction, ketika target prediksi bukan node atau edge melainkan seluruh graph
• Graph komputasi dapat memuat ratusan ribu node, sehingga Full Graph Training yang menggunakan seluruh graph sekaligus bisa jadi tidak mungkin secara komputasional
• GST membagi graph besar menjadi segmen-segmen kecil, lalu hanya memilih subset acak dari segmen untuk memperbarui model
• Segmen lainnya menghasilkan embedding tanpa menyimpan activation intermediate sehingga penggunaan memori berkurang
• Semua embedding segmen digabungkan untuk membentuk embedding graph besar asli, lalu digunakan untuk prediksi
• Historical embedding table dan segment dropout juga diperkenalkan untuk mengurangi staleness pada historical embedding
• Seluruh metode ini memangkas waktu pelatihan end-to-end hingga 3 kali

Teknik peningkatan yang tervalidasi di kompetisi Kaggle

• Kompetisi Kaggle Fast or Slow? Predict AI Model Runtime diadakan berdasarkan dataset TpuGraphs, dengan partisipasi 792 orang dari 616 tim di 66 negara
• Jumlah submission mencapai 10.507, dan bagi 153 orang ini adalah kompetisi Kaggle pertama mereka, dengan 47 di antaranya masuk 100 besar
• Tim peserta bereksperimen dengan berbagai teknik
  • Pruning dan compression graph: alih-alih GST, mereka menguji metode untuk mengompresi graph besar, termasuk pendekatan yang hanya mempertahankan subgraph yang mencakup node yang dapat dikonfigurasi dan tetangga langsungnya
  • Mengubah nilai padding: karena nilai padding default 0 bertabrakan dengan nilai feature yang valid, penggunaan -1 dapat sangat meningkatkan akurasi model
  • Menambah fitur node dan mengubah encoding: fitur node tambahan seperti contracting dimensions pada dot general penting, dan cara encoding fitur node juga dapat memengaruhi hasil
  • Cross-configuration attention: tim pemenang merancang layer sederhana agar model dapat membandingkan konfigurasi secara eksplisit, dan hasilnya jauh lebih baik daripada pendekatan yang menginferensikan tiap konfigurasi secara terpisah
• Hasil kompetisi dan solusi pemenang dijadwalkan dibahas pada 16 Desember 2023 dalam sesi kompetisi workshop ML for Systems di NeurIPS

Sesi terkait NeurIPS Expo

• Bagi pembaca yang tertarik pada data terstruktur dan riset kecerdasan buatan, panel NeurIPS Expo Graph Learning Meets Artificial Intelligence diadakan pada 9 Desember 2023
• Panel ini membahas antara lain perkembangan model biaya berbasis pembelajaran

[GN⁺]

Komentar Hacker News

• Kompiler ML terlalu dibesar-besarkan. Ini kompromi yang sama seperti kompiler tradisional: throughput yang didapat jauh lebih besar daripada merekrut programmer performa spesialis, tetapi yang terakhir biasanya jauh lebih cepat dan dalam beberapa kasus bisa unggul beberapa orde besaran
  Ada kekurangan di banyak lapisan. Di level algoritme, ini tidak memberi umpan balik kepada manusia tentang trik untuk membuat jaringan lebih cepat, hanya memberi sinyal yang sangat dasar. Intent juga hilang. Perancang jaringan ML menentukan arsitektur dengan Python, tetapi setelah melewati beberapa tahap lowering, hasilnya bisa menjadi sesuatu yang sama sekali tak terduga. Belakangan ini saya melihat sebuah kompiler yang saat melakukan slice update membuat semua rentang indeks array yang mungkin, lalu memotongnya untuk mendapatkan indeks yang akan di-update, kemudian melakukan scatter. Saya menggantinya dengan satu pemanggilan memcpy. Kernel juga tidak efisien. Setiap kali output kompiler seperti ini berhadapan dengan programmer assembly yang terampil, kompiler kalah, biasanya dengan selisih lebih dari 30%. Kelihatannya mudah diselesaikan, tetapi jika tak seorang pun berhasil menyelesaikannya dengan benar selama 50 tahun terakhir, jelas ini tidak sesederhana kedengarannya

  • Lihat engine catur Stockfish: setelah bertahun-tahun menggunakan heuristik buatan manusia untuk evaluasi papan, mereka membuangnya dan menggantinya dengan jaringan saraf kecil, dan hasilnya lebih baik
    Kompiler juga punya banyak heuristik seperti inlining, loop unrolling, dan vectorization, jadi jaringan saraf bisa membantu, dan mungkin lebih mudah dipelihara daripada sekian banyak heuristik buatan manusia
  • Menariknya, Anda bilang ini kompromi seperti kompiler tradisional, padahal kompiler tradisional itu sendiri sangat berguna
  • Kedengarannya terlalu absolut dan tertutup
  • Benar. Tinggal pekerjakan orang untuk menulis assembly dengan tangan, lalu untuk apa ada yang memakai gcc/clang?
  • Throughput itu justru intinya. Tidak mungkin setiap pekerjaan ML ditempeli ahli performa
    Optimasi seperti ini tetap jauh lebih baik daripada tidak ada sama sekali

• Bisa dijelaskan dengan lebih membumi? Saya penasaran seperti apa keadaan nyata kompiler ML saat ini dan apa yang realistis bisa diharapkan dalam waktu dekat

  • Salah satu pendekatan termudah adalah torch.compile. Ini iterasi terbaru dari kompiler PyTorch, dan pendekatan sebelumnya adalah TorchScript dan FX Tracing
    Cukup tulis model = torch.compile(model). “Di 163 model open source ini, torch.compile bekerja pada 93% kasus dan membuat pelatihan 43% lebih cepat pada GPU NVIDIA A100. Dengan presisi Float32, rata-ratanya 21% lebih cepat, dan dengan presisi AMP, rata-ratanya 51% lebih cepat.”[1] Google tampaknya ingin lebih banyak orang terlibat dalam R&D pendekatan seperti ini
    [1] https://pytorch.org/get-started/pytorch-2.0/
  • Harapan dalam waktu dekat adalah bisa memakai AMD, CUDA, TPU, CPU dan sebagainya tanpa perlu dukungan vendor eksplisit untuk framework tempat model itu dikembangkan
    Kenyataannya kompleks, jadi kalau sangat disederhanakan, caranya adalah mengompilasi graph komputasi ke suatu intermediate representation lalu mengimplementasikan backend yang cocok untuk itu. Untuk proyek terkait, lihat stableHLO, IREE, dan openXLA. Kompiler jit milik Jax juga bisa dilihat sebagai salah satu bentuk kompiler seperti ini. Operasi yang ditrace diturunkan ke XLA, lalu XLA melakukan berbagai keajaiban lagi agar bisa berjalan di backend. Pada akhirnya, semakin ke bawah, ini terus menjadi soal transformasi dan abstraksi
  • Cukup lihat torch.compile

• Ringkasnya, ini adalah upaya meningkatkan prediksi performa waktu eksekusi graph komputasi dengan graph neural network (GNN). Mereka memakai kamus embedding untuk opcode tiap node bersama fitur node lain seperti shape, bits, dan window size ([1])
  Mereka merilis dataset graph besar berisi performa hasil dari beragam konfigurasi kompilasi XLA dan TPU di [2], lalu di [3] meningkatkan prediksi untuk graph yang lebih besar menggunakan cara membagi graph (METIS graph partition, baru kali ini saya melihatnya) dan berbagai teknik pelatihan. Ini tentang memprediksi performa graph yang diberikan, bukan tentang memperbaiki, mengusulkan, atau memodifikasi graph baru yang ekuivalen. Model dengan daya prediksi yang lumayan, seperti pada FunSearch, bisa dipakai bersama pencarian evolusioner
  [1] https://github.com/google-research-datasets/tpu_graphs#featu...
  [2] TpuGraphs: A Performance Prediction Dataset on Large Tensor Computational Graphs https://arxiv.org/abs/2308.13490
  [3] Learning Large Graph Property Prediction via Graph Segment Training https://arxiv.org/abs/2305.12322

• Bisa jelaskan bagaimana konvolusi bekerja pada graph itu? Tensor dengan shape [2,4,16] dikonvolusikan dengan kernel shape [4,16,8], tetapi hasilnya tensor [2,8]; bagaimana itu mungkin?

  • Mungkin ini membantu: pada tensor input [2,4,16], 2 bisa dilihat sebagai ukuran batch, 4 sebagai dimensi fitur input, dan 16 sebagai dimensi kanal input
    Pada kernel [4,16,8], 4 adalah ukuran jendela filter, 16 cocok dengan dimensi kanal input, dan 8 adalah dimensi kanal output. Pada output [2,8], 2 tetap sebagai ukuran batch, dan 8 cocok dengan dimensi kanal output kernel. Sepintas dimensinya memang terlihat tidak cocok, tetapi konvolusi pada graph memanfaatkan struktur ketetanggaan. Kernel bergerak di atas graph sambil menerapkan bobot pada fitur node saat ini dan tetangga dalam radius tertentu, lalu mengumpulkan jumlah berbobot itu untuk membentuk fitur baru bagi tiap kanal output. Struktur graph, bobot edge, serta detail implementasi seperti padding dan stride juga bisa memengaruhi shape output

• Bagaimana keadaan Gemini?

  • Menarik bahwa GPT-4 terus unggul: https://twitter.com/lmsysorg/status/1735729398672716114
    Kalau dipikir-pikir, setidaknya ada lima model fondasi yang sedang naik daun seperti Llama, Claude, Gemini, Falcon, dan Mistral, saling salip-menyalip, tetapi GPT masih tetap satu tingkat di atas, dan sudah begitu selama setahun. Sudah terlihat bahwa large language model berbasis Transformer cukup sederhana sehingga siapa pun bisa membuatnya jika mampu membakar GPU time senilai sekitar sejuta dolar, tetapi tetap belum bisa sepenuhnya menyamai OpenAI. Apa rahasia khusus mereka?

• Bagaimana dengan Transformer itu sendiri? Apakah ada petunjuk bahwa ia optimal dalam suatu pengertian?

• Rasanya paragraf pertama menenggelamkan poin utamanya, tetapi selebihnya isinya bagus

• Kecepatan kemajuan ML saat ini sungguh mengejutkan. Saya tidak percaya singularitas, tetapi ini mengubah software dan masyarakat dengan cara yang tak diprediksi siapa pun

  • Kalau melihat ini dan FunSearch, singularitas terasa seperti sudah dekat
    https://deepmind.google/discover/blog/funsearch-making-new-d...
  • Bagi saya, ini terlihat seperti demam emas lain setelah dot-com, mobile, cloud, dan VR
  • Lima tahun lagi, saya rasa orang tidak akan memrogram seperti sekarang
  • Saya lebih ingin melihat dulu obat untuk penyakit yang sulit disembuhkan. Singularitas sendiri tak berarti bila tidak menguntungkan manusia, dan manfaat itu seharusnya terutama berupa peningkatan kesehatan dan pengurangan penderitaan