Engenharia de serving com comprometimento de engenheiro, não de consultor.
A Talvane foi criada em Recife para ajudar equipes que já têm modelos validados a colocá-los em produção de forma estável e com custo previsível.
← Voltar ao inícioUma empresa de engenharia voltada a resultados mensuráveis
A Talvane nasceu da observação de um padrão recorrente: equipes com modelos bem treinados enfrentando contas de cloud que cresciam sem explicação clara, latências que variavam sem causa identificada, e arquiteturas de serving montadas para um tráfego que não era o real.
O trabalho da Talvane começa pela leitura do que existe — exportações de billing, traces de requisição, logs de infraestrutura — antes de qualquer sugestão de mudança. Cada recomendação vem acompanhada de um número: o efeito esperado, com o intervalo em que esse efeito costuma se manifestar.
Operamos com escopo e preço fixos porque escopo aberto não é compatível com planejamento. O cliente sabe, antes de começar, o que vai receber e quanto vai pagar.
Medição antes de recomendação
Nenhuma mudança de arquitetura é proposta sem leitura prévia dos dados de produção. Opiniões sem números ficam de fora dos relatórios.
Entregáveis que ficam com o cliente
Código, runbooks e configurações de tracing são transferidos ao cliente ao final de cada engajamento. O trabalho não cria dependência.
Escopo honesto
O que está e o que não está dentro do escopo é definido antes do início. Expansões de escopo não acontecem por omissão.
Equipe
Rafael Mendonça
Engenheiro de Infraestrutura de Serving
Foco em batching, autoscaling e análise de custo de token para modelos hospedados e auto-hospedados. Trabalhou anteriormente com pipelines de dados em escala para fintechs do Nordeste.
Carla Siqueira
Engenheira de Observabilidade
Especialista em instrumentação de traces distribuídos e separação de latência de modelo versus latência de rede. Experiência com ambientes multi-região e arquiteturas de fila assíncrona.
Thiago Oliveira
Engenheiro de Custo e Capacidade
Leitura e interpretação de exportações de billing de AWS, GCP e Azure. Foco na relação entre padrão de tráfego e escolha de hardware para serving de modelos densos e esparsos.
Padrões de trabalho
Confidencialidade de dados
Um NDA é assinado antes do início de qualquer engajamento. Dados de billing e logs são usados apenas para o trabalho contratado e não são retidos após a conclusão.
Testes no tráfego real
Cargas de teste são construídas a partir do tráfego observado em produção. Resultados de benchmarks sintéticos são apresentados apenas como referência, não como previsão.
Código revisado e documentado
Todo código de infraestrutura entregue passa por revisão interna antes da entrega. A documentação é parte do entregável, não um apêndice opcional.
Plano de falha documentado
Cada arquitetura proposta inclui o que acontece quando os componentes falham — não como apêndice, mas como parte central do design. Rollback ensaiado antes da implantação.
Relatórios com premissas explícitas
Todo relatório de custo e latência lista as premissas usadas nos cálculos. O cliente pode verificar e contestar cada número apresentado.
Escopo contratual fixo
O escopo é definido por escrito antes do início. Solicitações fora do escopo são discutidas separadamente — não adicionadas silenciosamente ao trabalho em andamento.
Infraestrutura de inferência em produção: o que costuma dar errado e por quê importa medir
A maioria das equipes que coloca um modelo em produção faz isso com uma configuração que funciona razoavelmente bem no primeiro mês. O problema aparece quando o tráfego cresce ou muda de padrão: a latência sobe, o custo escala de forma não linear, e ninguém consegue dizer rapidamente qual componente é responsável.
Tracing distribuído resolve uma parte do problema — mas só se o trace cobrir o caminho completo da requisição, incluindo tempo de fila, serialização e desserialização. A maioria das implementações mede apenas o tempo de execução do modelo, que costuma ser a menor parte do problema em serviços com carga variável.
No lado do custo, a concentração de gasto raramente está onde a equipe imagina. Modelos grandes em endpoints dedicados são o suspeito óbvio, mas frequentemente o gasto concentra em chamadas de embedding, reranking ou pré-processamento que rodam com frequência maior do que o modelo principal.
A Talvane trabalha com equipes de engenharia em Recife e em outras partes do Brasil que precisam de um número confiável antes de tomar decisões de arquitetura ou de planejamento de capacidade. O trabalho começa pela leitura dos dados existentes — e vai até onde o cliente precisa chegar.
Pronto para mapear onde o gasto concentra?
A revisão de custo é a entrada mais direta. Uma sessão de leitura de billing entrega um breakdown por workload e uma lista ranqueada de onde vale a pena intervir.
Solicitar avaliação — R$ 780