Os aplicativos de aprendizado de máquina (ML) são complexos de implantar e geralmente exigem a capacidade de hiperdimensionamento, além de requisitos de latência ultrabaixa e orçamentos de custo rigorosos. Casos de uso como detecção de fraudes, recomendações de produtos e previsão de tráfego são exemplos em que os milissegundos são importantes e críticos para o sucesso dos negócios. Contratos de nível de serviço (SLAs) rígidos precisam ser atendidos, e uma solicitação típica pode exigir várias etapas, como pré-processamento, transformação de dados, engenharia de recursos, lógica de seleção de modelo, agregação de modelo e pós-processamento.
A implantação de modelos de ML em escala com custo otimizado e eficiência de computação pode ser uma tarefa assustadora e complicada. Cada modelo tem seus próprios méritos e dependências com base nas fontes de dados externas, bem como no ambiente de tempo de execução, como o poder de CPU/GPU dos recursos de computação subjacentes. Um aplicativo pode exigir vários modelos de ML para atender a uma única solicitação de inferência. Em determinados cenários, uma solicitação pode fluir por vários modelos. Não existe uma abordagem única para todos, e é importante que os profissionais de ML procurem métodos testados e comprovados para lidar com os desafios recorrentes de hospedagem de ML. Isso levou à evolução dos padrões de design para hospedagem de modelos de ML.
Nesta postagem, exploramos padrões de design comuns para criar aplicativos de ML em Amazon Sage Maker.
Padrões de design para criar aplicativos de ML
Vejamos os seguintes padrões de design a serem usados para hospedar aplicativos de ML.
Aplicativos de ML baseados em modelo único
Essa é uma ótima opção quando seu caso de uso de ML requer um único modelo para atender a uma solicitação. O modelo é implantado em uma infraestrutura de computação dedicada com capacidade de dimensionamento com base no tráfego de entrada. Essa opção também é ideal quando o aplicativo cliente tem um requisito de inferência de baixa latência (da ordem de milissegundos ou segundos).
Aplicativos de ML baseados em vários modelos
Para tornar a hospedagem mais econômica, esse padrão de design permite hospedar vários modelos na mesma infraestrutura de locatário. Vários modelos de ML podem compartilhar os recursos de host ou contêiner, incluindo o armazenamento em cache dos modelos de ML mais usados na memória, resultando em melhor utilização da memória e dos recursos de computação. Dependendo dos tipos de modelos que você escolheu implantar, a co-hospedagem de modelos pode usar os seguintes métodos:
- Hospedagem multimodelo – Esta opção permite hospedar vários modelos usando um contêiner de serviço compartilhado em um único endpoint. Esse recurso é ideal quando você tem um grande número de modelos semelhantes que pode servir por meio de um contêiner de serviço compartilhado e não precisa acessar todos os modelos ao mesmo tempo.
- Hospedagem em vários contêineres – Essa opção é ideal quando você tem vários modelos em execução em diferentes pilhas de serviço com necessidades de recursos semelhantes e quando modelos individuais não têm tráfego suficiente para utilizar a capacidade total das instâncias de terminal. A hospedagem de vários contêineres permite implantar vários contêineres que usam diferentes modelos ou estruturas em um único endpoint. Os modelos podem ser completamente heterogêneos, com sua própria pilha de serviço independente.
- Conjuntos de modelos – Em muitos casos de uso de produção, muitas vezes pode haver muitos modelos upstream alimentando entradas para um determinado modelo downstream. É aqui que os conjuntos são úteis. Os padrões de conjunto envolvem a mistura da saída de um ou mais modelos básicos para reduzir o erro de generalização da previsão. Os modelos base podem ser diversos e treinados por diferentes algoritmos. Os conjuntos de modelos podem superar os modelos individuais porque o erro de previsão do modelo diminui quando a abordagem de conjunto é usada.
Os seguintes são casos de uso comuns de padrões de conjunto e seus diagramas de padrões de design correspondentes:
- Dispersão-reunião – Em um padrão scatter-gather, uma solicitação de inferência é roteada para vários modelos. Um agregador é então usado para coletar as respostas e destilá-las em uma única resposta de inferência. Por exemplo, um caso de uso de classificação de imagem pode usar três modelos diferentes para executar a tarefa. O padrão scatter-gather permite combinar resultados de inferências executadas em três modelos diferentes e escolher o modelo de classificação mais provável.
- Modelo agregado – Em um padrão de agregação, é calculada a média das saídas de vários modelos. Para modelos de classificação, as previsões de vários modelos são avaliadas para determinar a classe que recebeu mais votos e é tratada como a saída final do conjunto. Por exemplo, em um problema de classificação de duas classes para classificar um conjunto de frutas como laranjas ou maçãs, se dois modelos votam em uma laranja e um modelo vota em uma maçã, então a saída agregada será uma laranja. A agregação ajuda a combater a imprecisão em modelos individuais e torna a saída mais precisa.
- Seleção dinâmica – Outro padrão para modelos de conjunto é executar dinamicamente a seleção de modelo para os atributos de entrada fornecidos. Por exemplo, em uma dada entrada de imagens de frutas, se a entrada contiver uma laranja, o modelo A será usado porque é especializado para laranjas. Se a entrada contiver uma maçã, o modelo B será usado porque é especializado para maçãs.
- Aplicativos de ML de inferência serial – Com um padrão de inferência serial, também conhecido como pipeline de inferência, os casos de uso têm requisitos para pré-processar dados de entrada antes de invocar um modelo de ML pré-treinado para gerar inferências. Além disso, em alguns casos, as inferências geradas podem precisar ser processadas posteriormente, para que possam ser facilmente consumidas por aplicativos downstream. Um pipeline de inferência permite reutilizar o mesmo código de pré-processamento usado durante o treinamento do modelo para processar os dados de solicitação de inferência usados para previsões.
- Logíca de negócios – A produção de ML sempre envolve lógica de negócios. Os padrões de lógica de negócios envolvem tudo o que é necessário para executar uma tarefa de ML que não seja inferência de modelo de ML. Isso inclui carregar o modelo de Serviço de armazenamento simples da Amazon (Amazon S3), por exemplo, pesquisas de banco de dados para validar a entrada, obtenção de recursos pré-computados do armazenamento de recursos e assim por diante. Após a conclusão dessas etapas de lógica de negócios, as entradas são passadas para os modelos de ML.
Opções de inferência de ML
Para a implantação do modelo, é importante retroceder a partir do seu caso de uso. Qual é a frequência da previsão? Você espera tráfego ao vivo para seu aplicativo e resposta em tempo real para seus clientes? Você tem muitos modelos treinados para diferentes subconjuntos de dados para o mesmo caso de uso? O tráfego de previsão flutua? A latência da inferência é uma preocupação? Com base nesses detalhes, todos os padrões de design anteriores podem ser implementados usando as seguintes opções de implantação:
- Inferência em tempo real – A inferência em tempo real é ideal para cargas de trabalho de inferência em que você tem requisitos de baixa latência, interativos e em tempo real. As cargas de trabalho de inferência de ML em tempo real podem incluir um aplicativo de ML baseado em modelo único, em que um aplicativo requer apenas um modelo de ML para atender a uma única solicitação, ou um aplicativo de ML baseado em vários modelos, em que um aplicativo requer vários modelos de ML para atender a um único solicitar.
- Inferência quase em tempo real (assíncrona) – Com inferência quase em tempo real, você pode enfileirar as solicitações recebidas. Isso pode ser utilizado para executar inferência em entradas com centenas de MBs. Ele opera quase em tempo real e permite que os usuários usem a entrada para inferência e leiam a saída do endpoint de um bucket S3. Pode ser especialmente útil em casos com NLP e visão computacional, onde há grandes cargas que requerem tempos de pré-processamento mais longos.
- Inferência em lote – A inferência em lote pode ser utilizada para executar a inferência offline em um grande conjunto de dados. Como é executado offline, a inferência em lote não oferece a latência mais baixa. Aqui, a solicitação de inferência é processada com um acionador agendado ou baseado em evento de um trabalho de inferência em lote.
- inferência sem servidor – A inferência sem servidor é ideal para cargas de trabalho que têm períodos ociosos entre picos de tráfego e podem tolerar alguns segundos extras de latência (inicialização a frio) para a primeira chamada após um período ocioso. Por exemplo, um serviço de chatbot ou um aplicativo para processar formulários ou analisar dados de documentos. Nesse caso, talvez você queira uma opção de inferência online capaz de provisionar e dimensionar automaticamente a capacidade de computação com base no volume de solicitações de inferência. E durante o tempo ocioso, ele deve ser capaz de desligar completamente a capacidade de computação para que você não seja cobrado. A inferência sem servidor elimina o trabalho pesado indiferenciado de selecionar e gerenciar servidores, iniciando automaticamente os recursos de computação e dimensionando-os para dentro e para fora, dependendo do tráfego.
Use as funções de aptidão para selecionar a opção de inferência de ML correta
Decidir sobre a opção de hospedagem certa é importante porque afeta os usuários finais renderizados por seus aplicativos. Para isso, tomamos emprestado o conceito de funções de condicionamento físico, que foi cunhado por Neal Ford e seus colegas da AWS Partner ThoughtWorks em seu trabalho Construindo Arquiteturas Evolutivas. As funções de condicionamento físico fornecem uma avaliação prescritiva de várias opções de hospedagem com base nos objetivos do cliente. As funções de adequação ajudam a obter os dados necessários para permitir a evolução planejada de sua arquitetura. Eles definem valores mensuráveis para avaliar o quão perto sua solução está de alcançar seus objetivos definidos. As funções de adequação podem e devem ser adaptadas à medida que a arquitetura evolui para orientar um processo de mudança desejado. Isso fornece aos arquitetos uma ferramenta para orientar suas equipes, mantendo a autonomia da equipe.
Existem cinco funções principais de adequação com as quais os clientes se preocupam quando se trata de selecionar a opção de inferência de ML certa para hospedar seus modelos e aplicativos de ML.
função de fitness | Descrição |
Custo |
Implantar e manter um modelo de ML e um aplicativo de ML em uma estrutura escalável é um processo de negócios crítico, e os custos podem variar muito, dependendo das escolhas feitas sobre infraestrutura de hospedagem de modelo, opção de hospedagem, estruturas de ML, características do modelo de ML, otimizações, política de dimensionamento, e mais. As cargas de trabalho devem utilizar a infraestrutura de hardware de maneira ideal para garantir que o custo permaneça sob controle. Essa função de adequação refere-se especificamente ao custo de infraestrutura, que faz parte do custo total de propriedade (TCO) geral. Os custos de infraestrutura são os custos combinados de armazenamento, rede e computação. Também é fundamental entender outros componentes do TCO, incluindo custos operacionais e custos de segurança e conformidade. Os custos operacionais são os custos combinados de operação, monitoramento e manutenção da infraestrutura de ML. Os custos operacionais são calculados como o número de engenheiros necessários com base em cada cenário e o salário anual dos engenheiros, agregados em um período específico. Clientes que usam soluções de ML autogerenciadas em Amazon Elastic Compute Nuvem (Amazônia EC2), Serviço Amazon Elastic Container (Amazon ECS), e Serviço Amazon Elastic Kubernetes (Amazon EKS) precisam construir ferramentas operacionais por conta própria. Os clientes que usam o SageMaker incorrem em TCO significativamente menor. A inferência do SageMaker é um serviço totalmente gerenciado e fornece recursos prontos para implantação de modelos de ML para inferência. Você não precisa provisionar instâncias, monitorar a integridade da instância, gerenciar atualizações ou patches de segurança, emitir métricas operacionais ou criar monitoramento para suas cargas de trabalho de inferência de ML. Ele possui recursos integrados para garantir alta disponibilidade e resiliência. O SageMaker oferece suporte à segurança com criptografia de ponta a ponta em repouso e em trânsito, incluindo criptografia do volume raiz e Loja de blocos elásticos da Amazon (Amazon EBS) volume, Nuvem virtual privada da Amazon (Amazon VPC) suporte, AWS PrivateLink, chaves gerenciadas pelo cliente, Gerenciamento de acesso e identidade da AWS (IAM) controle de acesso refinado, AWS CloudTrail auditorias, criptografia entre nós para treinamento, controle de acesso baseado em tags, isolamento de rede e proxy de aplicativo interativo. Todos esses recursos de segurança são fornecidos prontos para uso no SageMaker e podem economizar às empresas dezenas de meses de esforço de engenharia em um período de 3 anos. O SageMaker é um serviço qualificado pela HIPAA e é certificado em PCI, SOC, GDPR e ISO. O SageMaker também oferece suporte a terminais FIPS. Para obter mais informações sobre o TCO, consulte O custo total de propriedade do Amazon SageMaker. |
latência de inferência | Muitos modelos e aplicativos de ML têm latência crítica, na qual a latência de inferência deve estar dentro dos limites especificados por um objetivo de nível de serviço. A latência de inferência depende de vários fatores, incluindo tamanho e complexidade do modelo, plataforma de hardware, ambiente de software e arquitetura de rede. Por exemplo, modelos maiores e mais complexos podem levar mais tempo para executar a inferência. |
Taxa de transferência (transações por segundo) | Para inferência de modelo, otimizar a taxa de transferência é crucial para ajustar o desempenho e atingir o objetivo de negócios do aplicativo ML. À medida que avançamos rapidamente em todos os aspectos do ML, incluindo implementações de baixo nível de operações matemáticas no design de chips, as bibliotecas específicas de hardware desempenham um papel maior na otimização do desempenho. Vários fatores, como tamanho da carga útil, saltos de rede, natureza dos saltos, recursos do gráfico do modelo, operadores no modelo e CPU, GPU e perfil de memória das instâncias de hospedagem do modelo afetam a taxa de transferência do modelo de ML. |
Como escalonar a complexidade da configuração | É crucial que os modelos ou aplicativos de ML sejam executados em uma estrutura escalonável que possa lidar com a demanda de tráfego variável. Ele também permite a utilização máxima dos recursos de CPU e GPU e evita o provisionamento excessivo de recursos de computação. |
Padrão de tráfego esperado | Os modelos ou aplicativos de ML podem ter diferentes padrões de tráfego, variando de tráfego ao vivo contínuo em tempo real a picos periódicos de milhares de solicitações por segundo e de padrões de solicitação pouco frequentes e imprevisíveis a solicitações em lote off-line em conjuntos de dados maiores. Recomenda-se trabalhar para trás a partir do padrão de tráfego esperado para selecionar a opção de hospedagem correta para seu modelo de ML. |
Implantando modelos com o SageMaker
SageMaker é um serviço totalmente gerenciado da AWS que oferece a todos os desenvolvedores e cientistas de dados a capacidade de criar, treinar e implantar rapidamente modelos de ML em grande escala. Com a inferência do SageMaker, você pode implantar seus modelos de ML em endpoints hospedados e obter resultados de inferência. O SageMaker oferece uma ampla seleção de hardware e recursos para atender aos seus requisitos de carga de trabalho, permitindo que você selecione mais de 70 tipos de instância com aceleração de hardware. O SageMaker também pode fornecer recomendação de tipo de instância de inferência usando um novo recurso chamado SageMaker Inference Recommender, caso você não tenha certeza de qual seria o ideal para sua carga de trabalho.
Você pode escolher as opções de implantação para atender melhor aos seus casos de uso, como inferência em tempo real, assíncrona, em lote e até endpoints sem servidor. Além disso, o SageMaker oferece várias estratégias de implantação, como canário, azul verde, sombra, e teste A/B para implantação de modelo, juntamente com implantação econômica com vários modelos, endpoints de vários contêineres e dimensionamento elástico. Com a inferência do SageMaker, você pode visualizar as métricas de desempenho de seus endpoints em Amazon CloudWatch, dimensionar endpoints automaticamente com base no tráfego e atualize seus modelos em produção sem perder a disponibilidade.
O SageMaker oferece quatro opções para implantar seu modelo para que você possa começar a fazer previsões:
- Inferência em tempo real – Isso é adequado para cargas de trabalho com requisitos de latência de milissegundos, tamanhos de carga útil de até 6 MB e tempos de processamento de até 60 segundos.
- Transformação em lote – Isso é ideal para previsões off-line em grandes lotes de dados disponíveis antecipadamente.
- Inferência assíncrona – Isso é projetado para cargas de trabalho que não têm requisitos de latência abaixo de um segundo, tamanhos de carga de até 1 GB e tempos de processamento de até 15 minutos.
- inferência sem servidor – Com inferência sem servidor, você pode implantar rapidamente modelos de ML para inferência sem precisar configurar ou gerenciar a infraestrutura subjacente. Além disso, você paga apenas pela capacidade computacional usada para processar solicitações de inferência, o que é ideal para cargas de trabalho intermitentes.
O diagrama a seguir pode ajudá-lo a entender as opções de implantação do modelo de hospedagem SageMaker junto com as avaliações de função de aptidão associadas.
Vamos explorar cada uma das opções de implantação com mais detalhes.
Inferência em tempo real no SageMaker
A inferência em tempo real do SageMaker é recomendada se você tiver tráfego sustentado e precisar de latência menor e consistente para suas solicitações com tamanhos de carga útil de até 6 MB e tempos de processamento de até 60 segundos. Você implanta seu modelo nos serviços de hospedagem SageMaker e obtém um endpoint que pode ser usado para inferência. Esses endpoints são totalmente gerenciados e oferecem suporte ao dimensionamento automático. A inferência em tempo real é popular para casos de uso em que você espera uma resposta síncrona de baixa latência com padrões de tráfego previsíveis, como recomendações personalizadas para produtos e serviços ou casos de uso de detecção de fraude transacional.
Normalmente, um aplicativo cliente envia solicitações ao ponto de extremidade HTTPS do SageMaker para obter inferências de um modelo implantado. Você pode implantar várias variantes de um modelo no mesmo endpoint HTTPS do SageMaker. Isso é útil para testar variações de um modelo em produção. O dimensionamento automático permite ajustar dinamicamente o número de instâncias provisionadas para um modelo em resposta a alterações em sua carga de trabalho.
A tabela a seguir fornece orientação sobre como avaliar a inferência em tempo real do SageMaker com base nas funções de adequação.
função de fitness | Descrição |
Custo |
Endpoints em tempo real oferecem resposta síncrona a solicitações de inferência. Como o endpoint está sempre em execução e disponível para fornecer resposta de inferência síncrona em tempo real, você paga pelo uso da instância. Os custos podem aumentar rapidamente quando você implanta vários endpoints, especialmente se os endpoints não utilizarem totalmente as instâncias subjacentes. Escolher a instância certa para seu modelo ajuda a garantir que você tenha a instância de melhor desempenho com o menor custo para seus modelos. O dimensionamento automático é recomendado para ajustar dinamicamente a capacidade, dependendo do tráfego, para manter um desempenho estável e previsível com o menor custo possível. O SageMaker estende o acesso às famílias de instâncias de ML baseadas em Graviton2 e Graviton3. AWS Graviton Os processadores são personalizados pela Amazon Web Services usando núcleos Arm Neoverse de 64 bits para oferecer o melhor desempenho de preço para suas cargas de trabalho em nuvem em execução no Amazon EC2. Com instâncias baseadas em Graviton, você tem mais opções para otimizar o custo e o desempenho ao implantar seus modelos de ML no SageMaker. O SageMaker também suporta Inf1 instâncias, fornecendo inferência de ML econômica e de alto desempenho. Com 1–16 Chips AWS Inferentia por instância, as instâncias Inf1 podem escalar em desempenho e fornecer taxa de transferência até três vezes maior e custo por inferência até 50% menor em comparação com as instâncias baseadas em GPU da AWS. Para usar instâncias Inf1 no SageMaker, você pode compilar seus modelos treinados usando Amazon Sage Maker Neo e selecione as instâncias Inf1 para implantar o modelo compilado no SageMaker. Você também pode explorar Planos de poupança para SageMaker para se beneficiar de economias de custo de até 64% em comparação com o preço sob demanda. Quando você cria um endpoint, o SageMaker anexa um volume de armazenamento EBS a cada instância de computação de ML que hospeda o endpoint. O tamanho do volume de armazenamento depende do tipo de instância. O custo adicional para endpoints em tempo real inclui o custo de GB por mês de armazenamento provisionado, mais dados de GB processados e dados de GB processados fora da instância do endpoint. |
latência de inferência | A inferência em tempo real é ideal quando você precisa de um endpoint persistente com requisitos de latência de milissegundos. Ele suporta tamanhos de carga útil de até 6 MB e tempos de processamento de até 60 segundos. |
Produtividade |
Um valor ideal de taxa de transferência de inferência é subjetivo a fatores como modelo, tamanho de entrada do modelo, tamanho do lote e tipo de instância de endpoint. Como prática recomendada, revise as métricas do CloudWatch para solicitações de entrada e utilização de recursos e selecione o tipo de instância apropriado para obter o rendimento ideal. Um aplicativo de negócios pode ser otimizado para throughput ou latência. Por exemplo, o lote dinâmico pode ajudar a aumentar a taxa de transferência de aplicativos sensíveis à latência usando inferência em tempo real. No entanto, há limites para o tamanho do lote, sem os quais a latência de inferência pode ser afetada. A latência de inferência aumentará à medida que você aumenta o tamanho do lote para melhorar a taxa de transferência. Portanto, a inferência em tempo real é uma opção ideal para aplicativos sensíveis à latência. O SageMaker fornece opções de inferência assíncrona e transformação em lote, que são otimizadas para oferecer maior rendimento em comparação com a inferência em tempo real se os aplicativos de negócios puderem tolerar uma latência ligeiramente maior. |
Como escalonar a complexidade da configuração |
Suporte a endpoints em tempo real do SageMaker dimensionamento automático sai da caixa. Quando a carga de trabalho aumenta, o dimensionamento automático coloca mais instâncias online. Quando a carga de trabalho diminui, o dimensionamento automático remove instâncias desnecessárias, ajudando a reduzir o custo de computação. Sem o dimensionamento automático, você precisa provisionar tráfego de pico ou indisponibilidade do modelo de risco. A menos que o tráfego para o seu modelo seja constante ao longo do dia, haverá excesso de capacidade não utilizada. Isso leva a uma baixa utilização e desperdício de recursos. Com o SageMaker, você pode configurar diferentes opções de dimensionamento com base no padrão de tráfego esperado. O dimensionamento simples ou o dimensionamento de rastreamento de destino é ideal quando você deseja dimensionar com base em uma métrica específica do CloudWatch. Você pode fazer isso escolhendo uma métrica específica e definindo valores limite. As métricas recomendadas para esta opção são médias Se você precisar de configuração avançada, poderá definir uma política de escalonamento de etapas para ajustar dinamicamente o número de instâncias a serem dimensionadas com base no tamanho da violação do alarme. Isso ajuda a configurar uma resposta mais agressiva quando a demanda atinge um determinado nível. Você pode usar uma opção de escalabilidade agendada quando souber que a demanda segue uma programação específica no dia, semana, mês ou ano. Isso ajuda a especificar uma programação única ou recorrente ou expressões cron junto com os horários de início e término, que formam os limites de quando a ação de dimensionamento automático é iniciada e interrompida. Para mais detalhes, consulte Configurar endpoints de inferência de escalonamento automático no Amazon SageMaker e Teste de carga e otimize um endpoint do Amazon SageMaker usando escalabilidade automática. |
Padrão de tráfego | A inferência em tempo real é ideal para cargas de trabalho com um padrão de tráfego contínuo ou regular. |
Inferência assíncrona no SageMaker
A inferência assíncrona do SageMaker é um novo recurso do SageMaker que enfileira as solicitações recebidas e as processa de forma assíncrona. Essa opção é ideal para solicitações com grandes tamanhos de carga útil (até 1 GB), longos tempos de processamento (até 15 minutos) e requisitos de latência quase em tempo real. Cargas de trabalho de exemplo para inferência assíncrona incluem empresas de assistência médica que processam imagens biomédicas de alta resolução ou vídeos como ecocardiogramas para detectar anomalias. Esses aplicativos recebem rajadas de tráfego de entrada em diferentes horários do dia e exigem processamento quase em tempo real a baixo custo. Os tempos de processamento para essas solicitações podem variar na ordem de minutos, eliminando a necessidade de executar inferência em tempo real. Em vez disso, as cargas úteis de entrada podem ser processadas de forma assíncrona a partir de um armazenamento de objeto como o Amazon S3 com enfileiramento automático e um limite de simultaneidade predefinido. Após o processamento, o SageMaker coloca a resposta de inferência no local do Amazon S3 retornado anteriormente. Você pode, opcionalmente, optar por receber notificações de sucesso ou erro via Serviço de notificação simples da Amazon (Amazônia SNS).
A tabela a seguir fornece orientação sobre como avaliar a inferência assíncrona do SageMaker com base nas funções de adequação.
função de fitness | Descrição |
Custo | A inferência assíncrona é uma ótima opção para cargas de trabalho sensíveis ao custo com grandes cargas e tráfego intermitente. A inferência assíncrona permite que você economize em custos dimensionando automaticamente a contagem de instâncias para zero quando não há solicitações para processar, para que você pague apenas quando seu endpoint estiver processando solicitações. As solicitações que são recebidas quando não há instâncias são enfileiradas para processamento depois que o ponto de extremidade aumenta. |
latência de inferência | A inferência assíncrona é ideal para requisitos de latência quase em tempo real. As solicitações são colocadas em uma fila e processadas assim que a computação estiver disponível. Isso normalmente resulta em dezenas de milissegundos de latência. |
Produtividade | A inferência assíncrona é ideal para casos de uso sensíveis à latência, porque os aplicativos não precisam comprometer a taxa de transferência. As solicitações não são descartadas durante picos de tráfego porque o ponto de extremidade de inferência assíncrona enfileira as solicitações em vez de descartá-las. |
Como escalonar a complexidade da configuração |
O SageMaker suporta dimensionamento automático para endpoint assíncrono. Ao contrário dos endpoints hospedados em tempo real, os endpoints de inferência assíncrona oferecem suporte à redução de instâncias para zero, definindo a capacidade mínima como zero. Para endpoints assíncronos, o SageMaker recomenda enfaticamente que você crie uma configuração de política para dimensionamento de rastreamento de destino para um modelo implantado (variante). Para casos de uso que podem tolerar uma penalidade de inicialização a frio de alguns minutos, você pode, opcionalmente, reduzir a contagem de instâncias de endpoint para zero quando não houver solicitações pendentes e aumentar novamente à medida que novas solicitações chegarem para que você pague apenas pela duração da endpoints estão processando ativamente solicitações. |
Padrão de tráfego | Os endpoints assíncronos enfileiram as solicitações recebidas e as processam de forma assíncrona. Eles são uma boa opção para padrões de tráfego intermitentes ou pouco frequentes. |
Inferência em lote no SageMaker
A transformação em lote do SageMaker é ideal para previsões off-line em grandes lotes de dados disponíveis antecipadamente. O recurso de transformação em lote é um método de alto desempenho e alto rendimento para transformar dados e gerar inferências. É ideal para cenários em que você está lidando com grandes lotes de dados, não precisa de latência de subsegundos ou precisa pré-processar e transformar os dados de treinamento. Os clientes em determinados domínios, como publicidade e marketing ou assistência médica, geralmente precisam fazer previsões off-line em conjuntos de dados de hiperescala, nos quais o alto rendimento geralmente é o objetivo do caso de uso e a latência não é uma preocupação.
Quando um trabalho de transformação em lote é iniciado, o SageMaker inicializa as instâncias de computação e distribui a carga de trabalho de inferência entre elas. Ele libera os recursos quando os trabalhos são concluídos, para que você pague apenas pelo que foi usado durante a execução do trabalho. Quando o trabalho é concluído, o SageMaker salva os resultados da previsão em um bucket do S3 especificado por você. Tarefas de inferência em lote geralmente são boas candidatas para escala horizontal. Cada trabalhador dentro de um cluster pode operar em um subconjunto diferente de dados sem a necessidade de trocar informações com outros trabalhadores. A AWS oferece várias opções de armazenamento e computação que permitem escalabilidade horizontal. As cargas de trabalho de exemplo para a transformação em lote do SageMaker incluem aplicativos offline, como aplicativos bancários para prever a rotatividade do cliente, em que um trabalho offline pode ser agendado para execução periódica.
A tabela a seguir fornece orientação sobre como avaliar a transformação em lote do SageMaker com base nas funções de adequação.
função de fitness | Descrição |
Custo | A transformação em lote do SageMaker permite executar previsões em conjuntos de dados em lote grandes ou pequenos. Você é cobrado pelo tipo de instância que escolher, com base na duração do uso. O SageMaker gerencia o provisionamento de recursos no início do trabalho e os libera quando o trabalho é concluído. Não há custo adicional de processamento de dados. |
latência de inferência | Você pode usar a invocação baseada em evento ou programada. A latência pode variar dependendo do tamanho dos dados de inferência, simultaneidade do trabalho, complexidade do modelo e capacidade da instância de computação. |
Produtividade |
Os trabalhos de transformação em lote podem ser executados em uma variedade de conjuntos de dados, de petabytes de dados a conjuntos de dados muito pequenos. Não há necessidade de redimensionar conjuntos de dados maiores em pequenos blocos de dados. Você pode acelerar trabalhos de transformação em lote usando valores ideais para parâmetros como MaxPayloadInMB, MaxConcurrentTransformsou Estratégia em lote. O valor ideal para O processamento em lote pode aumentar a taxa de transferência e otimizar seus recursos porque ajuda a concluir um número maior de inferências em um determinado período de tempo às custas da latência. Para otimizar a implantação do modelo para maior rendimento, a diretriz geral é aumentar o tamanho do lote até que o rendimento diminua. |
Como escalonar a complexidade da configuração | A transformação em lote do SageMaker é usada para inferência offline que não é sensível à latência. |
Padrão de tráfego | Para inferência offline, uma tarefa de transformação em lote é agendada ou iniciada usando um acionador baseado em evento. |
Inferência sem servidor no SageMaker
A inferência sem servidor do SageMaker permite implantar modelos de ML para inferência sem precisar configurar ou gerenciar a infraestrutura subjacente. Com base no volume de solicitações de inferência que seu modelo recebe, a inferência sem servidor do SageMaker provisiona, dimensiona e desativa automaticamente a capacidade de computação. Como resultado, você paga apenas pelo tempo de computação para executar seu código de inferência e pela quantidade de dados processados, não pelo tempo ocioso. Você pode usar os algoritmos integrados do SageMaker e os contêineres de estrutura de ML para implantar seu modelo em um endpoint de inferência sem servidor ou optar por trazer seu próprio contêiner. Se o tráfego se tornar previsível e estável, você poderá atualizar facilmente de um endpoint de inferência sem servidor para um endpoint em tempo real do SageMaker sem a necessidade de fazer alterações na imagem do contêiner. Com a inferência sem servidor, você também se beneficia de outros recursos do SageMaker, incluindo métricas integradas, como contagem de invocação, falhas, latência, métricas de host e erros no CloudWatch.
A tabela a seguir fornece orientação sobre como avaliar a inferência sem servidor do SageMaker com base nas funções de adequação.
função de fitness | Descrição |
Custo | Com um modelo de pagamento conforme o uso, a inferência sem servidor é uma opção econômica se você tiver padrões de tráfego pouco frequentes ou intermitentes. Você paga apenas pela duração em que o terminal processa a solicitação e, portanto, pode economizar custos se o padrão de tráfego for intermitente. |
latência de inferência |
Os endpoints sem servidor oferecem baixa latência de inferência (na ordem de milissegundos a segundos), com a capacidade de escalar instantaneamente de dezenas a milhares de inferências em segundos com base nos padrões de uso, tornando-o ideal para aplicativos de ML com tráfego intermitente ou imprevisível. Como os endpoints sem servidor provisionam recursos de computação sob demanda, seu endpoint pode experimentar alguns segundos extras de latência (inicialização a frio) para a primeira chamada após um período ocioso. O tempo de inicialização a frio depende do tamanho do seu modelo, quanto tempo leva para baixar seu modelo e o tempo de inicialização do seu contêiner. |
Produtividade | Ao configurar seu endpoint sem servidor, você pode especificar o tamanho da memória e o número máximo de invocações simultâneas. A inferência sem servidor do SageMaker atribui automaticamente recursos de computação proporcionais à memória selecionada. Se você escolher um tamanho de memória maior, seu contêiner terá acesso a mais vCPUs. Como regra geral, o tamanho da memória deve ser pelo menos tão grande quanto o tamanho do seu modelo. Os tamanhos de memória que você pode escolher são 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB e 6144 MB. Independentemente do tamanho da memória que você escolher, os endpoints sem servidor têm 5 GB de armazenamento em disco efêmero disponível. |
Como escalonar a complexidade da configuração | Os endpoints sem servidor iniciam automaticamente os recursos de computação e os expandem dependendo do tráfego, eliminando a necessidade de escolher tipos de instância ou gerenciar políticas de dimensionamento. Isso elimina o trabalho pesado indiferenciado de selecionar e gerenciar servidores. |
Padrão de tráfego | A inferência sem servidor é ideal para cargas de trabalho com padrões de tráfego pouco frequentes ou intermitentes. |
Modelar padrões de design de hospedagem no SageMaker
Os endpoints de inferência do SageMaker usam contêineres do Docker para hospedar modelos de ML. Os contêineres permitem que você empacote o software em unidades padronizadas que são executadas de forma consistente em qualquer plataforma compatível com o Docker. Isso garante portabilidade entre plataformas, implantações de infraestrutura imutáveis e gerenciamento de mudanças e implementações de CI/CD mais fáceis. O SageMaker fornece contêineres gerenciados pré-construídos para estruturas populares, como Apache MXNet, TensorFlow, PyTorch, Sklearn e Hugging Face. Para obter uma lista completa de imagens de contêiner do SageMaker disponíveis, consulte Imagens de recipientes de aprendizagem profunda disponíveis. Caso o SageMaker não tenha um contêiner compatível, você também pode criar seu próprio contêiner (BYOC) e enviar sua própria imagem personalizada, instalando as dependências necessárias para seu modelo.
Para implantar um modelo no SageMaker, você precisa de um contêiner (contêineres de estrutura gerenciada do SageMaker ou BYOC) e uma instância de computação para hospedar o contêiner. O SageMaker oferece suporte a várias opções avançadas para padrões de design de hospedagem de modelos de ML comuns, nos quais os modelos podem ser hospedados em um único contêiner ou co-hospedados em um contêiner compartilhado.
Um aplicativo de ML em tempo real pode usar um único modelo ou vários modelos para atender a uma única solicitação de previsão. O diagrama a seguir mostra vários cenários de inferência para um aplicativo ML.
Vamos explorar uma opção de hospedagem do SageMaker adequada para cada um dos cenários de inferência anteriores. Você pode consultar as funções de adequação para avaliar se é a opção certa para o caso de uso específico.
Hospedando um aplicativo de ML baseado em modelo único
Existem várias opções para hospedar aplicativos de ML baseados em modelo único usando os serviços de hospedagem SageMaker, dependendo do cenário de implantação.
Endpoint de modelo único
Os endpoints de modelo único do SageMaker permitem que você hospede um modelo em um contêiner hospedado em instâncias dedicadas para baixa latência e alta taxa de transferência. Esses endpoints são totalmente gerenciados e oferecem suporte ao dimensionamento automático. Você pode configurar o endpoint de modelo único como um endpoint provisionado onde você passa a configuração da infraestrutura do endpoint, como o tipo e a contagem da instância, ou um endpoint sem servidor onde o SageMaker inicia automaticamente os recursos de computação e os escala dentro e fora dependendo do tráfego, eliminando a necessidade para escolher tipos de instância ou gerenciar políticas de escalabilidade. Os endpoints sem servidor são para aplicativos com tráfego intermitente ou imprevisível.
O diagrama a seguir mostra cenários de inferência de endpoint de modelo único.
A tabela a seguir fornece orientação sobre como avaliar as funções de aptidão para um endpoint de modelo único provisionado. Para avaliações da função de adequação do ponto de extremidade sem servidor, consulte a seção de ponto de extremidade sem servidor nesta postagem.
função de fitness | Descrição |
Custo | Você é cobrado pelo uso do tipo de instância que escolher. Como o endpoint está sempre em execução e disponível, os custos podem aumentar rapidamente. Escolher a instância certa para seu modelo ajuda a garantir que você tenha a instância de melhor desempenho com o menor custo para seus modelos. O dimensionamento automático é recomendado para ajustar dinamicamente a capacidade, dependendo do tráfego, para manter um desempenho estável e previsível com o menor custo possível. |
latência de inferência | Um endpoint de modelo único fornece inferência síncrona, interativa e em tempo real com requisitos de latência de milissegundos. |
Produtividade | A taxa de transferência pode ser afetada por vários fatores, como tamanho de entrada do modelo, tamanho do lote, tipo de instância de endpoint e assim por diante. Recomenda-se revisar as métricas do CloudWatch para solicitações de entrada e utilização de recursos e selecionar o tipo de instância apropriado para obter a taxa de transferência ideal. O SageMaker fornece recursos para gerenciar recursos e otimizar o desempenho de inferência ao implantar modelos de ML. Você pode otimize o desempenho do modelo usando o Neo, ou use instâncias Inf1 para melhor rendimento de seus modelos hospedados no SageMaker usando uma instância de GPU para seu endpoint. |
Como escalonar a complexidade da configuração | A escala automática é suportada imediatamente. A SageMaker recomenda a escolha de um configuração de escala executando testes de carga. |
Padrão de tráfego | Um endpoint de modelo único é ideal para cargas de trabalho com padrões de tráfego previsíveis. |
Co-hospedagem de vários modelos
Quando você está lidando com um grande número de modelos, a implantação de cada um em um endpoint individual com um contêiner e uma instância dedicados pode resultar em um aumento significativo no custo. Além disso, também fica difícil gerenciar tantos modelos em produção, especialmente quando você não precisa invocar todos os modelos ao mesmo tempo, mas ainda precisa que eles estejam sempre disponíveis. A co-hospedagem de vários modelos nos mesmos recursos de computação subjacentes facilita o gerenciamento de implantações de ML em escala e reduz os custos de hospedagem por meio do aumento do uso do endpoint e de seus recursos de computação subjacentes. O SageMaker oferece suporte a opções avançadas de co-hospedagem de modelo, como terminal multimodelo (MME) para modelos homogêneos e terminal multicontêiner (MCE) para modelos heterogêneos. Os modelos homogêneos usam a mesma estrutura de ML em um contêiner de serviço compartilhado, enquanto os modelos heterogêneos permitem implantar vários contêineres de serviço que usam modelos ou estruturas diferentes em um único endpoint.
O diagrama a seguir mostra as opções de co-hospedagem de modelo usando o SageMaker.
Pontos de extremidade de vários modelos do SageMaker
SageMaker MMEs permitem hospedar vários modelos usando um contêiner de serviço compartilhado em um único endpoint. Esta é uma solução escalável e econômica para implantar um grande número de modelos que atendem ao mesmo caso de uso, estrutura ou lógica de inferência. Os MMEs podem atender solicitações dinamicamente com base no modelo invocado pelo chamador. Ele também reduz a sobrecarga de implantação porque o SageMaker gerencia o carregamento de modelos na memória e os dimensiona com base nos padrões de tráfego para eles. Esse recurso é ideal quando você tem um grande número de modelos semelhantes que pode servir por meio de um contêiner de serviço compartilhado e não precisa acessar todos os modelos ao mesmo tempo. Os endpoints de vários modelos também permitem o compartilhamento de tempo de recursos de memória em seus modelos. Isso funciona melhor quando os modelos são bastante semelhantes em tamanho e latência de invocação, permitindo que os MMEs usem efetivamente as instâncias em todos os modelos. Os MMEs do SageMaker oferecem suporte à hospedagem de modelos baseados em CPU e GPU. Ao usar modelos baseados em GPU, você pode reduzir os custos de implantação do modelo por meio do aumento do uso do endpoint e de suas instâncias de computação aceleradas subjacentes. Para um caso de uso real de MMEs, consulte Como dimensionar a inferência de aprendizado de máquina para casos de uso de SaaS multilocatário.
A tabela a seguir fornece orientação sobre como avaliar as funções de aptidão para MMEs.
função de fitness | Descrição |
Custo |
Os MMEs permitem o uso de um contêiner de serviço compartilhado para hospedar milhares de modelos em um único endpoint. Isso reduz significativamente os custos de hospedagem, melhorando a utilização do endpoint em comparação com o uso de endpoints de modelo único. Por exemplo, se você tiver 10 modelos para implantar usando uma instância ml.c5.large, com base em Preços do SageMaker, o custo de ter 10 endpoints persistentes de modelo único é: 10 * US$ 0.102 = US$ 1.02 por hora. Considerando que, com um MME hospedando os 10 modelos, alcançamos uma economia de custos 10 vezes maior: 1 * US$ 0.102 = US$ 0.102 por hora. |
latência de inferência |
Por padrão, os MMEs armazenam em cache os modelos usados com frequência na memória e no disco para fornecer inferência de baixa latência. Os modelos em cache são descarregados ou excluídos do disco apenas quando um contêiner fica sem memória ou espaço em disco para acomodar um novo modelo de destino. Os MMEs permitem o carregamento lento de modelos, o que significa que os modelos são carregados na memória quando invocados pela primeira vez. Isso otimiza a utilização da memória; no entanto, causa picos de tempo de resposta no primeiro carregamento, resultando em um problema de inicialização a frio. Portanto, os MMEs também são adequados para cenários que podem tolerar penalidades ocasionais de latência relacionadas à inicialização a frio que ocorrem ao invocar modelos usados com pouca frequência. Para atender às metas de latência e taxa de transferência dos aplicativos de ML, as instâncias de GPU são preferidas às instâncias de CPU (dada a oferta de poder computacional das GPUs). Com suporte MME para GPU, você pode implantar milhares de modelos de aprendizado profundo por trás de um endpoint do SageMaker. Os MMEs podem executar vários modelos em um núcleo de GPU, compartilhar instâncias de GPU atrás de um endpoint em vários modelos e carregar e descarregar dinamicamente modelos com base no tráfego de entrada. Com isso, você pode economizar custos significativamente e obter o melhor desempenho de preço. Se o seu caso de uso exigir transações por segundo (TPS) significativamente maiores ou requisitos de latência, recomendamos hospedar os modelos em endpoints dedicados. |
Produtividade |
Um valor ideal de taxa de transferência de inferência MME depende de fatores como modelo, tamanho da carga útil e tipo de instância do endpoint. Uma quantidade maior de memória de instância permite que você tenha mais modelos carregados e prontos para atender a solicitações de inferência. Você não precisa perder tempo carregando o modelo. Uma quantidade maior de vCPUs permite invocar mais modelos exclusivos simultaneamente. Os MMEs carregam e descarregam dinamicamente o modelo de e para a memória da instância, o que pode afetar o desempenho de E/S. SageMaker MMEs com GPU funcionam usando Servidor de inferência NVIDIA Triton, que é um software de serviço de inferência de código aberto que simplifica o processo de serviço de inferência e fornece alto desempenho de inferência. O SageMaker carrega o modelo na memória do contêiner NVIDIA Triton em uma instância acelerada por GPU e atende à solicitação de inferência. O núcleo da GPU é compartilhado por todos os modelos em uma instância. Se o modelo já estiver carregado na memória do contêiner, as solicitações subsequentes serão atendidas mais rapidamente porque o SageMaker não precisa baixá-lo e carregá-lo novamente. Um teste e análise de desempenho adequados são recomendados em implantações de produção bem-sucedidas. O SageMaker fornece métricas do CloudWatch para endpoints multimodelos para que você possa determinar o uso do endpoint e a taxa de ocorrência do cache para ajudar a otimizar seu endpoint. |
Como escalonar a complexidade da configuração | Os terminais multimodelo SageMaker oferecem suporte total ao dimensionamento automático, que gerencia réplicas de modelos para garantir que os modelos sejam dimensionados com base em padrões de tráfego. No entanto, um teste de carga adequado é recomendado para determinar o tamanho ideal das instâncias para escalabilidade automática do endpoint. O dimensionamento correto da frota do MME é importante para evitar o descarregamento de muitos modelos. Carregar centenas de modelos em algumas instâncias maiores pode levar à limitação em alguns casos, e usar mais instâncias menores pode ser preferível. Para aproveitar o escalonamento de modelo automatizado no SageMaker, certifique-se de ter configuração do escalonamento automático da instância para provisionar capacidade de instância adicional. Configure sua política de escalabilidade no nível do endpoint com parâmetros personalizados ou invocações por minuto (recomendado) para adicionar mais instâncias à frota de endpoints. As taxas de invocação usadas para acionar um evento de dimensionamento automático são baseadas no conjunto agregado de previsões em todo o conjunto de modelos atendidos pelo endpoint. |
Padrão de tráfego | Os MMEs são ideais quando você tem um grande número de modelos de tamanho semelhante que pode servir por meio de um contêiner de serviço compartilhado e não precisa acessar todos os modelos ao mesmo tempo. |
Pontos de extremidade de vários contêineres do SageMaker
SageMaker MCE suporta a implantação de até 15 contêineres que usam modelos ou estruturas diferentes em um único endpoint e os invoca independentemente ou em sequência para inferência de baixa latência e economia de custos. Os modelos podem ser completamente heterogêneos, com sua própria pilha de serviço independente. Hospedar com segurança vários modelos de diferentes estruturas em uma única instância pode economizar até 90% no custo.
Os padrões de invocação do MCE são os seguintes:
- Pipelines de inferência – Os contêineres em um MME podem ser invocados em uma sequência linear, também conhecida como pipeline de inferência serial. Eles são normalmente usados para separar pré-processamento, inferência de modelo e pós-processamento em contêineres independentes. A saída do contêiner atual é passada como entrada para o próximo. Eles são representados como um único modelo de pipeline no SageMaker. Um pipeline de inferência pode ser implantado como um MME, onde um dos contêineres no pipeline pode atender solicitações dinamicamente com base no modelo que está sendo invocado.
- Invocação direta - Com invocação direta, uma solicitação pode ser enviada para um contêiner de inferência específico hospedado em um MCE.
A tabela a seguir fornece orientação sobre como avaliar as funções de aptidão para MCEs.
função de fitness | Descrição |
Custo | Os MCEs permitem executar até 15 contêineres de ML diferentes em um único endpoint e invocá-los independentemente, economizando custos. Essa opção é ideal quando você tem vários modelos em execução em diferentes pilhas de serviço com necessidades de recursos semelhantes e quando modelos individuais não têm tráfego suficiente para utilizar a capacidade total das instâncias de endpoint. Os MCEs são, portanto, mais econômicos do que um endpoint de modelo único. Os MCEs oferecem resposta de inferência síncrona, o que significa que o endpoint está sempre disponível e você paga pelo tempo de atividade da instância. O custo pode aumentar dependendo do número e tipo de instâncias. |
latência de inferência | Os MCEs são ideais para executar aplicativos de ML com diferentes estruturas e algoritmos de ML para cada modelo que são acessados com pouca frequência, mas ainda requerem inferência de baixa latência. Os modelos estão sempre disponíveis para inferência de baixa latência e não há problema de inicialização a frio. |
Produtividade | Os MCEs são limitados a até 15 contêineres em um endpoint de vários contêineres, e a inferência de GPU não é suportada devido à contenção de recursos. Para endpoints de vários contêineres usando o modo de invocação direta, o SageMaker não apenas fornece métricas em nível de instância como faz com outros endpoints comuns, mas também oferece suporte a métricas por contêiner. Como prática recomendada, revise as métricas do CloudWatch para solicitações de entrada e utilização de recursos e selecione o tipo de instância apropriado para obter o rendimento ideal. |
Como escalonar a complexidade da configuração | Os MCEs suportam dimensionamento automático. No entanto, para configurar o dimensionamento automático, é recomendável que o modelo em cada contêiner exiba utilização de CPU e latência semelhantes em cada solicitação de inferência. Isso é recomendado porque se o tráfego para o endpoint de vários contêineres mudar de um modelo de baixa utilização da CPU para um modelo de alta utilização da CPU, mas o volume geral de chamadas permanecer o mesmo, o endpoint não será expandido e pode não haver instâncias suficientes para lidar com todas as solicitações para o modelo de alta utilização da CPU. |
Padrão de tráfego | Os MCEs são ideais para cargas de trabalho com padrões de tráfego contínuos ou regulares, para hospedar modelos em diferentes estruturas (como TensorFlow, PyTorch ou Sklearn) que podem não ter tráfego suficiente para saturar a capacidade total de uma instância de endpoint. |
Hospedando um aplicativo de ML baseado em vários modelos
Muitos aplicativos de negócios precisam usar vários modelos de ML para atender a uma única solicitação de previsão para seus consumidores. Por exemplo, uma empresa de varejo que deseja fornecer recomendações aos seus usuários. O aplicativo ML neste caso de uso pode querer usar diferentes modelos customizados para recomendar diferentes categorias de produtos. Se a empresa deseja adicionar personalização às recomendações usando informações individuais do usuário, o número de modelos personalizados aumenta ainda mais. Hospedar cada modelo personalizado em uma instância de computação distinta não é apenas um custo proibitivo, mas também leva à subutilização dos recursos de hospedagem se nem todos os modelos forem usados com frequência. O SageMaker oferece opções de hospedagem eficientes para aplicativos de ML baseados em vários modelos.
O diagrama a seguir mostra as opções de hospedagem multimodelo para um único endpoint usando o SageMaker.
Pipeline de inferência serial
Um pipeline de inferência é um modelo do SageMaker composto por uma sequência linear de 2 a 15 contêineres que processam solicitações de inferências nos dados. Você usa um pipeline de inferência para definir e implantar qualquer combinação de algoritmos integrados pré-treinados do SageMaker e seus próprios algoritmos personalizados empacotados em contêineres do Docker. Você pode usar um pipeline de inferência para combinar tarefas de ciência de dados de pré-processamento, previsões e pós-processamento. A saída de um contêiner é passada como entrada para o próximo. Ao definir os contêineres para um modelo de pipeline, você também especifica a ordem na qual os contêineres são executados. Eles são representados como um único modelo de pipeline no SageMaker. O pipeline de inferência pode ser implantado como um MME, onde um dos contêineres no pipeline pode atender solicitações dinamicamente com base no modelo que está sendo invocado. Você também pode executar um transformação em lote trabalho com um pipeline de inferência. Os pipelines de inferência são totalmente gerenciados.
A tabela a seguir fornece orientação sobre como avaliar as funções de adequação para hospedagem de modelo de ML usando um pipeline de inferência serial.
função de fitness | Descrição |
Custo | O pipeline de inferência serial permite que você execute até 15 contêineres de ML diferentes em um único endpoint, levando à economia de hospedagem dos contêineres de inferência. Não há custos adicionais para usar esse recurso. Você paga apenas pelas instâncias executadas em um endpoint. O custo pode aumentar dependendo do número e tipo de instâncias. |
latência de inferência | Quando um aplicativo de ML é implantado como um pipeline de inferência, os dados entre modelos diferentes não saem do espaço do contêiner. O processamento de recursos e as inferências são executados com baixa latência porque os contêineres são colocados nas mesmas instâncias do EC2. |
Produtividade | Dentro de um modelo de pipeline de inferência, o SageMaker lida com invocações como uma sequência de solicitações HTTP. O primeiro contêiner no pipeline lida com a solicitação inicial, então a resposta intermediária é enviada como uma solicitação para o segundo contêiner e assim por diante, para cada contêiner no pipeline. O SageMaker retorna a resposta final ao cliente. A taxa de transferência é subjetiva para fatores como modelo, tamanho de entrada do modelo, tamanho do lote e tipo de instância do endpoint. Como prática recomendada, revise as métricas do CloudWatch para solicitações de entrada e utilização de recursos e selecione o tipo de instância apropriado para obter o rendimento ideal. |
Como escalonar a complexidade da configuração | Os pipelines de inferência serial oferecem suporte ao escalonamento automático. No entanto, para configurar o dimensionamento automático, é recomendável que o modelo em cada contêiner exiba utilização de CPU e latência semelhantes em cada solicitação de inferência. Isso é recomendado porque se o tráfego para o endpoint de vários contêineres mudar de um modelo de baixa utilização da CPU para um modelo de alta utilização da CPU, mas o volume geral de chamadas permanecer o mesmo, o endpoint não será expandido e pode não haver instâncias suficientes para lidar com todas as solicitações para o modelo de alta utilização da CPU. |
Padrão de tráfego |
Os pipelines de inferência serial são ideais para padrões de tráfego previsíveis com modelos executados sequencialmente no mesmo endpoint. |
Implantando conjuntos de modelos (Triton DAG):
O SageMaker oferece integração com Servidor de inferência NVIDIA Triton NFT`s Contêineres do servidor de inferência Triton. Esses contêineres incluem NVIDIA Triton Inference Server, suporte para estruturas de ML comuns e variáveis de ambiente úteis que permitem otimizar o desempenho no SageMaker. Com as imagens de contêiner NVIDIA Triton, você pode servir modelos de ML facilmente e se beneficiar das otimizações de desempenho, lotes dinâmicos e suporte a vários frameworks fornecidos pelo NVIDIA Triton. O Triton ajuda a maximizar a utilização de GPU e CPU, reduzindo ainda mais o custo da inferência.
Em casos de uso de negócios em que os aplicativos de ML usam vários modelos para atender a uma solicitação de previsão, se cada modelo usar uma estrutura diferente ou for hospedado em uma instância separada, isso pode levar a um aumento da carga de trabalho e do custo, bem como um aumento na latência geral. O SageMaker NVIDIA Triton Inference Server oferece suporte à implantação de modelos de todas as principais estruturas, como TensorFlow GraphDef, TensorFlow SavedModel, ONNX, PyTorch TorchScript, TensorRT e formatos de modelo Python/C++ e muito mais. O conjunto de modelos Triton representa um pipeline de um ou mais modelos ou lógica de pré-processamento e pós-processamento e a conexão de tensores de entrada e saída entre eles. Uma única solicitação de inferência para um conjunto aciona a execução de todo o pipeline. O Triton também possui vários algoritmos integrados de agendamento e lote que combinam solicitações de inferência individuais para melhorar o rendimento da inferência. Essas decisões de agendamento e lote são transparentes para o cliente que solicita a inferência. Os modelos podem ser executados em CPUs ou GPUs para máxima flexibilidade e suporte a requisitos de computação heterogêneos.
A hospedagem de vários modelos com suporte de GPU em endpoints de vários modelos é suportada por meio do Servidor de Inferência SageMaker Triton. O NVIDIA Triton Inference Server foi estendido para implementar um Contrato de API MME, para integração com MMEs. Você pode usar o NVIDIA Triton Inference Server, que cria uma configuração de repositório de modelo para diferentes back-ends de estrutura, para implantar um MME com dimensionamento automático. Esse recurso permite dimensionar centenas de modelos hiperpersonalizados que são ajustados para atender às experiências exclusivas do usuário final em aplicativos de IA. Você também pode usar esse recurso para obter o desempenho de preço necessário para seu aplicativo de inferência usando GPUs fracionais. Para saber mais, consulte Execute vários modelos de aprendizado profundo na GPU com endpoints de vários modelos do Amazon SageMaker.
A tabela a seguir fornece orientação sobre como avaliar as funções de adequação para hospedagem de modelo de ML usando MMEs com suporte a GPU em contêineres de inferência Triton. Para endpoints de modelo único e avaliações de funções de adequação de endpoint sem servidor, consulte as seções anteriores desta postagem.
função de fitness | Descrição |
Custo | Os MMEs SageMaker com suporte a GPU usando o Triton Inference Server fornecem uma maneira escalável e econômica de implantar um grande número de modelos de aprendizado profundo por trás de um terminal SageMaker. Com MMEs, vários modelos compartilham a instância de GPU por trás de um endpoint. Isso permite quebrar o custo linearmente crescente de hospedar vários modelos e reutilizar a infraestrutura em todos os modelos. Você paga pelo tempo de atividade da instância. |
latência de inferência |
O SageMaker com Triton Inference Server foi desenvolvido especificamente para maximizar a taxa de transferência e a utilização de hardware com latência de inferência ultrabaixa (milissegundos de um dígito). Possui uma ampla variedade de estruturas de ML compatíveis (incluindo TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT) e back-ends de infraestrutura, incluindo GPUs NVIDIA, CPUs e Inferência da AWS. Com o suporte MME para GPU usando o SageMaker Triton Inference Server, você pode implantar milhares de modelos de aprendizado profundo por trás de um endpoint SageMaker. O SageMaker carrega o modelo na memória do contêiner NVIDIA Triton em uma instância acelerada por GPU e atende à solicitação de inferência. O núcleo da GPU é compartilhado por todos os modelos em uma instância. Se o modelo já estiver carregado na memória do contêiner, as solicitações subsequentes serão atendidas mais rapidamente porque o SageMaker não precisa baixá-lo e carregá-lo novamente. |
Produtividade |
Os MMEs oferecem recursos para executar vários modelos de aprendizado profundo ou ML na GPU, ao mesmo tempo, com o Triton Inference Server. Isso permite que você use facilmente o serviço de inferência de alto desempenho e multiestrutura NVIDIA Triton com a implantação de modelo totalmente gerenciado do SageMaker. O Triton é compatível com todas as inferências baseadas em NVIDIA GPU, x86, Arm® CPU e AWS Inferentia. Ele oferece lotes dinâmicos, execuções simultâneas, configuração de modelo ideal, conjunto de modelos e entradas de áudio e vídeo de streaming para maximizar o rendimento e a utilização. Outros fatores, como rede e tamanho da carga útil, podem desempenhar um papel mínimo na sobrecarga associada à inferência. |
Como escalonar a complexidade da configuração |
Os MMEs podem escalar horizontalmente usando uma política de escala automática e provisionar instâncias de computação de GPU adicionais com base em métricas como Com o servidor de inferência Triton, você pode criar facilmente um contêiner personalizado que inclua seu modelo com o Triton e trazê-lo para o SageMaker. O SageMaker Inference lidará com as solicitações e dimensionará automaticamente o contêiner à medida que o uso aumentar, facilitando a implantação do modelo com o Triton na AWS. |
Padrão de tráfego |
Os MMEs são ideais para padrões de tráfego previsíveis com modelos executados como DAGs no mesmo endpoint. O SageMaker cuida da modelagem de tráfego para o endpoint MME e mantém cópias de modelo ideais em instâncias de GPU para obter o melhor desempenho de preço. Ele continua roteando o tráfego para a instância em que o modelo é carregado. Se os recursos da instância atingirem a capacidade devido à alta utilização, o SageMaker descarregará os modelos menos usados do contêiner para liberar recursos para carregar modelos usados com mais frequência. |
Melhores práticas
Considere as seguintes práticas recomendadas:
- Alta coesão e baixo acoplamento entre os modelos – Hospede os modelos no mesmo contêiner com alta coesão (conduz a funcionalidade de um único negócio) e os encapsule para facilitar o upgrade e a capacidade de gerenciamento. Ao mesmo tempo, separe esses modelos uns dos outros (hospede-os em contêineres diferentes) para que você possa atualizar facilmente um modelo sem afetar outros modelos. Hospede vários modelos que usam contêineres diferentes atrás de um ponto de extremidade e invoque-os independentemente ou adicione lógica de pré-processamento e pós-processamento de modelo como um pipeline de inferência serial.
- latência de inferência – Agrupe os modelos orientados à funcionalidade de um único negócio e hospede-os em um único contêiner para minimizar o número de saltos e, portanto, minimizar a latência geral. Existem outras ressalvas, como se os modelos agrupados usarem várias estruturas; você também pode optar por hospedar em vários contêineres, mas executar no mesmo host para reduzir a latência e minimizar os custos.
- Agrupe logicamente modelos de ML com alta coesão – O grupo lógico pode consistir em modelos homogêneos (por exemplo, todos os modelos XGBoost) ou heterogêneos (por exemplo, alguns XGBoost e alguns BERT). Pode consistir em modelos que são compartilhados em várias funcionalidades de negócios ou podem ser específicos para atender a apenas uma funcionalidade de negócios.
- modelos compartilhados – Se o grupo lógico consistir em modelos compartilhados, a facilidade de atualizar os modelos e a latência desempenharão um papel importante na arquitetura dos terminais do SageMaker. Por exemplo, se a latência for uma prioridade, é melhor colocar todos os modelos em um único contêiner atrás de um único endpoint do SageMaker para evitar vários saltos. A desvantagem é que, se algum dos modelos precisar ser atualizado, isso resultará na atualização de todos os pontos de extremidade relevantes do SageMaker que hospedam esse modelo.
- Modelos não compartilhados – Se o grupo lógico consistir apenas em modelos específicos de recursos de negócios e não for compartilhado com outros grupos, a complexidade do empacotamento e as dimensões de latência se tornarão essenciais. É aconselhável hospedar esses modelos em um único contêiner por trás de um único endpoint do SageMaker.
- Uso eficiente de hardware (CPU, GPU) – Agrupar modelos baseados em CPU e hospedá-los no mesmo host para que você possa usar a CPU com eficiência. Da mesma forma, agrupe modelos baseados em GPU para que você possa usá-los e dimensioná-los com eficiência. Existem cargas de trabalho híbridas que requerem CPU e GPU no mesmo host. A hospedagem dos modelos somente de CPU e somente de GPU no mesmo host deve ser orientada por requisitos de alta coesão e latência do aplicativo. Além disso, custo, capacidade de dimensionamento e raio de explosão no impacto em caso de falha são as principais dimensões a serem observadas.
- Funções de condicionamento físico – Use as funções de condicionamento físico como diretriz para selecionar uma opção de hospedagem de ML.
Conclusão
Quando se trata de hospedagem de ML, não existe uma abordagem única para todos. Os profissionais de ML precisam escolher o padrão de design certo para enfrentar seus desafios de hospedagem de ML. A avaliação das funções de condicionamento fornece orientação prescritiva sobre a seleção da opção de hospedagem de ML correta.
Para obter mais detalhes sobre cada uma das opções de hospedagem, consulte as seguintes postagens desta série:
Sobre os autores
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.
Deepali Rajale é gerente técnico de contas especialista em AI/ML da Amazon Web Services. Ela trabalha com clientes corporativos fornecendo orientação técnica sobre a implementação de soluções de aprendizado de máquina com as melhores práticas. Em seu tempo livre, ela gosta de fazer caminhadas, filmes e sair com a família e amigos.
Saurabh Trikande é gerente de produto sênior da Amazon SageMaker Inference. Ele é apaixonado por trabalhar com clientes e motivado pelo objetivo de democratizar o aprendizado de máquina. Ele se concentra nos principais desafios relacionados à implantação de aplicativos de ML complexos, modelos de ML multilocatários, otimizações de custos e à implantação de modelos de aprendizado profundo mais acessíveis. Em seu tempo livre, Saurabh gosta de caminhar, aprender sobre tecnologias inovadoras, seguir o TechCrunch e passar tempo com sua família.
- Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
- Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/model-hosting-patterns-in-amazon-sagemaker-part-1-common-design-patterns-for-building-ml-applications-on-amazon-sagemaker/
- 1
- 10
- 100
- 11
- 39
- 7
- 70
- a
- habilidade
- Capaz
- Sobre
- acelerado
- Acesso
- acessadas
- acessível
- acomodar
- Conta
- preciso
- Alcançar
- alcançar
- em
- Açao Social
- ativamente
- Adição
- Adicional
- Adicionalmente
- endereço
- avançar
- avançado
- Vantagem
- Publicidade
- afetar
- Depois de
- agregação
- Agregador
- agressivo
- acordos
- AI
- AI / ML
- alarme
- algoritmos
- Todos os Produtos
- Permitindo
- permite
- já
- sempre
- Amazon
- Amazon EC2
- Amazon Sage Maker
- Amazon Web Services
- quantidade
- análise
- analisar
- e
- e infra-estrutura
- anual
- Outro
- apache
- api
- Apple
- Aplicação
- aplicações
- abordagem
- apropriado
- Aplicativos
- arquitetura
- ARM
- artificial
- inteligência artificial
- aspectos
- avaliação
- associado
- atributos
- auditivo
- auditorias
- auto
- Automatizado
- Automático
- automaticamente
- disponibilidade
- disponível
- média
- AWS
- em caminho duplo
- Apoiado
- Bancário
- base
- baseado
- Porque
- tornam-se
- torna-se
- antes
- atrás
- ser
- beneficiar
- MELHOR
- melhores práticas
- Melhor
- entre
- biomédica
- Bloquear
- Empréstimo
- limites
- Caixa
- violação
- Break
- trazer
- Traz
- Orçamentos
- construir
- Prédio
- construído
- construídas em
- negócio
- Aplicações de Negócio
- Processo de negócio
- negócios
- Esconderijo
- calculado
- chamada
- chamado
- visitante
- candidatos
- capacidades
- Capacidade
- Cuidado
- casas
- casos
- Categorias
- causas
- certo
- Non-GMO
- desafios
- alterar
- Alterações
- características
- carregada
- chatbot
- verificar
- lasca
- escolha
- escolhas
- Escolha
- escolha
- classe
- classificação
- classificar
- cliente
- clientes
- Fechar
- Na nuvem
- Agrupar
- código
- cunhado
- colegas
- coletar
- combater
- combinação
- combinar
- combinado
- comum
- Empresas
- Empresa
- comparado
- completar
- completamente
- integrações
- complexidade
- compliance
- componentes
- composta
- compromisso
- poder computacional
- Computar
- computador
- Visão de Computador
- computação
- conceito
- Interesse
- concorrente
- Configuração
- da conexão
- consistente
- consumida
- Consumidores
- Recipiente
- Containers
- contém
- continuar
- continua
- contínuo
- ao controle
- núcleo
- Correspondente
- Custo
- economia de custos
- relação custo-benefício
- custos
- poderia
- crio
- cria
- crítico
- crucial
- Atual
- personalizadas
- cliente
- Clientes
- DAG
- dados,
- informática
- ciência de dados
- cientista de dados
- banco de dados
- conjuntos de dados
- dia
- lidar
- decisões
- dedicado
- profundo
- deep learning
- Padrão
- definição
- entregar
- Demanda
- demandas
- Democratizando
- Dependendo
- depende
- implantar
- implantado
- Implantação
- desenvolvimento
- Implantações
- Design
- Padrões de design
- projetado
- detalhe
- detalhes
- Detecção
- Determinar
- Developer
- Desenvolvimento
- diagramas
- diferente
- difícil
- dimensões
- diretamente
- distinto
- distribuído
- computação distribuída
- diferente
- Estivador
- INSTITUCIONAIS
- Não faz
- domínios
- não
- down
- download
- desvantagem
- dirigido
- desistiu
- Caindo
- durante
- dinâmico
- cada
- Mais cedo
- mais fácil
- facilmente
- Eficaz
- efetivamente
- eficácia
- eficiências
- eficiente
- eficientemente
- esforço
- ou
- eliminando
- permitir
- permite
- criptografia
- end-to-end
- Ponto final
- Engenharia
- Engenheiros
- suficiente
- garantir
- garante
- Empreendimento
- empresas
- Todo
- Meio Ambiente
- erro
- erros
- especialmente
- avaliadas
- avaliações
- Mesmo
- Evento
- tudo
- evolução
- exemplo
- exemplos
- exchange
- exposições
- esperar
- esperado
- vasta experiência
- Experiências
- explorar
- expressões
- externo
- extra
- Rosto
- fatores
- Falha
- bastante
- famílias
- família
- mais rápido
- Característica
- Funcionalidades
- alimentação
- poucos
- final
- Primeiro nome
- primeira vez
- fitness
- ANIMARIS
- Flexibilidade
- fluxo
- flutuar
- concentra-se
- seguinte
- segue
- Ford
- formulário
- formas
- fracionário
- Quadro
- enquadramentos
- fraude
- detecção de fraude
- Gratuito
- Frequência
- freqüentemente
- amigos
- da
- Frutas
- cheio
- totalmente
- função
- funcionalidades
- funcionalidade
- funções
- mais distante
- RGPD
- Geral
- gerado
- gerando
- ter
- OFERTE
- dado
- meta
- Objetivos
- Bom estado, com sinais de uso
- GPU
- GPUs
- gráfico
- ótimo
- maior
- grandemente
- Grupo
- Do grupo
- Cresça:
- guia
- manipular
- Alças
- acessível
- Hardware
- ter
- Saúde
- saúde
- ajudar
- ajuda
- ajuda
- SUA PARTICIPAÇÃO FAZ A DIFERENÇA
- Alta
- alta performance
- de alta resolução
- superior
- Acertar
- Horizontal
- hospedeiro
- hospedado
- hospedagem
- custos de hospedagem
- serviços de hospedagem
- Como funciona o dobrador de carta de canal
- Contudo
- HTML
- HTTPS
- Centenas
- HÍBRIDO
- ideal
- Dados de identificação:
- inativo
- imagem
- Classificação de imagem
- imagens
- imutável
- Impacto
- impactada
- Impacto
- executar
- implementado
- implementação
- importante
- melhorar
- melhorar
- in
- incluir
- inclui
- Incluindo
- Entrada
- Crescimento
- aumentou
- Aumenta
- aumentando
- de treinadores em Entrevista Motivacional
- independentemente
- Individual
- INFORMAÇÕES
- Infraestrutura
- do estado inicial,
- inovadores
- tecnologias inovadoras
- entrada
- instalando
- instância
- em vez disso
- integrar
- integração
- Inteligência
- interativo
- envolver
- ISO
- isolamento
- IT
- Trabalho
- Empregos
- Chave
- chaves
- Saber
- conhecido
- grande
- Maior
- Latência
- lançamento
- lança
- de lançamento
- conduzir
- principal
- Leads
- APRENDER
- aprendizagem
- Deixar
- levou
- Nível
- bibliotecas
- facelift
- Limitado
- limites
- Lista
- viver
- carregar
- carregamento
- cargas
- localização
- longo
- mais
- olhar
- perder
- lote
- Baixo
- máquina
- aprendizado de máquina
- moldadas
- a Principal
- a manter
- mantém
- principal
- fazer
- FAZ
- Fazendo
- gerencia
- gerenciados
- de grupos
- Gerente
- gestão
- gestão
- muitos
- Marketing
- matemático
- Importância
- Maximizar
- máximo
- significa
- Conheça
- Memória
- método
- métodos
- métrico
- Métrica
- poder
- mínimo
- mínimo
- Minutos
- Misturando
- ML
- Moda
- modelo
- modelos
- Monitore
- monitoração
- Mês
- mês
- mais
- a maioria
- motivados
- Filmes
- Ponto de extremidade multimodelo
- múltiplo
- multidão
- Natureza
- necessário
- você merece...
- Cria
- rede
- Novo
- Próximo
- PNL
- notificação
- notificações
- número
- Nvidia
- objeto
- objetivo
- objetivos
- obtendo
- ocasional
- oferecer
- Oferece
- modo offline
- ONE
- online
- open source
- operar
- opera
- operando
- operacional
- Operações
- operadores
- ideal
- otimização
- Otimize
- otimizado
- Otimiza
- otimizando
- Opção
- Opções
- Laranja
- ordem
- organizações
- Outros
- marcante
- global
- próprio
- propriedade
- pacote
- acondicionamento
- parâmetros
- parte
- particular
- parceiro
- passou
- apaixonado
- Patches
- padrão
- padrões
- Pagar
- Pico
- Realizar
- atuação
- realização
- significativo
- periodicamente
- períodos
- Personalização
- Personalizado
- escolher
- oleoduto
- Lugar
- Locais
- planejado
- planos
- plataforma
- Plataformas
- platão
- Inteligência de Dados Platão
- PlatãoData
- Jogar
- mais
- políticas
- Privacidade
- Popular
- possível
- Publique
- POSTAGENS
- poder
- prática
- práticas
- Previsível
- prevendo
- predição
- Previsões
- preferido
- anteriormente
- preço
- Diretor
- prioridade
- privado
- Problema
- problemas
- processo
- Processado
- processos
- em processamento
- processadores
- Produto
- gerente de produto
- Produção
- Produtos
- Perfil
- adequado
- fornecer
- fornecido
- fornece
- fornecendo
- provisão
- procuração
- propósito
- Empurrar
- pytorch
- rapidamente
- alcance
- variando
- rapidamente
- Taxa
- Preços
- alcançar
- Chega
- Leia
- pronto
- reais
- mundo real
- em tempo real
- receber
- recebido
- recebe
- recomendar
- Recomendação
- recomendações
- Recomenda
- recomendando
- recomenda
- recorrente
- reduzir
- reduz
- refere-se
- Independentemente
- regular
- relacionado
- Releases
- relevante
- permanece
- repositório
- representado
- representa
- solicitar
- pedidos
- requerer
- requeridos
- requerimento
- Requisitos
- exige
- recurso
- Recursos
- resposta
- DESCANSO
- resultar
- resultando
- Resultados
- varejo
- Retorna
- rever
- Risco
- Tipo
- raiz
- Rota
- Regra
- Execute
- corrida
- SaaS
- sábio
- Inferência do SageMaker
- salário
- mesmo
- Salvar
- poupança
- Poupança
- escalável
- Escala
- Escalas
- dimensionamento
- cenários
- cronograma
- programado
- Ciência
- Cientista
- Segundo
- segundo
- Seção
- seções
- firmemente
- segurança
- selecionando
- doadores,
- senior
- sensível
- Seqüência
- serial
- Série
- servir
- Serverless
- Servidores
- serve
- serviço
- Serviços
- de servir
- conjunto
- contexto
- vários
- formação
- Partilhar
- compartilhado
- Turnos
- rede de apoio social
- Shows
- periodo
- de forma considerável
- semelhante
- Similarmente
- simples
- solteiro
- Tamanho
- tamanhos
- pequeno
- menor
- So
- Software
- solução
- Soluções
- alguns
- Fontes
- Espaço
- especialista
- especializado
- específico
- especificamente
- especificada
- velocidade
- Passar
- picos
- estável
- pilha
- Pilhas
- começo
- começado
- começa
- inicialização
- Startups
- estável
- Passo
- Passos
- Ainda
- Pára
- armazenamento
- loja
- estratégias
- de streaming
- Estrito
- discordaram
- subseqüente
- sucesso
- bem sucedido
- tal
- suficiente
- adequado
- ajuda
- Suportado
- suportes
- surge
- mesa
- Tire
- toma
- Target
- visadas
- Tarefa
- tarefas
- Profissionais
- equipes
- TechCrunch
- Dados Técnicos:
- Tecnologias
- inquilino
- fluxo tensor
- teste
- ensaio
- A
- deles
- si mesmos
- assim
- assim sendo
- milhares
- três
- limiar
- Através da
- todo
- Taxa de transferência
- tempo
- vezes
- para
- juntos
- também
- ferramenta
- Total
- tps
- Rastreamento
- tráfego
- Trem
- treinado
- Training
- transacional
- Transações
- Transformar
- Transformação
- transformando
- trânsito
- transparente
- desencadear
- Tritão
- VIRAR
- tipos
- típico
- tipicamente
- para
- subjacente
- compreender
- único
- unidades
- imprevisível
- não usado
- Atualizar
- Atualizações
- atualização
- atualizado
- uptime
- Uso
- usar
- caso de uso
- Utilizador
- usuários
- geralmente
- utilizar
- utilizado
- VALIDAR
- valor
- Valores
- Variante
- vário
- via
- Vídeo
- VÍDEOS
- Ver
- Virtual
- visão
- volume
- Voto
- votos
- Desperdício
- web
- serviços web
- semana
- O Quê
- O que é a
- qual
- enquanto
- Largo
- Ampla variedade
- precisarão
- dentro
- sem
- Atividades:
- trabalhou
- trabalhador
- trabalhadores
- trabalhar
- trabalho
- mundo
- seria
- XGBoostName
- ano
- Vocês
- investimentos
- zefirnet
- zero