Panduan pengguna LLM dengan bobot terbuka di GDC dengan air gap

Panduan deployment ini memberikan petunjuk mendetail tentang cara menjalankan Model Bahasa Besar (LLM) canggih menggunakan software open source (OSS) di lingkungan air-gapped Google Distributed Cloud (GDC). Khususnya, panduan ini menyajikan semua langkah yang diperlukan untuk menjalankan rilis terbaru model Gemma, DeepSeek , dan Llama, sekaligus memperkenalkan prosedur umum untuk menyajikan LLM lain yang tersedia secara publik. Kami akan memanfaatkan backend penayangan yang di-container, seperti vLLM dan Ollama, yang mencakup berbagai fungsi, tingkat konfigurasi, dan kemudahan deployment.

Ringkasan konten

Panduan ini menjelaskan deployment dan pengoperasian Model Bahasa Besar (LLM) open source di lingkungan air-gapped Google Distributed Cloud (GDC).

Tujuan dan infrastruktur inti

• Tujuan: Petunjuk mendetail untuk menjalankan LLM canggih, termasuk Gemma 3 (multimodal), DeepSeek-R1, dan Llama (3.1/3.2) menggunakan backend yang dioptimalkan seperti vLLM dan Ollama.
• Rilis minimum: Rilis software GDC dengan air gap 1.15.x*.
• Persyaratan hardware: Diperlukan minimal 1 GPU NVIDIA A100. Penyimpanan berperforma tinggi (PVC 500GiB+) direkomendasikan untuk mengoptimalkan waktu pemuatan bobot model dari 30 menit menjadi kurang dari 5 menit.

Komponen deployment

Komponen	Deskripsi
Backend LLM	vLLM (penyajian throughput tinggi dengan PagedAttention) dan Ollama (pengelolaan lokal yang disederhanakan dan dukungan multimodal)
Model	LLM yang tersedia untuk umum, termasuk lini Gemma, DeepSeek, dan Llama
Akselerator	Mendukung slice GPU NVIDIA A100 penuh atau GPU Multi-Instance (MIG), bergantung pada footprint VRAM model
Layanan GDC	Menggunakan GDC Container Service, Load Balancer (ELB/ILB), Harbor Container Registry

Prosedur operasional utama

• Pengelolaan Model: Backend LLM mengelola pemuatan dan pembatalan pemuatan model berdasarkan penggunaan. vLLM menyematkan model ke memori untuk latensi rendah yang konsisten, sementara Ollama memungkinkan pemuatan model dinamis, tetapi secara otomatis membatalkan pemuatan model setelah 30 menit tidak aktif.
• Penyesuaian: Pengguna dapat menggunakan LLM pilihan dengan menariknya dari Internet, membuat image Docker baru, dan menguploadnya ke registry Harbor lokal.

Prasyarat

Rilis

• GDC dengan air gap versi 1.15.1 atau yang lebih tinggi.

Komponen

• Cluster pengguna dibuat dengan resource yang memadai (CPU, Memori, GPU).
• Minimal diperlukan 1 GPU NVIDIA A100.
• Instance Harbor tersedia dan dapat diakses.
• CLI kubectl dan gdcloud yang dikonfigurasi untuk mengakses cluster pengguna.
• Klien Docker diinstal dan dikonfigurasi untuk mengirim ke Harbor.
• Izin IAM yang diperlukan telah diberikan (misalnya, Namespace Admin, Cluster Developer).
• Akun dan autentikasi Hugging Face dikonfigurasi jika menggunakan model yang dibatasi.

Kapasitas yang dibutuhkan

Resource	Kapasitas
CPU	8 vCPU
Memori RAM	32 GiB
Penyimpanan Efemeral	16 Gi
GPU	1 GPU NVIDIA A100
Volume persisten	*500GiB+

Resource hardware ini diperlukan agar backend penayangan dapat menjalankan LLM dengan akselerasi GPU. Misalnya, satu a2-ultragpu-1g-gdc a2-ultragpu-1g-gdc akan menyediakan resource yang cukup.

Diagram tingkat tinggi

Diagram ini menggambarkan pengguna yang menggunakan API yang diekspos oleh dua backend LLM, vLLM dan Ollama, untuk mendapatkan respons inferensi dari model open source, seperti Gemma, Llama, dan DeepSeek. Bergantung pada ukuran model, yang diukur dalam miliaran parameter, setiap LLM mungkin memerlukan GPU penuh atau sebagian untuk dijalankan.

Catatan: vLLM tidak mendukung penayangan beberapa model dalam satu proses server atau penentuan beberapa model dalam perintah server vLLM. Untuk menjalankan beberapa model, Anda harus meluncurkan instance server vLLM terpisah, masing-masing di port dan (opsional) GPU yang berbeda, serta menggunakan router atau load balancer eksternal (misalnya, Nginx) untuk mengarahkan permintaan ke server yang sesuai berdasarkan model yang diminta.

Diagram batas layanan dan keamanan untuk deployment LLM

Solusi ini bergantung pada layanan berikut yang sudah disertakan dalam stack software GDC dengan air gap:

• GDC Container Service: untuk menjalankan semua proses dan menskalakannya menggunakan HPA.
• GDC Load Balancer: menggunakan Layanan Kubernetes, untuk melayani semua backend dalam solusi ini dan membuat LLM dapat diakses dari jaringan pelanggan, ini disebut ELB yang merupakan singkatan dari External Load Balancer. Sebaliknya, pelanggan dapat memilih untuk menjaga LLM tetap dapat dijangkau dari dalam cluster pengguna saja, yang mungkin berguna jika hanya ada agen internal yang meminta inferensi di dalam solusinya. Konfigurasi ini disebut ILB, singkatan dari Internal Load Balancer.
• CI/CD GDC: Harbor Container Registry untuk menyimpan backend LLM dan bobot model.
• GDC Observability Stack: untuk mengumpulkan dan menelusuri log backend serta menyediakan dasbor.

Dari segi keamanan, akses ke deployment LLM bergantung pada pengguna mana yang dapat menjangkau layanan Load Balancer yang mengekspos backend penayangan LLM, yang berjalan sebagai pod dalam project / namespace Kubernetes.

Deployment

Prasyarat

Instal alat berikut di workstation yang terhubung ke lingkungan GDC dengan air gap Anda:

1. docker
2. kubectl
3. gdcloud CLI

Dokumen ini berisi semua kode sumber dan file konfigurasi yang Anda butuhkan untuk men-deploy LLM.

Membuat secret untuk menarik image dari Harbor

Untuk mengonfigurasi secret penarikan image untuk beban kerja container di GDC dengan air gap, Anda perlu membuat secret Kubernetes docker-registry yang berisi kredensial untuk mengakses project Harbor pribadi Anda. Secret ini kemudian dirujuk dalam spesifikasi deployment Anda.

Anda harus menggunakan akun robot Harbor untuk akses terprogram ke image dalam project Harbor pribadi.

Ikuti langkah-langkah berikut untuk mengonfigurasi secret penarikan image:

Buat akun robot Harbor:

• Buka UI instance Harbor Anda.
• Buka project Harbor Anda.
• Pilih tab "Akun Robot".
• Klik "+ NEW ROBOT ACCOUNT".
• Beri nama (misalnya, oss-llm-puller) dan berikan izin yang diperlukan (setidaknya akses "pull") hingga waktu habis masa berlaku.
• Simpan nama akun robot (misalnya, robot$oss-llm-puller) dan token rahasia yang diberikan dengan aman.

Mengautentikasi Docker ke Harbor:

Di komputer Anda yang telah menginstal Docker dan memiliki akses jaringan ke registry Harbor, login menggunakan kredensial akun robot:

export INSTANCE_URL="your-harbor-instance-url"
# for example, harbor1-project1.org1.zone1.google.gdc.com

export ROBOT_NAME="your-robot-account-name"
# for example, robot\$oss-llm-puller (note how we escape the $ character)

export ROBOT_SECRET="your-robot-account-secret"

docker login ${INSTANCE_URL} --username ${ROBOT_NAME} --password ${ROBOT_SECRET}

# Sample output:

WARNING! Using --password via the CLI is insecure. Use --password-stdin.

WARNING! Your credentials are stored unencrypted in '$HOME/.docker/config.json'.
Configure a credential helper to remove this warning. See
https://docs.docker.com/go/credential-store/

Login Succeeded

Seperti yang ditunjukkan dalam contoh output, perintah ini memperbarui file konfigurasi Docker lokal Anda ($HOME/.docker/config.json) dengan detail autentikasi. File config.json akan terlihat seperti ini:

{
    "auths": {
        "harbor1-project1.org1.zone1.google.gdc.com": {
            "auth": "...omitted..."
        }
    }
}

Jika Anda menggunakan klien Docker untuk login ke registry lain di masa lalu, Anda akan melihat lebih banyak entri di dalam "auths".

Buat secret penarikan image Kubernetes:

Gunakan kubectl untuk membuat secret jenis docker-registry di namespace project Anda, menggunakan file konfigurasi Docker yang diperbarui pada langkah sebelumnya:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS certificate}

gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

export SECRET_NAME="oss-llm-pull-secret" # You can choose another name
export NAMESPACE="your-project-namespace"
# Assuming default Docker config path. Adjust if necessary.
export DOCKER_CONFIG_PATH="$HOME/.docker/config.json"

kubectl create secret docker-registry ${SECRET_NAME} \
      --from-file=.dockerconfigjson=${DOCKER_CONFIG_PATH} \
      -n ${NAMESPACE}

Anda akan mereferensikan secret ini nanti dalam spesifikasi container backend LLM dengan menyertakan kolom imagePullSecrets.

Dengan mengikuti langkah-langkah ini, cluster Kubernetes Anda kini akan menggunakan kredensial yang diberikan untuk menarik image container dari registry Harbor pribadi di lingkungan GDC dengan air gap Anda. Langkah-langkah ini juga disertakan dalam dokumentasi produk.

Menyiapkan deployment LLM

Anda memiliki dua opsi berikut untuk Backend LLM:

• vLLM
• Ollama

Anda dapat memilih salah satunya atau men-deploy kedua backend. Setiap backend dapat menjalankan satu atau beberapa LLM, misalnya:

• Gemma 3
• DeepSeek
• Llama
• LLM lainnya

Di bagian 1, kami memberikan petunjuk tentang cara men-deploy vLLM, dan di bagian 2, kami menunjukkan cara menginstal Ollama.

1. Men-deploy vLLM sebagai backend LLM Anda

Mendapatkan image Docker vLLM

Secara umum, vLLM digunakan untuk menyajikan model yang didownload dari HuggingFace seperti yang akan kami tunjukkan dalam deployment LLM ini. Beberapa model dibatasi, artinya pengguna harus secara eksplisit meminta atau menyetujui untuk mengakses file dan konten mereka di Hugging Face Hub sebelum mereka dapat mendownload atau menggunakannya.

Login ke instance Harbor Anda menggunakan Docker seperti yang dijelaskan dalam dokumentasi. Di komputer dengan akses internet, tarik image Docker vLLM, lalu transfer ke project Harbor Anda:

# Pull and Tag vLLM (v0.13.0 recommended for stability)
docker pull vllm/vllm-openai:v0.13.0
docker tag vllm/vllm-openai:v0.13.0 HARBOR_URL/PROJECT/vllm-openai:v0.13.0
docker push HARBOR_URL/PROJECT/vllm-openai:v0.13.0

Ganti kode berikut:

• HARBOR_URL: URL instance Harbor.
• PROJECT: nama project Harbor.

Versi vLLM yang digunakan untuk panduan deployment ini adalah: v0.13.0

Menyimpan bobot model LLM Anda di PVC

Buka Terminal baru dan buat folder tempat Anda akan menyimpan file deployment vLLM:

mkdir vllm-deployment
cd vllm-deployment

Kemudian, buat file YAML (misalnya, model-pvc.yaml) untuk mendeklarasikan Persistent Volume Claim (PVC) menggunakan primitif Kubernetes standar:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: model-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Gi
  storageClassName: standard-rwo
  volumeMode: Filesystem

Hubungkan ke cluster GDC dengan air gap Anda dan terapkan PVC:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS cert}

gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

# Apply the PVC manifest
kubectl apply -f model-pvc.yaml

Download bobot model dari Hugging Face:

# Log in to Hugging Face
hf auth login

# Download weights for Gemma 3 (for example, 4B instruction-tuned)
hf download google/gemma-3-4b-it

Contoh output:

Fetching 9 files: 100%| 9/9 [00:00<00:00, 19.34it/s]
Downloading (…)7f58a/.gitattributes: 100%| 1.62k/1.62k [00:00<00:00, 7.82MB/s]
Downloading (…)del-00002-of-00002.safetensors: 100%| 3.75G/3.75G [00:46<00:00, 81.3MB/s]
Downloading (…)del-00001-of-00002.safetensors: 100%| 4.90G/4.90G [00:54<00:00, 90.1MB/s]
Downloading (…)-3-4b-it/README.md: 100%| 23.3k/23.3k [00:00<00:00, 48.0MB/s]
Downloading (…)8a/model.safetensors.index.json: 100%| 26.3k/26.3k [00:00<00:00, 39.5MB/s]
Downloading (…)f58a/config.json: 100%| 908/908 [00:00<00:00, 4.41MB/s]
Downloading (…)generation_config.json: 100%| 210/210 [00:00<00:00, 936kB/s]
Downloading (…)tokenizer.json: 100%| 33.1M/33.1M [00:01<00:00, 17.6MB/s]
/Users/rashjab/.cache/huggingface/hub/models--google--gemma-3-4b-it/snapshots/952ec8ffca3adadfd00c6d71b40280ebdbb7f58a

Seperti yang dapat Anda lihat dalam contoh output, ukuran file model di disk adalah 8,64 GB yang sesuai dengan PVC 500 GiB yang kita tentukan sebelumnya. Selalu pastikan hal ini terjadi untuk model apa pun yang Anda pilih untuk dimuat ke dalam Persistent Volume (PV) dan, misalnya, model 15 GB, menggunakan PVC 500 GiB untuk mencapai 1.500 IOPS, sehingga secara signifikan mengurangi waktu pemuatan bobot dari ~30 menit menjadi kurang dari 5 menit.

Isi PV dengan menyalin file model ke dalam volumenya. Hal ini sering kali melibatkan:

• Membuat pod "pembantu" sementara yang me-mount PV.
• Menggunakan kubectl cp untuk menyalin file model dari workstation ke volume terpasang pod helper.
• Contoh pod helper:

helper-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: model-uploader
spec:
  containers:
  - name: uploader
    image: HARBOR_URL/PROJECT/busybox:latest
    command: ["sleep", "3600"]
    volumeMounts:
    - name: model-data
      mountPath: /data
  imagePullSecrets:
  - name: oss-llm-pull-secret
  volumes:
  - name: model-data
    persistentVolumeClaim:
      claimName: model-pvc

Ganti kode berikut:

• HARBOR_URL: URL instance Harbor.
• PROJECT: nama project Harbor.
• oss-llm-pull-secret: jika Anda memilih nama secret penarikan image yang berbeda.
• model-pvc: dengan nama yang Anda berikan ke PVC Anda.

Kirim image Docker helper (busybox):

docker pull busybox:latest
docker tag busybox HARBOR_URL/PROJECT/busybox:latest
docker push HARBOR_URL/PROJECT/busybox:latest

Ganti kode berikut:

• HARBOR_URL: URL instance Harbor.
• PROJECT: nama project Harbor.

Terapkan file helper-pod.yaml dan salin bobot model ke PV:

kubectl apply -f helper-pod.yaml

# Wait for the pod to be Running
kubectl cp ~/.cache/huggingface/hub/ NAMESPACE/model-uploader:/data/

# After copying, delete the helper pod
kubectl delete pod model-uploader

Men-deploy backend vLLM

Buat file deployment untuk vLLM guna menjalankan server model. Contoh berikut men-deploy model gemma-3-4b-it.

vllm-gemma-3-4b-it-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gemma-3-4b-it
  labels:
    app: gemma-3-4b-it
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gemma-3-4b-it
  template:
    metadata:
      labels:
        app: gemma-3-4b-it
    spec:
      volumes:
      - name: cache-volume
        persistentVolumeClaim:
          claimName: model-pvc # change with the name you gave initially to your PVC
      # vLLM needs to access the host's shared memory for tensor parallel inference.
      - name: shm
        emptyDir:
          medium: Memory
          sizeLimit: "16Gi"
      containers:
      - name: gemma-3-4b-it
        image: HARBOR_URL/PROJECT/vllm-openai:v0.13.0
        command: ["python3"]
        args: [
          "-m",
          "vllm.entrypoints.openai.api_server",
          "--model",
          "google/gemma-3-4b-it", # Use the repo ID
          "--max-model-len",
          "32768",
          "--enforce-eager"
        ]
        env:
        - name: HF_HUB_OFFLINE
          value: "1"
        - name: HF_HOME
          value: "/model" # Tells vLLM to look for models in /model/hub
        # --- PERFORMANCE & STABILITY OPTIMIZATIONS ---
        - name: NCCL_P2P_DISABLE
          value: "1" # Prevents initialization hangs on P2P checks
        - name: NCCL_IB_DISABLE
          value: "1" # Prevents initialization hangs on InfiniBand checks
        # --- FIPS BYPASS ---
        - name: BORINGSSL_FIPS
          value: "0"
        - name: OPENSSL_FIPS
          value: "0"
        - name: OPENSSL_CONF
          value: "/dev/null"
        - name: FIPS_SIG
          value: "off"
        ports:
        - containerPort: 8000
        securityContext:
          privileged: true
          runAsUser: 0
        resources:
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
            cpu: "8"       # Increased to handle model weight verification
            memory: "64Gi"  # Increased to ensure headroom for weight loading
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
            cpu: "8"
            memory: "32Gi"
        volumeMounts:
        - name: cache-volume
          mountPath: /model
        - name: shm
          mountPath: /dev/shm
      imagePullSecrets:
      - name: oss-llm-pull-secret

Ganti kode berikut:

• HARBOR_URL: URL instance Harbor.
• PROJECT: nama project Harbor.
• oss-llm-pull-secret: nama yang Anda berikan saat pembuatan secret penarikan image.
• claimName: nama yang Anda berikan pada pembuatan PVC awal.

Catatan: Kita meminta GPU penuh dalam deployment ini, meskipun model dapat muat dalam slice GPU dengan VRAM 20 GB saja. Namun, hal ini akan memberikan throughput tertinggi ke LLM, yang diukur dalam token/dtk, karena semua core GPU akan tersedia untuk inferensi.

Selanjutnya, buat file Layanan Kubernetes untuk mengekspos API backend vLLM:

vllm-gemma-3-4b-it-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: gemma-3-4b-it
  namespace: NAMESPACE
spec:
  ports:
  - name: http-gemma-3-4b-it
    port: 80
    protocol: TCP
    targetPort: 8000
  selector:
    app: gemma-3-4b-it
  sessionAffinity: None
  type: LoadBalancer

Terapkan konfigurasi deployment dan layanan:

kubectl apply -f vllm-gemma-3-4b-it-deployment.yaml
kubectl apply -f vllm-gemma-3-4b-it-service.yaml

Memverifikasi dan menguji deployment vLLM

1. Periksa status pod:

   kubectl get pods
   

   Tunggu hingga pod berada dalam status Running.

2. Periksa layanan:

   kubectl get service
   

   Contoh output:

   # NAME          TYPE         CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   # gemma-3-4b-it LoadBalancer 10.201.136.62  136.125.37.198   80:30109/TCP   3d1h
   

   Catat EXTERNAL-IP layanan vLLM (misalnya, 136.125.37.198) dari output sebelumnya. Anda juga dapat mencetaknya dengan:

   kubectl get service gemma-3-4b-it \
   -o jsonpath='{.status.loadBalancer.ingress[*].ip}'
   

3. Melihat log:

   kubectl logs YOUR_VLLM_POD
   

   Cari pesan yang menunjukkan bahwa server telah dimulai dan model dimuat (misalnya, INFO: Application startup complete.). Karena tidak ada download Hugging Face, proses ini akan cepat jika file berada di PVC dengan kapasitas Volume Persisten yang tinggi.

4. Uji inferensi dengan curl:

   Setelah memverifikasi bahwa pod vLLM berjalan dan Anda memiliki alamat IP eksternal Service, Anda dapat mengirim permintaan inferensi menggunakan curl. Karena vLLM menyediakan API yang kompatibel dengan OpenAI, Anda dapat menggunakan endpoint /v1/chat/completions:

   curl http://EXTERNAL_IP/v1/chat/completions \
     -H "Content-Type: application/json" \
     -d '{
       "model": "google/gemma-3-4b-it",
       "messages": [
         {"role": "user", "content": "What is Google Distributed Cloud air-gapped?"}
       ],
       "max_tokens": 100
     }'
   

   Ganti EXTERNAL_IP dengan alamat IP eksternal layanan vLLM.

2. Men-deploy Ollama sebagai backend LLM Anda

Ollama adalah framework populer untuk menjalankan LLM open source secara lokal dan di lingkungan dalam container. Hal ini menyederhanakan eksekusi model dengan menangani download bobot, kuantisasi, dan akselerasi GPU. API ini mencakup REST API bawaan untuk membuat penyelesaian, respons chat, dan embedding.

Tidak seperti mesin penayangan lainnya, Ollama mengelola eksekusi model secara dinamis:

• Pemuatan Model Dinamis: Saat permintaan untuk model tertentu diterima, Ollama memuat bobot ke dalam memori (VRAM GPU atau RAM sistem) sesuai permintaan.
• Pembongkaran karena Tidak Ada Aktivitas: Jika tidak ada permintaan inferensi yang diterima untuk model selama 30 menit (dapat dikonfigurasi dengan OLLAMA_KEEP_ALIVE), Ollama akan membongkarnya dari memori untuk membebaskan resource hardware bagi workload lain.
• Satu Model Aktif per Instance: Ollama memproses permintaan untuk satu model aktif dalam satu waktu per instance server. Jika beberapa model dipanggil secara paralel, Ollama akan mengantrekan permintaan dan menukar model secara berurutan, yang dapat menyebabkan latensi. Untuk menayangkan beberapa model secara bersamaan tanpa menukar, Anda harus men-deploy instance Ollama terpisah untuk setiap model.

Mendownload bobot model dan membuat image Docker

Tidak seperti vLLM, yang dapat memuat bobot langsung dari Persistent Volume, Ollama biasanya mengharapkan model disimpan dalam format direktori internalnya (~/.ollama/models).

Dalam lingkungan yang terisolasi, tempat container runtime tidak dapat mendownload model dari internet publik, Anda harus mengemas bobot model ke dalam image container itu sendiri selama fase build. Pendekatan ini memastikan container sepenuhnya mandiri dan siap ditayangkan segera setelah deployment tanpa memerlukan akses jaringan eksternal.

Buat folder untuk deployment Ollama:

mkdir ollama-gemma3
cd ollama-gemma3

Buat Dockerfile dengan konten berikut:

# Use a standard Linux base image
FROM ubuntu

# Install necessary dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    ca-certificates \
    zstd \
    && rm -rf /var/lib/apt/lists/*

# Install Ollama
# This uses Ollama's official installation script, which adds Ollama to /usr/local/bin
RUN curl -fsSL https://ollama.com/install.sh -o install.sh && \
    chmod +x install.sh && \
    ./install.sh && \
    rm install.sh

# Set environment variables for Ollama (optional, but a good practice)
# ENV OLLAMA_HOST="0.0.0.0"

# If you want to customize the model storage path within the container, set OLLAMA_MODELS, for example:
# ENV OLLAMA_MODELS="/usr/local/ollama/models"
# The default OLLAMA_MODELS is /root/.ollama
# Then, ensure you create and populate that directory.

# --- Download Gemma 3 model weights ---
# This step starts Ollama server in the background, pulls the model,
# and then kills the server to allow the Docker build to continue.
# This approach works around the Docker RUN command limitations for services.

RUN ollama serve & \
    # Give the Ollama server a moment to start up
    # Use --retry and --retry-connrefused to handle startup delays
    curl --retry 10 --retry-connrefused -s http://localhost:11434 || true && \
    # Pull the Gemma 3 model weights
    ollama pull gemma3:latest && \
    # Stop the background Ollama server process cleanly
    pkill ollama || true

# Expose Ollama's default port
EXPOSE 11434

# Command to run Ollama server when the container starts
CMD ["ollama", "serve"]

Jika Anda ingin mencoba LLM open source lain, seperti model dari keluarga Llama 3.2 atau DeepSeek-R1, ubah perintah Ollama ini di Dockerfile sebelumnya:

ollama pull gemma3:latest

Misalnya, jika Anda ingin menarik Llama 3.2 dengan 3 miliar parameter, gunakan perintah ini:

ollama pull llama3.2:3b

Atau, jika Anda lebih suka menggunakan DeepSeek-R1 dengan 8 miliar parameter, gunakan perintah ini:

ollama pull deepseek-r1:8b

Anda juga dapat mendownload lebih dari satu LLM dan membuat container bobot modelnya. Kemudian, Ollama akan dapat beralih antar-model saat Anda meminta inferensi dengan berbagai model yang telah dimuat sebelumnya. Misalnya, Anda dapat menambahkan model Gemma dan Llama ke image Docker Anda. Ingatlah bahwa di lingkungan yang terisolasi dari internet, backend Ollama tidak memiliki akses ke library Ollama untuk mendownload model kapan saja.

Jangan lupa untuk memeriksa dan menyetujui setiap lisensi model dan persyaratan penggunaan sebelum menjalankannya di aplikasi Anda. Ada banyak LLM di library Ollama. Anda hanya memerlukan koneksi Internet untuk mendownload bobot model saat membangun image Docker backend LLM.

Bangun image Docker dan kirimkan ke Harbor

Login ke instance Harbor Anda menggunakan Docker seperti yang dijelaskan dalam dokumentasi. Bangun image Docker Gemma 3 dan upload ke repositori Harbor Anda:

docker build -t ollama-gemma3 .
docker tag ollama-gemma3 HARBOR_URL/PROJECT/ollama-gemma3:latest
docker push HARBOR_URL/PROJECT/ollama-gemma3:latest

Ganti kode berikut:

• HARBOR_URL: URL instance Harbor.
• PROJECT: nama project Harbor.

Versi Ollama yang digunakan untuk panduan deployment ini: 0.14.1

Menyiapkan deployment dan layanan Kubernetes

Buat file bernama ollama-gemma3.yaml untuk menentukan deployment backend Ollama dan konfigurasi load balancer-nya untuk mengeksposnya sebagai layanan:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama-gemma3
  namespace: osd-dev
  labels:
    app: ollama-gemma3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama-gemma3
  template:
    metadata:
      labels:
        app: ollama-gemma3
    spec:
      containers:
      - name: ollama-gemma3
        image: rashjab-mhs-rashjab-test2.gdc1.us-west6-a.staging.gpcdemolabs.com/rashjab-repo/ollama-gemma3:latest
        env:
        # This is the crucial fix: Tell Ollama to listen on all network interfaces
        - name: OLLAMA_HOST
          value: "0.0.0.0"
        imagePullPolicy: Always
        ports:
        - containerPort: 11434
        securityContext:
          privileged: true
          runAsUser: 0
        resources:
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
      imagePullSecrets:
      - name: oss-llm-pull-secret
---
apiVersion: v1
kind: Service
metadata:
  name: ollama-gemma3
  namespace: osd-dev
spec:
  type: LoadBalancer
  selector:
    app: ollama-gemma3
  ports:
  - name: ollama-gemma3-port
    port: 11434
    protocol: TCP
    targetPort: 11434

Ganti kode berikut:

• HARBOR_URL: URL instance Harbor.
• PROJECT: nama project Harbor.
• oss-llm-pull-secret: jika Anda memilih nama secret penarikan image yang berbeda.

Memverifikasi alokasi GPU

GDC dengan air gap mendukung Multi-Instance GPU (MIG) NVIDIA, dan berbagai profil MIG-nya dapat ditinjau dalam dokumentasi publik. Jika Anda men-deploy LLM kecil, sebaiknya periksa ukurannya (dalam memori) dan partisi GPU Anda dengan tepat. Skema partisi untuk node pool ditentukan dalam resource kustom Cluster-nya. Untuk mengetahui informasi selengkapnya tentang cara menerapkan skema partisi GPU, lihat Menambahkan node pool. Jika Anda adalah Operator Aplikasi (AO), konsultasikan dengan Administrator Platform (PA) Anda tentang akselerator yang diinstal dan tersedia di project / cluster Anda. Anda dapat menemukan detail selengkapnya tentang cara mengonfigurasi container untuk menggunakan resource GPU dan cara memeriksa alokasi resource GPU.

Presisi default model Gemma 3 4B adalah 16-bit. Menurut tabel yang dipublikasikan oleh Google ini, persyaratan memori GPU untuk LLM ini adalah 6,4 GB, menggunakan presisi BF16 (16-bit).

Pada ollama-gemma3.yaml sebelumnya, kita memasang slice GPU 10 GB (NVIDIA A100) ke container, karena jumlah memori VRAM ini cukup untuk memuat dan mengeksekusi model Gemma 3 4B, seperti yang ditunjukkan berikutnya:

ollama-gemma3.yaml

... omitted ...

        resources:
          limits:
            nvidia.com/mig-1g.10gb-NVIDIA_A100_80GB_PCIE: 1
          requests:
            nvidia.com/mig-1g.10gb-NVIDIA_A100_80GB_PCIE: 1

... omitted ...

Deploy backend Ollama dan ekspos sebagai layanan

Hubungkan ke cluster Anda dan tetapkan konteks ke namespace project Anda:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS certificate}

gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

Terapkan manifes Ollama:

kubectl apply -f ollama-gemma3.yaml

Pastikan pod Ollama berjalan dan layanan terkait sudah ada:

kubectl get pods

Contoh output:

# NAME                             READY   STATUS    RESTARTS   AGE
# ollama-gemma3-6fc6fff74b-9qtpf   1/1     Running   0          1h

kubectl get service

Contoh output:

# NAME             TYPE          CLUSTER-IP    EXTERNAL-IP    PORT(S)          AGE
# ollama-gemma3   LoadBalancer  172.0.0.1     10.0.0.1       11434:31822/TCP  1d

Catat EXTERNAL-IP layanan Ollama (misalnya, 10.0.0.1) dari output sebelumnya. Anda juga dapat mencetaknya dengan:

kubectl get service ollama-gemma3 \
-o jsonpath='{.status.loadBalancer.ingress[*].ip}'

Sebelum memeriksa apakah Ollama Gemma 3 berfungsi, Anda harus menerapkan kebijakan Jaringan seperti :

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ollama-ingress
  namespace: osd-dev
spec:
  subject:
    subjectType: UserWorkload
  policyType: Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0 # Allows traffic from any IP. Restrict this for production.
    ports:
    - protocol: TCP
      port: 11434

Terapkan kebijakan jaringan:

kubectl apply -f ollama-netpol.yaml

Verifikasi dan uji deployment Ollama:

1. Periksa apakah Ollama sedang berjalan:

   curl http://EXTERNAL_IP:11434
   

   Respons yang diharapkan: "Ollama is running" (Ollama sedang berjalan)

2. Mengirim permintaan penyelesaian:

   curl -X POST http://EXTERNAL_IP:11434/v1/completions \
     -H "Content-Type: application/json" \
     -d '{
       "model": "gemma3:latest",
       "prompt": "Google Distributed Cloud air-gapped is a",
       "max_tokens": 128,
       "temperature": 0.90
     }'
   

Meminta inferensi

Setelah backend LLM (vLLM dan Ollama) di-deploy dan dapat dijangkau melalui layanan LoadBalancer masing-masing, Anda dapat mulai menggunakannya untuk inferensi.

Bergantung pada kasus penggunaan, Anda memiliki beberapa opsi:

• UI Web Interaktif: Untuk menguji, membuat prototipe, atau memberikan pengalaman seperti ChatGPT kepada pengguna, Anda dapat men-deploy Open WebUI atau frontend serupa.
• Antarmuka Command Line (CLI): Untuk verifikasi, pembuatan skrip, atau otomatisasi yang cepat, Anda dapat menggunakan curl atau skrip kustom.
• Integrasi Aplikasi: Hubungkan aplikasi internal, agen AI, atau plugin IDE (misalnya, Continue untuk VS Code/JetBrains) langsung ke endpoint yang kompatibel dengan OpenAI yang disediakan oleh vLLM (/v1) atau Ollama (/v1).

1. Berinteraksi dengan LLM menggunakan UI

Untuk menyediakan antarmuka seperti ChatGPT untuk berinteraksi dengan model Anda, deploy Open WebUI di cluster Anda.

Membuat Deployment Open WebUI

Buat open-webui-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: open-webui
  namespace: osd-dev
  labels:
    app: open-webui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: open-webui
  template:
    metadata:
      labels:
        app: open-webui
    spec:
      containers:
      - name: open-webui
        image: HARBOR_URL/PROJECT/open-webui:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        env:
        - name: OPENAI_API_BASE_URL
          value: "http://gemma-3-4b-it/v1" # Point to your vLLM service
        - name: OPENAI_API_KEY
          value: "EMPTY"
        - name: WEBUI_AUTH
          value: "False"
      imagePullSecrets:
      - name: oss-llm-pull-secret
---
apiVersion: v1
kind: Service
metadata:
  name: open-webui
  namespace: osd-dev
spec:
  type: LoadBalancer
  selector:
    app: open-webui
  ports:
  - port: 80
    targetPort: 8080

Menerapkan Kebijakan Jaringan

Anda harus mengizinkan komputer Anda menjangkau layanan Open WebUI di port 80.

Perbarui kebijakan Jaringan Project PNP Anda untuk menyertakan layanan open-webui atau menerapkan kebijakan yang luas:

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-webui-ingress
  namespace: NAMESPACE
spec:
  subject:
    subjectType: UserWorkload
  policyType: Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0 # Allows traffic from any IP then restrict this for production
    ports:
    - protocol: TCP
      port: 8080

Verifikasi

1. Dapatkan IP WebUI:

   kubectl get service open-webui -n NAMESPACE
   

2. Akses UI: Buka browser Anda, lalu buka http://WEB_UI_EXTERNAL_IP

3. Konfigurasi: Saat login pertama kali, buat akun administrator. Di setelan, pastikan koneksi OpenAI mengarah ke http://gemma-3-4b-it/v1

4. Pilih Model: Di antarmuka chat, pilih google/gemma-3-4b-it dari drop-down model.

   

2. Membuat permintaan HTTP menggunakan CLI

• curl:

curl -X POST http://OLLAMA_LOAD_BALANCER_IP:11434/v1/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "gemma3:latest",
  "prompt": "Google Distributed Cloud air-gapped is a",
  "max_tokens": 128,
  "temperature": 0.90
}'

Validasi dan verifikasi

Pastikan semua container dan layanan sedang Berjalan:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS cert}
gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

# Pods

kubectl get pods # This command should return results like below

# NAME                                   READY   STATUS    RESTARTS   AGE
# vllm-6fc6fff74b-9qtpf                 1/1     Running   0          1h
# ollama-798fbf6ff6-9m7ln               1/1     Running   0          1h


# Services

kubectl get services # This command should return results like below

# NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)           AGE
# vllm-service              LoadBalancer   172.0.0.1        10.0.0.1       11434:31822/TCP   1h
# ollama-service        LoadBalancer   172.0.0.2        10.0.0.2       11434:30728/TCP   1h

Langkah-langkah penghapusan

1. Hapus semua resource Kubernetes:

   kubectl delete -f vllm-gemma-3-4b-it-deployment.yaml
   kubectl delete -f vllm-gemma-3-4b-it-service.yaml
   

2. Hapus container yang tidak digunakan secara manual dari repositori Harbor Anda.

Operasi

Backend vLLM

Dasar-Dasar vLLM

vLLM dirancang sebagai mesin layanan model tunggal berperforma tinggi. Fitur ini tidak mendukung penyajian beberapa model dalam satu proses server atau penentuan beberapa model dalam satu perintah startup. Untuk menayangkan lebih dari satu model (misalnya, model chat dan model penyematan terpisah), Anda harus meluncurkan instance vLLM terpisah, masing-masing di pod atau container-nya sendiri, yang secara opsional ditetapkan ke GPU atau slice GPU yang berbeda. Tidak seperti backend lain yang dapat menukar model secara dinamis, instance vLLM menyematkan modelnya dan memori cache KV terkait saat inisialisasi untuk memastikan throughput tinggi dan latensi rendah yang konsisten.

Anda dapat membuka terminal di pod vLLM mana pun menggunakan perintah berikutnya:

kubectl exec -it gemma-3-4b-random-string -n NAMESPACE -- /bin/bash

Perintah ini akan menunjukkan model mana yang dimuat, argumennya, dan PID-nya :

ps aux | grep vllm

Output serupa yang diharapkan:

root           1  0.1  0.8 9436960 1550504 ?     Ssl  Feb04   9:18 python3 -m vllm.entrypoints.openai.api_server --model google/gemma-3-4b-it --max-model-len 32768 --enforce-eager
root         504  0.0  0.0   3476  1596 pts/0    S+   02:48   0:00 grep --color=auto vllm

Jika Anda menginginkan tampilan yang lebih bersih dan lebih "mirip Ollama" tanpa kekacauan perintah grep itu sendiri dan PID sistem, Anda dapat menggunakan perintah satu baris ini:

ps aux | grep [v]llm.entrypoints | awk -F'--model ' '{print $2}' | awk '{print $1}'

Contoh respons :

google/gemma-3-4b-it

Anda dapat memantau status deployment vLLM menggunakan perintah kubectl standar dan dengan membuat kueri endpoint API internal.

Memeriksa Log Pod

Buka terminal untuk melihat log inisialisasi dan penayangan:

kubectl logs -f gemma-3-4b-it-random_string -n NAMESPACE

Cari konfirmasi bahwa server sudah siap:

(APIServer pid=1) INFO:     Started server process [1]
(APIServer pid=1) INFO:     Waiting for application startup.
(APIServer pid=1) INFO:     Application startup complete.

Query Internal Status

Karena vLLM menyediakan API yang kompatibel dengan OpenAI, Anda dapat memverifikasi model yang dimuat dan kesehatan sistem langsung dari terminal di dalam cluster (misalnya, menggunakan pod debug-sh).

Anda harus meluncurkan pod debug terlebih dahulu. Berikut petunjuknya :

Luncurkan Pod Debug

Jalankan perintah berikut untuk memulai shell sementara di namespace project Anda. Konfigurasi ini menggunakan image busybox (yang sebelumnya dikirim ke registry Harbor Anda) dan menyuntikkan kredensial yang diperlukan dengan tanda --overrides:

kubectl run --rm -it debug-sh \
  --image=HARBOR_URL/PROJECT/busybox:latest \
  --restart=Never -n osd-dev --overrides='{
    "spec": {
      "imagePullSecrets": [{"name": "oss-llm-pull-secret"}]
    }
  }' -- sh

Parameter utama:

• --rm: Menghapus pod secara otomatis saat keluar, sehingga menghemat resource cluster.
• --overrides: Wajib ada di lingkungan dengan air gap agar pod dapat melakukan autentikasi dengan registry Harbor pribadi.

Status Server Model Kueri

Setelah berada di dalam pod, gunakan utilitas wget untuk membuat kueri vLLM API. Karena layanan vLLM memetakan port internal 8000 ke port 80, Anda dapat menggunakan nama DNS layanan:

• Daftar Model yang Dimuat: Pastikan mesin vLLM telah berhasil diinisialisasi dan memuat bobot Gemma 3.

  wget -qO- http://gemma-3-4b-it/v1/models
  

  Respons Berhasil:

  {"object":"list","data":[{"id":"google/gemma-3-4b-it"}]}
  

• Periksa Kesehatan Aplikasi: Konfirmasi bahwa server API siap memproses permintaan.

  wget -qO- http://gemma-3-4b-it/health
  

  Respons keberhasilan:

  OK
  

Dasar-Dasar Ollama

Ollama tidak mendukung pemuatan beberapa model ke dalam memori secara bersamaan. Selain itu, jika Anda tidak menggunakan LLM selama jangka waktu tertentu (biasanya 30 menit secara default), Ollama akan membatalkan pemuatan model saat ini dari memori.

Karena perilaku yang dijelaskan sebelumnya, solusi ini menerapkan dua atau lebih backend Ollama, bergantung pada kebutuhan dan kasus penggunaan Anda, sehingga banyak developer atau pengguna dapat menggunakannya secara paralel tanpa hanya memiliki satu instance Ollama yang memuat dan membatalkan muatan model secara sering, sehingga menghasilkan latensi yang tidak perlu.

Anda dapat membuka terminal di pod Ollama mana pun menggunakan perintah berikutnya:

kubectl exec -it ollama-chat-random_string -- sh
kubectl exec -it ollama-autocomplete-random_string -- sh

Di dalam pod, Anda dapat menggunakan Ollama CLI untuk menjelajahi model yang tersedia dan melihat model mana yang dimuat:

• Di pod ollama-chat, Anda akan menemukan satu model:

  # ollama list
  NAME                     ID              SIZE      MODIFIED
  codegemma:7b-instruct    0c96700aaada    5.0 GB    2 hours ago
  
  # ollama ps
  NAME                     ID              SIZE     PROCESSOR    UNTIL
  codegemma:7b-instruct    0c96700aaada    10 GB    100% GPU     4 minutes from now
  

• Di pod ollama-autocomplete, Anda akan menemukan dua model:

  # ollama list
  NAME                     ID              SIZE      MODIFIED
  codegemma:2b             926331004170    1.6 GB    2 hours ago
  codegemma:7b-code        aee9a63c13b9    5.0 GB    2 hours ago
  
  # ollama ps
  NAME                 ID              SIZE      PROCESSOR    UNTIL
  codegemma:7b-code    aee9a63c13b9    7.1 GB    100% GPU     4 minutes from now
  

• Saat Ollama membatalkan pemuatan model saat ini, outputnya kosong:

  # ollama ps
  NAME    ID    SIZE    PROCESSOR    UNTIL
  

Perhatikan bahwa Ollama memuat kembali model secara dinamis saat Anda mengirim permintaan bantuan kode berikutnya, tanpa intervensi manual.

Pentingnya kapasitas GPU

Jika Anda menyediakan satu slice GPU dengan 10 GB, tetapi footprint memori model sedikit lebih besar dari itu, Anda akan melihat bahwa sebagian LLM dimuat di CPU, seperti berikut:

# ollama ps
NAME                     ID              SIZE     PROCESSOR         UNTIL
codegemma:7b-instruct    0c96700aaada    10 GB    6%/94% CPU/GPU    29 minutes from now

Hal ini tidak optimal dan menghasilkan latensi respons yang lebih tinggi, jadi pastikan Anda memberikan ukuran GPU yang disarankan dalam panduan ini.

Catatan: Hal ini hanya terjadi dengan Ollama. Untuk vLLM, jika model terlalu besar untuk memori GPU yang dialokasikan, model akan error (error OutOfMemory) selama inisialisasi. Fitur ini menolak untuk berjalan dalam status pemisahan CPU yang "bermasalah" karena fitur intinya PagedAttention memerlukan VRAM berkecepatan tinggi agar dapat berfungsi.

LLM

Menggunakan LLM lain atau LLM pilihan Anda dengan vLLM

Untuk menjalankan Gemma dengan berbagai ukuran atau Model Bahasa Besar (LLM) open source lainnya dengan vLLM di GDC dengan air gap, seperti DeepSeek-R1 atau Llama 3.1, Anda harus menyerap bobot model baru ke dalam lingkungan Anda dan memperbarui manifes deployment untuk mengarah ke aset baru.

Berdasarkan prosedur operasional yang ditetapkan untuk solusi ini, ikuti langkah-langkah berikut untuk memuat model yang berbeda :

1. Download Bobot Model Baru:

   Di workstation dengan akses internet, gunakan Hugging Face CLI untuk mendownload bobot untuk model pilihan Anda.

   • Untuk Gemma 3 (3-12b-it):

   hf download google/gemma-3-12b-it
   

   • Untuk DeepSeek-R1 (7B Distill):

   hf download deepseek-ai/DeepSeek-R1-Distill-Qwen-7B
   

   • Untuk Llama 3.1 (8B):

   hf download meta-llama/Meta-Llama-3.1-8B-Instruct
   

   Catatan: Pastikan Anda telah menyetujui persyaratan lisensi model di Hugging Face sebelum mendownload.

2. Isi Volume Persisten (PVC):

   Perbarui model-pvc yang ada atau buat yang baru dengan kapasitas yang memadai untuk model baru. Gunakan metode pod helper untuk mentransfer bobot dari workstation Anda. Faktor bentuk yang lebih besar memerlukan ruang disk yang jauh lebih besar. Pastikan Persistent Volume Claim (PVC) Anda memiliki kapasitas yang cukup untuk menyimpan bobot baru.

   • Gemma 3 4B: ~15,2 GB.
   • Gemma 3 27B: ~54 GB+.
   • Rekomendasi: Pertahankan rekomendasi PVC 500 GiB untuk memastikan IOPS tinggi (1.500) agar pemuatan lebih cepat, terlepas dari ukuran model.

   # Copy the new model's hub directory to the helper pod
   kubectl cp ~/.cache/huggingface/hub/ osd-dev/model-uploader:/data/
   

3. Perbarui Manifes Deployment vLLM:

   Ubah YAML deployment vLLM Anda untuk mereferensikan ID model baru. Tidak seperti Ollama, yang dapat menukar model secara dinamis, instance vLLM dikhususkan untuk satu model dan harus diupdate atau di-deploy ulang untuk mengubah model.

   Perbarui bagian args deployment Anda, bergantung pada model yang Anda gunakan, berikut deepseek sebagai contoh:

   args: [
     "-m", "vllm.entrypoints.openai.api_server",
     "--model", "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", # Update to new Repo ID
     "--max-model-len", "32768",
     "--enforce-eager" # Recommended for GDC stability
   ]
   

4. Menyesuaikan Resource GPU dan Memori:

   Model yang lebih besar memerlukan lebih banyak VRAM untuk bobot dan cache KV. Jika Anda beralih dari model 4B ke model 8B atau 14B, pastikan batas resource Anda cukup untuk menghindari error "kehabisan memori".

   • Penggunaan VRAM: Dengan presisi 16-bit, model 8B memerlukan sekitar 16 GB hanya untuk bobot, ditambah memori tambahan untuk cache vLLM PagedAttention.
   • Rekomendasi: Gunakan GPU A100 penuh (nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1) untuk model dengan parameter lebih dari 7B guna memastikan performa dan ruang cadangan yang optimal untuk cache KV.

5. Verifikasi Model Baru:

   Setelah deployment selesai merekonsiliasi, verifikasi bahwa model baru sudah aktif dengan API internal:

   # Inside a debug-sh pod
   wget -qO- http://gemma-3-4b-it/v1/models
   

   Respons Berhasil:

   {"object":"list","data":[{"id":"deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"}]}
   

Menghadirkan LLM lain dengan Ollama

Jika Anda ingin mencoba LLM open source lain, seperti model dari keluarga Llama 3.2 atau DeepSeek-R1, ubah perintah Ollama ini di Dockerfile sebelumnya:

ollama pull gemma3:latest

Misalnya, jika Anda ingin menarik Llama 3.2 dengan 3 miliar parameter, gunakan perintah ini:

ollama pull llama3.2:3b

Atau, jika Anda lebih suka menggunakan DeepSeek-R1 dengan 8 miliar parameter, gunakan perintah ini:

ollama pull deepseek-r1:8b

Anda juga dapat mendownload lebih dari satu LLM dan membuat container bobot modelnya. Kemudian, Ollama akan dapat beralih antar-model saat Anda meminta inferensi dengan berbagai model yang telah dimuat sebelumnya. Misalnya, Anda dapat menambahkan model Gemma dan Llama ke image Docker Anda. Ingatlah bahwa di lingkungan yang terisolasi dari internet, backend Ollama tidak memiliki akses ke library Ollama untuk mendownload model kapan saja.

Jangan lupa untuk memeriksa dan menyetujui setiap lisensi model dan persyaratan penggunaan sebelum menjalankannya di aplikasi Anda. Ada banyak LLM di library Ollama. Anda hanya memerlukan koneksi Internet untuk mendownload bobot model saat membangun image Docker backend LLM.

Membuka WebUI

Periksa apakah pod Open WebUI dalam status berjalan :

kubectl get pods -n NAMESPACE

Output yang diharapkan :

NAME                             READY   STATUS    RESTARTS   AGE
open-webui-69df4664d-przjl       1/1     Running   0          6d3h

Periksa IP layanan :

kubectl get service -n NAMESPACE

Output yang diharapkan:

NAME          TYPE            CLUSTER-IP       EXTERNAL-IP      PORT(S)           AGE
open-webui     LoadBalancer   10.201.137.164   136.125.37.224   80:30492/TCP      6d3h

Bagian berikut menunjukkan cara menggunakan fitur UI utama.

Menskalakan solusi dengan backend Ollama

Secara vertikal

• Alokasikan slice GPU yang lebih besar untuk LLM Anda yang menjadi hambatan hingga Anda menggunakan GPU penuh.
• Jika ingin menggunakan LLM yang lebih besar untuk akurasi respons yang lebih baik, misalnya, LLM dengan 405B parameter, bukan yang 7B, Anda mungkin memerlukan lebih dari satu GPU agar dapat menjalankannya dengan lancar.
• Model yang cocok dengan lebih dari satu GPU mengalami beberapa latensi terkait dengan komunikasi antar-GPU.

Secara horizontal

• Deploy pod Ollama sebanyak yang Anda perlukan untuk mencapai target throughput pada LLM tertentu.
  • Untuk melakukannya, tingkatkan jumlah replika dalam file YAML deployment Ollama yang sesuai.
• Layanan Kubernetes, yang berjenis LoadBalancer, akan mendistribusikan permintaan bantuan kode di antara endpoint (yaitu pod) dan menampilkan respons masing-masing melalui IP eksternal yang terekspos.
• Ingat, plugin Lanjutkan hanya mengarah ke satu alamat IP per fungsi.

Untuk menskalakan backend vLLM dalam lingkungan air-gapped GDC, Anda dapat mengikuti strategi yang serupa dengan yang digunakan untuk Ollama, dengan berfokus pada alokasi resource hardware dan replikasi pod.

Menskalakan solusi dengan backend vLLM

Secara vertikal

• Mengupgrade Alokasi GPU: Jika throughput inferensi (token/dtk) menjadi penghambat, alokasikan slice GPU yang lebih besar hingga Anda menggunakan GPU NVIDIA A100 penuh.
• Konfigurasi Multi-GPU: Untuk model berukuran sangat besar (misalnya, parameter 70B hingga 405B) yang tidak muat dalam memori satu A100 80 GB, Anda harus menskalakan ke beberapa GPU menggunakan paralelisme tensor.
• Pertimbangan Latensi: Perhatikan bahwa model yang mencakup lebih dari satu GPU mungkin mengalami sedikit overhead terkait komunikasi antar-GPU (misalnya, sinkronisasi NCCL).

Secara horizontal

• Meningkatkan Throughput melalui Replika: Untuk menangani volume permintaan pengguna serentak yang lebih tinggi untuk model yang sama, tingkatkan jumlah replicas dalam YAML deployment vLLM Anda.
• Instance Model Khusus: Karena vLLM dirancang sebagai mesin penayangan model tunggal dan menyematkan memori cache KV-nya saat inisialisasi, Anda harus men-deploy serangkaian pod terpisah untuk setiap LLM berbeda yang ingin dihosting.
• Load Balancing: Layanan Kubernetes GDC (jenis LoadBalancer) akan otomatis mendistribusikan permintaan inferensi yang masuk di antara semua endpoint pod vLLM yang sehat dan terkait dengan layanan tersebut.

Pemecahan masalah

Error	Mitigasi
FIPS SELFTEST FAILURE	Terjadi saat library seperti BoringSSL tidak memiliki tanda tangan integritas. Perbaiki dengan menyetel BORINGSSL_FIPS=0 dan menggunakan image vLLM resmi
Pemuatan Berat yang Tertunda	Periksa apakah ada throttling IOPS pada PVC kecil. Volume 500 GiB diperlukan untuk inisialisasi model performa.
Koneksi Ditolak	Pastikan PNP secara eksplisit mengizinkan targetPort (8000/8080). Firewall GDC tidak otomatis memberikan akses ke port backend untuk VIP Load Balancer.