It depends on what you want to optimize — but for the case we care about, MoE + TibiOS, the answer is: to scale MoE inference, aggregate throughput usually matters more than network latency, as long as the network has enough bandwidth. There are two different things to separate.

Depende de qué quieras optimizar — pero para el caso que nos ocupa, MoE + TibiOS, la respuesta es: para escalar inferencia MoE, el throughput agregado suele importar más que la latencia de red, siempre que la red tenga suficiente ancho de banda. Hay que separar dos cosas.

1. Network latency affects a single request. Each token may need to travel Router → Network → Expert → Network → Next layer. Every added network hop increases end-to-end latency. This matters most for interactive chat, agents and tool calling, small-batch requests, and anything sensitive to TTFT/TPOT.

1. La latencia de red afecta a una request individual. Cada token puede necesitar recorrer Router → Red → Expert → Red → Siguiente capa. Cada salto de red añadido incrementa la latencia end-to-end. Esto importa sobre todo para chat interactivo, agentes y tool calling, requests con batch pequeño, y todo lo sensible a TTFT/TPOT.

2. Aggregate throughput affects how many requests or tokens you can process. With many GPUs, each hosting a different subset of experts, a huge number of expert operations can run in parallel — and that is exactly where TibiOS's advantage shows up.

2. El throughput agregado afecta a cuántas requests o tokens puedes procesar. Con muchas GPUs, cada una alojando un subconjunto distinto de experts, se pueden ejecutar muchísimas operaciones de experts en paralelo simultáneamente — y ahí es precisamente donde aparece la ventaja de TibiOS.

A simple example: a single 128 GB GPU can serve one request in ~100 ms — about 10 requests/second. With TibiOS on 16 × 8 GB GPUs, if the network adds 10 ms of overhead, a single request takes ~110 ms — individually slower. But with all 16 GPUs working in parallel, aggregate capacity could hypothetically reach ~80–120 requests/second, depending on the model, routing, batch size, and network. That capacity depends on a critical condition: the network. 16 GPUs over 1 GbE and the network becomes the bottleneck; 10/25 GbE already changes things significantly; 40/100 GbE or InfiniBand/RDMA makes the cost of all-to-all communication far less dominant.

Un ejemplo sencillo: una única GPU de 128 GB puede atender una request en ~100 ms — unas 10 requests/segundo. Con TibiOS en 16 × GPU de 8 GB, si la red añade 10 ms de overhead, una request individual tarda ~110 ms — más lenta a nivel individual. Pero con las 16 GPUs trabajando en paralelo, la capacidad agregada podría alcanzar hipotéticamente 80–120 requests/segundo, dependiendo del modelo, el routing, el batch y la red. Esa capacidad depende de una condición crítica: la red. Con 16 GPUs sobre 1 GbE, la red se convierte en el cuello de botella; con 10/25 GbE la cosa ya cambia mucho; y con 40/100 GbE o InfiniBand/RDMA el coste del all-to-all deja de ser tan dominante.

For TibiOS, individual latency depends on network + compute; aggregate throughput depends on GPU count + bandwidth + routing + network — and that second one is where the real opportunity lies. A distributed architecture of 8 GB GPUs will probably never beat a single 128 GB GPU on individual latency. What it can do is deliver far more aggregate compute per dollar, and let the system grow from 8 → 16 → 32 → 64 → 128 GPUs without ever changing the model architecture. That is the story: not "latency vs. throughput," but individual latency vs. the capacity and throughput of the whole cluster.

Para TibiOS, la latencia individual depende de red + cómputo; el throughput agregado depende de número de GPUs + ancho de banda + routing + red — y es en este segundo punto donde está la verdadera oportunidad. Una arquitectura distribuida de GPUs de 8 GB probablemente nunca va a ganarle a una única GPU de 128 GB en latencia individual. Lo que sí puede hacer es conseguir mucho más cómputo agregado por dólar, y permitir que el sistema crezca de 8 → 16 → 32 → 64 → 128 GPUs sin cambiar nunca la arquitectura del modelo. Esa es la historia: no "latencia vs. throughput", sino latencia individual frente a la capacidad y el throughput de todo el clúster.

A common objection to local AI: on a single machine, sensitive chat data never leaves it — but TibiOS distributes the model across many GPUs, so where does that data end up? The key distinction is that distributing the model does not mean distributing or persisting the user's data. Tokens travel between TibiOS nodes only in RAM/VRAM during inference and are released immediately after use; by default there is zero persistence — no logs, no database, no cloud backup.

Una objeción habitual a la IA local: en una sola máquina, los datos sensibles del chat nunca salen de ella — pero TibiOS distribuye el modelo entre muchas GPUs, ¿dónde termina entonces esa información? La distinción clave es que distribuir el modelo no implica distribuir ni persistir los datos del usuario. Los tokens viajan entre nodos de TibiOS solo en RAM/VRAM durante la inferencia y se liberan inmediatamente después de usarse; por defecto hay persistencia cero — sin logs, sin base de datos, sin backup en la nube.

This works because TibiOS separates Control Plane (routing, orchestration) from Data Plane (the actual tokens/weights), and offers two distinct deployment models: TibiOS Private Cluster, where every GPU node sits inside infrastructure the user owns and controls, and TibiOS Distributed Community, an optional shared-compute network across independent, third-party nodes. Sensitive data should stay on a Private Cluster; the Community network is for workloads that don't require that guarantee.

Esto funciona porque TibiOS separa el Control Plane (routing, orquestación) del Data Plane (los tokens/pesos reales), y ofrece dos modelos de despliegue distintos: TibiOS Private Cluster, donde cada nodo GPU está dentro de infraestructura que el usuario posee y controla, y TibiOS Distributed Community, una red opcional de cómputo compartido entre nodos independientes de terceros. Los datos sensibles deben quedarse en un Private Cluster; la red Community es para cargas que no requieren esa garantía.

The design principle: "Compute can be distributed. Data sovereignty does not have to be." A stricter mode is also on the roadmap — tibios --privacy=strict — enforcing no cloud inference, no conversation persistence, no prompt logging, no telemetry with user data, and encrypted node-to-node traffic. That is a stronger claim than plain "local AI": TibiOS can distribute the model across many GPUs without distributing ownership of the user's data.

El principio de diseño: "El cómputo puede distribuirse. La soberanía del dato no tiene por qué." También está en el roadmap un modo más estricto — tibios --privacy=strict — que fuerza sin inferencia en la nube, sin persistencia de conversaciones, sin logging de prompts, sin telemetría con datos de usuario, y tráfico cifrado entre nodos. Es una afirmación más fuerte que la simple "IA local": TibiOS puede distribuir el modelo entre muchas GPUs sin distribuir la propiedad de los datos del usuario.

Not every GPU offers the same hardware trust guarantees, and this matters for where TibiOS can run untrusted nodes. NVIDIA Jetson AGX Orin ships real hardware security — a Hardware Root of Trust, Secure Boot, an OP-TEE Trusted Execution Environment (ARM TrustZone), secure storage, AES-XTS 128-bit DRAM encryption, and crypto acceleration. That is a solid foundation for trusted edge/private nodes, but it is not the same model as NVIDIA's Confidential Computing.

No todas las GPUs ofrecen las mismas garantías de confianza de hardware, y esto importa a la hora de decidir dónde puede correr TibiOS en nodos no confiables. NVIDIA Jetson AGX Orin incorpora seguridad de hardware real — un Hardware Root of Trust, Secure Boot, un Trusted Execution Environment OP-TEE (ARM TrustZone), almacenamiento seguro, cifrado de DRAM AES-XTS de 128 bits, y aceleración criptográfica. Es una base sólida para nodos edge/privados de confianza, pero no es el mismo modelo que el Confidential Computing de NVIDIA.

NVIDIA's H100/H200/B200 GPUs add a specific Confidential Computing solution: they can run alongside a Confidential VM, protect the workload from the infrastructure operator itself, support attestation, and protect data crossing PCIe — including documented Confidential Containers support across H100, H200, B200 and select multi-GPU configurations. That is the difference that matters for TibiOS: Orin proves the node is secure-booted and its memory is encrypted, but H100/H200/B200-class Confidential Computing can prove a workload is protected even from the operator of hardware TibiOS does not own.

Las GPUs H100/H200/B200 de NVIDIA añaden una solución específica de Confidential Computing: pueden funcionar junto a una Confidential VM, proteger la carga frente al propio operador de la infraestructura, soportar attestation, y proteger los datos que cruzan PCIe — incluyendo soporte documentado de Confidential Containers en H100, H200, B200 y ciertas configuraciones multi-GPU. Esa es la diferencia que importa para TibiOS: Orin demuestra que el nodo arrancó de forma segura y que su memoria está cifrada, pero el Confidential Computing de clase H100/H200/B200 puede demostrar que una carga está protegida incluso frente al operador de un hardware que TibiOS no posee.

This maps cleanly onto TibiOS's two deployment models: Orin for private/edge nodes — the machines are ours, so full Confidential Computing isn't required — and H100/H200/B200 for confidential nodes on infrastructure TibiOS does not fully control, where the operator provides GPU, power and connectivity, and Confidential Computing is what prevents them from accessing the workload's contents. The honest framing: Orin provides hardware-backed security and encrypted memory for trusted edge deployments; Hopper/Blackwell GPUs add full NVIDIA Confidential Computing for higher-assurance, multi-tenant, untrusted-node deployments.

Esto encaja perfectamente con los dos modelos de despliegue de TibiOS: Orin para nodos privados/edge — las máquinas son nuestras, así que no hace falta Confidential Computing completo — y H100/H200/B200 para nodos confidenciales sobre infraestructura que TibiOS no controla del todo, donde el operador aporta GPU, energía y conectividad, y el Confidential Computing es lo que le impide acceder al contenido de la carga. El planteamiento honesto: Orin aporta seguridad respaldada por hardware y memoria cifrada para despliegues edge de confianza; las GPUs Hopper/Blackwell añaden Confidential Computing completo de NVIDIA para despliegues multi-tenant de mayor garantía sobre nodos no confiables.