Mengapa IBM beralih ke agen
Klien korporat jarang membeli model demi demo yang cantik. Mereka butuh perangkat lunak yang benar-benar melakukan sesuatu: memproses tiket, mencocokkan faktur, memanggil API internal, menulis ringkasan dokumen. Justru inilah ceruk yang diisi oleh logika agen — ketika model tidak sekadar menjawab pertanyaan, tetapi memutuskan sendiri alat mana yang harus dipanggil berikutnya.
Granite 4.2 dalam kisah ini bukanlah "sekadar model besar lainnya", melainkan upaya IBM melengkapi lini produknya agar dapat bekerja dengan sama percaya diri baik di cloud maupun di lingkungan tertutup milik pelanggan. Taruhannya ada pada kombinasi tiga hal: bobot terbuka, kebutuhan perangkat keras yang sederhana, dan perilaku yang dapat diprediksi saat memanggil fungsi eksternal.
Apa sebenarnya lini Granite itu
IBM sudah lama mengelola keluarga model terbuka dengan nama Granite. Seiring waktu, terbentuklah filosofi yang mudah dikenali: model dirilis dalam beberapa ukuran, berorientasi terutama pada kode, pengolahan tabel, ekstraksi data dari dokumen, dan skenario korporat, bukan pada persaingan di benchmark obrolan umum.
Ukuran itu penting
Lini ini dibangun seperti tangga — dari varian yang sangat kecil yang muat di satu kartu grafis atau bahkan berjalan di prosesor, hingga model kelas menengah. Intinya adalah agar setiap tugas dapat ditangani dengan ukuran yang paling minimal namun memadai. Untuk agen yang terutama merutekan permintaan dan memanggil fungsi, model raksasa sering kali berlebihan: lebih mahal dalam inference dan lebih lambat merespons.
Arsitektur hibrida
Pada cabang keempat keluarga ini, IBM beralih ke skema hibrida, di mana sebagian lapisan dibangun dengan Mamba dan sebagian lagi dengan attention transformer klasik. Keuntungan praktisnya cukup membumi: konteks panjang diproses lebih murah, memori lebih hemat, dan throughput pada perangkat keras yang sama lebih tinggi. Untuk skenario agen, ini krusial karena konteks terus-menerus diisi dengan hasil pemanggilan alat, potongan dokumen, dan riwayat langkah.
Lisensi tanpa kejutan
Model Granite didistribusikan di bawah lisensi Apache 2.0. Bagi ahli hukum korporat ini berita yang membosankan, dan justru itulah kabar baiknya: Anda dapat melakukan fine-tuning, menyematkannya ke dalam produk komersial, men-deploy-nya di dalam perimeter, dan tidak perlu melaporkan kepada vendor berapa banyak keuntungan yang dihasilkan produk tersebut.
Argumen utama: ini bisa disimpan sendiri
API cloud nyaman tepat sampai data berada di bawah batasan regulasi. Bank, klinik, perusahaan industri, atau lembaga pemerintah sering kali secara fisik tidak dapat mengirim sebagian dokumen ke luar. Di sinilah pembicaraan tentang "perangkat keras sendiri" dimulai.
Apa yang sebenarnya dibutuhkan untuk menjalankan
Kuncinya di sini bukan akselerator terbaik, melainkan minimum yang wajar. Versi kecil Granite dapat dijalankan pada satu kartu konsumen, dalam kontainer di server tanpa GPU, atau di laptop pengembang. Ukuran menengah sudah memerlukan beberapa kartu atau kuantisasi. Menjalankannya biasanya melalui alat standar seperti vLLM atau Ollama, yang menghilangkan masalah keterikatan pada stack eksklusif vendor.
Keamanan dan prediktabilitas
Lapisan kedua dari argumen ini adalah kontrol. Ketika model berada di dalam perimeter Anda, Anda sendiri yang menentukan log apa yang ditulis, data apa yang masuk ke prompt, apa yang di-cache, dan berapa lama disimpan. Untuk agen, ini sangat penting: mereka mampu melakukan tindakan, bukan hanya menghasilkan teks, dan setiap tindakan semacam itu sebaiknya melewati aturan dan audit Anda sendiri.
IBM di sini tidak hanya menjual model, tetapi juga perangkat pendukungnya: platform watsonx, kumpulan model "penjaga" untuk memfilter konten yang tidak diinginkan, dan alat fine-tuning pada data Anda sendiri. Model dalam skema seperti ini hanyalah detail, meskipun detail yang sentral.
Bagaimana skenario agen terlihat dalam praktik
Ide agen itu sederhana: model menerima tugas, memutuskan data apa yang kurang, memanggil alat yang diperlukan, membaca responsnya, dan melanjutkan hingga mencapai hasil. Perbedaan antara "sekadar obrolan" dan agen terletak pada adanya siklus dan hak akses.
Peran tipikal yang menjadi sasaran model semacam ini:
- Router. Menganalisis permintaan masuk dan memutuskan skenario mana yang harus menanganinya.
- Ekstraktor. Mengambil field dari faktur, kontrak, rekening, dan menyusunnya ke dalam struktur.
- Eksekutor. Memanggil API sistem internal: membuat permintaan, memperbarui status, mengirim email.
- Peninjau. Memeriksa hasil langkah sebelumnya dan memutuskan apakah hasil itu dapat diterima.
Model kecil pada setiap langkah ini sering kali lebih menguntungkan daripada satu model besar: lebih murah, lebih cepat, lebih mudah diuji, dan yang tak kalah penting, lebih mudah diganti jika kualitasnya tidak lagi memuaskan.
Apa yang perlu diperhatikan dan di mana batasannya
Model terbuka bukanlah pil ajaib, dan pembicaraan jujur tentang batasan lebih bermanfaat daripada pemasaran.
Ukuran versus kualitas penalaran
Model kecil hemat, tetapi pada tugas bertahap yang kompleks masih kalah dari model besar. Kompromi biasanya dicari secara arsitektural: membagi peran di antara beberapa model kecil, menambahkan pemeriksaan deterministik pada kode, dan menyisakan hak keputusan akhir bagi manusia.
Ekosistem di sekitarnya
Bobot terbuka berarti model mudah dipindahkan antar-framework — dari LangChain hingga orkestrator buatan sendiri. Sisi lainnya: solusi "siap pakai" untuk industri tertentu lebih sedikit dibandingkan platform proprietary, dan sebagian pekerjaan integrasi menjadi tanggung jawab tim pelanggan.
Perangkat keras dan biaya kepemilikan
Perangkat keras sendiri bukan hanya penghematan biaya API, tetapi juga belanja modal, listrik, pendinginan, dan orang-orang yang merawat semuanya. Untuk perusahaan kecil, cloud hampir selalu lebih murah; untuk perusahaan besar dengan data sensitif — sebaliknya, dan ambang ini bergeser tergantung pada volume.
Penilaian kualitas
Jebakan utamanya adalah mengukur agen dengan benchmark umum. Agen yang berfungsi diuji pada skenarionya sendiri: kumpulan tugas nyata dengan jawaban benar yang diketahui, ketahanan terhadap data masukan yang buruk, dan perilaku ketika alat yang dipanggil mengembalikan kesalahan. Tanpa kumpulan seperti itu, angka apa pun dari catatan rilis tetap hanya angka dari catatan rilis.
Apa yang bisa disimpulkan
Reaksi IBM terhadap kondisi pasar saat ini tampak logis. Sementara sebagian pihak mengejar kualitas puncak di cloud, pihak lain mengisi ceruk di mana kontrol, harga per token, dan kemampuan men-deploy semuanya di dalam perimeter lebih penting. Bobot terbuka plus kebutuhan sumber daya yang sederhana plus penekanan pada pemanggilan alat — itulah kombinasi yang dibutuhkan klien korporat yang lelah mengurus persetujuan pengiriman data ke luar.
Pertanyaan kuncinya bukanlah apakah versi baru ini akan melampaui para pemimpin dalam uji umum. Pertanyaannya adalah apakah tim memiliki disiplin untuk membangun kontur agen yang layak di sekitar model: dengan hak akses terbatas, audit, pengujian, dan rollback yang jelas. Jika ya — menyimpan agen semacam itu di perangkat keras sendiri menjadi strategi yang sepenuhnya masuk akal, bukan sebuah kompromi.
