이 글은 Iambic Therapeutics의 리더십 팀과 공동으로 작성한 게스트 포스트입니다.
Iambic 치료제 암 환자에게 더 나은 의약품을 더 빠르게 제공하기 위해 혁신적인 AI 기반 기술을 개발한다는 사명을 가진 신약 발견 스타트업입니다.
당사의 고급 생성 및 예측 인공 지능(AI) 도구를 사용하면 가능한 약물 분자의 광대한 공간을 더 빠르고 효과적으로 검색할 수 있습니다. 당사의 기술은 다재다능하며 치료 영역, 단백질 종류 및 작용 메커니즘 전반에 걸쳐 적용 가능합니다. 차별화된 AI 도구를 만드는 것을 넘어 AI 소프트웨어, 클라우드 기반 데이터, 확장 가능한 컴퓨팅 인프라, 높은 처리량의 화학 및 생물학 기능을 통합하는 통합 플랫폼을 구축했습니다. 플랫폼은 모델을 개선하기 위한 데이터를 제공하여 AI를 활성화하고 자동화된 의사 결정 및 데이터 처리 기회를 활용하여 AI를 활성화합니다.
우리는 전례 없는 속도로 긴급한 환자 요구 사항을 해결하기 위해 우수한 임상 후보를 생산하는 능력으로 성공을 측정합니다. 우리는 경쟁사보다 훨씬 빠른 속도로 프로그램 출시부터 단 24개월 만에 임상 후보로 발전했습니다.
이번 포스팅에서는 우리가 어떻게 사용했는지에 초점을 맞췄습니다. 카펜터 on Amazon Elastic Kubernetes 서비스 (Amazon EKS)는 Iambic 발견 플랫폼의 핵심 요소인 AI 훈련 및 추론을 확장합니다.
확장 가능한 AI 훈련 및 추론의 필요성
매주 Iambic은 수십 개의 모델과 수백만 개의 분자에 대해 AI 추론을 수행하여 두 가지 주요 사용 사례를 제공합니다.
- 의약 화학자와 기타 과학자들은 당사의 웹 애플리케이션인 Insight를 사용하여 화학 공간을 탐색하고 실험 데이터에 액세스 및 해석하며 새로 설계된 분자의 특성을 예측합니다. 이 모든 작업은 실시간으로 대화형으로 수행되므로 대기 시간이 짧고 처리량이 중간인 추론이 필요합니다.
- 동시에 당사의 생성적 AI 모델은 수많은 속성 전반에 걸쳐 개선을 목표로 하는 분자를 자동으로 설계하고 수백만 명의 후보를 검색하며 엄청난 처리량과 중간 대기 시간을 요구합니다.
AI 기술과 전문 약물 사냥꾼의 도움을 받아 우리의 실험 플랫폼은 매주 수천 개의 고유한 분자를 생성하며 각 분자는 여러 생물학적 분석을 거칩니다. 생성된 데이터 포인트는 자동으로 처리되어 매주 AI 모델을 미세 조정하는 데 사용됩니다. 처음에는 모델을 미세 조정하는 데 몇 시간의 CPU 시간이 걸렸으므로 GPU에서 모델 미세 조정을 확장하기 위한 프레임워크가 필수적이었습니다.
우리의 딥 러닝 모델에는 적지 않은 요구 사항이 있습니다. 크기가 기가바이트에 달하고, 수가 많고 이질적이며, 빠른 추론과 미세 조정을 위해 GPU가 필요합니다. 클라우드 인프라를 고려하면서 우리는 GPU에 액세스하고, 급증하는 이기종 워크로드를 처리하기 위해 빠르게 확장 및 축소하고, 대규모 Docker 이미지를 실행할 수 있는 시스템이 필요했습니다.
우리는 AI 훈련과 추론을 지원하는 확장 가능한 시스템을 구축하고 싶었습니다. 우리는 Amazon EKS를 사용하며 작업자 노드를 자동 확장할 수 있는 최상의 솔루션을 찾고 있었습니다. 우리는 여러 가지 이유로 Kubernetes 노드 자동 확장을 위해 Karpenter를 선택했습니다.
- Kubernetes 의미론을 사용하여 확장을 위한 노드 요구 사항 및 포드 사양을 정의하여 Kubernetes와의 통합 용이성
- 지연 시간이 짧은 노드 확장
- 코드 도구로서의 인프라와의 통합 용이성(Terraform)
노드 프로비저너는 Amazon EKS 및 다음과 같은 기타 AWS 리소스와의 간편한 통합을 지원합니다. 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 인스턴스 및 아마존 엘라스틱 블록 스토어 볼륨. 프로비저너가 사용하는 Kubernetes 의미 체계는 오염 또는 허용 및 선호도 또는 반선호도 사양과 같은 Kubernetes 구성을 사용하여 지시된 예약을 지원합니다. 또한 Karpenter가 예약할 수 있는 GPU 인스턴스의 수와 유형을 쉽게 제어할 수 있습니다.
솔루션 개요
이 섹션에서는 자체 워크로드에 사용하는 것과 유사한 일반 아키텍처를 제시합니다. 이를 통해 사용자 지정 지표를 기반으로 효율적인 자동 확장을 사용하여 모델을 탄력적으로 배포할 수 있습니다.
다음 다이어그램은 솔루션 아키텍처를 보여줍니다.
아키텍처는 간단한 서비스 Kubernetes 포드 내의 EKS 클러스터. 이는 모델 추론, 데이터 시뮬레이션 또는 HTTP 요청으로 액세스할 수 있는 기타 컨테이너화된 서비스일 수 있습니다. 서비스는 다음을 사용하여 역방향 프록시 뒤에 노출됩니다. Traefik. 역방향 프록시는 서비스 호출에 대한 측정항목을 수집하고 이를 표준 측정항목 API를 통해 공개합니다. 프로 메테우스. Kubernetes 이벤트 기반 자동 확장 처리(케다)은 Prometheus에서 사용할 수 있는 사용자 정의 지표를 기반으로 서비스 Pod 수를 자동으로 확장하도록 구성됩니다. 여기서는 초당 요청 수를 사용자 정의 지표로 사용합니다. 워크로드에 대해 다른 지표를 선택하는 경우에도 동일한 아키텍처 접근 방식이 적용됩니다.
Karpenter는 클러스터의 리소스 부족으로 인해 실행할 수 없는 보류 중인 Pod를 모니터링합니다. 이러한 포드가 감지되면 Karpenter는 클러스터에 더 많은 노드를 추가하여 필요한 리소스를 제공합니다. 반대로 클러스터에 예약된 포드에 필요한 것보다 더 많은 노드가 있는 경우 Karpenter는 일부 작업자 노드를 제거하고 포드를 다시 예약하여 더 적은 수의 인스턴스에 통합합니다. 초당 HTTP 요청 수와 노드 수는 다음을 사용하여 시각화할 수 있습니다. 그라 파나 계기반. 자동 크기 조정을 시연하기 위해 하나 이상의 실행 간단한 로드 생성 포드, 다음을 사용하여 서비스에 HTTP 요청을 보냅니다. 컬.
솔루션 배포
. 단계별 연습, 우리는 사용 AWS 클라우드9 아키텍처를 배포할 환경으로 사용됩니다. 이를 통해 웹 브라우저에서 모든 단계를 완료할 수 있습니다. 로컬 컴퓨터나 EC2 인스턴스에서 솔루션을 배포할 수도 있습니다.
배포를 단순화하고 재현성을 향상시키기 위해 우리는 다음의 원칙을 따릅니다. 수행 프레임워크 및 구조 의존성 도커 템플릿. 우리는 AWS-DO-EKS 프로젝트 및 사용 도커, 필요한 도구와 스크립트를 갖춘 컨테이너 이미지를 구축합니다. 컨테이너 내에서 Karpenter를 사용하여 EKS 클러스터를 생성하는 것부터 확장까지 엔드투엔드 연습의 모든 단계를 실행합니다. EC2 인스턴스.
이 게시물의 예에서는 다음을 사용합니다. EKS 클러스터 매니페스트:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: do-eks-yaml-karpenter
version: '1.28'
region: us-west-2
tags:
karpenter.sh/discovery: do-eks-yaml-karpenter
iam:
withOIDC: true
addons:
- name: aws-ebs-csi-driver
version: v1.26.0-eksbuild.1
wellKnownPolicies:
ebsCSIController: true
managedNodeGroups:
- name: c5-xl-do-eks-karpenter-ng
instanceType: c5.xlarge
instancePrefix: c5-xl
privateNetworking: true
minSize: 0
desiredCapacity: 2
maxSize: 10
volumeSize: 300
iam:
withAddonPolicies:
cloudWatch: true
ebs: true
이 매니페스트는 do-eks-yaml-karpenter
EBS CSI 드라이버가 애드온으로 설치되어 있습니다. 두 개의 관리형 노드 그룹 c5.xlarge
클러스터에 필요한 시스템 포드를 실행하기 위해 노드가 포함됩니다. 작업자 노드는 프라이빗 서브넷에서 호스팅되며 클러스터 API 엔드포인트는 기본적으로 퍼블릭입니다.
클러스터를 생성하는 대신 기존 EKS 클러스터를 사용할 수도 있습니다. 우리는 다음을 따라 Karpenter를 배포합니다. 명령 Karpenter 문서에서 또는 다음을 실행하여 스크립트, 배포 지침을 자동화합니다.
다음 코드는 이 예에서 사용하는 Karpenter 구성을 보여줍니다.
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
metadata: null
labels:
cluster-name: do-eks-yaml-karpenter
annotations:
purpose: karpenter-example
spec:
nodeClassRef:
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values:
- spot
- on-demand
- key: karpenter.k8s.aws/instance-category
operator: In
values:
- c
- m
- r
- g
- p
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values:
- '2'
disruption:
consolidationPolicy: WhenUnderutilized
#consolidationPolicy: WhenEmpty
#consolidateAfter: 30s
expireAfter: 720h
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "do-eks-yaml-karpenter"
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "do-eks-yaml-karpenter"
role: "KarpenterNodeRole-do-eks-yaml-karpenter"
tags:
app: autoscaling-test
blockDeviceMappings:
- deviceName: /dev/xvda
ebs:
volumeSize: 80Gi
volumeType: gp3
iops: 10000
deleteOnTermination: true
throughput: 125
detailedMonitoring: true
다음 요구 사항에 따라 기본 Karpenter NodePool을 정의합니다.
- Karpenter는 두 가지 모두에서 인스턴스를 시작할 수 있습니다.
spot
및on-demand
용량 풀 - 인스턴스는 '
c
"(컴퓨팅 최적화), "m
”(일반용), “r
”(메모리 최적화) 또는 “g
"및"p
” (GPU 가속) 컴퓨팅 제품군 - 인스턴스 생성은 2보다 커야 합니다. 예를 들어,
g3
허용되지만g2
하지 않습니다
기본 NodePool은 중단 정책도 정의합니다. 활용률이 낮은 노드가 제거되므로 포드를 통합하여 더 적거나 더 작은 노드에서 실행할 수 있습니다. 또는 지정된 기간 후에 빈 노드가 제거되도록 구성할 수 있습니다. 그만큼 expireAfter
설정은 노드가 중지되고 필요한 경우 교체되기 전 노드의 최대 수명을 지정합니다. 이를 통해 보안 취약성을 줄이고 가동 시간이 긴 노드에서 일반적으로 발생하는 파일 조각화 또는 메모리 누수 등의 문제를 방지할 수 있습니다.
기본적으로 Karpenter는 AI 또는 기계 학습(ML) 워크로드를 실행하는 데 충분하지 않을 수 있는 작은 루트 볼륨으로 노드를 프로비저닝합니다. 일부 딥 러닝 컨테이너 이미지의 크기는 수십 GB에 달할 수 있으며, 이러한 이미지를 사용하여 Pod를 실행하기에 충분한 저장 공간이 노드에 있는지 확인해야 합니다. 그러기 위해 우리는 다음을 정의합니다. EC2NodeClass
과 blockDeviceMappings
, 이전 코드에 표시된 대로.
Karpenter는 클러스터 수준에서 자동 크기 조정을 담당합니다. Pod 수준에서 Auto Scaling을 구성하기 위해 KEDA를 사용하여 다음과 같은 사용자 지정 리소스를 정의합니다. ScaledObject
, 다음 코드와 같이
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: keda-prometheus-hpa
namespace: hpa-example
spec:
scaleTargetRef:
name: php-apache
minReplicaCount: 1
cooldownPeriod: 30
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus- server.prometheus.svc.cluster.local:80
metricName: http_requests_total
threshold: '1'
query: rate(traefik_service_requests_total{service="hpa-example-php-apache-80@kubernetes",code="200"}[2m])
앞의 매니페스트는 다음을 정의합니다. ScaledObject
이름 keda-prometheus-hpa
, php-apache 배포 확장을 담당하고 항상 하나 이상의 복제본을 실행 상태로 유지합니다. 측정항목을 기반으로 이 배포의 Pod를 확장합니다. http_requests_total
지정된 쿼리로 얻은 Prometheus에서 사용할 수 있으며, 각 Pod가 초당 30개 이하의 요청을 처리하도록 Pod를 확장하는 대상이 있습니다. 요청 로드가 XNUMX초 이상 임계값 미만인 경우 복제본을 축소합니다.
XNUMXD덴탈의 배포 사양 예제 서비스의 경우 다음이 포함됩니다. 리소스 요청 및 제한:
resources:
limits:
cpu: 500m
nvidia.com/gpu: 1
requests:
cpu: 200m
nvidia.com/gpu: 1
이 구성을 사용하면 각 서비스 포드는 정확히 하나의 NVIDIA GPU를 사용합니다. 새 포드가 생성되면 GPU를 사용할 수 있을 때까지 보류 상태로 유지됩니다. Karpenter는 보류 중인 포드를 수용하기 위해 필요에 따라 클러스터에 GPU 노드를 추가합니다.
A 부하 생성 포드 미리 설정된 빈도로 서비스에 HTTP 요청을 보냅니다. 복제본 수를 늘려 요청 수를 늘립니다. 부하 생성기 배포.
활용도 기반 노드 통합을 통한 전체 확장 주기가 Grafana 대시보드에 시각화됩니다. 다음 대시보드에는 인스턴스 유형별 클러스터의 노드 수(상단), 초당 요청 수(왼쪽 하단) 및 Pod 수(오른쪽 하단)가 표시됩니다.
클러스터를 생성하는 데 사용한 두 개의 c5.xlarge CPU 인스턴스로 시작합니다. 그런 다음 단일 GPU가 필요한 하나의 서비스 인스턴스를 배포합니다. Karpenter는 이러한 요구 사항을 충족하기 위해 g4dn.xlarge 인스턴스를 추가합니다. 그런 다음 로드 생성기를 배포하면 KEDA가 더 많은 서비스 포드를 추가하고 Karpenter가 더 많은 GPU 인스턴스를 추가하게 됩니다. 최적화 후 상태는 3.8개의 GPU가 있는 하나의 p8xlarge 인스턴스와 5.12개의 GPU가 있는 하나의 g4xlarge 인스턴스로 결정됩니다.
로드 생성 배포를 40개의 복제본으로 확장하면 KEDA는 포드당 필요한 요청 로드를 유지하기 위해 추가 서비스 포드를 생성합니다. Karpenter는 클러스터에 g4dn.metal 및 g4dn.12xlarge 노드를 추가하여 추가 Pod에 필요한 GPU를 제공합니다. 확장된 상태에서 클러스터는 16개의 GPU 노드를 포함하고 초당 약 300개의 요청을 처리합니다. 부하 생성기를 1개의 복제본으로 축소하면 반대 프로세스가 발생합니다. 휴지 기간이 지나면 KEDA는 서비스 포드 수를 줄입니다. 그런 다음 더 적은 수의 포드가 실행됨에 따라 Karpenter는 클러스터에서 활용률이 낮은 노드를 제거하고 서비스 포드는 더 적은 수의 노드에서 실행되도록 통합됩니다. 로드 생성기 포드가 제거되면 GPU 4개가 포함된 단일 g1dn.xlarge 인스턴스의 단일 서비스 포드가 계속 실행됩니다. 서비스 포드도 제거하면 클러스터는 CPU 노드가 XNUMX개만 있는 초기 상태로 유지됩니다.
우리는 다음과 같은 경우에 이 동작을 관찰할 수 있습니다. NodePool
설정이 있어요 consolidationPolicy: WhenUnderutilized
.
이 설정을 사용하면 Karpenter는 가능한 한 적은 수의 노드로 클러스터를 동적으로 구성하는 동시에 모든 포드를 실행할 수 있는 충분한 리소스를 제공하고 비용도 최소화합니다.
다음 대시보드에 표시된 크기 조정 동작은 NodePool
통합 정책은 다음과 같이 설정됩니다. WhenEmpty
, 와 함께 consolidateAfter: 30s
.
이 시나리오에서는 냉각 기간 이후 노드에서 실행 중인 포드가 없는 경우에만 노드가 중지됩니다. 활용도 기반 통합 정책에 비해 확장 곡선이 매끄러워 보입니다. 그러나 확장된 상태에서는 더 많은 노드가 사용되는 것을 볼 수 있습니다(22 대 16).
전반적으로 포드와 클러스터 자동 확장을 결합하면 클러스터가 워크로드에 따라 동적으로 확장되어 필요할 때 리소스를 할당하고 사용하지 않을 때는 제거하여 활용도를 최대화하고 비용을 최소화할 수 있습니다.
결과
Iambic은 이 아키텍처를 사용하여 AWS에서 GPU를 효율적으로 사용하고 워크로드를 CPU에서 GPU로 마이그레이션했습니다. EC2 GPU 기반 인스턴스, Amazon EKS 및 Karpenter를 사용하여 물리 기반 모델에 대한 더 빠른 추론을 지원하고 서비스로서의 교육에 의존하는 응용 과학자를 위한 빠른 실험 반복 시간을 지원했습니다.
다음 표에는 이 마이그레이션의 일부 시간 측정항목이 요약되어 있습니다.
태스크 | CPU | GPU |
물리 기반 ML 모델에 확산 모델을 사용한 추론 | 3,600 초 |
100 초 (GPU 고유의 일괄 처리로 인해) |
서비스로서의 ML 모델 교육 | 180 분 | 4 분 |
다음 표에는 시간 및 비용 지표 중 일부가 요약되어 있습니다.
태스크 | 성능/비용 | |
CPU | GPU | |
ML 모델 학습 |
240 분 훈련 작업당 평균 $0.70 |
20 분 훈련 작업당 평균 $0.38 |
요약
이 게시물에서는 Iambic이 Karpenter와 KEDA를 사용하여 Amazon EKS 인프라를 확장하여 AI 추론 및 교육 워크로드의 지연 시간 요구 사항을 충족하는 방법을 보여주었습니다. Karpenter와 KEDA는 EKS 클러스터와 여기에서 실행되는 워크로드를 자동으로 확장하는 데 도움이 되는 강력한 오픈 소스 도구입니다. 이는 성능 요구 사항을 충족하면서 컴퓨팅 비용을 최적화하는 데 도움이 됩니다. 이 문서의 전체 연습을 따르면 코드를 확인하고 자신의 환경에 동일한 아키텍처를 배포할 수 있습니다. GitHub 레포.
저자에 관하여
매튜 웰본 Iambic Therapeutics의 기계 학습 담당 이사입니다. 그와 그의 팀은 AI를 활용하여 새로운 치료법의 식별과 개발을 가속화하고 환자에게 생명을 구하는 의약품을 더 빠르게 제공합니다.
폴 휘트모어 Iambic Therapeutics의 수석 엔지니어입니다. 그는 Iambic AI 기반 약물 발견 플랫폼을 위한 인프라 제공을 지원합니다.
알렉스 이안쿨스키 ML/AI Frameworks의 수석 솔루션 설계자로서 고객이 AWS에서 컨테이너와 가속화된 컴퓨팅 인프라를 사용하여 AI 워크로드를 조정하도록 돕는 데 중점을 두고 있습니다.
- SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
- PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
- PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
- 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
- PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
- 출처: https://aws.amazon.com/blogs/machine-learning/scale-ai-training-and-inference-for-drug-discovery-through-amazon-eks-and-karpenter/
- :있다
- :이다
- :아니
- ][피
- $UP
- 1
- 10
- 100
- 125
- 16
- 200
- 200m
- 22
- 24
- 26%
- 28
- 30
- 300
- 40
- 600
- 7
- 70
- 8
- 80
- a
- 능력
- 할 수 있는
- 소개
- 가속
- 가속 된
- 허용
- ACCESS
- 얻기 쉬운
- 수용하다
- 가로질러
- 동작
- 더하다
- 추가 기능
- 추가
- 주소
- 추가
- 많은
- 유연
- 후
- AI
- AI 모델
- AI 교육
- All
- 수
- 따라
- 또한
- 항상
- 아마존
- Amazon EC2
- Amazon Web Services
- an
- 및
- 어떤
- API를
- 앱
- 등장하다
- 응용할 수 있는
- 어플리케이션
- 적용된
- 적용하다
- 접근
- 건축
- 아키텍처
- 있군요
- 지역
- 인조의
- 인공 지능
- 인공 지능(AI)
- AS
- At
- 자동
- 자동화
- 오토마타
- 자동적으로
- 가능
- 피하기
- AWS
- 기반으로
- 배치
- BE
- 된
- 전에
- 행동
- 뒤에
- 이하
- BEST
- 더 나은
- 그 너머
- 생물학
- 블록
- 두
- 바닥
- 가져
- 가져
- 브라우저
- 빌드
- 비자 면제 프로그램에 해당하는 국가의 시민권을 가지고 있지만
- by
- 라는
- 통화
- CAN
- 게자리
- 후보자
- 기능
- 생산 능력
- 활용
- 가지 경우
- 원인
- 검사
- 화학
- 화학
- 왼쪽 메뉴에서
- 선택
- 수업
- 객관적인
- 클라우드
- 클라우드 인프라
- 클러스터
- 암호
- 수집하다
- 결합
- 비교
- 경쟁
- 완전한
- 진행완료
- 계산
- 계산
- 컴퓨터
- 컴퓨팅
- 구성
- 구성
- 통합
- 강화
- 구성
- 컨테이너
- 용기
- 이 포함되어 있습니다
- 제어
- 거꾸로
- 재사용 대기 시간
- 핵심
- 비용
- 비용
- 수
- 만들
- 만든
- 생성
- 만들기
- CSI
- 곡선
- 관습
- 고객
- 주기
- 계기반
- 데이터
- 데이터 점수
- 데이터 처리
- 의사 결정
- 깊은
- 깊은 학습
- 태만
- 밝히다
- 정의
- 배달
- 보여
- 배포
- 전개
- 배치하다
- 디자인
- 설계
- 탐지 된
- 개발
- 도표
- 다른
- 차별화 된
- 방송
- 감독 된
- 책임자
- 발견
- 붕괴
- do
- 도커
- 선적 서류 비치
- 한
- 아래 (down)
- 수십
- 구동
- 운전사
- 마약
- 두
- 역동적 인
- 마다
- 효과적으로
- 효율적인
- 힘들이지 않은
- 요소
- 가능
- 사용 가능
- 수
- 끝으로 종료
- 종점
- 기사
- 거대한
- 충분히
- 환경
- 갖추어 준
- 확립 된
- 이벤트
- 모든
- 정확하게
- 예
- 현존하는
- 실험
- 실험
- 전문가
- 탐험
- 드러난
- 용이하게하다
- FAST
- 빠른
- 를
- 적은
- 입양 부모로서의 귀하의 적합성을 결정하기 위해 미국 이민국에
- 초점
- 집중
- 따라
- 수행원
- 럭셔리
- 분열
- 뼈대
- 프레임 워크
- 진동수
- 에
- 가득 찬
- 일반
- 생성
- 생성
- 세대
- 생성적인
- 제너레이티브 AI
- 발전기
- 얻을
- GPU
- GPU
- 큰
- 그룹
- 손님
- 고객 포스트
- 핸들
- 있다
- he
- 도움
- 도움이
- 도움이
- 여기에서 지금 확인해 보세요.
- 그의
- 호스팅
- 진료 시간
- 방법
- 그러나
- HTTP
- HTTPS
- 식별
- if
- 설명하다
- 영상
- 형상
- 피할 수 없는
- 개선
- 개량
- in
- 포함
- 증가
- 증가
- 인프라
- 고유의
- 처음에는
- 처음에는
- 혁신적인
- 통찰력
- 설치
- 예
- 를 받아야 하는 미국 여행자
- 명령
- 통합 된
- 완성
- 인텔리전스
- 해석하다
- 문제
- IT
- 되풀이
- JPG
- 다만
- 유지
- 키
- 종류
- 레이블
- 결핍
- 넓은
- 숨어 있음
- 시작
- Leadership
- 누수
- 배우기
- 가장 작은
- 왼쪽 (left)
- 레벨
- 이점
- 일생
- 제한
- 하중
- 지방의
- 긴
- 이상
- 찾고
- 낮은
- 기계
- 기계 학습
- 유지하다
- 확인
- 제작
- 관리
- 최대화
- 최고
- XNUMX월..
- 측정
- 메커니즘
- 매질
- 소개
- 회의
- 메모리
- 합병
- 메타 데이터
- 금속
- 메트릭
- 통계
- 이전
- 이주
- 수백만
- 최소화
- Mission
- ML
- 모델
- 모델
- 모니터
- 개월
- 배우기
- 여러
- 절대로 필요한 것
- name
- 이름
- 필요한
- 필요
- 필요
- 신제품
- 새로운
- 아니
- 노드
- 노드
- 소설
- 번호
- 다수의
- 엔비디아
- 관찰
- 획득
- of
- on
- 온디맨드
- ONE
- 만
- 열 수
- 오픈 소스
- 연산자
- 기회
- 최적화
- 최적화
- 최적화
- or
- 기타
- 우리의
- 아웃
- 위에
- 자신의
- 환자
- 환자
- 대기
- 용
- 성능
- 수행하다
- 기간
- 장소
- 플랫폼
- 플라톤
- 플라톤 데이터 인텔리전스
- 플라토데이터
- 전철기
- 정책
- 정책
- 가능한
- 게시하다
- powered
- 강한
- 선행
- 예측
- 제시
- 일차
- 교장
- 원칙
- 사설
- 방법
- 처리됨
- 처리
- 생산
- 프로그램
- 프로젝트
- 속성
- 단백질
- 제공
- 제공
- 대리
- 공개
- 목적
- 질문
- 빨리
- R
- 현실
- 실시간
- 이유
- 감소
- 감소
- 수정하다
- 지방
- 의지하다
- 유적
- 제거
- 제거됨
- 제거하다
- 제거
- 대체
- 대답
- 의뢰
- 요청
- 필요
- 필수
- 요구조건 니즈
- 필요
- 의지
- 제품 자료
- 책임
- 역
- 연락해주세요
- 직위별
- 뿌리
- 달리기
- 달리는
- 같은
- 확장성
- 규모
- 규모 인공 지능
- 비늘이있는
- 저울
- 스케일링
- 대본
- 예약
- 일정
- 과학자
- 스크립트
- 검색
- 수색
- 둘째
- 초
- 섹션
- 보안
- 본
- 의미론
- 보내다
- 전송
- 섬기는 사람
- 봉사하다
- 서비스
- 서비스
- 피복재
- 세트
- 설정
- 정착하다
- 전시
- 표시
- 쇼
- 크게
- 비슷한
- 단순화
- 시뮬레이션
- 단일
- 크기
- 작은
- 작은
- 펴다
- So
- 소프트웨어
- 해결책
- 솔루션
- 일부
- 출처
- 스페이스 버튼
- 명세서
- 지정
- 명세서
- 속도
- Spot
- 표준
- 스타트
- 시작
- 주 정부
- 단계
- 정지
- 저장
- 구조
- 서브넷
- 성공
- 이러한
- 충분한
- 우수한
- 공급
- SUPPORT
- 지원
- 확인
- SVC
- 체계
- 테이블
- 소요
- 대상
- 목표
- 팀
- 기술
- 이 템플릿
- 수십
- 테라 폼
- 보다
- 그
- XNUMXD덴탈의
- 국가
- 그들의
- 그들
- 그때
- 치료학
- 그곳에.
- 그것에 의하여
- Bowman의
- 그들
- 이
- 수천
- 임계값
- 을 통하여
- 처리량
- 시간
- 시대
- 에
- 했다
- 검색을
- 상단
- 트레이닝
- 참된
- 두
- 유형
- 유형
- 전형적인
- 유일한
- 전례가없는
- 까지
- 가동 시간
- 긴급한
- us
- 사용
- 익숙한
- 사용
- v1
- 마케팅은:
- 거대한
- 다양한
- 버전
- 를 통해
- 음량
- 볼륨
- vs
- 취약점
- 연습
- 원
- 였다
- we
- 웹
- 웹 응용 프로그램
- 웹 브라우저
- 웹 서비스
- 주
- 잘
- 했다
- 뭐
- 언제
- 어느
- 동안
- 누구
- 의지
- 과
- 이내
- 작업
- 노동자
- 얌
- 자신의
- 너의
- 제퍼 넷