google/pegasus-xsum adalah checkpoint untuk summarization, bukan utilitas teks berukuran kecil. Latensinya mengikuti pekerjaan yang memang dilakukan Transformer encoder-decoder besar: sumber harus di-encode terlebih dahulu, lalu decoder dijalankan berulang kali sampai ringkasan selesai. Di CPU, fase kedua biasanya membuat output yang pendek terasa jauh lebih mahal daripada yang diperkirakan.

Paper PEGASUS menjelaskan Transformer encoder-decoder yang di-pretrain dengan Gap Sentences Generation dan melaporkan model terbaik berukuran 568 juta parameter. Checkpoint XSum kemudian di-fine-tune untuk abstractive summarization pada satu dokumen. Kombinasi ini berguna ketika kualitas ringkasan menjadi prioritas, tetapi pekerjaan inferensinya jelas lebih besar daripada sekadar mengambil beberapa kalimat sumber atau menjalankan classifier kecil.

Pertanyaan performa yang berguna bukan hanya apakah PEGASUS “besar”. Yang perlu diketahui adalah bagian mana yang menghabiskan waktu, konfigurasi apa yang memperbanyak pekerjaan tersebut, dan optimasi mana yang masih mempertahankan perilaku yang dibutuhkan aplikasi.

Summarization memiliki fase encode dan generate

Untuk input sepanjang (N) token, encoder membentuk representasi kontekstual dari sumber. Pekerjaan ini dilakukan sekali per request. Gambaran sederhananya:

source text
    |
tokenizer
    |
N source tokens
    |
encoder
    |
source representations
    |
decoder step 1 -> token 1
decoder step 2 -> token 2
decoder step 3 -> token 3
...
decoder step T -> token T

Decoder bekerja secara autoregresif. Jika ringkasan menghasilkan (T) token, generasi memerlukan rangkaian langkah decoder, bukan satu forward pass yang langsung mengeluarkan seluruh ringkasan.

Caching mencegah setiap langkah decoder menghitung ulang seluruh key-value state dari token output sebelumnya, tetapi caching tidak menghapus pekerjaan forward yang berulang. Setiap token baru tetap membutuhkan evaluasi distribusi next-token dan attention terhadap hasil encode sumber.

Di sinilah latensi sering terasa tidak proporsional: ringkasan 60 token bukan satu operasi output. Setelah sumber selesai di-encode, masih ada sekitar 60 keputusan generasi yang berjalan secara berurutan.

Panjang sumber memengaruhi encoder dan cross-attention

Teks sumber yang lebih panjang menambah pekerjaan awal encoder. Self-attention pada Transformer konvensional juga semakin mahal ketika sequence memanjang karena posisi-posisi di dalam sequence saling berinteraksi.

Dampaknya tidak berhenti setelah encoding selesai. Layer decoder memakai cross-attention terhadap output encoder. Sumber yang panjang berarti decoder memiliki encoded memory yang lebih besar untuk diperhatikan saat menghasilkan setiap token.

Karena itu, membatasi panjang sumber merupakan salah satu kontrol latensi yang paling langsung. Namun trade-off-nya bersifat semantik, bukan hanya komputasional: truncation dapat membuang informasi yang seharusnya masuk ke ringkasan.

Untuk dokumen panjang, mengambil sejumlah token pertama secara membabi buta biasanya bukan kebijakan produksi yang baik. Arsitektur yang lebih tepat dapat memecah dokumen, memilih passage relevan, meringkas per chunk, atau memakai model yang memang dirancang untuk konteks lebih panjang. Setiap pendekatan mengubah profil kualitas dan latensi sehingga perlu diuji terhadap distribusi dokumen sebenarnya.

Beam search dapat memperbanyak pekerjaan decoder

Decoding policy hampir sama pentingnya dengan ukuran model.

Greedy decoding hanya mempertahankan satu sequence kandidat pada setiap langkah:

num_beams = 1

step 1 -> one candidate
step 2 -> one candidate
step 3 -> one candidate

Beam search mempertahankan beberapa kandidat sekaligus:

num_beams = 4

step 1 -> four candidates
step 2 -> four candidates
step 3 -> four candidates
...

Kenaikan runtime tidak bisa dianggap tepat empat kali lipat karena batching, memory bandwidth, kernel, pengelolaan cache, dan utilisasi hardware ikut menentukan. Namun beam width yang lebih besar tetap menambah pekerjaan decoder dan lalu lintas memori. Di CPU, perbedaannya dapat terasa besar.

Jika latensi lebih penting daripada peningkatan kualitas dari beam search, num_beams=1 layak menjadi konfigurasi pertama yang di-benchmark. Jika greedy decoding menurunkan kualitas terlalu jauh, num_beams=2 dapat menjadi titik tengah. Pilihan ini sebaiknya ditentukan dari pengukuran pada teks representatif, bukan sekadar mengikuti default dari contoh kode.

Panjang output adalah anggaran latensi

Karena generasi bersifat autoregresif, max_new_tokens sekaligus menjadi batas komputasi.

Request yang diizinkan menghasilkan 160 token mempunyai worst-case decoder budget jauh lebih besar daripada request yang dibatasi 60 token. Memberi batas maksimum sangat besar “untuk berjaga-jaga” membuat tail latency lebih sulit dikendalikan, terutama ketika stopping behavior berbeda antar dokumen.

Untuk output ringkas bergaya XSum, batas output yang ketat biasanya lebih selaras dengan tujuan checkpoint daripada membiarkan generasi berkembang menjadi beberapa paragraf.

Konfigurasi awal yang berorientasi pada latensi dapat berbentuk:

from transformers import AutoModelForSeq2SeqLM, AutoTokenizer

model_id = "google/pegasus-xsum"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForSeq2SeqLM.from_pretrained(model_id)
model.eval()

inputs = tokenizer(
    text,
    return_tensors="pt",
    truncation=True,
    max_length=512,
)

summary_ids = model.generate(
    **inputs,
    num_beams=1,
    max_new_tokens=64,
)

summary = tokenizer.decode(
    summary_ids[0],
    skip_special_tokens=True,
)

Angka tersebut adalah pilihan operasional, bukan nilai optimum universal. Batas sumber 512 token bisa tidak cocok untuk dokumen yang fakta pentingnya muncul di bagian akhir, sedangkan 64 token output mungkin terlalu pendek untuk produk lain. Manfaat utama batas tersebut adalah membuat anggaran latensi menjadi eksplisit.

Eksekusi CPU memperlihatkan biaya model secara penuh

GPU dapat menjalankan operasi matriks padat di balik inferensi Transformer dengan parallel throughput yang jauh lebih tinggi daripada CPU general-purpose pada umumnya. Inferensi CPU tetap masuk akal untuk request rate rendah, lingkungan tanpa accelerator, pekerjaan offline, atau deployment yang lebih mengutamakan kesederhanaan operasional daripada latensi.

Namun memindahkan PEGASUS-XSum ke CPU tidak membuat arsitekturnya mengecil. Encoder, decoder, attention layer, dan seluruh weight model tetap harus diproses.

Perbedaan ini penting ketika PEGASUS dibandingkan dengan general-purpose model yang jauh lebih kecil. Decoder-only model kecil dapat memiliki parameter lebih sedikit dan langkah inferensi yang lebih murah walaupun tidak dilatih secara khusus untuk summarization. PEGASUS-XSum dapat lebih tepat secara spesialisasi tugas tetapi tetap kalah jauh pada latensi.

Pemilihan model sebaiknya memisahkan dua pertanyaan:

Apakah kualitas dan gaya ringkasannya sesuai kebutuhan?
Apakah hardware deployment dapat mencapainya dalam latency budget?

Sebuah model dapat lolos pertanyaan pertama dan gagal pada pertanyaan kedua.

Ukur tokenization dan generation secara terpisah

Timer end-to-end hanya menunjukkan bahwa inferensi lambat. Angka itu belum menunjukkan apa yang harus diubah.

Untuk pekerjaan performa, pisahkan setidaknya waktu tokenization dan generation, lalu catat jumlah token input dan output. Pada GPU, device perlu disinkronkan di sekitar batas pengukuran karena eksekusi asynchronous dapat membuat hasil timing menyesatkan.

Benchmark CPU minimal dapat mencatat:

from time import perf_counter

t0 = perf_counter()
inputs = tokenizer(
    text,
    return_tensors="pt",
    truncation=True,
    max_length=512,
)
t1 = perf_counter()

with torch.inference_mode():
    summary_ids = model.generate(
        **inputs,
        num_beams=1,
        max_new_tokens=64,
    )
t2 = perf_counter()

print({
    "input_tokens": inputs["input_ids"].shape[-1],
    "output_tokens": summary_ids.shape[-1],
    "tokenization_s": t1 - t0,
    "generation_s": t2 - t1,
})

Jalankan corpus yang sama dengan beam width 1, 2, dan 4. Ulangi pada input pendek, sedang, dan panjang. Dari sini akan terlihat apakah bottleneck mengikuti panjang sumber, jumlah token yang dihasilkan, decoding policy, atau kombinasi ketiganya.

Warm-up juga perlu diperhitungkan. Inferensi pertama dapat membawa biaya satu kali yang tidak mewakili request steady-state. Jika startup penting bagi aplikasi, laporkan cold latency dan warm latency secara terpisah.

Batch throughput berbeda dari latensi satu request

Batching beberapa dokumen dapat meningkatkan utilisasi hardware, terutama pada accelerator. Itu tidak otomatis membuat satu dokumen selesai lebih cepat.

Service untuk throughput offline dapat sengaja menunggu beberapa request agar membentuk batch. API interaktif biasanya lebih peduli pada latensi per request dan tail latency. Deployment PEGASUS-XSum yang sama dapat membutuhkan ukuran batch berbeda tergantung metrik mana yang menjadi batas utama.

Dokumen dengan panjang bervariasi juga menimbulkan padding overhead. Mengelompokkan input dengan panjang serupa dapat mengurangi pekerjaan yang terbuang pada pipeline berbasis batch.

Precision dan runtime teroptimasi berguna setelah decoding dibatasi

Reduced precision, quantization, graph compilation, runtime berbasis ONNX, dan kernel khusus hardware dapat meningkatkan efisiensi inferensi. Besarnya peningkatan bergantung pada hardware dan dukungan operator, dan beberapa teknik dapat mengubah perilaku numerik.

Optimasi tersebut lebih berguna setelah biaya generasi yang jelas sudah dikendalikan. Melakukan quantization sambil mempertahankan beam width yang tidak perlu besar dan batas generasi yang longgar dapat berarti mengoptimalkan lapisan masalah yang salah.

Urutan praktisnya:

1. ukur request yang representatif
2. batasi panjang sumber dan output dengan sengaja
3. benchmark greedy versus beam decoding
4. pilih CPU atau accelerator berdasarkan target latensi
5. baru evaluasi precision, quantization, compilation, dan batching

Urutan ini membuat dampak setiap perubahan dapat diukur dan menjaga regresi kualitas tetap bisa dikaitkan dengan keputusan tertentu.

Modelnya mungkin memang terlalu besar untuk target latensi

Ada titik ketika tuning generate() bukan lagi jawaban yang tepat. Jika service berbasis CPU membutuhkan latensi rendah yang konsisten di bawah concurrency, encoder-decoder 568 juta parameter dapat menjadi pasangan yang buruk untuk kebutuhan tersebut meskipun beam sudah diatur dengan hati-hati.

Pada batas itu, mengganti model merupakan keputusan arsitektur. Model summarization yang lebih kecil, sequence-to-sequence model multibahasa, compact instruction model, atau pipeline extractive mungkin lebih sesuai. Masing-masing membawa failure mode berbeda: cakupan bahasa, factuality, gaya output, controllability, dan perilaku terhadap panjang dokumen perlu dievaluasi ulang.

PEGASUS-XSum lambat karena alasan yang dapat dijelaskan. Model ini meng-encode sumber dengan Transformer yang cukup besar lalu menjalankan decoder secara berurutan untuk setiap token output; beam search, sumber panjang, dan batas output yang longgar menambah pekerjaan di atas biaya dasar tersebut. Setelah komponen biaya diukur secara terpisah, pilihannya menjadi konkret: kurangi pekerjaan decoding, pindahkan ke hardware yang mampu menanganinya, atau gunakan model dengan arsitektur yang lebih sesuai dengan latency budget.

Referensi

  • Zhang, J., Zhao, Y., Saleh, M., dan Liu, P. J. “PEGASUS: Pre-training with Extracted Gap-sentences for Abstractive Summarization.” ICML 2020.
  • Hugging Face model card: google/pegasus-xsum.
Kecerdasan Buatan Peringkasan PEGASUS Inferensi Performa