Bahagian 2: Menskalakan Inferens Terjemahan: +82% Throughput

​

Penulis

​

Rekap: Masalah

• Overhead serialisasi baris gilir
• Pertembungan pengiraan GPU antara proses pekerja
• Corak penggunaan GPU tersentak

​

Percubaan 2: Batching Statik

​

Pelaksanaan

# Dalam proses pekerja
MAX_BATCH_SIZE = 16
BATCH_TIMEOUT = 0.05  # 50ms

while True:
    batch_keys = []
    batch_tasks = []

    # Kumpul tugas pertama (menyekat)
    first_key = queue.get()
    batch_keys.append(first_key)
    batch_tasks.append(tasks[first_key])

    # Cuba kumpul lebih banyak tugas (tidak menyekat dengan timeout)
    batch_start = time.time()
    while len(batch_keys) < MAX_BATCH_SIZE:
        time_remaining = BATCH_TIMEOUT - (time.time() - batch_start)
        if time_remaining <= 0:
            break
        try:
            key = queue.get(timeout=time_remaining)
            batch_keys.append(key)
            batch_tasks.append(tasks[key])
        except Empty:
            break

    # Proses batch menggunakan vLLM
    results = translation_provider.translate_batch(
        texts=[t.text for t in batch_tasks],
        source_langs=[t.source_lang for t in batch_tasks],
        target_langs=[t.target_lang for t in batch_tasks]
    )

• Saiz batch: 16 permintaan
• Timeout: 50ms (jangan tunggu tanpa had untuk batch penuh)
• vLLM memproses berbilang urutan bersama-sama
• Masih menggunakan pekerja multiprocessing

​

Keputusan

Rajah 1: Batching statik memberikan peningkatan throughput dan masa respons yang ketara

​

Pertukaran

• Peningkatan throughput besar
• GPU digunakan dengan lebih baik
• Pelaksanaan mudah

• Penyekatan head-of-line: Semua permintaan menunggu yang paling perlahan
• Dengan input panjang berubah-ubah, terjemahan pendek menunggu yang panjang
• Contoh: [50 token, 50 token, 200 token] - dua pertama menunggu terjemahan 200-token

​

Percubaan 3: Continuous Batching

​

Apakah Continuous Batching?

• Permintaan baharu menyertai pertengahan penjanaan
• Permintaan selesai keluar segera (tidak menunggu yang lain)
• Komposisi batch dikemas kini setiap token
• AsyncLLMEngine vLLM mengendalikan ini secara automatik

​

Pelaksanaan

from vllm import AsyncLLMEngine, EngineArgs

engine_args = EngineArgs(
    model=model_id,
    max_num_seqs=64,  # Percubaan awal
    max_num_batched_tokens=16384,
    gpu_memory_utilization=0.3,
    enable_chunked_prefill=True,
)

engine = AsyncLLMEngine.from_engine_args(engine_args)

@app.post("/translate")
async def translate(request: TranslateRequest):
    result_generator = engine.generate(
        request.text,
        sampling_params,
        request_id=generate_id()
    )

    async for output in result_generator:
        final_output = output
    return TranslateResponse(translation=final_output.text)

• AsyncLLMEngine digunakan terus dalam FastAPI
• vLLM mengendalikan batching secara dalaman melalui enjin continuous batching
• Async/await tulen sepanjang masa

​

Semakan Realiti Ujian

​

Keputusan Awal (Input Seragam)

Rajah 2: Continuous batching dengan input seragam menunjukkan throughput 15 RPS yang mengagumkan

​

Input Panjang Berubah-ubah (Realiti)

• Beban sangat berat: 1.1 RPS (vs 2.2 RPS dengan seragam)
• Malah garis dasar berprestasi lebih teruk dengan data realistik

• Beban sangat berat: 3.5 RPS (dengan penalaan max_num_seqs=16)
• Konfigurasi yang sama yang memberikan kami 15 RPS dengan input seragam

Rajah 3: Jurang prestasi antara data ujian seragam dan input panjang berubah-ubah realistik

​

Penalaan Konfigurasi

​

Apa Yang Kami Temui

# Metrik Prometheus vLLM yang kami pantau:
# - vllm:time_to_first_token_seconds (TTFT)
# - vllm:time_per_output_token_seconds (masa decode)
# - vllm:gpu_cache_usage_perc (penggunaan cache KV)
# - vllm:num_requests_running / waiting (kedalaman baris gilir)

• Beban kerja sebenar: 2-20 permintaan serentak setiap pelayan (puncak pengeluaran ~20 setiap pelayan)
• Konfigurasi: max_num_seqs=64
• Keputusan: 60+ slot kosong mewujudkan overhead

• Cache KV dipra-peruntukkan untuk 64 urutan
• Penjadual vLLM menguruskan 64 slot tetapi hanya menggunakan 5-10
• Masa decode setiap token meningkat
• Memori terbuang pada slot urutan yang tidak digunakan
• Overhead penjadual untuk slot kosong

​

Pendekatan Penalaan

1. Ukur taburan permintaan serentak sebenar dalam pengeluaran
2. Mulakan dengan max_num_seqs=1, tingkatkan secara beransur-ansur: 2 -> 4 -> 8 -> 16 -> 32
3. Pantau masa decode dan latensi ekor pada setiap langkah
4. Berhenti apabila prestasi merosot

​

Konfigurasi Akhir

from translation_lib.config import AsyncVLLMTranslationProvider

provider = AsyncVLLMTranslationProvider(
    model_name=model_id,
    revision=model_revision,
    gpu_memory_utilization=0.3,  # ~10GB pada RTX 5090
    max_num_seqs=16,  # Bersaiz betul kepada beban kerja sebenar setiap pelayan
    huggingface_token=hf_token,
    supported_language_pairs=None,  # Model berbilang bahasa
)

await provider.initialize_engine()

​

Rasional Konfigurasi

• Puncak pengeluaran: ~20 permintaan serentak setiap pelayan
• Ujian: Disahkan sehingga 25 serentak
• Menyediakan ruang kepala tanpa membazir sumber
• Overhead penjadual sepadan dengan beban sebenar

• Dikurangkan dari lalai 16384
• Lebih sesuai untuk panjang urutan purata kami
• Mengurangkan tekanan memori

• Memperuntukkan ~10GB VRAM untuk model + cache KV pada RTX 5090 (32GB)
• Dijejak melalui vllm:gpu_cache_usage_perc
• Seimbang untuk konfigurasi kami

Rajah 4: Kemajuan throughput melalui semua percubaan pengoptimuman

​

Keputusan Pengeluaran

​

Sebelum vs Selepas

Rajah 5: Keputusan penggunaan pengeluaran menunjukkan peningkatan throughput 82%

Rajah 6: Peningkatan latensi P95 merentasi percubaan pengoptimuman

Rajah 7: Evolusi masa respons dengan input panjang berubah-ubah

​

Ringkasan

​

Apa Yang Berkesan

• AsyncLLMEngine mengendalikan batching secara automatik
• Tiada overhead pengumpulan batch manual
• Integrasi async/await langsung dengan FastAPI

• max_num_seqs=16 (sepadan dengan beban kerja sebenar setiap pelayan)
• Bukan 64 (maksimum teori yang mewujudkan overhead)
• gpu_memory_utilization=0.3 untuk peruntukan 10GB

• Input panjang berubah-ubah mendedahkan isu konfigurasi
• Data ujian seragam memberikan 15 RPS yang mengelirukan

• Penggunaan cache KV
• Masa decode setiap token
• Kedalaman baris gilir
• Membimbing keputusan konfigurasi

​

Perjalanan Lengkap