Uma chamada que demorava dois segundos para a equipa do piloto demora vinte com a empresa toda a usar. GPUs paradas de noite e em fila ao meio-dia, e ninguém sabe dizer para onde vai o tempo.
Uma chamada que demorava dois segundos para a equipa do piloto demora vinte às nove da manhã com a empresa toda a usar.
As GPUs ficam paradas de noite e em fila ao meio-dia. As instâncias na cloud correm o mês inteiro para uma carga que tem pico duas horas por dia.
Modelo, recuperação, rede, base de dados. Sem medição cada equipa culpa a outra, e a correção é um palpite.
Instrumentamos o caminho do pedido à resposta, descobrimos para onde vão o tempo e o dinheiro, e construímos uma camada de serviço à medida da carga real: agrupamento, cache, escala automática e um custo que se lê.
Três partes: medir, servir, escalar.
Para onde vai cada milissegundo e cada euro.
O modelo como um serviço rápido e contido.
Capacidade que segue a carga, vigiada por alguém.
Quatro fases, a começar por números do seu sistema atual.
Medir o que corre hoje.
A camada de serviço para a sua carga.
Contentores, pipelines, testes.
Trocar, observar, entregar.
A mesma IA, mais rápida no pico, mais barata em repouso, e deixa de ser um mistério.
Um número no percentil 95, medido sob carga real, que a equipa pode pôr num acordo de serviço.
A capacidade desce quando ninguém pergunta. A fatura mensal acompanha o número de pedidos em vez do número de dias.
Quando uma chamada é lenta, o rasto mostra a etapa. Quando a fatura mexe, o relatório mostra a equipa.
| Lado a lado | Instalação do piloto | Infraestrutura otimizada |
|---|---|---|
| Latência no pico | Cresce com os utilizadores | Mantida no percentil acordado |
| Custo | Instâncias fixas, paradas a maior parte das horas | Segue os pedidos |
| Escala | Alguém adiciona uma máquina | Uma regra escrita, testada |
| Quando parte | Um utilizador avisa | Um alerta nomeia o componente |
| Uso do hardware | Um pedido de cada vez | Agrupado, em cache, quantizado |
Depende do modelo, da curva de carga e de onde os dados podem estar. Medimos primeiro a sua carga e testamos os servidores ou tipos de instância candidatos com os seus pedidos reais. A recomendação vem com os números que a produziram, e com o que a mudaria.
Não prometemos um número antes de medir. A fase de avaliação regista uma semana da sua carga real e mostra para onde vão o tempo e o custo; a fase de desenho estima a melhoria a partir dessa curva, e o teste de carga confirma-a antes da transição.
Sim, e é o caso habitual. A avaliação instrumenta o sistema atual sem o mudar. A maioria das melhorias, agrupamento, cache, quantização, uma regra de escala, é adicionada à instalação existente em vez de a substituir.
A regra de escala é escrita a partir da curva registada com margem acima do pico, e um teto de custo. Um pico acima do teto entra em fila em vez de falhar, e o alerta diz-lhe que aconteceu para o teto poder ser revisto.
Somos uma equipa pequena de especialistas seniores. Escolhemos o modelo certo e a camada certa, e construímos o mínimo de maquinaria que resolve o problema. Tem uma chamada com um engenheiro, não um deck de vendas.
