Arsitektur Audio Chunking: Serverless vs Dedicated Worker

Aplikasi pembelajaran bahasa berbasis audio seperti flashcard kalimat dan teknik shadowing membutuhkan latensi pemrosesan rendah dan akurasi segmentasi tinggi. File audio berdurasi panjang harus dipecah menjadi potongan-potongan kecil (chunking) berdasarkan deteksi hening (voice activity detection atau VAD) sebelum ditranskripsi oleh model speech-to-text seperti Whisper. Mengimplementasikan pipeline ini menimbulkan pertanyaan arsitektural mendasar: menjalankan pemrosesan menggunakan platform serverless berbasis event (seperti AWS Lambda dan S3) atau menggunakan armada dedicated worker VM yang dilengkapi GPU/CPU teroptimasi.

Alur Data Pipeline Pemrosesan Audio

Baik serverless maupun dedicated worker mengikuti siklus hidup data ingestion yang serupa. Perbedaan utama terletak pada lokasi eksekusi komputasi beratnya.

Client (Web/Mobile)
   │
   ▼
[Object Storage: S3 / GCS] ──(Event Notification)──► [Queue: SQS / RabbitMQ]
                                                          │
             ┌────────────────────────────────────────────┴───────────────────────────────────────────┐
             ▼                                                                                        ▼
   [Serverless Pipeline]                                                                    [Dedicated Worker VM]
   1. Lambda download audio chunk                                                           1. Worker pull task dari queue
   2. FFmpeg slicing (silence detection)                                                    2. FFmpeg streaming read & slice
   3. Whisper API call / Lambda container Whisper.cpp                                      3. Local faster-whisper (GPU/vCPU)
   4. Tulis metadata ke DB, simpan potongan ke S3                                           4. Batch write metadata ke DB & S3

Tahap pertama melibatkan pemotongan audio menggunakan FFmpeg berdasarkan ambang batas volume suara, dilanjutkan dengan pembuatan timestamped transcript per segmen kalimat untuk sinkronisasi antarmuka pengguna.

Pendekatan 1: Serverless (AWS Lambda + S3)

Pada arsitektur serverless, setiap upload ke Amazon S3 memicu event ke AWS Lambda secara langsung atau melalui Amazon SQS. Lambda mengeksekusi biner FFmpeg yang dibundel di dalam Lambda Layer atau OCI container image.

Implementasi Pemotongan Audio pada AWS Lambda

Berikut implementasi handler Python minimal menggunakan FFmpeg terkompilasi statis untuk memecah audio berdasarkan deteksi hening:

import subprocess
import json
import boto3
import os

s3_client = boto3.client('s3')

def lambda_handler(event, context):
    # ponytail: implementasi dasar tanpa chunk overlap handling, upgrade saat segment drift terdeteksi
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    input_path = f"/tmp/{os.path.basename(key)}"
    output_pattern = "/tmp/chunk_%03d.mp3"
    
    s3_client.download_file(bucket, key, input_path)
    
    # Segmentasi audio pada jeda hening minimal 0.5s di bawah -30dB
    ffmpeg_cmd = [
        "ffmpeg", "-y", "-i", input_path,
        "-f", "segment",
        "-segment_time", "3",
        "-reset_timestamps", "1",
        output_pattern
    ]
    
    result = subprocess.run(ffmpeg_cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    if result.returncode != 0:
        raise RuntimeError(f"FFmpeg error: {result.stderr.decode('utf-8')}")
        
    generated_files = [f for f in os.listdir('/tmp') if f.startswith('chunk_')]
    for file_name in generated_files:
        s3_client.upload_file(f"/tmp/{file_name}", bucket, f"processed/{file_name}")
        os.remove(f"/tmp/{file_name}")
        
    os.remove(input_path)
    return {"status": "complete", "chunks_count": len(generated_files)}

Kelemahan dan Batasan Serverless

• Cold Start: Container image yang memuat model ML dan dependensi audio sering berukuran di atas 1 GB, memicu latensi inisialisasi awal 3-10 detik.
• Batas Durasi Eksekusi: Batas eksekusi maksimal 15 menit pada AWS Lambda berisiko gagal saat memproses file podcast berdurasi di atas 1-2 jam jika transkripsi berjalan paralel di runtime yang sama.
• Keterbatasan Akselerasi Grafis: AWS Lambda belum menyediakan native GPU execution untuk akselerasi inferensi model Whisper berukuran sedang hingga besar (base/small/medium).

Pendekatan 2: Dedicated Worker VM (FFmpeg + Whisper Self-Hosted)

Pendekatan ini menggunakan VM persisten (misal: AWS EC2 g4dn.xlarge dengan GPU NVIDIA T4 atau c6i.2xlarge dengan CPU AVX-512) yang terus memantau antrean task (seperti Redis Streams atau RabbitMQ). Worker menggunakan library teroptimasi seperti faster-whisper (berbasis CTranslate2).

Worker Consumer Implementation

import os
import pika
import json
from faster_whisper import WhisperModel

# Inisialisasi model satu kali saat worker booting
model = WhisperModel("small", device="cuda", compute_type="float16")

def process_audio(ch, method, properties, body):
    data = json.loads(body)
    file_path = data["file_path"]
    
    # Transkripsi langsung dengan VAD filter bawaan untuk auto-chunking
    segments, _ = model.transcribe(
        file_path,
        beam_size=5,
        vad_filter=True,
        vad_parameters=dict(min_silence_duration_ms=500)
    )
    
    results = [{"start": s.start, "end": s.end, "text": s.text} for s in segments]
    
    # Simpan hasil segmentasi dan teks
    print(f"Processed {len(results)} chunks for {file_path}")
    ch.basic_ack(delivery_tag=method.delivery_tag)

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.basic_qos(prefetch_count=1)
channel.basic_consume(queue='audio_tasks', on_message_callback=process_audio)
channel.start_consuming()

Analisis Perbandingan Mendalam

1. Throughput dan Concurrency

Serverless unggul dalam menangani lonjakan beban mendadak (burst traffic). Seribu pengguna yang mengunggah audio secara bersamaan dapat memicu 1.000 instans Lambda secara paralel. Sebaliknya, dedicated worker memerlukan konfigurasi Auto Scaling Group (ASG) berbasis metrik antrean SQS/RabbitMQ yang membutuhkan waktu penyediaan VM baru sekitar 2 hingga 5 menit.

2. Biaya Data Egress dan Network I/O

Pada arsitektur serverless, data audio bergerak bolak-balik antara S3 dan container runtime Lambda. Jika Lambda memanggil third-party API (seperti OpenAI Whisper API) untuk proses transkripsi, terdapat biaya data egress publik. Pada dedicated worker dalam satu Virtual Private Cloud (VPC) dengan S3 Gateway Endpoint, biaya transfer data internal adalah nol.

Estimasi Biaya Operasional per 1.000 Jam Audio

Asumsi: 1.000 jam audio = 60.000 audio berdurasi 1 menit (~1 MB per file, total 60 GB data). Rasio pemrosesan audio terhadap waktu riil (Real-Time Factor / RTF) dianggap 0.2x untuk GPU dan 0.5x untuk Lambda CPU berdaya tinggi.

Catatan: Biaya dedicated worker bersifat flat. Jika beban kerja di bawah 200 jam per bulan, model serverless lebih hemat karena dedicated worker menghasilkan biaya saat idle (menganggur).

Panduan Keputusan Arsitektur

Pilih arsitektur berdasarkan fase produk dan volume komputasi:

1. Gunakan Serverless (AWS Lambda + Managed STT API) jika: Beban kerja bersifat fluktuatif atau belum stabil (< 300 jam audio per bulan), tim berfokus penuh pada validasi produk, dan Anda ingin meminimalkan beban pemeliharaan infrastruktur Linux/GPU patching.
2. Gunakan Dedicated Worker VM (Self-hosted GPU + faster-whisper) jika: Volume traffic harian konsisten atau tinggi (> 1.000 jam per bulan), aplikasi membutuhkan latensi inferensi sub-detik untuk live shadowing feedback, dan Anda memiliki kapabilitas untuk mengelola container orchestration (misal via Nomad atau Kubernetes KEDA).