Como hospedar o Kimi K3 por conta própria

O que é necessário para hospedar o Kimi K3 por conta própria

Hospedar o Kimi K3 por conta própria significa encontrar espaço para 2.8 trilhões de parâmetros. A Moonshot publicou os pesos abertos em MXFP4, que usa cerca de meio byte por peso, portanto apenas os pesos somam aproximadamente 1.4 TB antes de alocar um único token de cache. Nenhum acelerador à venda atualmente comporta isso sozinho. Para uma GPU, a resposta é não. Para um servidor, a resposta é sim em dois formatos. O primeiro é um nó com 8 GPUs de 288 GB por acelerador, que é o formato usado pelas menores receitas publicadas para servir vários usuários. O segundo é uma máquina com cerca de 1.6 TB de RAM e VRAM combinadas, executando o GGUF Q8 sem perdas da Unsloth no llama.cpp, com ou sem GPU, servindo um usuário por vez.

Esse é o veredito. Tudo abaixo é a aritmética por trás dele, porque essa é a parte que você reutiliza na próxima versão. Vários fornecedores de infraestrutura publicaram guias de implantação do K3 nas semanas após o anúncio de 16 July 2026, e todos presumiam que você já possuía um cluster. Esta página começa do outro lado: quanto custa, o que você pode executar como alternativa e como identificar em qual dessas duas situações você está.

O número total de parâmetros e o número de parâmetros ativos não são iguais

O K3 é um modelo de mistura de especialistas. MoE (mixture of experts) divide a rede em várias sub-redes e permite que um router escolha algumas delas para cada token. O model card indica 2.8T de parâmetros totais e 104B de parâmetros ativados por token, entre 896 especialistas encaminhados, dos quais 16 são ativados para cada token, em 93 camadas.

Essas duas contagens de parâmetros respondem a perguntas diferentes. Trocá-las é o erro mais comum em qualquer discussão sobre se é possível executar o modelo.

Os parâmetros ativos definem o custo computacional. Cada token é processado por cerca de 104B de parâmetros. Por isso, o throughput esperado é semelhante ao de um modelo denso de 104B, e não ao de um modelo de 2.8T. Essa é precisamente a razão para usar um MoE.

O número total de parâmetros define o custo de memória. O router pode selecionar qualquer especialista para qualquer token. Por isso, todos os especialistas precisam de ser armazenados num local rápido antes de chegar o primeiro pedido. É possível manter apenas os especialistas mais utilizados na VRAM e carregar os restantes quando necessário: o llama.cpp's --moe-cache-mib mantém uma cache de especialistas na GPU. Os especialistas restantes ficam na RAM do sistema e os que faltam são carregados quando o router os seleciona. Isto não reduz o tamanho total. Os restantes especialistas continuam a ter de ficar na RAM, e uma ligação PCIe transfere dezenas de gigabytes por segundo, enquanto a HBM transfere terabytes por segundo. Por isso, cada falha de cache acrescenta tempo. Se o modelo também não couber na RAM e for necessário carregar especialistas a partir de NVMe, o processo será ainda mais lento. O guia do K3 da Unsloth avisa que o offloading para disco é muito mais lento.

Portanto, o custo computacional é baixo, mas o custo de armazenamento é elevado. Dimensione o hardware com base em 2.8T. Dimensione as expectativas de velocidade com base em 104B.

Bytes por peso e de onde vêm os terabytes

Contagem de parâmetros multiplicada pelos bytes por peso. Para os pesos, essa é toda a fórmula.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

O K3 foi treinado com consciência de quantização e lançado com pesos MXFP4 e ativações MXFP8, portanto a linha de 4 bits é a relevante. As linhas acima servem de escala: em bf16, o mesmo modelo precisaria de 5.6 TB. O MXFP4 também armazena uma escala de 8 bits compartilhada para cada bloco de 32 pesos, o que adiciona cerca de 6 por cento, e a configuração da Moonshot exclui a atenção, os especialistas compartilhados e a torre de visão do formato de 4 bits. Por isso, o checkpoint completo chega a cerca de 1.56 TB segundo a contagem da Unsloth, em vez de 1.4 TB exatos.

Isso reduz a margem de redução habitual, mas não a elimina. O checkpoint lançado já é de 4 bits, portanto a economia mais fácil já foi obtida, mas reduzir ainda mais a precisão continua diminuindo o tamanho. Em 27 de outubro de 2026, as quantizações dinâmicas GGUF do K3 medidas pela Unsloth variam de 861.3 GB para UD-Q2_K_XL de 2 bits a 594 GB para UD-IQ1_S de 1 bit. A Unsloth publica o custo dessa redução: a concordância de tokens top-1 com o modelo completo é de 90.390 por cento em UD-Q2_K_XL, 84.127 por cento em UD-IQ2_XXS de 711.1 GB e 78.875 por cento em UD-IQ1_S. O repositório da Unsloth no Hugging Face também inclui arquivos menores de 1 bit, até 466 GB para UD-Q1_0, mas não publica uma métrica de concordância associada a eles. Essa é uma perda de precisão medida, e até o menor arquivo ainda tem cerca de 1.6 vezes o tamanho da maior placa individual.

Quantas GPUs o Kimi K3 precisa

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Considere esses números como um mínimo, não como uma meta. Eles contabilizam apenas os pesos: não incluem o cache KV, os buffers de ativação, a fragmentação do alocador nem espaço para uma segunda solicitação simultânea. A divisão não precisa ser uniforme: o paralelismo de pipeline do vLLM divide o modelo por camadas e aceita divisões desiguais, e as receitas de prefill do K3 no SGLang executam 8 e 16 estágios de pipeline em 93 camadas.

As orientações publicadas ficam acima desse mínimo. A orientação de lançamento da Moonshot recomendava um supernó com 64 ou mais aceleradores. Em 27 October 2026, o cookbook do SGLang inclui uma configuração com H100 formada por quatro nós de 8 GPUs, totalizando 32 GPUs e 2,560 GB de memória agregada, em comparação com um mínimo de 18 placas. Ele também lista receitas para um único nó com um nó B300 de 8 GPUs e um nó MI350X ou MI355X de 8 GPUs, com 2,304 GB a 288 GB por placa. Essa diferença em relação ao mínimo não é desperdício. Ela cobre o cache KV, a memória de ativação e a margem necessária para o servidor processar muitas solicitações em lote ao mesmo tempo. A opção mais acessível, com 5 placas da classe GB300, na prática é arredondada para exatamente esse tipo de nó de 8 GPUs, que é a menor máquina para a qual alguém publica uma receita de serving multiusuário do K3.

A cache KV é a parte que surpreende

Os pesos têm um custo fixo. A cache KV (key value) não: cresce com o comprimento do contexto e novamente com cada utilizador concorrente. Para a atenção comum, a fórmula é bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, e depois multiplica-se pelo comprimento do contexto e pela concorrência.

Eis um exemplo calculado, que é apenas um exemplo: 64 camadas, 8 cabeças KV, dimensão de cabeça 128, fp8. Isso dá 2 64 8 128 1 = 131,072 bytes, ou seja, 128 KiB por token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Um utilizador com contexto de 128k consome 16 GiB. Um utilizador com o milhão completo consome 128 GiB. Isso corresponde a quase metade de uma placa de 288 GB para uma única conversa, antes de carregar um único peso.

O K3 não usa atenção comum, e esse último número explica porquê. As suas 93 camadas são compostas por 69 camadas KDA (Kimi Delta Attention) e 24 camadas Gated MLA (multi-head latent attention). A KDA mantém um estado recorrente de tamanho fixo, em vez de uma cache que cresce a cada token. A MLA comprime a key e o value num único vetor latente de baixa ordem, pelo que o custo real por token fica muito abaixo do exemplo calculado. O config.json publicado pela Moonshot indica que o tamanho desse latente é kv_lora_rank de 512 mais uma key rotativa com largura 64 (qk_rope_head_dim), ou seja, 576 valores por token e por camada MLA. Em 24 camadas, com 2 bytes por valor, isso corresponde a 27,648 bytes, cerca de 27 KiB por token, ou aproximadamente 27 GiB para uma conversa completa com 1,048,576 tokens, além do estado KDA fixo. Considere isto uma estimativa, não uma medição: os engines preenchem e organizam a cache à sua maneira, e uma cache de 8 bits reduz aproximadamente este valor para metade.

Para saber o que a sua própria implementação mantém, não monitorize nvidia-smi enquanto aumenta --max-model-len. O vLLM pré-aloca o pool da cache KV, dimensionado a partir de --gpu-memory-utilization (0.92 por predefinição na documentação atual) ou de um orçamento explícito de cache por GPU. Por isso, a memória total da GPU mostra o pool, não uma única conversa. Consulte antes o log de arranque, onde o vLLM apresenta o tamanho da cache KV em tokens e a concorrência máxima para o seu comprimento de contexto.

A estrutura deste raciocínio continua válida na próxima release. Se um modelo anuncia um contexto de um milhão de tokens e não explica o seu desenho de atenção, assuma que a cache é a limitação principal até que alguém demonstre o contrário.

Camada 1: alugue o cluster à hora

Esta é a camada que disponibiliza o K3, com a precisão de lançamento, para muitos utilizadores em simultâneo. Uma máquina com RAM suficiente também pode executar o K3 com a precisão de lançamento através do Q8 GGUF da Unsloth, que a Unsloth classifica como precisão total sem perdas, mas essa opção atende um utilizador de cada vez e é abordada na camada 2. Aqui, não compra o hardware. Aluga-o durante as horas de que precisa e encerra-o depois.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

A tarifa é uma suposição, não uma cotação. As tarifas sob demanda variam muito conforme o provedor e a geração da GPU. As peças de 288 GB necessárias para as receitas de nó único custam mais por hora do que uma H100, e a capacidade reservada é mais barata. Use o valor real do seu provedor e refaça a multiplicação: GPUs vezes horas vezes tarifa. O objetivo do gráfico é mostrar a proporção. Ativar um nó com 8 GPUs durante quatro horas por dia custa 2,400 USD por mês, enquanto manter em execução a configuração SGLang dimensionada para 32 GPUs H100 custa 57,600 USD.

Os dois servidores principais publicam um comando de inicialização no model card.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Nenhum dos dois comandos isolados é o que deve ser executado num cluster real. Adicione as flags de paralelismo correspondentes ao seu hardware: o SGLang usa --tp-size para paralelismo de tensor, --pp-size para paralelismo de pipeline e --ep-size para paralelismo de especialistas. O paralelismo de tensor vezes o paralelismo de pipeline tem de ser igual ao número de GPUs disponíveis, e o paralelismo de especialistas divide os especialistas dentro desse grupo. É por isso que a receita para 32 GPUs H100 define --tp-size 32 e --ep-size 32.

Confirme que o servidor iniciou antes de enviar tráfego real:

curl http://127.0.0.1:30000/v1/models

Um servidor saudável responde com um objeto JSON que lista o model id. Connection refused significa que o processo ainda está carregando os pesos ou já foi encerrado. Leia o log do servidor antes de tentar novamente.

Nas primeiras semanas, a falha mais comum era usar um runtime mais antigo que o modelo. O K3 foi lançado com KDA e uma nova camada MoE que as versões estáveis do vLLM e do SGLang ainda não incluíam no lançamento. O sintoma é o servidor ser encerrado durante a inicialização, com uma linha no formato Model architectures [...] are not supported for now. Nenhuma alteração de configuração corrige isso, porque o código para executar essas camadas não está presente na sua compilação. Desde então, isso mudou: em 27 October 2026, o SGLang já incluía suporte ao K3 nas suas releases desde a v0.5.17, sendo a v0.5.22 a mais recente, e as notas de release do vLLM da v0.28.0 à v0.32.0 incluem trabalho relacionado ao K3. Instale uma release atual. Alguns caminhos específicos de hardware ainda indicam uma imagem dedicada, como as compilações NVFP4 do SGLang para Blackwell. Consulte a receita correspondente à sua placa.

Há um detalhe de custo que costuma passar despercebido. A medição começa quando a instância inicia, não quando o modelo fica pronto. Um download de 1.56 TB a 1 GB/s consome cerca de 26 minutos do tempo do cluster antes do primeiro token. Armazene os pesos num volume que permaneça disponível depois do encerramento da instância, para que a segunda execução comece em minutos.

Tier 2: executar um modelo menor num único acelerador

Neste tier, você não está executando o K3. Diga isso explicitamente antes de começar, porque a maioria das discussões sobre "executar o K3 localmente" termina aqui sem admitir isso.

A regra de compatibilidade usa a mesma fórmula em escala menor: parâmetros vezes bytes por peso, mais o cache KV, mais cerca de 2 GB de sobrecarga de runtime, precisa ficar abaixo da sua VRAM. Em 4 bits, isso representa aproximadamente meio byte por parâmetro, o que permite combinações confortáveis:

• placa de 16 GB: modelo 7B em 4 bits, com espaço para um contexto longo
• placa de 24 GB: modelo 14B em 4 bits
• placa de 48 GB: modelo 32B em 4 bits
• placa de 80 GB: modelo 70B em 4 bits ou um MoE da classe 30B em 8 bits

Cada combinação acima pressupõe uma solicitação por vez. Assim que uma segunda pessoa envia um prompt, cada slot concorrente precisa do próprio cache KV. Esse é o equilíbrio que as configurações NUM_PARALLEL e MAX_QUEUE do Ollama fazem entre slots paralelos, solicitações em fila e a VRAM disponível.

Há uma forma de executar o próprio K3 numa única máquina grande, entre este tier e o último. A Unsloth documenta builds GGUF do K3 no llama.cpp, desde quantizações de 1 bit e 2 bits até UD-Q8_K_XL, que ela classifica como lossless em precisão total. Ela também cita uma NVIDIA DGX Station como hardware capaz de executá-las. A regra prática é que RAM mais VRAM deve ser aproximadamente igual ao tamanho da quantização: cerca de 610 GB para o build UD-IQ1_S de 1 bit até cerca de 1.6 TB para o Q8. Abaixo disso, o modelo passa a usar o disco e fica muito mais lento. Uma GPU é opcional: as instruções de build da Unsloth desativam o CUDA "if you don't have a GPU or just want CPU inference". Os builds de 1 bit e 2 bits são versões fortemente quantizadas do K3, com o custo de precisão descrito acima. O build Q8 é o K3 na precisão publicada, servido a um usuário na velocidade da RAM. Nenhum dos dois é um modelo menor.

O Ollama é o caminho mais curto para colocar um servidor funcional em uma VPS com uma GPU conectada:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run baixa o modelo na primeira utilização e depois apresenta um prompt. Uma tag inexistente retorna Error: model "..." not found. Por isso, copie as tags da página da biblioteca em vez de digitá-las de memória. O passo a passo completo, incluindo a unidade systemd e o acesso remoto, está em executar o Ollama numa VPS.

O llama.cpp oferece mais controle sobre a quantização e o offload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 solicita todas as camadas na GPU. Leia o log de carga: ele informa quantas camadas foram transferidas. As camadas que passam para a RAM do sistema são executadas na largura de banda da RAM, e não na largura de banda da HBM. Por isso, a velocidade de geração cai uma ordem de grandeza assim que o modelo deixa de caber. Os compromissos entre as duas ferramentas são descritos em Ollama e llama.cpp lado a lado.

Tier 3: API hospedada, orquestração autogerida

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

O endpoint é compatível com a OpenAI, portanto um cliente existente funciona depois que você altera a URL base.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Uma chave válida retorna um objeto JSON com um array choices. Um 401 significa que a autenticação falhou: verifique se a chave está correta, não expirou nem foi desativada e se o cabeçalho contém Authorization: Bearer seguido da chave. Um erro de modelo não encontrado geralmente significa que o id mudou, porque os provedores aposentam ids entre checkpoints.

Agora, o ponto de equilíbrio, usando a taxa de aluguel considerada acima. Um nó com 8 GPUs sempre ligado custa 14,400 USD por mês e, a 15.00 USD por milhão de tokens de saída, o mesmo valor compra aproximadamente 960 milhões de tokens de saída pela API. Para obter vantagem em custo, você precisa gerar quase 1 bilhão de tokens de saída por mês, aproximadamente 30 milhões por dia, e manter o cluster ocupado o tempo todo, porque GPUs ociosas são cobradas pela mesma taxa que GPUs ocupadas. Cargas de trabalho de agentes com muitos prompts afastam ainda mais esse ponto: o contexto repetido é cobrado pela taxa de cache hit de 0.30 USD por milhão, em vez da taxa de cache miss de 3.00 USD.

O que você hospeda por conta própria nesta camada é tudo o que fica ao redor do modelo: um gateway que mantém a chave da API para que ela nunca chegue a um cliente, logs de requisições e respostas, novas tentativas, limites de taxa e orçamentos por usuário. Isso é executado em um VPS pequeno, sem nenhuma GPU. A mesma divisão se aplica a pesos fechados, em que hospedar o Claude por conta própria não é possível no nível do modelo e a orquestração é a única parte sob seu controle.

Qual stack de serving pertence a cada nível

Servidores da classe vLLM e SGLang pertencem ao nível 1. Eles existem para atender muitas requisições simultaneamente, com continuous batching e paged KV cache, além de tensor parallelism e expert parallelism distribuídos por vários nós. Eles pressupõem aceleradores de datacenter e uma interconexão rápida entre eles. Em uma única placa de consumo, são mais complexos de instalar e oferecem poucos benefícios perceptíveis.

llama.cpp e Ollama pertencem ao nível 2. Eles são voltados para uma única máquina, quantização GGUF, offload para a CPU quando o modelo não cabe e baixa concorrência. O llama.cpp carrega um MoE enorme mantendo os pesos dos experts na RAM do sistema (--cpu-moe ou --n-cpu-moe) e, com --moe-cache-mib, armazena em cache na GPU os experts que utiliza. É assim que os builds K3 GGUF da Unsloth são executados em uma única máquina. A velocidade depende da largura de banda da RAM e da frequência com que o router não encontra o expert no cache. Se o arquivo for maior que a RAM mais a VRAM, ele passa a usar o disco. É uma configuração viável para um usuário. Não é um serviço que possa atender muitos usuários. A comparação completa está em Ollama versus vLLM, e isso não muda com o modelo: a questão é sempre saber se você está atendendo muitos usuários em hardware compartilhado ou um usuário em sua própria máquina.

Os quatro números que permanecem válidos depois deste marco

1. O número total de parâmetros multiplicado pelos bytes por peso dá o limite mínimo de memória. Nada é executado abaixo desse limite com a precisão disponibilizada, e quantizar abaixo de uma versão de 4 bits poupa até cerca de 70 por cento, com um custo de precisão, não uma redução de uma ordem de grandeza.
2. Os parâmetros ativos determinam a classe de throughput. Um MoE de 2.8T com 104B de parâmetros ativos tem capacidade de processamento equivalente à de um modelo de 104B.
3. A cache KV por token, multiplicada pelo tamanho do contexto e pela concorrência, é o custo que continua a crescer depois de os pesos terem sido pagos.
4. Tokens por segundo por dólar é o único número que determina o nível adequado. Tudo o que vem acima serve de entrada para esse cálculo.

Aplique esses quatro números a qualquer versão e obterá a resposta correta antes de consultar um guia do fornecedor. A próxima já foi anunciada: a Moonshot lançou o K3.1 Pro, baseado no K3 e com pós-treino adicional, no Kimi Code em 23 October 2026, e o quickstart da API informa que os pesos completos serão lançados até 4 November. Registe depois a data de cada valor anotado. Os preços e as listas de arquiteturas suportadas mudaram nas duas semanas seguintes ao lançamento do K3. Os valores de lançamento desta página foram publicados em July 2026, e as receitas de serving, as versões do runtime e os números de quantização foram revistos novamente em 27 October 2026.

FAQ

Posso executar o Kimi K3 em uma única GPU?

Não. Os pesos ocupam cerca de 1.4 TB na precisão MXFP4 distribuída pela Moonshot, e até a menor quantização publicada do K3, o arquivo UD-Q1_0 de 466 GB da Unsloth, é cerca de 1.6 vezes maior que os 288 GB dos maiores aceleradores amplamente disponíveis. O llama.cpp pode manter os experts na RAM do sistema e armazenar em cache os que estão ativos na GPU, mas isso ainda exige aproximadamente o tamanho da quantização em RAM mais VRAM; abaixo disso, o modelo passa para o disco e executa muito mais lentamente. As menores receitas publicadas para servir usam um nó com 8 GPUs B300 ou MI350X/MI355X, e a receita para H100 usa 32.

De quanta VRAM o Kimi K3 precisa?

Comece com 1.4 TB apenas para os pesos, o que corresponde a 18 GPUs H100 de 80GB ou 5 GPUs da classe GB300. Depois, adicione o cache KV e a memória de ativação. A orientação de lançamento da Moonshot recomendava 64 ou mais aceleradores. Em 27 October 2026, o cookbook do SGLang publica receitas de nó único com 8 GPUs B300 ou 8 GPUs MI350X/MI355X, totalizando 2,304 GB, e uma configuração com 32 GPUs H100, totalizando 2,560 GB; portanto, trate o tamanho dos pesos como um piso, não como um requisito.

A quantização faz o Kimi K3 caber em um único nó?

O checkpoint de 4-bit distribuído já cabe em um único nó se esse nó tiver oito GPUs de 288 GB, que é o formato usado pelas receitas B300 e MI355X do SGLang, e em uma máquina com cerca de 1.6 TB de RAM mais VRAM usando o GGUF Q8 sem perdas da Unsloth. Reduzir mais ajuda a usar máquinas menores: as compilações GGUF dinâmicas medidas pela Unsloth variam de 861.3 GB em 2-bit a 594 GB em 1-bit, e o repositório lista arquivos de 1-bit com tamanhos que chegam a 466 GB, o menor tamanho listado, em comparação com cerca de 1.56 TB sem perdas. O custo em precisão foi medido: a concordância top-1 com o modelo completo cai para 90.390 por cento em UD-Q2_K_XL e 78.875 por cento em UD-IQ1_S. Nenhuma delas cabe em uma única GPU.

Alugar GPUs é mais barato que a API do Kimi K3?

Somente com volume alto e constante. Considerando 2.50 USD por hora de GPU, um nó com 8 GPUs sempre ligado custa 14,400 USD por mês, e o mesmo valor compra cerca de 960 milhões de tokens de saída à taxa publicada de 15.00 USD por milhão. Você também paga pelas horas ociosas, pelos downloads dos pesos e pela pessoa que mantém o cluster em funcionamento. Alugue por hora para picos de demanda e compare com o volume de tokens medido no seu ambiente, não com uma estimativa.

O que significa ter 104B de parâmetros ativos para a velocidade?

Isso significa que a aritmética por token é a de um modelo de 104B, portanto o throughput fica nessa classe, e não na classe de 2.8T. Isso não informa nada sobre a memória: todos os 2.8T parâmetros permanecem residentes, porque o router pode chamar qualquer expert para qualquer token. Use a contagem de parâmetros ativos para prever tokens por segundo e a contagem total para dimensionar a VRAM.