Este post foi escrito em parceria com Jad Chamoun, diretor de engenharia da Forethought Technologies, Inc. e Salina Wu, engenheira sênior de ML da Forethought Technologies, Inc.
Premeditação é um conjunto líder de IA generativa para atendimento ao cliente. No centro de sua suíte está o inovador SuporteGPT™ tecnologia que usa aprendizado de máquina para transformar o ciclo de vida do suporte ao cliente, aumentando a deflexão, melhorando o CSAT e aumentando a produtividade do agente. O SupportGPT™ utiliza sistemas de recuperação de informações (IR) de última geração e modelos de linguagem grande (LLMs) para potencializar mais de 30 milhões de interações com clientes anualmente.
O principal caso de uso do SupportGPT é melhorar a qualidade e a eficiência das interações e operações de suporte ao cliente. Ao usar sistemas de IR de última geração alimentados por incorporações e modelos de classificação, o SupportGPT pode pesquisar rapidamente informações relevantes, fornecendo respostas precisas e concisas às consultas dos clientes. Forethought usa modelos ajustados por cliente para detectar as intenções do cliente, a fim de resolver as interações do cliente. A integração de grandes modelos de linguagem ajuda a humanizar a interação com agentes automatizados, criando uma experiência de suporte mais envolvente e satisfatória.
O SupportGPT também auxilia os agentes de suporte ao cliente, oferecendo sugestões de preenchimento automático e elaborando respostas apropriadas para tickets de clientes que se alinham com os da empresa com base em respostas anteriores. Usando modelos de linguagem avançados, os agentes podem abordar as preocupações dos clientes com mais rapidez e precisão, resultando em maior satisfação do cliente.
Além disso, a arquitetura do SupportGPT permite detectar lacunas nas bases de conhecimento de suporte, o que ajuda os agentes a fornecer informações mais precisas aos clientes. Depois que essas lacunas são identificadas, o SupportGPT pode gerar automaticamente artigos e outros conteúdos para preencher essas lacunas de conhecimento, garantindo que a base de conhecimento de suporte permaneça centrada no cliente e atualizada.
Nesta postagem, compartilhamos como o Forethought usa Amazon Sage Maker endpoints multimodelo em casos de uso de IA generativa para economizar mais de 66% no custo.
Desafios de infraestrutura
Para ajudar a trazer esses recursos para o mercado, a Forethought dimensiona com eficiência suas cargas de trabalho de ML e fornece soluções hiperpersonalizadas adaptadas ao caso de uso específico de cada cliente. Essa hiperpersonalização é obtida por meio do ajuste fino de modelos e classificadores incorporados aos dados do cliente, garantindo resultados precisos de recuperação de informações e conhecimento de domínio que atende às necessidades exclusivas de cada cliente. Os modelos personalizados de preenchimento automático também são ajustados com base nos dados do cliente para aumentar ainda mais a precisão e a relevância das respostas geradas.
Um dos desafios significativos no processamento de IA é a utilização eficiente de recursos de hardware, como GPUs. Para enfrentar esse desafio, a Forethought usa os endpoints de vários modelos (MMEs) do SageMaker para executar vários modelos de IA em um único endpoint e escala de inferência. Como a hiperpersonalização de modelos exige que modelos exclusivos sejam treinados e implantados, o número de modelos aumenta linearmente com o número de clientes, o que pode se tornar caro.
Para alcançar o equilíbrio certo de desempenho para custo e inferência em tempo real, a Forethought optou por usar SageMaker MMEs, que oferecem suporte à aceleração de GPU. Os MMEs SageMaker permitem que a Forethought forneça soluções de alto desempenho, escaláveis e econômicas com latência de subsegundos, abordando vários cenários de suporte ao cliente em escala.
SageMaker e Forethought
O SageMaker é um serviço totalmente gerenciado que oferece aos desenvolvedores e cientistas de dados a capacidade de criar, treinar e implantar modelos de ML rapidamente. Os MMEs SageMaker fornecem uma solução escalável e econômica para implantar um grande número de modelos para inferência em tempo real. Os MMEs usam um contêiner de serviço compartilhado e uma frota de recursos que podem usar instâncias aceleradas, como GPUs, para hospedar todos os seus modelos. Isso reduz os custos de hospedagem maximizando a utilização do endpoint em comparação com o uso de endpoints de modelo único. Ele também reduz a sobrecarga de implantação porque o SageMaker gerencia o carregamento e o descarregamento de modelos na memória e os dimensiona com base nos padrões de tráfego do endpoint. Além disso, todos os endpoints em tempo real do SageMaker se beneficiam de recursos integrados para gerenciar e monitorar modelos, como incluir variantes de sombra, dimensionamento automáticoe integração nativa com Amazon CloudWatch (para mais informações, consulte Métricas do CloudWatch para implantações de endpoint de vários modelos).
À medida que o Forethought cresceu para hospedar centenas de modelos que também exigiam recursos de GPU, vimos uma oportunidade de criar uma arquitetura mais econômica, confiável e gerenciável por meio dos MMEs do SageMaker. Antes de migrar para SageMaker MMEs, nossos modelos foram implantados no Kubernetes em Serviço Amazon Elastic Kubernetes (Amazon EKS). Embora o Amazon EKS fornecesse recursos de gerenciamento, ficou imediatamente claro que estávamos gerenciando uma infraestrutura que não foi especificamente adaptada para inferência. A Forethought precisava gerenciar a inferência de modelo no Amazon EKS, o que era um fardo para a eficiência da engenharia. Por exemplo, para compartilhar recursos caros de GPU entre vários modelos, éramos responsáveis por alocar frações rígidas de memória para modelos especificados durante a implantação. Queríamos abordar os seguintes problemas principais com nossa infraestrutura existente:
- Alto custo – Para garantir que cada modelo tenha recursos suficientes, seríamos muito conservadores em quantos modelos caberiam por instância. Isso resultou em custos de hospedagem de modelos muito mais altos do que o necessário.
- Baixa confiabilidade – Apesar de ser conservador em nossa alocação de memória, nem todos os modelos têm os mesmos requisitos e, ocasionalmente, alguns modelos apresentam erros de falta de memória (OOM).
- Gerenciamento ineficiente – Tínhamos que gerenciar diferentes manifestos de implantação para cada tipo de modelo (como classificadores, incorporações e preenchimento automático), o que era demorado e sujeito a erros. Também tivemos que manter a lógica para determinar a alocação de memória para diferentes tipos de modelo.
Em última análise, precisávamos de uma plataforma de inferência para assumir o trabalho pesado de gerenciar nossos modelos em tempo de execução para melhorar o custo, a confiabilidade e o gerenciamento de atendimento de nossos modelos. Os MMEs SageMaker nos permitiram atender a essas necessidades.
Por meio de seu carregamento e descarregamento de modelo dinâmico e inteligente e de seus recursos de dimensionamento, os MMEs SageMaker forneceram uma solução significativamente mais econômica e confiável para hospedar nossos modelos. Agora podemos ajustar muito mais modelos por instância e não precisamos nos preocupar com erros OOM porque os MMEs do SageMaker lidam com o carregamento e descarregamento de modelos dinamicamente. Além disso, as implantações agora são tão simples quanto chamar as APIs do Boto3 SageMaker e anexar as políticas adequadas de dimensionamento automático.
O diagrama a seguir ilustra nossa arquitetura legada.
Para iniciar nossa migração para SageMaker MMEs, identificamos os melhores casos de uso para MMEs e quais de nossos modelos se beneficiariam mais com essa mudança. Os MMEs são mais bem usados para o seguinte:
- Modelos que devem ter baixa latência, mas podem suportar um tempo de inicialização a frio (quando é carregado pela primeira vez)
- Modelos que são chamados com frequência e consistência
- Modelos que precisam de recursos parciais de GPU
- Modelos que compartilham requisitos comuns e lógica de inferência
Identificamos nossos modelos de incorporação e modelos de linguagem de preenchimento automático como os melhores candidatos para nossa migração. Para organizar esses modelos em MMEs, criaríamos um MME por tipo de modelo ou tarefa, um para nossos modelos de incorporação e outro para modelos de linguagem de preenchimento automático.
Já tínhamos uma camada de API sobre nossos modelos para gerenciamento e inferência de modelos. Nossa tarefa era retrabalhar como essa API estava implantando e lidando com a inferência em modelos sob o capô com o SageMaker, com alterações mínimas em como os clientes e as equipes de produto interagiam com a API. Também precisávamos empacotar nossos modelos e lógica de inferência personalizada para serem compatíveis com o NVIDIA Triton Inference Server usando SageMaker MMEs.
O diagrama a seguir ilustra nossa nova arquitetura.
Lógica de inferência personalizada
Antes de migrar para o SageMaker, o código de inferência personalizado da Forethought (pré-processamento e pós-processamento) era executado na camada da API quando um modelo era invocado. O objetivo era transferir essa funcionalidade para o próprio modelo para esclarecer a separação de responsabilidades, modularizar e simplificar seu código e reduzir a carga na API.
embeddings
Os modelos de incorporação do Forethought consistem em dois artefatos de modelo PyTorch, e a solicitação de inferência determina qual modelo chamar. Cada modelo requer texto pré-processado como entrada. Os principais desafios foram integrar uma etapa de pré-processamento e acomodar dois artefatos de modelo por definição de modelo. Para atender à necessidade de várias etapas na lógica de inferência, a Forethought desenvolveu um modelo de conjunto Triton com duas etapas: um processo de pré-processamento de back-end do Python e uma chamada de modelo de back-end do PyTorch. Os modelos de conjunto permitem definir e ordenar as etapas na lógica de inferência, com cada etapa representada por um modelo Triton de qualquer tipo de back-end. Para garantir a compatibilidade com o back-end Triton PyTorch, os artefatos de modelo existentes foram convertidos para o formato TorchScript. Modelos Triton separados foram criados para cada definição de modelo, e a camada de API do Forethought foi responsável por determinar o TargetModel
invocar com base na solicitação recebida.
autocomplete
Os modelos autocomplete (sequência a sequência) apresentaram um conjunto distinto de requisitos. Especificamente, precisávamos habilitar a capacidade de percorrer várias chamadas de modelo e armazenar em cache entradas substanciais para cada chamada, mantendo a baixa latência. Além disso, esses modelos necessitavam de etapas de pré-processamento e pós-processamento. Para atender a esses requisitos e obter a flexibilidade desejada, a Forethought desenvolveu modelos MME de preenchimento automático utilizando o back-end Triton Python, que oferece a vantagem de escrever o modelo como código Python.
O benchmarking
Depois que as formas do modelo Triton foram determinadas, implantamos modelos em endpoints de teste e realizamos benchmarking de recursos e desempenho. Nosso principal objetivo era determinar a latência para inicialização a frio versus modelos na memória e como a latência era afetada pelo tamanho da solicitação e pela simultaneidade. Também queríamos saber quantos modelos poderiam caber em cada instância, quantos modelos fariam com que as instâncias aumentassem com nossa política de dimensionamento automático e com que rapidez a expansão aconteceria. Mantendo os tipos de instância que já estávamos usando, fizemos nosso benchmarking com as instâncias ml.g4dn.xlarge e ml.g4dn.2xlarge.
Resultados
A tabela a seguir resume nossos resultados.
Tamanho da solicitação | Latência de inicialização a frio | Latência de inferência em cache | Latência simultânea (5 solicitações) |
Pequeno (30 fichas) | 12.7 segundos | 0.03 segundos | 0.12 segundos |
Médio (250 fichas) | 12.7 segundos | 0.05 segundos | 0.12 segundos |
Grande (550 fichas) | 12.7 segundos | 0.13 segundos | 0.12 segundos |
Notavelmente, a latência para solicitações de inicialização a frio é significativamente maior do que a latência para solicitações de inferência em cache. Isso ocorre porque o modelo precisa ser carregado do disco ou Serviço de armazenamento simples da Amazon (Amazon S3) quando uma solicitação de inicialização a frio é feita. A latência para solicitações simultâneas também é maior do que a latência para solicitações únicas. Isso ocorre porque o modelo precisa ser compartilhado entre solicitações simultâneas, o que pode levar à contenção.
A tabela a seguir compara a latência dos modelos herdados e os modelos SageMaker.
Tamanho da solicitação | Modelos legados | Modelos do SageMaker |
Pequeno (30 fichas) | 0.74 segundos | 0.24 segundos |
Médio (250 fichas) | 0.74 segundos | 0.24 segundos |
Grande (550 fichas) | 0.80 segundos | 0.32 segundos |
No geral, os modelos do SageMaker são uma escolha melhor para hospedar modelos de preenchimento automático do que os modelos legados. Eles oferecem menor latência, escalabilidade, confiabilidade e segurança.
Uso de recursos
Em nossa busca para determinar o número ideal de modelos que poderiam caber em cada instância, realizamos uma série de testes. Nosso experimento envolveu o carregamento de modelos em nossos endpoints usando um tipo de instância ml.g4dn.xlarge, sem nenhuma política de dimensionamento automático.
Essas instâncias específicas oferecem 15.5 GB de memória, e buscamos alcançar aproximadamente 80% de uso de memória da GPU por instância. Considerando o tamanho de cada artefato do modelo de codificador, conseguimos encontrar o número ideal de codificadores Triton para carregar em uma instância para alcançar nosso uso de memória de GPU direcionado. Além disso, dado que cada um dos nossos modelos de incorporação corresponde a dois modelos de codificador Triton, conseguimos alojar um número definido de modelos de incorporação por instância. Como resultado, calculamos o número total de instâncias necessárias para atender a todos os nossos modelos de incorporação. Essa experimentação foi crucial para otimizar nosso uso de recursos e aumentar a eficiência de nossos modelos.
Conduzimos benchmarks semelhantes para nossos modelos de preenchimento automático. Esses modelos tinham cerca de 292.0 MB cada. Ao testarmos quantos modelos caberiam em uma única instância ml.g4dn.xlarge, notamos que só conseguíamos ajustar quatro modelos antes de nossa instância começar a descarregar modelos, apesar de os modelos terem um tamanho pequeno. Nossas principais preocupações eram:
- Causa para picos de utilização de memória da CPU
- Causa para modelos sendo descarregados quando tentamos carregar em mais um modelo em vez de apenas o modelo menos usado recentemente (LRU)
Conseguimos identificar a causa raiz do pico de utilização de memória proveniente da inicialização de nosso ambiente de tempo de execução CUDA em nosso modelo Python, que era necessário para mover nossos modelos e dados para dentro e para fora do dispositivo GPU. CUDA carrega muitas dependências externas na memória da CPU quando o tempo de execução é inicializado. Como o back-end Triton PyTorch manipula e abstrai a movimentação de dados para dentro e para fora do dispositivo GPU, não encontramos esse problema em nossos modelos de incorporação. Para resolver isso, tentamos usar instâncias ml.g4dn.2xlarge, que tinham a mesma quantidade de memória da GPU, mas o dobro da memória da CPU. Além disso, adicionamos várias otimizações secundárias em nosso código de back-end Python, incluindo a exclusão de tensores após o uso, esvaziamento do cache, desativação de gradientes e coleta de lixo. Com o tipo de instância maior, conseguimos ajustar 10 modelos por instância, e a utilização de memória da CPU e da GPU ficou muito mais alinhada.
O diagrama a seguir ilustra essa arquitetura.
Escala automática
Anexamos políticas de dimensionamento automático a nossas incorporações e MMEs de preenchimento automático. Nossa política para nosso endpoint de incorporação visava uma utilização média de memória de GPU de 80% usando métricas personalizadas. Nossos modelos de preenchimento automático observaram um padrão de alto tráfego durante o horário comercial e tráfego mínimo durante a noite. Por isso, criamos uma política de auto scaling baseada em InvocationsPerInstance
para que pudéssemos escalar de acordo com os padrões de tráfego, economizando custos sem sacrificar a confiabilidade. Com base em nosso benchmarking de uso de recursos, configuramos nossas políticas de escalabilidade com uma meta de 225 InvocationsPerInstance
.
Implantar lógica e pipeline
A criação de um MME no SageMaker é simples e semelhante à criação de qualquer outro terminal no SageMaker. Depois que o endpoint é criado, adicionar modelos adicionais ao endpoint é tão simples quanto mover o artefato do modelo para o caminho do S3 que o endpoint visa; neste ponto, podemos fazer solicitações de inferência para nosso novo modelo.
Definimos a lógica que receberia os metadados do modelo, formataria o endpoint de forma determinística com base nos metadados e verificaria se o endpoint existia. Caso contrário, criamos o endpoint e adicionamos o artefato do modelo Triton ao patch S3 para o endpoint (também formatado de forma determinística). Por exemplo, se os metadados do modelo indicassem que é um modelo de preenchimento automático, ele criaria um endpoint para modelos de preenchimento automático e um caminho S3 associado para artefatos de modelo de preenchimento automático. Se o endpoint existisse, copiaríamos o artefato de modelo para o caminho S3.
Agora que tínhamos nossas formas de modelo para nossos modelos MME e a funcionalidade para implantar nossos modelos no MME, precisávamos de uma maneira de automatizar a implantação. Nossos usuários devem especificar qual modelo desejam implantar; tratamos do empacotamento e implantação do modelo. O código de inferência personalizado empacotado com o modelo é versionado e enviado para o Amazon S3; na etapa de empacotamento, extraímos o código de inferência de acordo com a versão especificada (ou a versão mais recente) e usamos arquivos YAML que indicam as estruturas de arquivo dos modelos Triton.
Um requisito para nós era que todos os nossos modelos MME fossem carregados na memória para evitar qualquer latência de inicialização a frio durante solicitações de inferência de produção para carregar modelos. Para conseguir isso, fornecemos recursos suficientes para atender a todos os nossos modelos (de acordo com o benchmarking anterior) e chamamos todos os modelos em nosso MME em uma cadência horária.
O diagrama a seguir ilustra o pipeline de implantação de modelo.
O diagrama a seguir ilustra o pipeline de aquecimento do modelo.
invocação do modelo
Nossa camada de API existente fornece uma abstração para que os chamadores façam inferências em todos os nossos modelos de ML. Isso significava que só precisávamos adicionar funcionalidade à camada da API para chamar o SageMaker MME com o modelo de destino correto, dependendo da solicitação de inferência, sem nenhuma alteração no código de chamada. O código de inferência do SageMaker recebe a solicitação de inferência, formata as entradas Triton definidas em nossos modelos Triton e invoca os MMEs usando o Boto3.
Benefícios de custo
A Forethought fez avanços significativos na redução dos custos de hospedagem de modelo e na mitigação de erros de OOM de modelo, graças à migração para SageMaker MMEs. Antes dessa alteração, instâncias ml.g4dn.xlarge em execução no Amazon EKS. Com a transição para MMEs, descobrimos que ele poderia abrigar 12 modelos de incorporação por instância enquanto alcançava 80% de utilização da memória da GPU. Isso levou a uma queda significativa em nossas despesas mensais. Para colocar isso em perspectiva, percebemos uma economia de custos de até 80%. Além disso, para gerenciar um tráfego maior, consideramos escalar as réplicas. Assumindo um cenário em que empregamos três réplicas, descobrimos que nossa economia de custos ainda seria substancial mesmo nessas condições, girando em torno de 43%.
A jornada com os MMEs SageMaker provou ser financeiramente benéfica, reduzindo nossas despesas e garantindo o desempenho ideal do modelo. Anteriormente, nossos modelos de linguagem de preenchimento automático eram implantados no Amazon EKS, exigindo um número variável de instâncias ml.g4dn.xlarge com base na alocação de memória por modelo. Isso resultou em um custo mensal considerável. No entanto, com nossa recente migração para MMEs SageMaker, conseguimos reduzir substancialmente esses custos. Agora hospedamos todos os nossos modelos em instâncias ml.g4dn.2xlarge, o que nos permite empacotar modelos com mais eficiência. Isso reduziu significativamente nossas despesas mensais e agora conseguimos economias de custos na faixa de 66 a 74%. Essa mudança demonstrou como a utilização eficiente de recursos pode levar a economias financeiras significativas usando os MMEs SageMaker.
Conclusão
Nesta postagem, revisamos como o Forethought usa os endpoints multimodelo do SageMaker para diminuir o custo da inferência em tempo real. O SageMaker assume o trabalho pesado indiferenciado, portanto, o Forethought pode aumentar a eficiência da engenharia. Ele também permite que a Forethought reduza drasticamente o custo da inferência em tempo real, mantendo o desempenho necessário para as operações críticas de negócios. Com isso, a Forethought consegue oferecer uma oferta diferenciada para seus clientes por meio de modelos hiperpersonalizados. Use o SageMaker MME para hospedar seus modelos em escala e reduzir os custos de hospedagem melhorando a utilização do terminal. Ele também reduz a sobrecarga de implantação porque o Amazon SageMaker gerencia o carregamento de modelos na memória e os dimensiona com base nos padrões de tráfego para seu endpoint. Você pode encontrar amostras de código para hospedar vários modelos usando o SageMaker MME em GitHub.
Sobre os autores
Jad Chamoun é diretor de engenharia principal da Forethought. Sua equipe se concentra em engenharia de plataforma, abrangendo engenharia de dados, infraestrutura de aprendizado de máquina e infraestrutura de nuvem. Você pode encontrá-lo em LinkedIn.
Salina Wu é engenheiro sênior de infraestrutura de aprendizado de máquina na Forethought.ai. Ela trabalha em estreita colaboração com a equipe de aprendizado de máquina para criar e manter suas infraestruturas de dados, serviços e treinamento de ponta a ponta. Ela está particularmente motivada pela introdução de novas maneiras de melhorar a eficiência e reduzir custos em todo o espaço de ML. Quando não está no trabalho, Salina gosta de surfar, fazer cerâmica e estar na natureza.
James Park é arquiteto de soluções na Amazon Web Services. Ele trabalha com a Amazon.com para projetar, criar e implantar soluções de tecnologia na AWS e tem interesse particular em IA e aprendizado de máquina. Em seu tempo livre, ele gosta de conhecer novas culturas, novas experiências e estar atualizado com as últimas tendências tecnológicas. Você pode encontrá-lo em LinkedIn.
Sunil Padmanabhan é arquiteto de soluções de inicialização na AWS. Como ex-fundador de startups e CTO, ele é apaixonado por aprendizado de máquina e se concentra em ajudar startups a alavancar IA/ML para seus resultados de negócios e projetar e implantar soluções ML/AI em escala.
Dhawal Patel é Arquiteto Principal de Machine Learning na AWS. Ele trabalhou com organizações que vão desde grandes empresas até startups de médio porte em problemas relacionados à computação distribuída e Inteligência Artificial. Ele se concentra em aprendizado profundo, incluindo domínios de PNL e Visão Computacional. Ele ajuda os clientes a obter inferência de modelo de alto desempenho no SageMaker.
- Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
- EVM Finanças. Interface unificada para finanças descentralizadas. Acesse aqui.
- Grupo de Mídia Quântica. IR/PR Amplificado. Acesse aqui.
- PlatoAiStream. Inteligência de Dados Web3. Conhecimento Amplificado. Acesse aqui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/how-forethought-saves-over-66-in-costs-for-generative-ai-models-using-amazon-sagemaker/
- :tem
- :é
- :não
- :onde
- $UP
- 1
- 10
- 100
- 12
- 13
- 15%
- 24
- 250
- 30
- 32
- 7
- 80
- a
- habilidade
- Capaz
- Sobre
- abstração
- resumos
- acelerado
- Segundo
- precisão
- preciso
- exatamente
- Alcançar
- alcançado
- alcançar
- em
- adicionar
- adicionado
- acrescentando
- Adição
- Adicional
- Adicionalmente
- endereço
- endereçando
- avançado
- Vantagem
- Depois de
- Agente
- agentes
- AI
- casos de uso ai
- AI / ML
- Destinado
- alinhar
- alinhado
- Todos os Produtos
- alocação
- permitir
- permite
- já
- tb
- Apesar
- Amazon
- Amazon Sage Maker
- Amazon Web Services
- Amazon.com
- quantidade
- an
- e
- Anualmente
- Outro
- respostas
- qualquer
- api
- APIs
- aparente
- apropriado
- aproximadamente
- arquitetura
- SOMOS
- por aí
- artigos
- artificial
- inteligência artificial
- AS
- ajuda
- associado
- At
- auto
- automatizar
- Automatizado
- automaticamente
- média
- evitar
- longe
- AWS
- Backend
- Equilíbrio
- base
- baseado
- BE
- passou a ser
- Porque
- tornam-se
- sido
- antes
- começar
- ser
- aferimento
- benéfico
- beneficiar
- MELHOR
- Melhor
- entre
- impulsionar
- ambos
- trazer
- construir
- construídas em
- carga
- negócio
- mas a
- by
- Esconderijo
- calculado
- chamada
- chamado
- chamada
- chamadas
- CAN
- candidatos
- capacidades
- casas
- casos
- atende
- Causar
- desafiar
- desafios
- alterar
- Alterações
- verificar
- escolha
- escolheu
- clientes
- de perto
- Na nuvem
- infraestrutura de nuvem
- código
- frio
- Coleta
- COM
- vinda
- comum
- Empresa
- comparado
- compatibilidade
- compatível
- computador
- Visão de Computador
- computação
- Preocupações
- concorrente
- condições
- conduzido
- configurado
- conservador
- considerável
- considerado
- considerando
- Recipiente
- conteúdo
- convertido
- núcleo
- correta
- corresponde
- Custo
- economia de custos
- relação custo-benefício
- dispendioso
- custos
- poderia
- cobertura
- crio
- criado
- Criar
- crucial
- CTO
- personalizadas
- cliente
- dados do cliente
- A satisfação do cliente
- Atendimento ao Cliente
- Suporte ao cliente
- Clientes
- personalizado
- dados,
- Data
- Rejeitar
- diminuir
- profundo
- deep learning
- definido
- definição
- entregar
- entregando
- demonstraram
- Dependendo
- implantar
- implantado
- Implantação
- desenvolvimento
- Implantações
- Design
- desejado
- Apesar de
- Determinar
- determinado
- determina
- determinando
- desenvolvido
- desenvolvedores
- dispositivo
- DID
- diferente
- diferenciado
- Diretor
- descoberto
- distinto
- distribuído
- computação distribuída
- fazer
- domínio
- domínios
- não
- dramaticamente
- durante
- dinâmico
- dinamicamente
- cada
- eficiência
- eficiente
- eficientemente
- embutindo
- permitir
- permite
- end-to-end
- Ponto final
- noivando
- engenheiro
- Engenharia
- aumentar
- aprimorando
- suficiente
- garantir
- assegurando
- empresas
- Meio Ambiente
- erros
- Mesmo
- Cada
- exemplo
- existente
- esperado
- despesas
- caro
- vasta experiência
- Experiências
- experimentar
- externo
- mais rápido
- Envie o
- Arquivos
- preencher
- financeiro
- financeiramente
- Encontre
- Primeiro nome
- caber
- ANIMARIS
- Flexibilidade
- concentra-se
- seguinte
- Escolha
- formato
- Antigo
- encontrado
- fundador
- quatro
- da
- totalmente
- funcionalidade
- mais distante
- Além disso
- lacunas
- gerar
- gerado
- generativo
- IA generativa
- obtendo
- gif
- dado
- Dando
- meta
- GPU
- GPUs
- gradientes
- tinha
- mão
- manipular
- Alças
- Manipulação
- acontecer
- Hardware
- Ter
- ter
- he
- pesado
- levantamento pesado
- ajudar
- ajuda
- ajuda
- Alta
- alta performance
- superior
- ele
- sua
- capuz
- hospedeiro
- hospedagem
- custos de hospedagem
- HORÁRIO
- House
- Como funciona o dobrador de carta de canal
- Contudo
- HTML
- http
- HTTPS
- Centenas
- identificado
- if
- ilustra
- imediatamente
- melhorar
- melhorar
- in
- Inc.
- Incluindo
- Entrada
- Crescimento
- indicam
- indicado
- INFORMAÇÕES
- Infraestrutura
- infra-estrutura
- inovadores
- entrada
- inputs
- instância
- em vez disso
- Integração
- integração
- Inteligência
- interação
- interações
- interesse
- para dentro
- introduzindo
- invocado
- invoca
- envolvido
- emitem
- IT
- ESTÁ
- se
- viagem
- jpg
- apenas por
- manutenção
- Chave
- Saber
- Conhecimento
- língua
- grande
- Grandes empresas
- Maior
- Latência
- mais recente
- camada
- conduzir
- principal
- aprendizagem
- mínimo
- levou
- Legado
- menos
- Alavancagem
- aproveita as
- facelift
- carregar
- carregamento
- cargas
- lógica
- Baixo
- diminuir
- máquina
- aprendizado de máquina
- moldadas
- a Principal
- a manter
- Manter
- fazer
- gerencia
- gerenciados
- de grupos
- gestão
- gestão
- muitos
- mercado
- maximizando
- significava
- Memória
- metadados
- Métrica
- migrando
- migração
- milhão
- mínimo
- menor
- mitigando
- ML
- modelo
- modelos
- Monitore
- mensal
- mais
- Além disso
- a maioria
- motivados
- mover
- em movimento
- muito
- Ponto de extremidade multimodelo
- múltiplo
- devo
- nativo
- Natureza
- necessário
- você merece...
- necessário
- Cria
- Novo
- PNL
- agora
- número
- Nvidia
- objetivo
- of
- WOW!
- oferecer
- oferecendo treinamento para distância
- Oferece
- frequentemente
- on
- uma vez
- ONE
- só
- Operações
- Oportunidade
- ideal
- otimizando
- or
- ordem
- organizações
- Outros
- A Nossa
- nós mesmos
- Fora
- resultados
- Acima de
- durante a noite
- Pack
- pacote
- empacotado
- acondicionamento
- particular
- particularmente
- apaixonado
- Remendo
- caminho
- padrão
- padrões
- atuação
- perspectiva
- oleoduto
- plataforma
- platão
- Inteligência de Dados Platão
- PlatãoData
- ponto
- políticas
- Privacidade
- Publique
- poder
- alimentado
- apresentado
- anterior
- anteriormente
- primário
- Diretor
- Prévio
- problemas
- processo
- em processamento
- Produto
- Produção
- produtividade
- adequado
- comprovado
- fornecer
- fornecido
- fornece
- provisão
- empurrado
- colocar
- Python
- pytorch
- qualidade
- consultas
- busca
- rapidamente
- alcance
- variando
- Posição
- alcançar
- em tempo real
- realizado
- recentemente
- recentemente
- reduzir
- reduz
- redução
- relacionado
- relevância
- relevante
- confiabilidade
- confiável
- permanece
- representado
- solicitar
- pedidos
- requeridos
- requerimento
- Requisitos
- exige
- recurso
- Recursos
- respostas
- responsabilidades
- responsável
- resultar
- resultando
- Resultados
- Comentários
- certo
- rígido
- raiz
- Execute
- corrida
- sacrificando
- sábio
- Inferência do SageMaker
- mesmo
- satisfação
- Salvar
- poupança
- Poupança
- serra
- AMPLIAR
- escalável
- Escala
- aumento de escala
- Escalas
- dimensionamento
- cenário
- cenários
- cientistas
- Pesquisar
- segurança
- busca
- senior
- separado
- Seqüência
- Série
- servir
- serviço
- Serviços
- de servir
- conjunto
- vários
- Shadow
- formas
- Partilhar
- compartilhado
- ela
- periodo
- de forma considerável
- semelhante
- simples
- simplificar
- solteiro
- Tamanho
- pequeno
- smart
- So
- solução
- Soluções
- RESOLVER
- alguns
- Espaço
- específico
- especificamente
- especificada
- espigão
- encenação
- começo
- começado
- inicialização
- Startups
- estado-da-arte
- Passo
- Passos
- Ainda
- armazenamento
- franco
- avanços
- substancial
- tal
- suíte
- ajuda
- sistemas
- mesa
- equipamento
- adaptados
- Tire
- toma
- Target
- visadas
- tem como alvo
- Tarefa
- Profissionais
- equipes
- Tecnologias
- Tecnologia
- testado
- testes
- do que
- obrigado
- que
- A
- deles
- Eles
- Este
- deles
- isto
- três
- Através da
- bilhetes
- tempo
- demorado
- para
- Tokens
- topo
- Total
- tráfego
- Trem
- treinado
- Training
- transferência
- Transformar
- transição
- Tendências
- experimentado
- Tritão
- Twice
- dois
- tipo
- tipos
- para
- único
- us
- Uso
- usar
- caso de uso
- usava
- usuários
- usos
- utilização
- Utilizando
- versão
- muito
- visão
- vs
- queremos
- querido
- foi
- Caminho..
- maneiras
- we
- web
- serviços web
- foram
- quando
- se
- qual
- enquanto
- de
- sem
- Atividades:
- trabalhou
- trabalho
- preocupar-se
- seria
- escrita
- wu
- yaml
- Vocês
- investimentos
- zefirnet