Floating Data Centers na prática: guia técnico para devs

Quando a IA generativa começou a escalar de verdade, eu senti um padrão claro: o gargalo deixou de ser “só” modelo e passou a ser infraestrutura. Segundo o Sapo.pt, a Samsung quer levar os centros de dados para o mar com os Floating Data Centers (FDC). A ideia parece futurista, mas ela nasce de três dores bem concretas: espaço, energia e arrefecimento. E, como dev que já viu custo explodir por causa de latência e capacidade, eu vejo aqui um caminho possível — com riscos reais — para mover data centers de onde “não dá” para onde “faz sentido”.

Floating Data Centers: por que tirar o data center da terra faz sentido com IA

O problema dos data centers tradicionais é previsível. A fonte menciona espaço, energia e arrefecimento. Eu adiciono um quarto item que quase ninguém fala: restrições de implantação. Permissões, obras civis, acesso a rede, tempo de construção e até logística de manutenção viram projetos longos demais quando a demanda de GPU cresce rápido.

Nos FDC, a proposta é deslocar parte dessas restrições para o contexto marítimo. Na prática, isso não elimina complexidade — só troca o tipo de complexidade. Em vez de “construir do zero em terra”, você precisa “integrar” um navio com infraestrutura de TI e operação contínua no ambiente marinho.

Espaço: quando a escalabilidade vira disputa por terreno

Ter terreno na cidade certa é caro e muitas vezes politicamente travado. Já no mar, o “terreno” é o leito/área de operação e a restrição vira outra: acesso a energia e capacidade de atracar/substituir módulos.

Para quem programa e opera sistemas com cargas elásticas, isso é relevante: capacidade disponível mais cedo pode reduzir a janela entre demanda e provisionamento. E isso impacta diretamente pipelines de IA (treino, fine-tuning, inferência e batch jobs).

Energia: amortizar custo e reduzir dependência de infraestrutura local

IA em produção é um “buraco” de energia. Além do consumo do hardware, você tem perdas elétricas, UPS, HVAC (climatização) e redes. A promessa dos FDC é colocar o data center onde dá para garantir energia de forma estável (por exemplo, via contratos e infraestrutura dedicada).

Na minha experiência com ambientes corporativos, o custo da energia não é só kWh. É também estabilidade (quedas, variações) e capacidade contratada (demanda máxima). Em navio, você tende a operar com uma estratégia mais desenhada para previsibilidade.

Arrefecimento: o mar como “troca térmica” (mas com engenharia pesada)

Arrefecimento é o maior vilão. A fonte diz que arrefecimento é um obstáculo em terra. No mar, a água salgada pode ajudar, mas também traz desafios: corrosão, biofouling (vida aderida), manutenção e controle de temperatura.

O “porquê” aqui é direto: você reduz a energia gasta em refrigeração e aumenta a eficiência do ciclo. Mas, para isso funcionar, o sistema precisa ser projetado para convivência real com o ambiente (não só com planilha).

Samsung Heavy Industries vs Hitachi: construir de raiz ou converter navios existentes

Segundo o Sapo.pt, existem duas abordagens concorrentes: a Samsung Heavy Industries aposta em construir navios especialmente preparados para abrigar infraestrutura de data center. Já a Hitachi (em parceria com a Mitsui O.S.K. Lines) tenta converter navios existentes em plataformas reutilizadas.

Construir de raiz (Samsung): mais controle, mais tempo e mais CAPEX

Quando você constrói desde o início, você decide:

• layout de salas técnicas e zonas de arrefecimento;
• tratamento anticorrosão e materiais;
• rotas de cabos e redundância;
• vibração e estabilidade para racks, UPS e refrigeração;
• segurança (incêndio, ventilação, contenção).

O custo disso é tempo e dinheiro de desenvolvimento. Em troca, você tende a ter melhor eficiência e menos “remendos” na operação.

Converter navios (Hitachi): menor tempo de entrada, mais compromissos

Converter pode acelerar o start, mas costuma trazer compromissos:

• limitações físicas no layout;
• infra elétrica e térmica que não casam perfeitamente com o modelo de cargas;
• mais trabalho de adaptação para redundância e manutenção;
• risco maior de atingir um teto de performance por restrições do casco/instalação.

Para devs e engenheiros de plataforma, isso vira um problema indireto: se o navio “aguenta menos” do que o planejado, você ajusta capacidade e escala de forma conservadora. E IA sofre com isso porque throughput e tempo de treino/importante para custos.

Posidonia 2026: por que acordos importam mais do que o marketing

Segundo o Sapo.pt, o projeto ganhou tração na Posidonia 2026, em Atenas, com acordo entre a Samsung Heavy Industries, a Capital Clean Energy Carriers Corp e a Lloyd’s Register.

O que eu gosto nesses acordos (e o que normalmente influencia mais do que a manchete) é: classe do navio, certificações e viabilidade operacional. Para data center, isso é crítico porque você precisa de padrões de segurança e inspeção. Lloyd’s Register, por exemplo, é uma peça importante nesse quebra-cabeça de conformidade.

Na Prática: como você “pensa como software” quando a infraestrutura muda

Se um FDC virar real na sua rota (ou na de seus clientes), não é só hardware. Você precisa ajustar arquitetura de software para refletir características do ambiente.

Aqui vai um passo a passo que eu usaria para orientar uma equipe de engenharia:

1. Defina metas de disponibilidade e latência.
   
   Em navio, você pode ter restrições operacionais (trocas, manutenção, mudanças de condições ambientais). Traduz isso em SLOs: uptime, RTO/RPO, latência máxima por região.
2. Modele capacidade como “elasticidade com teto físico”.
   
   Não assuma escala infinita. Crie limites por rack/cluster e implemente políticas de autoscaling que respeitem o hardware.
3. Implemente observabilidade com métricas térmicas e de energia.
   
   A diferença entre “funcionou” e “funcionou bem” vai estar em métricas: temperatura em zonas, carga elétrica, eficiência de refrigeração, taxa de erro de hardware.
4. Planeje atualizações e deploys com janelas de estabilidade.
   
   Se o ambiente exige paradas programadas (por manutenção), seu CI/CD precisa suportar rollouts com segurança.
5. Reduza acoplamento entre dados e compute.
   
   Em vez de assumir que o storage “sempre vai estar no mesmo lugar”, prepare replicação e estratégias de ingestão/consistência.

Uma parte prática de código ajuda a entender a ideia de “escala respeitando limites”. Exemplo: usar uma política simples para limitar autoscaling com base em uma métrica de energia/temperatura que você exporta via Prometheus.

from dataclasses import dataclass

@dataclass
class NodeTelemetry:
    temperature_c: float
    power_kw: float

def desired_replicas(current: int, telemetry: NodeTelemetry,
                      temp_max: float = 75.0, power_max: float = 250.0,
                      scale_step: int = 2, max_replicas: int = 64) -> int:
    """
    Regras simples:
    - se estiver frio e com energia folgada, sobe
    - se estiver perto do limite, mantém
    - se estiver acima do limite, reduz
    """
    if telemetry.temperature_c > temp_max or telemetry.power_kw > power_max:
        return max(1, current - scale_step)
    if telemetry.temperature_c < (temp_max - 10) and telemetry.power_kw < (power_max * 0.8):
        return min(max_replicas, current + scale_step)
    return current

O “porquê” dessa decisão: em ambientes onde arrefecimento e energia estão mais “sensíveis”, você quer evitar que o autoscaler reaja tarde demais. Em vez de deixar o sistema “quebrar e depois corrigir”, você toma decisões antes do limite.

Erros Comuns: o que devs costumam ignorar (e que pode virar custo ou indisponibilidade)

Eu já vi equipes caírem em padrões repetidos. Com FDC, alguns ficam ainda mais perigosos.

1) Tratar infraestrutura como “abstrata” demais

Em data center tradicional, dá para mascarar problemas por um tempo. Em navio, limites térmicos e elétricos podem aparecer de forma mais dinâmica. Se você abstrair demais, você perde oportunidade de ajuste proativo.

2) Autoscaling sem feedback de energia/arrefecimento

Autoscaling quase sempre olha CPU/RAM/latência. Isso é insuficiente quando o gargalo está no sistema de refrigeração ou na disponibilidade elétrica. Resultado: você sobe réplicas e piora a condição térmica.

3) Não planejar manutenção como “evento de plataforma”

Se um FDC precisa de manutenção programada, você precisa tratar isso no calendário e nas playbooks: drenar tráfego, migrar workloads, garantir que jobs grandes sejam pausados/retomados.

4) Confiar demais em um único domínio de falha

Em IA, você tem dependências: checkpointing, storage, conectividade e orquestração. Se qualquer componente for “single point”, a recuperação vira caro e lento. A correção não é só backup; é simular falhas e validar RTO/RPO.

5) Métricas sem contexto (apenas “CPU alto”)

CPU alto pode ser só sintoma. Para entender custo e performance, você precisa de correlação: CPU/GPU + energia + temperatura + taxa de erro de hardware.

Implicações práticas para IA e para quem programa no dia a dia

O impacto mais direto é financeiro e operacional.

• Menos fricção para adicionar capacidade: se o ciclo de implantação for mais rápido, pipelines de treino e inferência ganham tempo.
• Eficiência térmica pode virar vantagem competitiva: se o arrefecimento ficar mais eficiente, o custo por token/por iteração pode cair.
• Resiliência vira parte do produto: com ambiente “menos convencional”, a maturidade em observabilidade e recuperação define qualidade.

E do lado do software, eu esperaria mais adoção de: políticas de escala baseadas em múltiplas métricas, padrões de checkpoint confiáveis, e orquestração com migração/pausa consciente.

FAQ

Floating Data Centers podem substituir totalmente os data centers em terra?

Não tende a ser “substituição total”. Eu vejo como complemento. Plataformas marítimas podem atender cargas específicas (escalas temporárias, expansão rápida, áreas sem infraestrutura pronta), enquanto data centers em terra continuam essenciais para estabilidade de longo prazo e ecossistemas locais.

O mar ajuda no arrefecimento, mas não cria novos problemas?

Cria. A água salgada aumenta riscos de corrosão e biofouling. O projeto precisa prever materiais, manutenção e sistemas de troca térmica. Sem isso, você troca o gargalo de eficiência por um gargalo de confiabilidade.

Converter navios existentes é sempre pior do que construir de raiz?

Não necessariamente. Pode ser ótimo para reduzir tempo de entrada e validar demanda. Mas normalmente exige mais compromissos no design e pode limitar performance máxima e redundância — o que impacta custo e SLOs.

Como desenvolvedores devem preparar sistemas de IA para esses ambientes?

Priorize: checkpointing robusto, recuperação (RTO/RPO) testada, autoscaling com métricas além de CPU/RAM, e observabilidade que correlacione energia/temperatura com performance.

Que tipo de falha é mais provável em um data center flutuante?

Geralmente, falhas se conectam a estabilidade ambiental e manutenção: problemas térmicos, corrosão, degradação de componentes e logística de suporte. Por isso, a disciplina de operação e monitoramento contínuo fica ainda mais central.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.