Tokenomics: Mengukur ke Mana Token Digunakan dalam Rekayasa Perangkat Lunak Berbasis Agen

 (arxiv.org)
1 poin oleh GN⁺ 4 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Studi yang memetakan jejak eksekusi sistem pengembangan perangkat lunak multi-agen berbasis LLM ke tahap-tahap SDLC, dan mengukur bahwa konsumsi token lebih terkonsentrasi pada code review dan verifikasi daripada generasi awal
  • Pada 30 tugas pengembangan perangkat lunak yang dijalankan oleh ChatDev, tahap code review terkonfirmasi sebagai titik konsumsi terbesar dengan rata-rata 59,4% token
  • Komposisi token rata-rata seluruh tugas adalah 53,9% input, 24,4% output, dan 21,6% reasoning, menunjukkan bahwa penyampaian konteks berulang antar agen membentuk communication tax yang besar
  • Tahap coding memiliki porsi token output tinggi sebesar 58,0%, sedangkan tahap dokumentasi memiliki porsi token input tinggi sebesar 80,2%, sehingga pola penggunaan token tiap tahap pengembangan terlihat jelas berbeda
  • Kesimpulannya, untuk prediksi biaya dan optimasi workflow, dibutuhkan protokol kolaborasi agen yang lebih efisien token serta kerangka evaluasi yang terstandarisasi

Abstrak

  • Sistem multi-agen berbasis LLM (LLM-MA) semakin banyak diterapkan untuk mengotomatisasi pekerjaan rekayasa perangkat lunak yang kompleks seperti requirement engineering, pembuatan kode, dan pengujian
  • Karena efisiensi operasional dan konsumsi sumber dayanya belum cukup dipahami, biaya yang sulit diprediksi dan dampak lingkungan menjadi faktor yang menghambat adopsi nyata
  • Penelitian ini menganalisis jejak eksekusi dari 30 tugas pengembangan perangkat lunak yang dijalankan framework ChatDev dengan GPT-5 reasoning model, lalu memetakan langkah-langkah internalnya ke tahap desain, coding, penyelesaian kode, code review, pengujian, dan dokumentasi
  • Hasil awal menunjukkan bahwa tahap code review yang berulang menghabiskan rata-rata 59,4% token dan menjadi titik konsumsi terbesar
  • Token input secara konsisten menempati porsi terbesar dengan rata-rata 53,9%, memberikan bukti empiris bahwa ada potensi inefisiensi yang signifikan dalam kolaborasi agen
  • Biaya utama dalam rekayasa perangkat lunak berbasis agen tidak terkonsentrasi pada pembuatan kode awal, melainkan pada proses perbaikan dan verifikasi yang terotomatisasi
  • Metodologi ini dapat dimanfaatkan untuk prediksi biaya, optimasi workflow, dan riset protokol kolaborasi agen yang lebih efisien token

Pendahuluan

  • Rekayasa perangkat lunak skala besar sedang mengeksplorasi sistem multi-agen berbasis LLM untuk mengotomatisasi pekerjaan kompleks di seluruh SDLC
  • Framework LLM-MA mensimulasikan peran tim manusia seperti product manager, arsitek, developer, dan tester sebagai agen LLM terspesialisasi, yang bekerja kolaboratif untuk menjalankan tugas desain, coding, dan verifikasi
  • Secara prinsip, sistem LLM-MA dapat membagi pekerjaan antar agen untuk meningkatkan otonomi dan ketahanan
  • Penelitian sebelumnya membahas bahwa sistem LLM-MA dapat mendorong pemikiran divergen, memperkuat reasoning dan factuality, serta berkembang ke masalah yang melampaui kemampuan agen tunggal
  • Dalam rekayasa perangkat lunak, ada potensi untuk mengotomatisasi workflow end-to-end dari requirement hingga testing secara terintegrasi
  • Framework AGENTTAXO menyediakan taksonomi untuk menganalisis distribusi token pada sistem LLM-MA umum, serta memperkenalkan konsep “communication tax” untuk menjelaskan overhead interaksi antar agen
  • Klasifikasi kegagalan MAST menunjukkan bahwa banyak masalah pada sistem LLM-MA berasal dari desain dan koordinasi sistem, seperti pengulangan tahap dan verifikasi yang tidak lengkap, bukan semata keterbatasan LLM individual
  • Penelitian yang ada telah menganalisis perilaku agen dalam konteks umum, tetapi masih ada kesenjangan pengetahuan mengenai efisiensi sumber daya pada sistem yang diterapkan ke workflow rekayasa perangkat lunak multistep
  • Pertanyaan inti untuk adopsi praktis, yaitu “ke mana token pergi”, masih belum cukup terjawab dalam domain rekayasa perangkat lunak
  • Tokenomics adalah istilah untuk studi efisiensi operasional dan konsumsi sumber daya pada sistem LLM-MA
  • Analisis dilakukan dengan memetakan langkah-langkah internal ChatDev ke tahap pengembangan untuk melihat distribusi konsumsi token
  • ChatDev mensimulasikan perusahaan perangkat lunak virtual, di mana berbagai peran agen seperti programmer dan tester menyelesaikan SDLC melalui percakapan multi-turn
  • Disediakan dataset kurasi berisi 30 jejak eksekusi serta paket replikasi lengkap

Desain penelitian

  • Tujuan dan objek analisis

    • Tujuannya adalah menyelidiki secara empiris bagaimana konsumsi token terdistribusi ketika sistem LLM-MA menjalankan tugas pengembangan perangkat lunak end-to-end
    • Objek analisis awal adalah ChatDev
    • Arsitektur “chat chain” milik ChatDev merepresentasikan model waterfall berurutan yang jelas dari desain → coding → testing, sehingga tahap-tahapnya tegas dan cocok untuk dipetakan ke tahap pengembangan perangkat lunak
    • ChatDev adalah salah satu framework open source yang populer dan banyak disitasi

  • Kurasi dataset

    • ChatDev dijalankan pada 30 tugas pengembangan perangkat lunak yang berbeda
    • Prompt dikumpulkan dari ProgramDev Dataset yang digunakan dalam penelitian MAST
    • Prompt yang dipilih mencakup algoritme sederhana seperti pembangkitan bilangan Fibonacci hingga aplikasi yang lebih kompleks seperti permainan catur
    • Keberagaman diverifikasi berdasarkan penelitian terbaru yang menunjukkan bahwa jumlah token reasoning dapat menjadi indikator proksi kompleksitas tugas
    • Rentang konsumsi token reasoning pada 30 tugas adalah dari 17.280 hingga 40.000 token, yang menunjukkan keberagaman kompleksitas tugas yang memadai untuk penelitian ini

  • Pemilihan model

    • Model dasar untuk semua agen adalah GPT-5 reasoning model
    • Kriteria pemilihannya adalah popularitas dan kebaruan model, kecocokan untuk use case berbasis agen, serta kemampuan reasoning yang kuat sesuai ekspektasi agen otonom
    • Versi model yang digunakan dalam eksperimen adalah gpt-5-2025-08-07
    • Parameter temperature tidak didukung oleh model ini, sehingga digunakan nilai default 1.0
    • Context window adalah 400.000 token, dan token output maksimum adalah 128.000 token
    • Knowledge cutoff adalah 30 September 2024

  • Pipeline analisis

    • Pada tahap pengumpulan jejak, ChatDev diinstrumentasi untuk mencatat log jejak eksekusi penuh dari masing-masing 30 tugas
    • Prompt, respons, serta jumlah token input, output, dan reasoning dari setiap pemanggilan LLM ditangkap
    • Pemetaan tahap adalah metodologi inti yang mengubah langkah internal framework ChatDev menjadi tahap pengembangan yang universal
    • Abstraksi ini memungkinkan analisis yang dapat digeneralisasi dan dapat diperluas ke framework LLM-MA rekayasa perangkat lunak lainnya
    • Agregasi token dilakukan dengan skrip Python
    • Jejak yang dikumpulkan di-parse, lalu jumlah token per tahap pengembangan dijumlahkan di seluruh 30 eksekusi
    • Token dipecah menjadi token input, output, dan reasoning

  • Pemetaan langkah internal ChatDev ke tahap pengembangan

    • Tahap desain dipetakan ke DemandAnalysis dan LanguageChoose, dengan fokus pada pemahaman requirement dan keputusan teknologi tingkat tinggi
    • Tahap coding dipetakan ke Coding, yang terlibat langsung dalam penulisan source code awal
    • Tahap penyelesaian kode dipetakan ke CodeComplete, yang menyelesaikan placeholder atau file kode yang belum selesai dari tahap coding
    • Tahap code review dipetakan ke CodeReview, yang melakukan peninjauan, revisi, dan perbaikan kode melalui dialog berulang antara agen programmer dan agen code reviewer
    • Tahap testing dipetakan ke Test, yang berfokus pada pengujian sistem dinamis untuk menemukan dan memperbaiki bug yang memengaruhi eksekusi
    • Tahap dokumentasi dipetakan ke EnvironmentDoc, Reflection, dan Manual, yang menghasilkan manual pengguna dan dokumentasi dependensi environment yang diperlukan

Hasil penelitian dan diskusi

  • Pertanyaan penelitian

    • Pertanyaan utamanya adalah pola konsumsi token pada sistem LLM-MA dalam tugas pengembangan perangkat lunak
    • Memahami tokenomics sistem rekayasa perangkat lunak berbasis agen penting untuk adopsi yang praktis dan berkelanjutan
    • Penggunaan token yang tinggi berkaitan langsung dengan peningkatan biaya finansial, konsumsi energi, dan dampak lingkungan
    • Dengan mengidentifikasi lokasi konsumsi token di dalam SDLC, dapat dibuat “peta biaya” yang berguna untuk prediksi biaya dan optimasi workflow
    • Analisis dilakukan pada dua sumbu
    • Distribusi total token per tahap pengembangan yang telah dipetakan, seperti desain dan coding
    • Rasio token input, output, dan reasoning di dalam tiap tahap

  • Temuan 1: tahap code review mendominasi konsumsi token

    • Penggunaan token di seluruh proses pengembangan sangat tidak merata distribusinya
    • Tahap code review menghabiskan rata-rata 59,4% token di seluruh 30 tugas dan menjadi titik konsumsi terbesar
    • Tahap penyelesaian kode muncul pada 6 dari 30 tugas, dan pada eksekusi tersebut menghabiskan rata-rata 26,8% token
    • Tahap dokumentasi menghabiskan rata-rata 20,1% token, dan tahap testing 10,3%
    • Tahap testing muncul pada 12 dari 30 tugas
    • Coding awal relatif berbiaya rendah, dengan rata-rata 8,6%, dan desain 2,4%
    • Biaya utama dalam rekayasa perangkat lunak berbasis agen terkonsentrasi pada proses perbaikan dan verifikasi yang berulang dan bersifat percakapan, bukan pada generasi kode awal
    • Nilai n pada gambar menunjukkan jumlah tugas dari 30 tugas yang mengeksekusi tahap tertentu
    • Tidak semua tahap selalu dijalankan, dan agen dalam sistem multi-agen secara otonom memutuskan tahap mana yang akan dijalankan
    • Error bar menunjukkan ±1 standar deviasi, yang merepresentasikan variabilitas konsumsi token pada tiap tahap

  • Temuan 2: konsumsi token berpusat pada token input

    • Di semua tahap selain coding, token input jauh melebihi token output dan reasoning
    • Komposisi rata-rata penggunaan token total per tugas adalah 53,9% input, 24,4% output, dan 21,6% reasoning
    • Rasio sekitar 2:1 antara token input dan output memberikan bukti empiris yang kuat untuk “communication tax” yang telah dibahas pada penelitian sebelumnya
    • Agen menghabiskan token dengan mengirimkan konteks besar berulang kali selama percakapan kolaboratif
    • Dalam protokol kolaborasi agen saat ini, ada inefisiensi karena sebagian besar token dihabiskan untuk menyampaikan konteks, bukan menghasilkan output baru
    • Communication tax mungkin merupakan karakteristik inheren dari arsitektur multi-agen berbasis percakapan, dan menjadi target penelitian lanjutan

  • Temuan 3: perbedaan tokenomic profile tiap tahap pengembangan

    • Rasio token per tahap membentuk pola khas untuk masing-masing aktivitas rekayasa perangkat lunak
    • Tahap coding menjadi pengecualian yang berpusat pada output, dengan 58,0% output dan 6,9% input
    • Struktur yang berpusat pada output pada tahap coding sesuai dengan sifat tugas yang menghasilkan source code panjang dari spesifikasi desain yang ringkas
    • Tahap verifikasi dan dokumentasi seperti code review dan dokumentasi berpusat pada input
    • Porsi input pada code review adalah 51,4%
    • Porsi input pada dokumentasi adalah 80,2%
    • Tahap-tahap ini mengonsumsi kode yang sudah ada sebagai konteks besar dan menghasilkan output analitis yang lebih kecil
    • Token profile per tahap dapat digunakan sebagai peta biaya untuk tiap aktivitas engineering
    • Praktisi dapat lebih mudah mengidentifikasi peluang untuk prediksi biaya dan optimasi proses

  • Rasio token per tahap

    • Rasio rata-rata tahap desain adalah 60,4% input, 3,6% output, 36,0% reasoning
    • Rasio rata-rata tahap coding adalah 6,9% input, 58,0% output, 35,1% reasoning
    • Rasio rata-rata tahap penyelesaian kode adalah 47,7% input, 41,7% output, 10,5% reasoning
    • Rasio rata-rata tahap code review adalah 51,4% input, 24,7% output, 23,9% reasoning
    • Rasio rata-rata tahap testing adalah 60,8% input, 20,7% output, 18,4% reasoning
    • Rasio rata-rata tahap dokumentasi adalah 80,2% input, 8,3% output, 11,5% reasoning
    • Rasio rata-rata total per tugas adalah 53,9% input, 24,4% output, 21,6% reasoning

  • Diskusi

    • Hasil awal ini memberikan peta biaya awal untuk pengembangan perangkat lunak berbasis agen
    • Biaya token yang besar pada tahap code review dapat ditafsirkan sebagai “biaya percakapan”
    • Biaya ini muncul langsung dari arsitektur percakapan pada sistem LLM-MA, ketika agen berulang kali saling bertukar seluruh konteks kode untuk memperbaikinya
    • Protokol kolaborasi agen saat ini untuk verifikasi bisa sangat tidak efisien karena menghabiskan sumber daya besar bahkan untuk tugas yang hanya membutuhkan perbaikan kecil
    • Temuan ini juga selaras dengan hasil klasifikasi MAST terkait kegagalan verifikasi dan pengulangan tahap
    • Penggunaan token yang tinggi bisa menjadi gejala bahwa sistem agen sedang berusaha mengatasi masalah koordinasi inheren melalui percakapan yang dipaksakan
    • Praktisi dapat memperkirakan biaya proyek berbasis agen berdasarkan jenis pekerjaan yang dibutuhkan
    • Proyek greenfield yang menitikberatkan pada coding awal dan proyek yang berfokus pada refactoring atau debugging kode yang sudah ada memiliki struktur biaya yang berbeda
    • Pada proyek yang berpusat pada refactoring dan debugging kode yang sudah ada, siklus code review yang mahal dan berpusat pada input akan mendominasi biaya
    • Mengintegrasikan checkpoint “human-in-the-loop” sebelum tahap code review dapat mencegah loop iteratif berbiaya tinggi dan menjadi keputusan desain yang meningkatkan efisiensi ekonomi maupun komputasi
    • Tugas riset ke depan adalah merancang protokol kolaborasi yang lebih efisien token untuk verifikasi dan perbaikan
    • Diperlukan pendekatan yang melampaui sekadar pengiriman seluruh konteks
    • Dibutuhkan kerangka evaluasi yang terstandarisasi dan komprehensif
    • Kerangka ini dapat menjadi landasan umum untuk membenchmark dan membandingkan efisiensi berbagai arsitektur LLM-MA, seperti workflow percakapan hierarkis ChatDev dan assembly line berbasis SOP pada MetaGPT
    • Kerangka ini juga dapat berfungsi sebagai “Rosetta Stone” yang menerjemahkan perilaku tiap framework ke aktivitas rekayasa perangkat lunak yang universal

Ancaman validitas dan pekerjaan lanjutan

  • Ancaman validitas

    • Analisis ini didasarkan pada satu sistem LLM-MA, yaitu ChatDev, dan satu LLM, yaitu GPT-5 Reasoning Model
    • Pola konsumsi token yang diamati bisa berbeda pada arsitektur LLM-MA lain atau pada LLM lain dengan efisiensi token yang berbeda
    • Tiga puluh tugas pengembangan perangkat lunak ini beragam, tetapi mungkin tidak mewakili seluruh skenario dan kompleksitas pengembangan perangkat lunak yang mungkin terjadi
    • Skala dataset kurasi ini secara langsung disebabkan oleh kurangnya benchmark publik berskala besar untuk jejak agen yang terspesialisasi pada rekayasa perangkat lunak
    • Kurasi data adalah proses yang mahal dari sisi waktu dan biaya
    • Beberapa tahap pengembangan hanya dijalankan pada subset kecil dari 30 tugas
    • Penyelesaian kode jarang terpicu dengan n=6, dan testing dengan n=12
    • Karena kesimpulan tokenomic profile untuk tahap-tahap tertentu ini didasarkan pada sampel kecil, representativitasnya bisa rendah dan generalisasinya terbatas
    • Cara memetakan langkah internal ChatDev ke tahap pengembangan perangkat lunak merupakan sebuah abstraksi
    • Meskipun ini adalah pemetaan yang logis dan berguna untuk membuat kerangka evaluasi terstandarisasi, ia tetap hanya salah satu dari beberapa kemungkinan cara memetakan aktivitas agen

  • Kesimpulan dan pekerjaan lanjutan

    • Dalam rekayasa perangkat lunak berbasis agen, biaya token tidak terdistribusi merata, melainkan sangat terkonsentrasi pada tahap code review yang berulang dan bersifat percakapan
    • Token input yang membentuk “communication tax” mencakup sebagian besar penggunaan token total dan menjadi area kunci untuk optimasi di masa depan
    • Tugas pertama untuk pekerjaan lanjutan adalah memperluas dataset dengan lebih banyak tugas agar generalisasi meningkat
    • Tugas kedua adalah memperluas analisis ke LLM lain untuk memahami efek spesifik model
    • Tugas ketiga adalah memperluas analisis ke sistem LLM-MA lain untuk membandingkan dampak perbedaan arsitektur terhadap tokenomics
    • Tugas keempat adalah menyelidiki hubungan antara pola konsumsi token dan mode kegagalan
    • Tugas kelima adalah pengembangan dan validasi lebih lanjut atas framework pemetaan tahap pengembangan yang kokoh dan universal untuk benchmarking efisiensi agen rekayasa perangkat lunak

Bacaan terkait

1 komentar

 
GN⁺ 4 hari lalu
Komentar Hacker News

  • Saya membuat dan menggunakan sistem multi-agen untuk keperluan pribadi
    Saat diberi sebuah masalah, model yang cepat dan murah lebih dulu mengajukan pertanyaan, lalu berdasarkan jawabannya memperbaiki prompt masukan
    Setelah itu, sistem membagi masalah per bagian lalu memilih strategi seperti hakim akhir yang menarik kesimpulan, atau beberapa agen berdebat lalu hakim merangkum hasilnya
    Metode terbaik yang saya temukan adalah yang saya sebut all angles, yaitu menjalankan beberapa strategi secara paralel lalu hakim meta terakhir menyatukan responsnya
    Bagian paling berguna dari fitur yang baru saya tambahkan adalah layar untuk melihat perbedaan di antara tiap strategi
    Saya memakainya untuk isu kehidupan seperti mencari tempat tinggal, sekolah, dan masalah keluarga

    • Demo video dari yang saya buat ada di sini: https://streamable.com/e49cgt
    • Tadi Anda menyebut biaya; saya penasaran apakah Anda bisa menjelaskan lebih jauh struktur biaya kasar menurut jenis masalah
      Saya juga ingin tahu strategi apa yang dipakai dan bagaimana biaya berbeda untuk tiap strategi
    • Saya penasaran execution harness apa yang dipakai, dan LLM apa yang digunakan
    • Saya juga membuat sistem serupa, tetapi lebih berfokus pada loop umpan balik daripada perbaikan prompt yang eksploratif
      Dengan pendekatan ala sibernetika, saya terus memperbesar pustaka pemeriksaan deterministik dan perbaikan otomatis untuk menjaga stabilitas keluaran prompt
      “Masalah” yang tidak bisa ditangani pustaka itu akan terlihat oleh orang yang mengendalikan proses

  • Selama sebulan saya memakai GitHub Copilot secara intens tanpa putus, tetapi setelah perubahan harga, bulan berikutnya jatah token saya habis hanya dalam dua hari
    Perubahan sedrastis ini tampak seperti tanda bahwa harga token bersifat sewenang-wenang, dan bisnis AI sedang cepat kehabisan uang

    • Saya justru melihatnya lebih sebagai akibat dari dorongan mengejar valuasi maksimum atau IPO
      Ada rumor bahwa margin inferensi melebihi 70%
      Ambil SpaceX sebagai contoh: dalam 6 bulan terakhir mereka menaikkan harga produk konsumen secara umum, tetapi Alphabet dan Anthropic bersama-sama membayar lebih dari 2 miliar dolar per bulan, jadi ini bukan soal kekurangan uang
      Microsoft/GitHub berada di posisi membungkus ulang produk orang lain, jadi mereka yang merugi di sini
    • Kasus GitHub lebih mendekati pengecualian yang tampak sangat mendadak karena baru-baru ini ada perubahan kebijakan harga
      Secara umum, harga ditentukan oleh berbagai faktor dasar, dan itu sendiri tidak berarti bersifat sewenang-wenang
      Misalnya, kalau para eksekutif GitHub menentukan harga token dengan generator angka acak, barulah itu penetapan harga yang sewenang-wenang

  • Ada bagian yang menyebut “token input menyumbang rata-rata 53,9% dan menjadi porsi konsumsi terbesar”, tetapi dalam penggunaan saya rasionya sekitar 10:1
    Sebagian besar token yang dikonsumsi ada di sisi input, dan sering kali agen membaca jutaan token hanya untuk memperbaiki satu baris kode
    Jika mendekati 1:1 atau sisi output lebih besar, saya akan menganggap ada masalah pada agen tersebut, atau codebase-nya masih baru atau kosong

    • Saya penasaran apakah Anda sudah mencoba memberi agen alat yang lebih baik seperti AST dan language server agar lebih mudah menjelajahi dan mendokumentasikan codebase
      Satu juta token tanpa cache terdengar cukup besar
    • Jika token input memang mendominasi biaya sebesar itu, itu berarti perbaikan besar bisa didapat hanya dengan memanfaatkan caching dengan lebih baik
      Misalnya, Anda bisa menyuruh model menjalankan satu tahap “kompresi” untuk membuang bagian kode yang relevan, lalu memakai hasilnya sebagai prefiks yang di-cache untuk banyak panggilan sub-agen

  • Saat memakai agen untuk coding, mereka tampaknya ingin menulis unit test sampai ribuan, tetapi kurang cenderung melakukan pengujian dinamis

    • Mereka juga suka membakar banyak token untuk menulis dan men-debug test yang rusak secara semantik
    • Unit test juga merupakan salah satu jenis pengujian dinamis
      Pengujian statis itu hal seperti lint atau pemeriksaan tipe
      Jika yang Anda maksud adalah jenis pengujian dinamis lain selain unit test, saya penasaran apakah Anda sudah menyatakannya sebagai kebutuhan di tahap perencanaan atau PRD
    • AWS juga sangat mendorong solusi Lambda yang rumit untuk kebutuhan sederhana, dengan merangkai sebanyak mungkin layanan AWS yang bisa ditagih
      Kepentingan mereka tidak selalu sejalan dengan kepentingan Anda
      Dalam kasus ini, mereka ingin Anda membelanjakan uang secara tidak perlu untuk pekerjaan yang tidak berguna
      Mungkin sudah saatnya berhenti memakai eufemisme “token” juga
    • Tinggal instruksikan saja agar melakukan lebih banyak pengujian dinamis
      Saya kira salah satu alasan ada keengganan terhadap pengujian dinamis adalah karena itu memperlambat proses dan bisa menghentikan perangkat lunak di tempat yang tidak terduga

  • Ini mengingatkan saya pada makalah tahun lalu yang memberikan panduan anggaran untuk mengoptimalkan efisiensi penggunaan token
    [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

  • Ini mirip dengan miles kompensasi maskapai, dan dari sudut pandang perusahaan tidak memberi keuntungan dibanding menyewa waktu GPU bare-metal

    • Saya berharap masa buruk ini segera berakhir ketika lebih banyak perusahaan hardware merilis NPU murah dan ukuran model makin dioptimalkan
      Ketika sebagian besar permintaan AI bisa dipenuhi oleh hardware dan model on-premise atau on-device, saya jadi bertanya-tanya model dan ladang komputasi raksasa berbiaya operasional tinggi seperti itu nantinya berguna untuk apa
      Mungkin pelanggan yang tersisa hanya pemerintah besar, dan pada akhirnya pembayar pajaklah yang akan menanggung miliaran dolar yang diinvestasikan kartel AI

  • Saya menulis postingan Substack tentang topik ini pada bulan Desember: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

  • Dulu perusahaan seperti Google merekrut engineer berdasarkan seberapa baik mereka bisa mengoptimalkan infrastruktur
    Bisa jadi sebentar lagi perusahaan akan melihat kemampuan engineer dalam mengoptimalkan efisiensi token AI

    • Itu mengandaikan bahwa token akan tetap menjadi biaya yang berarti
      Sulit memastikan apakah para developer akan menemukan kegunaan untuk lebih banyak token secepat turunnya harga token itu sendiri
    • Saya tahu cara menurunkan biaya token perusahaan menjadi nol
      Perlakukan token sebagai biaya utilitas seperti internet, lalu biarkan engineer yang membayarnya sendiri

  • Sebagai selingan yang menarik, saya pernah ada di rapat untuk meninjau kandidat produk baru, dan semuanya berjalan baik sampai muncul layar yang menunjukkan produk itu telah ditambahi AI
    Tentu saja ada AI-nya, dan sangat terlihat dipaksakan
    Salah satu tanda paling jelas adalah adanya kolom yang menampilkan berapa token yang dipakai untuk setiap kueri
    Saya bertanya siapa yang membayar biaya token itu, dan dijawab bahwa itu sudah termasuk dalam lisensi; lalu saya bertanya apakah ada batas anggaran atau tidak terbatas, dan mereka bilang itu pertanyaan bagus dan akan dicek
    Alasan saya bertanya adalah karena satu kueri sederhana terkait perangkat yang baru saja ditunjukkan itu telah membakar 250 ribu token
    Saat itu saya mendengar salah satu eksekutif dari pihak mereka berkata keras-keras, “Kenapa kita menunjukkan ini ke pelanggan?” dan kami tertawa cukup keras
    Pelajaran yang saya ambil adalah biaya menambahkan AI ke apa pun belum benar-benar diperhitungkan, dan biaya nyata untuk menjalankan AI terlebih lagi tidak tercermin
    Apa pun yang dipasangi AI akan menjadi lebih mahal, suka atau tidak

    • AIshittification

  • Tokenomics sebenarnya sudah merupakan istilah untuk menjelaskan ekonomi kripto, jadi meskipun token yang dipakai AI itu jenis yang berbeda, saya tidak paham kenapa harus repot-repot mendefinisikan ulang istilah itu

    • Tokenomics juga sudah lama dipakai di kalangan penggemar ganja
    • Ini cuma tren baru
      Lupakan tren lama; yang ini juga akan basi, jadi sebaiknya ikut sebelum terlambat
    • cryptocurrency economics = cryptonomics
    • “Crypto” juga sudah ada sebelum dunia kripto mengambil alih istilah itu
      “Web 3.0” juga sudah ada sebelum orang kripto menjadikan Web3 berpusat pada kripto
      Jadi saya tidak melihat masalahnya
      Istilah memang terus dipakai ulang dalam konteks yang berbeda
      Lagi pula kebanyakan orang sudah pindah dari kripto, jadi kecil kemungkinan menimbulkan kebingungan