This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.

Status	Authors	Coach	DRIs	Owning Stage	Created
ongoing	`@reprazent`	`@andrewn` `@stanhu`	`@m_gill` `@mksionek` `@marin`	devops modelops	2023-07-14

요약
언어: 파이썬
직접 연결된 클라이언트
API
임베딩
배포
대체 솔루션
결정사항
향후 작업
AI 스택의 다른 컴포넌트
- 모델 레지스트리
- AI 에이전트

AI-gateway

요약

AI-gateway는 모든 사용자들이 GitLab의 독립적인 서비스로 AI 기능에 액세스할 수 있게 해줍니다. 이 독립적인 서비스는 사용자가 Self-Managed, 전용 또는 GitLab.com을 사용하더라도 모두에게 사용 가능합니다.

초기에는 모든 AI-gateway 배포가 GitLab(조직)에서 관리되며, GitLab.com 및 모든 GitLab Self-Managed 인스턴스가 동일한 게이트웨이를 사용할 것입니다. 그러나 나중에 필요에 따라 리전별 게이트웨이 또는 특정 고객용 게이트웨이를 배포할 수도 있습니다.

AI-Gateway는 cloud.gitlab.com/ai/*로부터 트래픽을 처리하는 API-Gateway입니다. IDE는 현재는 간접적으로 cloud.gitlab.com/ai/*를 GitLab Rails 인스턴스를 통해 사용합니다. 나중에는 IDE 등 네트워크 엔드포인트가 cloud.gitlab.com에 직접 연결할 수 있도록 계획하고 있습니다(자세한 내용은 직접 연결된 클라이언트를 참조하세요). AI-Gateway는 이 트래픽을 다른 서비스(이 경우 AI-제공 업체와 그들의 모델)로 보냅니다. 이러한 북/남 트래픽 패턴을 통해 우리는 어디로 어떤 요청을 보낼지 제어하고 리디렉션된 요청의 내용을 필요에 따라 변환할 수 있습니다.

현재, 멀티 리전 배포는 지원되지 않습니다. 이는 고려 중인 기능입니다. 기존 다이어그램은 여러 리전에 걸쳐 배포하는 잠재적인 아키텍처를 보여줍니다.

다이어그램 출처

GitLab의 통제 하에 호스팅된 서비스를 사용함으로써 우리는 모든 GitLab 인스턴스에 확장 가능한 방식으로 AI 기능을 제공할 수 있습니다. GitLab Rails 및 이에 따른 의존성(데이터베이스, Redis)을 확장하는 것보다는 이러한 소규모 상태 없는 서비스의 확장이 더 쉽습니다.

이를 통해 Self-Managed 설치 사용자도 자체 모델을 호스팅하거나 타사 공급업체에 연결하지 않고도 AI를 사용할 수 있습니다.

언어: 파이썬

AI-Gateway는 원래 IDE(통합 개발 환경)에서 Code Suggestions을 제공하기 위해 시작된 “model-gateway”로, 파이썬으로 작성되었습니다.

파이썬은 루비 개발자가 쉽게 이해할 수 있는 객체 지향 언어로, 더 젊은 코드베이스인 AI-gateway에서 루비 개발자가 파이썬 경험이 있는 데이터 및 ML 엔지니어가 쉽게 기여할 수 있게 합니다.

직접 연결된 클라이언트

직접 연결은 아직 지원되지 않으며 이 작업은 이 에픽에서 추적됩니다.

결정: ADR-001: 직접 연결 허용

코드 완성 요청은 클라이언트에서 AI Gateway로 직접 전송되어 이러한 요청의 지연 시간을 개선할 것입니다. 요청이 AI Gateway로 직접 전송될지 또는 GitLab Rails로 추가 부가 정보를 받을지는 클라이언트가 결정할 것입니다. 직접 연결의 사용은 선택 사항이며 하위 호환성이 있습니다. 코드 완성 요청의 유형을 지정하지 않더라도 클라이언트가 이를 지원하지 않으면 현재와 같이 GitLab Rails을 통해 이러한 요청을 전송할 수 있습니다.

API

AI-gateway를 위한 기본 안정적인 API

AI-gateway의 API는 다양한 클라이언트에서 사용될 것이므로 안정적이면서 유연한 API를 설계하는 것이 중요합니다.

이를 위해 우리는 빌드하는 각 사용 사례에 대해 API 엔드포인트를 구현할 수 있습니다. 이는 클라이언트와 AI-gateway 사이의 인터페이스가 우리가 구축하고 소유하는 것임을 의미합니다. 이는 미래의 확장 가능성, 구성 가능성 및 보안을 보장합니다.

API는 버전이 지정되지 않지만 하위 호환성이 있습니다. 세부 정보는 버전 간 호환성을 참조하세요. AI-gateway는 최신 2개의 주요 버전을 지원할 것입니다. 예를 들어, GitLab 17.2에서 작업할 때 GitLab 17 및 GitLab 16을 모두 지원할 것입니다.

클라이언트가 AI Gateway에 직접 연결할 수 있기 때문에, 요청의 유사 기능(리미트 설정, 회로 차단기, 비밀 데이터 익스팅션)은 스택의 이 수준뿐만 아니라 GitLab Rails에도 추가해야 합니다.

프로토콜

AI-Gateway 서비스와 클라이언트(및 GitLab Rails 애플리케이션) 간의 통신은 JSON 기반의 API를 사용해야 합니다.

AI-Gateway API는 각기 다른 AI 기능에 대한 액세스를 제공하는 단일 목적의 엔드포인트를 노출해야 합니다. 나중에 제공되는 섹션에서 특정 엔드포인트를 구축하는 데 대한 상세 가이드라인을 제공합니다.

AI Gateway 통신 프로토콜은 기능별 동적 정보를 랩핑하는 기본적인 봉투만 예상해야 합니다. 제안된 프로토콜의 아키텍처는 API 엔드포인트가 버전에 독립적이고 AI-Gateway API가 GitLab(또는 게이트웨이를 사용하는 다양한 클라이언트)의 여러 버전과 호환될 수 있도록 합니다.

즉, 모든 클라이언트는 버전과 관계없이 동일한 AI-Gateway API 기능 엔드포인트 세트 사용합니다. AI-gateway 기능 엔드포인트는 다른 클라이언트 버전을 지원해야 하고, 지원되는 다른 클라이언트 버전당 여러 기능 엔드포인트를 생성하지 않아야 한다는 것을 의미합니다.

그러나 특정 엔드포인트를 진화시키고자 하는 경우 경로에 버전을 추가할 수 있습니다. 이것이 자주 필요할 것으로 예상되지는 않지만, 경로에 버전을 추가하면 개별 GitLab 마일스톤 릴리스는 릴리스 당시에 테스트된 엔드포인트 버전을 계속 가리키게 하면서 빠르게 반복적으로 새로운 엔드포인트 버전을 도입할 수 있습니다.

또한 gRPC를 GitLab 인스턴스 간 통신 프로토콜로 고려해 보았으나, JSON API와 gRPC는 다음과 같은 부분에서 차이가 있습니다:

gRPC	REST + JSON
+ 진화가 쉬운 버전 레스 프로토콜 정의를 지원	- 엄격한 스키마가 없으므로 구현은 다중 버전을 지원하는 데 주의를 기울여야 합니다
+ vscode를 위한 새로운 Ruby-gRPC 서버: 모듈화된 모놀리스(modular monolith)를 위해 의존성을 제한할 수 있기 때문에 빠를 것으로 예상됨	- vscode를 위한 기존의 Grape API: 느린 부팅 시간 및 불필요한 리소스 로딩을 의미
+ 양방향 스트리밍	- 요청과 응답을 스트리밍하는 간단한 방법(아직 추가할 수 있음)
- Python-gRPC 서버: gRPC-Python 서버 실행 경험이 없음	+ Code Suggestions의 Python fastapi 서버, 이미 확장 중
- vscode를 통해 GitLab까지 알 수 없는 메시지 전달이 어려움	+ 새로운 VS Code + 새로운 AI-gateway를 지원하기 위한 오래된 GitLab 인스턴스를 통한 더 쉬운 지원
- 다른 클라이언트(gRPC, jetbrains, 기타 편집기)에서 gRPC 지원 미지원	+ 모든 외부 클라이언트에서 지원
- 프로토콜 불일치 가능성(VSCode –REST–> Rails –gRPC–> AI gateway)	+ 스택 전반에서 동일한 프로토콜

토론: 이미 부분적으로 존재하는 기능을 이식하기 위해 이번 반복에서 REST+JSON을 선택했다고 하더라도 새로운 기능을 위해 gRPC 또는 웹소켓을 배제해야 한다는 뜻은 아닙니다. 예를 들어, 채팅 기능은 요청 및 응답을 스트리밍하는 것이 더 나을 수 있습니다. 한 사용 사례 당 엔드포인트를 제안하고 있기 때문에 다른 기능은 다른 프로토콜을 선택할 수도 있지만, 교차 버전 호환성을 염두에 둬야 합니다.

단일 목적 엔드포인트

AI를 사용하는 경우 안정적인 API를 가진 단일 목적 엔드포인트를 구축하는 것을 선호합니다. 노출된 AI-제공 업체에 대한 직접적인 프록시 대신 특정 엔드포인트를 갖는 것이 좋습니다.

일부 기능은 특정 엔드포인트를 갖지만, 다른 기능은 같은 엔드포인트를 사용할 수 있습니다. 예를 들어, 코드 제안 또는 채팅이 각각의 자체 엔드포인트를 갖거나 요청 페이로드에서 제공되는 정보에 따라 문제 또는 Merge Request을 요약하는 여러 기능은 동일한 엔드포인트를 사용할 수 있습니다.

우리의 목표는 GitLab 모노리스 코드베이스에 AI 관련 로직을 하드코딩하여 고객이 최신 기능을 채택하는 데 필요한 시간을 최소화하는 것입니다:

고객이 최신 기능을 채택하는 데 필요한 시간을 최소화하고,
오랜 시간 사용되는 오래된 인스턴스의 지원을 중단하지 않고 제품을 변경할 수 있는 유연성을 유지하고,
최소한의 복잡성으로 .com SaaS, Self-Managed 및 Dedicated와 같은 모든 GitLab 배포를 지원할 수 있게 합니다.
통합된 AI 능력으로 리스크를 줄이고 통제 평면을 통합할 수 있게 함으로써
다양한 AI 모델 및 AI 업체를 쉽게 지원할 수 있는 최고의 다중 모델 앙상블 접근법을 지원할 수 있습니다.
비용을 제어하고 메트릭할 수 있는 단일 지점을 제공합니다.
가능한 많은지 게이트웨이에만 기록함으로써 메트릭(사용 통계, 응답 실패, 사용 패턴, 질문 범주 등)을 분산되지 않은 많은 지점에 기록하게 될 수 있도록 합니다. (물론 일부 메트릭은 클라이언트 측에서만 캡처할 수 있습니다.)

GitLab Rails에서 비지니스 로직을 가져오면 고객이 GitLab 인스턴스를 업그레이드해야 하므로 첫 번째 지점에 영향을 미칩니다. 내부 사용자 중 일부는 회사 정책으로 인해 즉시 인스턴스를 업그레이드할 수 없습니다. 예를 들어, 만약 GitLab Rails에서 prompt 템플릿 버그가 있고, 16.6에서 이 버그가 수정된 경우 사용자가 16.5를 사용하고 다음 업그레이드가 3개월 후에 예정된 경우, 3개월 동안 버그가 있는 기능을 사용해야 합니다.

이것은 prompt를 AI-gateway 내에 구축해야 한다는 뜻은 아닙니다. 그러나 prompt가 단일 목적 엔드포인트로 분류될 경우 페이로드는 prompt가 AI gateway에서 더 이상 지원되지 않거나 다른 메타데이터와 함께 구축된 모델을 지정해야 합니다. 이를 통해 AI 랜드스케이프가 변경되었을 때 이전 GitLab 설치에서 기능을 파괴하지 않으려고 할 수 있습니다.

AI-Gateway API 프로토콜

각각의 목적 단일 엔드포인트를 버전에 구애 받지 않는 방식으로 구축하는 것이 중요하며, 그로 인해 다른 GitLab 인스턴스 및 외부 클라이언트에서 사용할 수 있습니다. 이 목표를 달성하기 위해:

AI-Gateway 프로토콜은 기능별 정보를 포장하는 단순한 JSON 랩핑에 의존해야합니다. AI-Gateway 프로토콜은 OSI 모델의 전송 레이어 프로토콜 (예: TCP, UDP)로 각 노드 간의 정보를 전송하는 방식을 정의하지만 전송되는 정보가 무엇인지는 모릅니다.

AI-Gateway 프로토콜은 목적 단일 엔드포인트가 받은 정보가 어떻게 처리되고 어떤 방식으로 사용될지를 명시하지 않습니다. 엔드포인트는 해당 프로토콜 래핑에서 가져온 데이터를 사용할지 또는 무시할지를 자유롭게 결정할 수 있습니다.

AI-Gateway 프로토콜은 각 요청을 다음과 같이 정의합니다:

각 목적 단일 엔드포인트는 prompt_components라는 단일 키를 포함하는 JSON 객체를 포함하는 요청을 허용해야합니다.
prompt_components 키는 다음 규칙에 따라 구축된 JSON 랩핑의 배열을 포함해야합니다.

각 JSON 랩핑은 3가지 요소를 포함합니다:

type: 래핑 내에서 제시되는 정보 유형을 지정하는 문자열 식별자입니다. AI-Gateway 목적 단일 엔드포인트는 알지 못하는 유형을 무시할 수 있습니다.
payload: 실제 정보로서, 버전 및 클라이언트가 제공하는 데이터 형식에 따라 payload 요소 내의 데이터가 달라질 수 있습니다. 이는 AI-Gateway 목적 단일 엔드포인트가 payload 내의 데이터의 구조 및 유형을 고려하고 누락되거나 형식이 잘못된 정보를 유연하게 처리해야함을 의미합니다.
metadata: 이 필드에는 해당 prompt_components 랩핑을 작성한 클라이언트에 대한 정보가 포함됩니다. metadata 필드의 정보는 GitLab에서 트래픽 분석에 사용되거나 사용되지 않을 수 있습니다. payload와 마찬가지로 metadata 내의 모든 필드는 선택 사항으로 간주되어야합니다.

예상되는 유일한 랩핑 필드는 payload 필드입니다. 여기서 모든 필드가 선택 사항임을 확인하고, 필드의 이름을 변경하거나 제거하거나 다른 용도로 사용하지 않도록해야합니다.

payload의 내용을 문서화하고 유효성을 검사하기 위해 JSON-schema을 사용하여 그 형식을 지정할 수 있습니다.

AI-Gateway 컴포넌트에 따른 예시 요청은 다음과 같습니다:

{
  "prompt_components": [
    {
      "type": "prompt",
      "metadata": {
        "source": "GitLab EE",
        "version": "16.7.0-pre",
      },
      "payload": {
        "content": "...",
        "params": {
          "temperature": 0.2,
          "maxOutputTokens": 1024
        },
        "model": "code-gecko",
        "provider": "vertex-ai"
      }
    },
    {
      "type": "editor_content",
      "metadata": {
        "source": "vscode",
        "version": "1.1.1"
      },
       "payload": {
        "filename": "application.rb",
        "before_cursor": "require 'active_record/railtie'",
        "after_cursor": "\nrequire 'action_controller/railtie'",
        "open_files": [
          {
            "filename": "app/controllers/application_controller.rb",
            "content": "class ApplicationController < ActionController::Base..."
          }
        ]
      }
    }
  ]
}

13. Change the semantic of all return values

GitLab 인스턴스의 API

로컬 GitLab 인스턴스에서 외부 클라이언트가 사용할 수 있는 API입니다. 예를 들어, VSCode가 Self-Managed형 인스턴스와 통신하는 경우입니다.

이러한 버전은 크게 다를 수 있습니다. VSCode 확장 프로그램이 개발자에 의해 최신 상태로 유지될 수 있습니다. 그러나 작업용으로 사용하는 GitLab 인스턴스는 이전 버전을 유지할 수 있습니다. 따라서 안정성과 유연성에 대한 요구 사항은 AI 게이트웨이 클라이언트에 대해 동일하게 적용됩니다. 첫 번째 반복에서는 VSCode 확장 프로그램과 Web-IDE가 보내는 현재 REST 페이로드를 유지할 수 있지만, 적합한 GitLab 설치로 직접 이를 전달 할 수 있습니다. GitLab Rails는 페이로드를 AI-게이트웨이에 대한 랩핑할 수 있습니다. 그러므로 이후에 이 페이로드를 해석할 필요가 없습니다.

::Discussion:: 이 첫 번째 반복은 REST+JSON 방식을 사용합니다. 현재 VSCode 확장 프로그램이 모델 게이트웨이와 통신하는 방식입니다. 이는 이미 존재하는 페이로드를 랩핑하는 것에서 더 큰 반복으로 이어질 수 있음을 의미합니다. 이로 인해 크로스 버전 호환성의 장점도 얻게 됩니다. 그러나 앞으로의 반복이 반드시 REST+JSON을 사용해야 하는 것은 아닙니다. 각 기능마다 자체 엔드포인트로, 프로토콜 또한 다를 수 있습니다. ## 인증 및 권한 부여

GitLab은 권한의 첫 번째 레이어를 제공합니다. 사용자를 인증하고 사용자가 사용하려는 기능을 라이선스가 허용하는지 확인합니다. 이는 이미 GitLab에 내장된 인증, 정책 및 라이선스 확인을 통해 수행될 수 있습니다.

AI-게이트웨이에서 GitLab-인스턴스의 인증은 다음에서 논의되었습니다. - 이슈 177 - Epic 10808

최종 사용자, GitLab 인스턴스 및 AI-게이트웨이 간의 신뢰 위임 방법은 클라우드 커넥터 액세스 컨트롤 문서에서 다루고 있습니다.

AI 게이트웨이는 클라우드 커넥터를 통해서만 접근할 수 있으며 인스턴스 인증을 처리합니다. 또한 클라우드 커넥터는 엔드 사용자 인증도 지원해야 합니다. 왜냐하면 일부 요청(예: 코드 완성)은 직접 클라이언트에서 보내야 하며, 모든 요청을 간접적으로 GitLab Rails을 통해 보내지 않아도 되기 때문입니다. 이에 대한 가능한 해결책은 Epic 13252에 설명되어 있습니다. AI 게이트웨이는 GitLab Rails에 의해 프록시된 요청과 직접 클라이언트 요청을 구별할 수 있어야 합니다. 왜냐하면 일부 엔드포인트나 매개변수는(E.g., 클라이언트는 최종 프롬프트를 보내지 못하고 AI 게이트웨이가 최종 프롬프트를 구성하는 하위 구성요소만 보내야 함 등) 직접 요청으로 사용할 수 없을 수 있기 때문입니다.

임베딩

모든 기능에 대해 임베딩을 단일 엔드포인트로 요청할 수 있습니다. 예를 들어, 다음과 같은 요청으로:

POST /internal/embeddings

{
  "content": "The lazy fox and the jumping dog",
  "content_type": "issue_title",
  "metadata": {
    "source": "GitLab EE",
    "version": "16.3"
  }
}

앞으로 content_type 및 content 속성은 적절한 기준에 따라 다른 모델에서 임베딩을 만드는 데 사용될 수 있습니다. 응답에는 사용된 제공자 및 모델과 함께 임베딩 벡터가 포함됩니다. 예를 들어:

{
  "response": [0.2, -1, ...],
  "metadata": {
    "identifier": "8badf00d",
    "model": "text-embedding-ada-002",
    "provider": "open_ai",
  }
}

임베딩을 저장할 때는 모델과 제공자 데이터를 반드시 포함해야 합니다. 임베딩을 사용하여 프롬프트를 생성할 때 페이로드에 해당 메타데이터를 포함하여 임베딩의 품질을 판단할 수 있습니다.

배포

현재 AI 게이트웨이가 될 모델 게이트웨이는 gitlab-org/modelops/applied-ml/code-suggestions/ai-assist의 프로젝트 리포지터리에서 배포됩니다.

이는 자체 프로젝트의 Kubernetes 클러스터로 배포됩니다. 현재 엔지니어들이 직접 테스트에 사용 중인 스테이징 환경이 있습니다.

앞으로, Runway를 사용하여 배포할 예정입니다. 그 때 라이브 및 스테이징 배포가 이루어질 것입니다. 스테이징 배포는 프로덕션 환경에 도달하는 것을 막을 수 있는 자동화된 QA 실행에 사용될 수 있습니다.

더 많은 테스트 전략은&10563에서 논의됩니다.

대체 솔루션

대체 솔루션에 대한 논의는 applied-ml/code-suggestions/ai-assist#161에서 이루어 졌습니다.

결정사항

향후 작업

AI 게이트웨이의 목표는 모노리스가 GitLab의 모든 사용 사례에서 머신 러닝 모델에 액세스하는 기본 방법이 되는 것입니다. 이를 위해 다음과 같은 세 가지 범주로 목표가 분할되어 있습니다.

AI 게이트웨이를 통한 중앙 집중화 된 액세스
Self-Managed형 AI 게이트웨이
유닛 프리미티브

중앙 집중화 된 액세스 Through AI Gateway

독립된 서비스인 AI 게이트웨이는 GitLab 설치와 제3 자 AI 모델 사이의 모든 통신의 유일한 접속 지점입니다. 이것은 앱 기능 또는 코드 제안과 같은 GitLab의 모든 기능에 대한 액세스를 중앙화하고 관리하는 것을 목표로 하고 있습니다.

Mnodel registry(../../../user/project/ml/model_registry/index.md)는 사용자가 GitLab을 사용하여 기계 학습 모델을 관리할 수 있는 기능입니다. 대규모 언어 모델에 중점을 두는 것이 아니며, 현재 주로 작은 모델 응용 프로그램에 초점을 맞추고 있으며, 여러가지 방식으로 배포 될 수 있습니다. 이러한 사용자 배포 모델들을 위해 AI 게이트웨이를 통해 액세스 가능한 API를 자동 구성할 수있는 능력은 중요한 기능일 수 있습니다.

유닛 프리미티브

유닛 프리미티브는 AI 게이트웨이를 통해 AI 기능에 대한 액세스를 관리하는 전략의 기본적인 부분입니다. 이들은 AI 게이트웨이를 통해 액세스하고 관리 될 수 있는 가장 작은 기능 단위를 나타냅니다.

이러한 접근 방식은 AI 게이트웨이를 통한 AI 기능 노출에 대한 더 세분화된 제어를 제공하며, 사용자가 배포한 모델 및 로컬 호스트 모델을 지원하는 작업에 대한 길을 열어줍니다. 비즈니스적인 측면에서 유닛 프리미티브는 다양한 티어나 패키지 모델을 이동할 수 있는가장 작은 부분을 나타내며, 우리의 제공에서 유연성과 적응성을 제공합니다.

초기 반복에서는 두 가지 프리미티브(Code Suggestions 및 Chat)를 지원할 예정입니다. 다음 반복에서는 Chat 프리미티브를 상위 수준 도구를 기반으로 여러 프리미티브로 분해할 계획입니다. 이 작업은 AI 게이트웨이로의 분류 이동 작업이 완료 되는 것에 의존합니다.

유닛 프리미티브의 도입은 AI 기능 관리를 간소화하고 AI 게이트웨이를 통해 노출되는 기능에 대한 더 세분화 된 제어를 제공합니다. 또한 사용자가 배포한 및 로컬 호스팅 모델을 지원하는 작업에 길을 열어줍니다.

자세한 내용은 Initial Set of Unit Primitives 이슈를 참조하세요.

AI 기능 액세스를 위한 유닛 프리미티브

Self-Managed형 AI 게이트웨이

Self-Managed형 인스턴스는 GitLab 호스팅 AI 게이트웨이를 사용하거나 자체 AI 게이트웨이를 사용하여 자체 배포된 모델을 사용할 수 있습니다. Runway가 배포 방법으로 사용될 것으로 예상됩니다. 이것은 우리의 작업 중 일부는 AI 게이트웨이가 Self-Managed형 환경에서 배포될 수 있도록 보장하는 것입니다. 이 작업은 GitLab AI 기능을 지원하기 위한 로컬 호스팅 모델(로컬 추론)을 지원하는 작업과 연계될 것입니다.

Self-Managed형 AI 게이트웨이

AI 스택의 다른 컴포넌트

AI 게이트웨이는 AI 기능 및 모델에 대한 액세스를 중앙 집중화하지만 사용자가 목표를 달성하는 데 도움을 주기 위해 다른 컴포넌트와 상호 작용합니다:

AI 에이전트: 에이전트 및 프롬프트를 생성하고 관리합니다.
모델 레지스트리: 머신 러닝 모델을 관리하고 배포합니다.

모델 레지스트리

모델 레지스트리는 사용자가 GitLab을 사용하여 머신 러닝 모델을 관리할 수 있는 기능입니다. 대형 언어 모델에만 초점을 맞춘 것은 아니며 현재는 더 작은 모델 애플리케이션에 더 집중되어 있으며, 독립 실행 라이브러리, 서비스, 파드, 클라우드 배포 등으로 배포될 수 있습니다. 이러한 사용자 배포 모델의 경우 AI 게이트웨이를 통해 접근할 수 있는 API를 자동으로 구성하는 기능은 중요할 수 있습니다.

AI 에이전트

AI 에이전트는 사용자가 자신의 채팅 및 AI 기능을 구현하고 관리할 수 있는 기능입니다. 프롬프트, 모델 및 도구를 관리합니다. 개발은 현재 초기 단계에 있습니다. 성숙해지면 GitLab 기능을 에이전트로 이동할 계획이지만 현재 해결해야 할 막혀 있는 문제가 있습니다:

프롬프트 템플릿 부족.
사용자 정의 프롬프트 복제 구현을 AI 게이트웨이로.
GitLab 정의 프롬프트를 Self-Managed형 설치로 복제하는 구현 (예: 몇 가지 에이전트를 미리 채워두는 조직 수준 에이전트).