Transcodificação de voz em escala: quantos servidores seu SBC realmente precisa

Transcodificar milhares de chamadas G.729, AMR e EVS consome CPU pesado. Mostramos por que não é problema de GPU, a fórmula para dimensionar por núcleos e MHz, e quanto hardware custa de verdade.

Toda operação de interconexão esbarra no mesmo ponto: transcodificação consome CPU. Quando o tráfego mistura G.729, AMR-NB, AMR-WB e, cada vez mais, EVS, milhares de chamadas simultâneas podem saturar um servidor rápido. A pergunta que importa não é "qual hardware mágico resolve", e sim "quantos núcleos, de qual arquitetura, para a minha carga real".

Este post responde isso com uma fórmula que você aplica no guardanapo, e desfaz um mito caro pelo caminho.

Por que transcodificar dói

Transcodificar uma chamada é decodificar de um codec para PCM, reamostrar quando as taxas diferem, e recodificar no codec de destino. O custo não é igual entre codecs:

• G.711 é praticamente de graça (só uma tabela de companding).
• G.729 e AMR-NB são moderados.
• AMR-WB é pesado (banda larga a 16 kHz, encoder complexo).
• EVS é o mais caro de todos, de 6 a 10 vezes o custo do G.729.

A parte cara é sempre o encoder. Codecs CELP (a família do G.729, AMR e EVS) fazem uma busca de codebook por quadro, cheia de decisões dependentes dos dados. É computação sequencial, frame a frame, com pouca matemática por byte.

O mito da GPU

É tentador olhar para uma GPU moderna (uma NVIDIA GB10, por exemplo) e imaginar milhares de chamadas em paralelo. Não funciona, e vale entender por quê:

• Esses codecs são de ponto fixo. Não tocam nas unidades tensoriais FP4/FP8 que dão vantagem à GPU. Seria comprar um motor de Fórmula 1 para arar um campo.
• O encoder tem desvios dependentes de dados. Em hardware SIMT isso vira divergência de warp: as threads se serializam e a paralelização evapora.
• A vazão de GPU vem de batching profundo, que adiciona latência. O RTP em tempo real não tem esse orçamento (o ptime é de 20 ms).
• Nenhum codec CELP de telecom tem implementação CUDA pronta. Você escreveria o codec do zero, com risco de conformidade bit a bit.

Transcodificação em escala de SBC é carga de CPU (ou de DSP dedicado). GPU é excelente para áudio neural, como transcrição, supressão de ruído e codecs neurais. Não para transcodificar G.729.

A métrica certa: WMOPS e uma fórmula

Cada codec tem uma complexidade padronizada pela ITU-T e pelo 3GPP, medida em WMOPS (Weighted Million Operations Per Second). A partir dela, calibrando com um ponto real conhecido, dá para prever a capacidade segura de um nó com uma fórmula simples:

N = κ × n × (f ÷ 1000) × η

Onde:

• N: chamadas bidirecionais simultâneas com folga (uso de CPU em torno de 65%).
• κ: coeficiente do par de codec (tabela abaixo).
• n: número de núcleos físicos.
• f: frequência por núcleo em MHz (clock sustentado com todos os núcleos ativos).
• η: eficiência da arquitetura (x86 de referência = 1,00; ARM Ampere entre 0,80 e 0,85).

Como interconexão quase sempre tem G.711 de um lado, os pares úteis são todos contra G.711:

Repare na queda: um núcleo que aguenta cerca de 200 chamadas de G.729 aguenta só cerca de 50 de AMR-WB e cerca de 25 de EVS. Seu codec mais pesado é quem manda no dimensionamento.

Um exemplo concreto: 4.000 chamadas

Suponha 4.000 chamadas simultâneas de G.729 contra G.711, num EPYC de 3,3 GHz:

núcleos = 4.000 ÷ (66,7 × 3,3 × 1,0) ≈ 18 núcleos

Some folga para picos e sistema operacional e chegue a cerca de 24 núcleos. Cabe com sobra em um único socket. Para carrier você provisiona N+1, então são dois servidores, cada um capaz de sustentar os 4.000 sozinho. Se o mix pender para AMR-WB, a conta muda: 4.000 ÷ (17,1 × 3,3) ≈ 71 núcleos. É por isso que conhecer o mix real vale mais que qualquer chute.

x86 ou ARM: onde está a eficiência

Para essa carga, os dois entregam. A diferença aparece em chamadas por watt:

• x86 (AMD EPYC / Intel Xeon): caminho de menor atrito, é a plataforma para a qual o rtpengine foi construído e otimizado. A Dell PowerEdge cobre bem esse cenário.
• ARM (Ampere Altra Max / AmpereOne, em Supermicro): de 2 a 4 vezes mais chamadas por watt. Se a dor é consumo, densidade de rack e conta de energia, o ARM ganha. A NVIDIA Grace é a versão de servidor dos mesmos núcleos ARM.

Um detalhe importante: os números de ARM assumem bibliotecas otimizadas para NEON. As versões de fábrica do bcg729 e do opencore-amr são majoritariamente escalares, então sem ajuste a densidade pode ficar de 10% a 20% abaixo. Vale um benchmark antes de fechar a compra.

O custo que ninguém coloca na planilha

Hardware é a parte fácil. Em SBCs comerciais, o custo dominante costuma ser a licença de transcodificação por canal, cobrada por sessão simultânea e recorrente todo ano. Em 4.000 canais, isso ofusca o preço de um par de servidores.

O rtpengine é open source: zero licença por canal, para sempre. Some a isso que as patentes centrais do G.729 já expiraram (AMR e EVS ainda são licenciados, então acerte os royalties), e o quadro fica claro: para milhares de chamadas de interconexão, a resposta é um par de servidores x86 ou ARM bem dimensionados, não hardware exótico.

Como fechar o número com segurança

Estimativas te colocam na faixa certa. Um benchmark te dá a garantia. Carregue uma direção de transcodificação até cerca de 65% de CPU na sua build real, meça as chamadas simultâneas e reescale a fórmula. Um dia de teste transforma um intervalo de mais ou menos 40% em algo em torno de mais ou menos 20%.

Foi exatamente esse método que consolidamos em um datasheet de capacidade, com tabelas prontas por hardware para cada par de codec. Se você dimensiona interconexão, ele economiza uma rodada inteira de tentativa e erro.

---

Quer o datasheet completo, com a fórmula, os coeficientes por codec e as tabelas por servidor? Fale com a equipe da SipPulse.