微調 LLMOps 以實現快速模型評估和持續優化

大語言模型 (LLM) 為各行各業帶來了前所未有的機遇。然而，將 LLM 從研發轉向可靠、可擴展和可維護的生產系統會帶來獨特的運營挑戰。

LLMOps（大語言模型操作）旨在應對這些挑戰。它基于傳統機器學習操作（MLOps）的原則而構建，為管理從數據準備和模型微調到部署、監控和持續改進的整個LLM生命周期提供了框架。實施LLM會在整個制作流程和部署階段帶來一些重大挑戰，包括：

• 微調工作流管理：編排微調過程涉及管理大型模型、使用不同的超參數跟蹤大量實驗、確保結果的可重復性，以及高效使用分布式計算資源。
• 大規模評估：擴展評估的關鍵挑戰是超越簡單的指標來評估 LLM 輸出的主觀質量和安全性。在多智能體系統中，這一問題變得非常嚴重，因為單獨隔離和評估每個智能體節點的性能變得非常困難，并且給有效的大規模分析造成了重大障礙。
• 模型版本控制和沿襲：跟蹤經過微調的模型的沿襲（包括基礎模型版本、微調數據、超參數和評估結果）對于再現性、調試和監管合規性至關重要。高效管理和存儲大量大型模型構件也很困難。
• 推理服務復雜性：部署和服務 LLM 以實現低延遲和高吞吐量的實時推理，需要專用的服務框架、高效的模型加載 (特別是對于大型模型或 LoRA 等技術) ，以及根據需求進行動態擴展。優化不同硬件配置的推理性能是一項持續的挑戰。

Amdocs 是一家專門從事電信解決方案的公司，他們正在應對這些挑戰，以克服實施自定義 LLM 的復雜性，并加速其 AI 計劃。Amdocs 基于 NVIDIA AI Blueprint 構建了強大的 LLMOps 流程，用于構建數據飛輪，該流程使用 NVIDIA NeMo 微服務進行簡化的微調、評估、guardrailing 和 serving，并將其作為 NVIDIA NIM 提供，以實現高效、可擴展的部署。

它們的采用是由云原生的 GitOps 方法專門推動的，用于自動化和聲明性管理。在本博文中，我們將深入研究他們正在使用的架構，展示此堆棧如何解決關鍵的 LLMOps 挑戰，并重點介紹結果。

Amdocs 數據科學家 Liad Levi-Raz 表示：“利用由 GitOps 編排的 NVIDIA NeMo 微服務和 NVIDIA NIM 堆棧，從根本上改變了我們迭代和部署 LLM 的能力。我們將其集成到 CI/CD 自動化系統中，從而快速高效地評估新的 LLM，確保它們適合我們的用例。作為一名數據科學家，我只能專注于 LLM 微調，而不必擔心基礎架構細節。”

NVIDIA Nemo 微服務

NVIDIA NeMo 微服務旨在促進 LLM 的持續改進周期，通常被視為“Enterprise AI Flywheel”。該飛輪概念強調了 LLMOps 的迭代性質，即從部署模型中獲得的見解和新數據會反饋到開發過程中，從而不斷提高 LLM 的性能和能力，并優化模型。

此飛輪概念是 NVIDIA AI Blueprint 的一部分，用于構建數據飛輪，這是一種基于 NVIDIA NeMo 微服務構建的參考架構。下圖說明了此概念以及其中關鍵 NeMo 微服務的作用。

此迭代過程始于 NeMo Curator 整理和處理的企業數據，用于數據處理。準備好的數據由 NVIDIA NeMo Customizer 定制，并由 NVIDIA NeMo Evaluator 進行評估。NeMo Guardrails 為基礎模型用例提供了一層安全和對齊功能。

最后，該模型可以部署為 NVIDIA NIM，用于高級推理。NVIDIA NIM 旨在加速和簡化生成式 AI 模型的部署。它提供了一種標準化的方法，將這些模型打包和部署為容器化微服務，并優化其推理性能。

案例研究：Amdocs amAIz GenAI 平臺

為了應對 LLMOps 挑戰，尤其是快速可靠地驗證新的 LLM，Amdocs 采用了基于 GitOps 的強大 LLMOps 策略。這種方法使用 NVIDIA AI Blueprint 構建數據飛輪，并直接集成到其現有 amAIz 平臺的 CI/CD 工作流中。這可為考慮由 amAIz Suite 使用的任何新發布的 LLM 提供強大的評估和關鍵回歸測試。通過提供 LLM 的配置，該過程（包括在 NVIDIA DGX Cloud 上運行的 Kubernetes 集群上部署依賴 GPU 的組件）將自動觸發。在下一節中，我們將演示基于 GitOps 的 LLMOps 管道。

基于 GitOps 的 LLMOps 方法

本節將詳細介紹并演示基于 GitOps 構建的 LLMOps 工作流。圖 2 顯示了構建的 LLMOps 工作流的高級工作流圖。在圖的上半部分，我們展示了在 Amdocs 環境中部署的組件，而下半部分是在 NVIDIA DGX 云中部署的組件。

Amdocs 環境中的組件包括：

• Git 存儲庫：作為單一事實來源的版本控制系統。它存儲所有配置文件和工作流定義，數據科學家提交更改，ArgoCD 從中提取更新。
• 管理 Kubernetes 集群：Amdocs 中的核心編排環境，托管 ArgoCD 和 Argo Workflow。此 Kubernetes 集群通過 Azure Kubernetes Service (AKS) 創建，并且僅具有基于 CPU 的計算節點。
• ArgoCD：適用于 Kubernetes 的持續交付工具。它會持續監控 Git Repository 中的更改，拉取更改并同步 Kubernetes 集群以匹配所需狀態。它還可觸發將需要 GPU 的微服務和其他組件部署到 NVIDIA DGX Cloud。
• Argo 工作流：在 Kubernetes 集群內運行的工作流執行引擎，負責創建和執行 LLM 工作流。
• LLM 工作流組件：適用于 LLM 工作流的預定義、可重復使用的基礎模組。LLM 工作流模板參考了這些內容。這些組件基于 Argo Workflows 的 ClusterWorkflowTemplate 資源。ClusterWorkflowTemplate 是可重用工作流程的集群范圍定義，或可跨不同命名空間引用的工作流程步驟的模板。這實現了標準化和可共享的自動化邏輯。有關更多詳細信息，請參閱 Argo 集群工作流模板文檔。以下展示了此類組件的示例，其中定義了 NeMo 自定義步驟：

apiVersion: argoproj.io/v1alpha1
kind: ClusterWorkflowTemplate
metadata:
  name: nemo-customization-template
spec:
  templates:
    - name: nemo-customization
      inputs:
        parameters:
          - name: nemo_customizer_endpoint
          - name: dataset_name
          - name: dataset_namespace
          - name: config
          - name: output_model
          - name: name
          - name: training_type
          - name: finetuning_type
          - name: batch_size
          - name: epochs
          - name: learning_rate
          - name: adapter_dim
          - name: adapter_dropout
      container:
        image: ubuntu:24.10
        command: [/bin/bash, -c]
        args:
          - |
            apt-get update && apt-get install git curl jq -y && \
            curl -k -X POST "{{ inputs.parameters.nemo_customizer_endpoint }}/v1/customization/jobs" \
              -H 'accept: application/json' \
              -H 'Content-Type: application/json' \
              -d '{
                  "name": "{{inputs.parameters.name}}",
                  "output_model": "{{inputs.parameters.output_model}}",
                  "config": "{{inputs.parameters.config}}",
                  "dataset": {
                      "name": "{{inputs.parameters.dataset_name}}",
                      "namespace": "{{inputs.parameters.dataset_namespace}}"
                  },
                  "hyperparameters": {
                      "training_type": "{{inputs.parameters.training_type}}",
                      "finetuning_type": "{{inputs.parameters.finetuning_type}}",
                      "batch_size": {{inputs.parameters.batch_size}},
                      "epochs": {{inputs.parameters.epochs}},
                      "learning_rate": {{inputs.parameters.learning_rate}},
                      "lora": {
                          "adapter_dim": {{inputs.parameters.adapter_dim}},
                          "adapter_dropout": {{inputs.parameters.adapter_dropout}}
                      }
                  }
              }' \
            | jq -r '.id' > /tmp/customization_id.txt && \
            cat /tmp/customization_id.txt
      outputs:
        parameters:
        - name: customization_ids
          valueFrom:
            path: /tmp/customization_id.txt

這個名為 nemo-customization-template 的 ClusterWorkflowTemplate 定義了一個可重復使用的步驟，用于通過 NeMo Customizer 微服務 API 觸發模型自定義 (fine-tuning) 作業。它接受各種參數作為輸入，例如 NeMo Customizer 的端點、數據集 ID、父模型 ID 和用于訓練的超參數。容器內的 curl 命令對 NeMo Customizer 進行 API 調用，并傳遞這些參數以開始自定義過程。輸出捕獲定制 ID，以便在工作流中執行后續步驟。

• LLM 工作流模板：這些模板基于 ArgoWorkflow 模板資源，是完成 LLM 任務的可重復使用藍圖。它們定義了 LLM 工作流的結構和操作順序。這些模板參考并結合了各種 LLM 工作流組件 (例如 nemo-customization-template) ，以形成一個完整的工作流。運算序列可以是線性的 (簡單的步驟序列) ，也可以是有向無環圖 (DAG) ，用于并行執行和組件之間的復雜依賴關系。圖 3 展示了用于微調的高級 LLM 工作流程。圖中的每個框代表在整個工作流中執行特定任務的組件。

NeMo 微服務、NVIDIA NIM 的部署以及微調和評估作業的執行均在 NVIDIA DGX 云上自動完成，如圖 2 所示。通過將 Amdocs 的 ArgoCD 實例與 DGX 云中運行的專用 Kubernetes 集群集成，這有助于實現這一點。所有定向到此集群的傳入請求都會首先通過網關傳遞，然后網關會智能地將它們路由到 Kubernetes 入口控制器或直接路由到 Kube-API 服務器，確保高效、安全地訪問已部署的組件和觸發的作業。

LLMOps 工作流的實際應用

LLMOps 工作流始于數據集準備。上傳電信行業特定數據，包括客戶賬單數據。然后，系統會自動對其進行格式化，并將其拆分成訓練集和測試集。這些數據會經歷轉換、匿名化和標記化，并且可以使用 NVIDIA NeMo 框架功能進行綜合擴展。

在此用例中，Amdocs 需要一個帶標注的數據集。Amdocs 創建了一個緊湊的調優數據集，包含數十個示例，以及預期的輸入和輸出。表 1 突出顯示了樣本數據集。

系統會將數據集上傳到 NVIDIA NeMo Data Store。接下來，工作流將新的基礎 LLM 部署為 NIM (例如 LLaMA 3.1 8B – instruct)。

之后，使用 Parameter-Efficient Fine-Tuning (PEFT) 的模型（如 LoRA）使用 Nemo Customizer 在 Nemo Data Store 中存儲的準備數據子集上運行。該工作流會自動發現用于微調的最佳超參數，并通過 Nemo Customizer 將生成的模型上傳到 Nemo Data Store。

之后，使用 NeMo Evaluator 觸發多階段評估過程。

該工作流通過對原始基礎模型和使用 GSM8K、SQuAD、GLUE 和 SuperGLUE 等各種標準化基準對微調模型運行回歸測試來執行評估基準測試。此步驟是一項關鍵的回歸測試，可確保新模型的通用功能不會受到負面影響。

接下來，進行特定的業務評估。這涉及比較基礎模型和微調模型的預測，并使用定制化程度更高的基準 (LLM-as-a-judge，使用自定義數據集和自定義指標) 使用相關指標來分析性能。領域專家對確定的高性能模型進行最終人工評估，以確保符合業務需求。然后，使用適用于LLM的NVIDIA NIM部署選定的微調LoRA模型適配器。

在此工作流中，Git 充當單一事實來源，數據科學家在代碼中提交 LLM 工作流，DevOps 團隊則管理基礎設施配置。整個流程由 Argo 編排：ArgoCD 持續監控存儲庫，以在 Kubernetes 上部署和同步微服務，而 Argo Workflows 則使用 NeMo 微服務在 NVIDIA DGX 云上執行模型微調和評估等要求嚴苛的任務。這還實現了開發敏捷性，使科學家能夠在與 NeMo 微服務 API 直接交互的 Jupyter Notebook 中進行交互實驗。為實現全面監督，MLflow 已無縫集成，可自動捕獲所有實驗指標以進行分析。

這種集成的 GitOps 方法為 LLMOps 工作流提供了一個強大的自動化編排層，并且由于所有配置和工作流定義都在 Git 中進行版本控制，因此具有可重復性。用戶還可以快速找到性能信息和新模型的適用性，無需人工干預，從而加快其 AI 采用周期。

結果

評估結果顯示了微調過程在多個維度上的優勢。使用 TriviaQA 等標準基準進行的回歸測試確認，經過微調的模型保留了核心能力而不會降低，達到了與基礎模型相匹配的 0.6 分。

微調可提升特定任務的性能，即使僅使用 50 個訓練示例，LoRA 微調版本的精度也達到 0.83，如圖 4 所示。這優于基礎 Llama 3.1-8b-instruct 模型評分 0.74。

這一改進不僅限于量化指標。定性分析顯示了為生成格式正確且準確的結果而學習的經過微調的模型，該模型用于識別未發現賬單的時間，而基礎模型在這些特定實例中失敗了，如 Figure 5 所示。

為了獲得針對特定領域的更深入見解，我們評估的一個關鍵部分是自定義 LLM-as-a-judge。此方法使用專門的judge LLM 將回復與人類精心策劃的參考進行比較，并采用與應用程序 KPI 保持一致的自定義數據集和指標來評估正確性、相關性和流暢性。

這種方法的靈活性和魯棒性使跨多個維度的定制評估成為可能。這項先進技術與自動基準測試和相似性指標相結合，可提供全面的性能視圖并建立數據飛輪，從而實現迭代循環，通過一致的重復性評估不斷提高微調模型的質量。然后，較小的模型可以為生產級工作流提供動力支持，同時優化性能和成本。

總結

運營 LLM 帶來了重大挑戰，特別是在工作流復雜性、大規模部署以及確保持續性能和安全性方面。該架構使用 NVIDIA AI Blueprint 構建數據飛輪，其中包括用于持續微調和評估的 NVIDIA NeMo 微服務、用于高效推理的 NVIDIA NIM，以及通過 ArgoCD 和 Argo Workflow 進行的 GitOps 編排，這表明構建強大的 LLMOps 工作流是可以實現的。該堆棧促進了自動化工作流程，實現了類似于數據飛輪的持續改進周期，并直接解決了在生產環境中管理 LLM 的許多核心復雜性。該案例研究強調了將此類管道集成到現有的 CI/CD 流程中，以實現快速微調的實際優勢。

詳細了解與 Amdocs 和 NVIDIA 的合作。

開始使用適用于數據飛輪的 NVIDIA AI Blueprint，并探索 AI 賦能的電信運營。

?