Deploy dan Operasional
Target deploy berjalan di Huawei Cloud di Jakarta dengan node aplikasi FastAPI, node inferensi GPU, pencarian vektor PostgreSQL, OBS, Redis, Kafka, Langfuse, API gateway, dan isolasi jaringan.
- Platform cloud: Huawei Cloud
- Wilayah / availability zone: AP-Jakarta / General AZ
- Stack inti: Backend FastAPI, penyajian model vLLM self-hosted, pencarian vektor PostgreSQL, OBS, Redis, Kafka, dan layanan jaringan Huawei
Baseline pengadaan produksi
Tabel berikut menyalin 14 item baris dari lembar pengadaan Kebutuhan Spesifikasi Infrastruktur Platform AI yang disediakan. Purchase adalah durasi penagihan atau kuota penggunaan; Qty adalah jumlah sumber daya pada baris item tersebut. Semua baris menargetkan AP-Jakarta / General AZ.
| # | Layanan / tujuan | Penagihan / pembelian | Qty | Spesifikasi yang diperlukan | Penggunaan |
|---|---|---|---|---|---|
| 1 | GPU Nvidia A100 ECS GPU — inferensi LLM | Tahunan / 1 tahun | 1 | x86; 1x NVIDIA A100 (2×40 GB VRAM, 80 GB total); 16 vCPUs; 128 GiB | Kapasitas pengadaan untuk penalaran, perencanaan, dan sintesis jawaban LLM melalui vLLM. Profil yang dideploy menggunakan bobot FP8 resmi dari Qwen (ADR-0049) dan paralelisme tensor 2 pada device GPU 0 dan 1; spesifikasi wajib dipertahankan sebagai baseline pengadaan. |
| 2 | GPU Nvidia A30 ECS GPU — embedding, reranker, OCR | Tahunan / 1 tahun | 1 | x86; 1x NVIDIA A30 (1×24 GB VRAM); 24 vCPUs; 96 GiB | Menempatkan tiga model secara bersamaan: Qwen3-Embedding-8B (pembuatan vektor), bge-reranker-v2-m3 (pemeringkatan ulang hasil), dan PaddleOCR-VL (ekstraksi dokumen pindaian). |
| 3 | Elastic Volume Service 1 Penyimpanan blok GPU | Tahunan / 1 tahun | 4 | I/O ultra-tinggi; 1.000 GiB untuk GPU per volume | Penyimpanan SSD yang dapat dilampirkan untuk host GPU — unduhan bobot model, pertukaran KV cache, dan ruang kerja OCR. |
| 4 | Elastic Cloud Server Server aplikasi ECS | Tahunan / 1 tahun | 2 | x86; General computing-plus c9.xlarge.4; 4 vCPUs; 16 GiB; AlmaLinux 9.4 64-bit; 40 GB General Purpose SSD | Menjalankan backend FastAPI, orkestrator, dan worker ingesti di belakang load balancer. Dipasangkan (paired) untuk keperluan HA (high availability). |
| 5 | CCE+ECS+EVS+OBS PostgreSQL + vectorchord pada Percona (dikelola sendiri) | Tahunan / 1 tahun | 1 | PostgreSQL 17; Tunggal; Khusus; 8 vCPUs; 32 GB; 1.000 GB Extreme SSD; vectorchord | Penyimpanan data utama: vektor dokumen/chunk, pencarian leksikal full-text, riwayat percakapan, dan log audit. |
| 6 | Object Storage Service Penyimpanan objek OBS | Bayar sesuai penggunaan / 1 tahun | 1 | Standard; 20 TB; Penyimpanan objek Single-AZ; durasi penyimpanan 12 bulan | Menyimpan dokumen sumber mentah (PDF, DOCX, gambar), output ekstraksi OCR, dan artefak ingesti. Berfungsi sebagai korpus dokumen tahan lama yang mendukung index. |
| 7 | DCS (untuk Redis) Redis terkelola | Tahunan / 1 tahun | 1 | Basic; Redis 7.0; Master/Standby; x86; DRAM; 4 GB | Cache sesi, pembatasan laju API, kunci ingesti terdistribusi, dan pelacakan lag consumer Kafka. Master/Standby untuk failover. |
| 8 | DMS (untuk Kafka) Kafka terkelola | Tahunan / 1 tahun | 1 | kafka.2u4g.cluster.small; 3 broker; I/O ultra-tinggi; 600 GB total, 200 GB per broker | Pipeline ingesti async: distribusi event dokumen, antrean penulisan chunk, dan retry/backpressure untuk worker ingesti. |
| 9 | Reverse Proxy | Tahunan / 1 tahun | 1 | s7n.large.2; 2 vCPUs; 4 GiB; I/O tinggi; 40 GB | Menyediakan lapisan reverse proxy produksi di depan ingress aplikasi. |
| 10 | NAT Gateway | Tahunan / 1 tahun | 1 | Kecil | Akses internet keluar untuk layanan subnet privat — unduhan bobot model, pengiriman webhook, dan pembaruan dependensi. |
| 11 | Web Application Firewall | Bayar sesuai penggunaan / 8.766 jam | 1 | 10amounts; 1PCS; 200Million times | Melindungi endpoint API publik dari serangan OWASP-top-10, lalu lintas bot, dan penyalahgunaan volume. |
| 12 | Elastic IP | Bayar sesuai penggunaan / 8.766 jam | 2 | Dedicated Dynamic BGP; lalu lintas 15 TB per IP | IP publik statis untuk NAT gateway, APIG, ELB, dan endpoint egress WAF. |
| 13 | Log Tank Service | Tahunan / 1 tahun | 1 | 5 GB/hari; retensi 30 hari | Retensi terpusat untuk log layanan dan infrastruktur produksi. |
| 14 | Cloud Backup | Tahunan / 1 tahun | 4 | 1.000 GB per sumber daya backup | Kapasitas cadangan untuk data dan volume layanan produksi. |
Pemetaan arsitektur dan gerbang konfirmasi
Baseline pengadaan dan arsitektur aplikasi saling terkait, tetapi tidak dapat saling menggantikan. Selesaikan item-item berikut sebelum penerimaan produksi:
Redaksi pengadaan di atas menetapkan kapasitas A100, bukan topologi device yang dideploy. Profil penyajian produksi menjalankan Qwen3.8-27B dari checkpoint FP8 resmi (Qwen/Qwen3.8-27B-FP8, hanya bobot pada A100; ADR-0049) dengan paralelisme tensor 2 pada device GPU 0 dan 1 (lihat docker-compose.models.prod.inference.yml dan docs/deployment/model-serving-prod.md).
- Basis data produksi adalah PostgreSQL 17 yang dikelola sendiri dengan vectorchord pada Percona pada komponen komputasi dan penyimpanan CCE+ECS+EVS+OBS; spesifikasi pengadaan adalah Tunggal, Khusus, dengan 8 vCPUs, 32 GB, dan 1.000 GB Extreme SSD.
- Empat volume EVS menyediakan total kapasitas 4.000 GiB yang terpasang pada GPU, jika setiap persyaratan 1.000 GiB dialokasikan sebagaimana tertulis.
Jejak Staging (historis — staging sudah dihapus)
Historis. Host review-staging sudah dihapus (audit produksi firstmate 2026-10-07). Produksi melayani ref
2cc9a417di apps-0002 dengan frontend di https://rag-aceh-neo.reviewstagepro.com. Uraian di bawah menggambarkan box staging lama, bukan kondisi saat ini.
Lingkungan staging review saat ini adalah stack single-host sebagaimana dibangun, bukan topologi layanan terkelola produksi. Satu host GPU A30 menjalankan API, worker, layanan model, PostgreSQL/pgvector, MinIO, Redis, Kafka, dan Langfuse dalam container.
Lingkungan ini memvalidasi pipeline AI lengkap:
LLM → embedding → vector search → rerank → OCR
Lingkungan ini ditujukan untuk dataset sampel dan validasi fungsional, bukan untuk ketersediaan atau konkurensi produksi.
| # | Komponen | Deploy staging saat ini | Perbedaan dari produksi |
|---|---|---|---|
| 1 | Host GPU ECS | A30 24 GB; semua container staging berjalan di host ini | Produksi memisahkan tier aplikasi dan GPU |
| 2 | API dan worker | FastAPI dan worker ingesti; API terikat ke loopback :8000 | Produksi menggunakan dua node aplikasi di belakang ELB/APIG |
| 3 | Layanan AI | Qwen3-14B, BGE-M3, bge-reranker-v2-m3, dan PaddleOCR-VL | Produksi menggunakan alokasi model produksi yang disetujui |
| 4 | PostgreSQL + pgvector | Container di host | Produksi menggunakan PostgreSQL 17 yang dikelola sendiri dengan vectorchord pada Percona pada komponen komputasi dan penyimpanan CCE+ECS+EVS+OBS |
| 5 | Penyimpanan objek | MinIO di host | Produksi menggunakan OBS |
| 6 | Redis | Container di host | Produksi menggunakan DCS Redis HA |
| 7 | Kafka | Container di host | Produksi menggunakan DMS Kafka |
| 8 | Observabilitas | Stack Langfuse di host | Produksi mengisolasi dan mengukur layanan observabilitas |
| 9 | Ingress HTTPS | Caddy pada :443 publik, meneruskan ke loopback :8000 | Produksi menggunakan APIG dan ELB |
Ingress HTTPS Staging (historis — sudah dihapus)
API review dapat diakses di: (host sudah dihapus — audit produksi firstmate 2026-10-07; API produksi di https://rag-aceh-ai-eng-neo.reviewstagepro.com; frontend dan Studio di https://rag-aceh-neo.reviewstagepro.com)
https://rag-aceh-ai-eng.reviewstagepro.com
Ingress mengakhiri (terminate) TLS dan meneruskan permintaan ke layanan FastAPI yang hanya dapat diakses melalui loopback. Port 80, API internal :8000, port model :8001–:8004, dan semua port layanan data tetap tertutup secara eksternal.
Setiap rute data masih memerlukan X-API-Key. /healthz, /readyz, /openapi.json, dan UI non-produksi /docs tetap tidak terotentikasi untuk discovery dan probe orkestrasi. Aplikasi browser harus menggunakan BFF atau gateway dan tidak boleh menerima kunci bersama.
Staging tidak menggunakan ELB atau APIG. Ini dapat diterima untuk lalu lintas review, tetapi menciptakan batas kegagalan single-host dan belum menyediakan pembatasan laju gateway. Topologi produksi di atas tetap menjadi target.
Alokasi GPU Staging
| Komponen | Profil penyajian | Anggaran proses |
|---|---|---|
| Qwen3-14B-AWQ LLM | INT4, vLLM, konteks 4k | ~12 GB |
| Embedding BGE-M3 | FP16, TEI | ~2,8 GB |
| bge-reranker-v2-m3 | FP16, Infinity | ~1,5 GB |
| PaddleOCR-VL | BF16/FP16, backend vLLM | ~3 GB |
| Konteks CUDA | Empat proses GPU | ~1,5 GB |
| Total digunakan | Profil staging single-stream | ~18,8 / 24 GB |
GPU adalah dependensi staging yang paling kritis. Tanpa itu, tim tidak dapat memvalidasi inferensi LLM, embedding, reranking, atau OCR di bawah arsitektur yang di-deploy.
Jebakan operasional
- Teks OCR yang buruk harus disaring (gating) terlebih dahulu sebelum embedding untuk menghindari keracunan pencarian.
- Drift versi model OCR membuat skor confidence tidak dapat dibandingkan, kecuali versi dan kalibrasi dilakukan ulang.
- Penulisan vektor secara bersamaan (konkuren) memerlukan serialisasi atau keamanan transaksional.
- Overflow context window harus gagal atau memotong secara eksplisit, tidak boleh memotong secara diam-diam.
- Dokumen merupakan input yang tidak tepercaya, sehingga kebersihan prompt dan pengaman kebijakan (policy guard) bersifat wajib.