Qwen no seu Xeon
Qwen3.8-Flash-Next · referência de quantização: Unsloth UD-IQ4_XS · uma requisição por vez.
Perfis recomendados · Unsloth Studio
Escolha o hardware e transcreva os valores. Estes são perfis iniciais para uso diário, com prioridade à velocidade e margem de memória. “Ótimo” só pode ser confirmado medindo prefill e geração no seu PC.
Rótulos e ordem conferidos no código público do Unsloth Studio [11]. O print do Unsloth não foi recebido nesta conversa; a aparência exata da sua versão ainda precisa ser conferida. Esta página não altera o Unsloth.
Qwen3.8-Flash-Next · UD-IQ4_XS
Se faltar memória
Como procurar mais velocidade
Deixe Vision: Off para texto; ligar imagens carrega o projetor e altera o orçamento. Speculative Decoding: Off mantém a referência sem MTP. Parallel Slots: 1 dedica o contexto a uma conversa.
Os perfis GPU começam com MoE Layers on CPU: 48: preservam espaço para atenção, cache e microbatch. Reduzir esse valor é um experimento posterior, não um ganho garantido. Todos os especialistas na CPU não significa toda a computação na CPU.
Cuidados ao transcrever os campos
GPU Memory: Manual e GPU Layers explícito são necessários para controlar MoE Layers on CPU nessa interface. Com GPU Layers em Auto, as regras de ajuste automático podem mudar o que foi solicitado. Confirme a configuração efetiva no log após recarregar o modelo.
Mmap/Mlock: None é a tentativa inicial de desempenho com 128 GB. Se a memória residente pressionar o sistema, volte a mmap. As opções globais de Model Memory podem sobrepor esse campo; confira o log. Não confunda None com descarregar os pesos.
Em Extra llama-server arguments, os dispositivos abaixo assumem CUDA0 = 3060 e CUDA1 = 5060 Ti. Verifique --list-devices e selecione somente a placa indicada em GPUs. A seleção e a ordem precisam concordar com os argumentos. Se a sua versão rejeitar um argumento gerenciado, configure-o pelo campo correspondente e mantenha o restante; não ignore o erro de validação.
Nos perfis de uma placa, o número CUDA pode mudar após a instalação. No perfil CPU, --no-op-offload e --no-kv-offload evitam que operações ou cache ainda sejam executados na GPU. Caso essas flags não existam no build, uma versão compilada apenas para CPU é a referência inequívoca.
Quanto cada cenário pode entregar?
Geração · tokens por segundo
Mesmo modelo, pesos residentes; barras em escala comum. A faixa varia banda efetiva e custos residuais em ±25%: é sensibilidade, não probabilidade.
| Cenário | Camadas expert GPU | Pesos GPU estimados | Tempo / 500 tokens |
|---|
Equação e limites do cálculo
t = Dcpu / Bram + D3060 / B3060 + D5060 / B5060 + Vpcie / Bpcie + custo residual; geração = 1 / t. GB e MB são decimais. As parcelas são somadas como aproximação serial, sem somar as bandas das GPUs.
Os 1,6 GB/token de especialistas e 1,7 GB/token de outras leituras são uma decomposição hipotética dos ~6B ativos quantizados. Não foram extraídos dos tensores. Custo residual reúne computação, desquantização, latência, PLE e sincronização não capturados pelo termo de banda; não é uma medição isolada.
Para capacidade, assumimos 60 GB de especialistas distribuídos uniformemente por 48 camadas, 3 GB de pesos restantes nas GPUs, mais 2 GB de reserva por GPU para contexto curto, buffers e tela. Arredondamos a quantidade de camadas para baixo. A divisão real dos tensores pode impedir que essa alocação caiba. Use os logs para substituir as hipóteses.
O alvo de camadas é limitado por cada capacidade; nas duas placas, distribuímos proporcionalmente à capacidade disponível. O tráfego é agregado e repartido por essa distribuição; há 80% de eficiência PCIe hipotética. Não modelamos competição por canais da RAM, paginação, distribuição desigual de especialistas, sobreposição, kernels específicos, contexto longo ou prefill. Os resultados são um mapa de sensibilidade, não previsão validada.
O caminho dos dados
45 GB/s é só a hipótese inicial
O link precisa ser medido sob carga
A placa usa até oito pistas
PCIe 3.0: 8 GT/s × 128/130 ÷ 8 × pistas, por direção, antes de overhead de pacotes: x4 = 3,94 GB/s; x1 = 0,985 GB/s. A plataforma do Xeon limita a geração a PCIe 3.0. A indicação de PCIe 4.0 no CPU-Z não comprova um link 4.0 operacional. Os 2,5 GT/s e clocks baixos dos prints podem refletir repouso. [1–5]
A MR9S é anunciada com dois slots PCIe 3.0 x16 e um x4. A revisão física, o encaixe das duas placas e a largura negociada precisam ser verificados: um conector comprido não garante dezesseis pistas. A especificação x8 da 5060 Ti é corroborada por outro fabricante; o SKU exato da Palit ainda não foi informado. [3–5]
Memória que cabe ≠ memória lida por token
A arquitetura tem 125B parâmetros, ~6B ativos, mais 51B em n-gram embeddings e 4B de MTP; há 48 camadas e 10 especialistas roteados + 1 compartilhado ativos por camada. O GGUF UD-IQ4_XS citado ocupa ~93,7 GB (~87,3 GiB), não 125B × quatro bits. O tipo IQ4_XS não determina sozinho o tamanho final. [6–7]
Nem 16 GB nem 28 GB de VRAM comportam todos esses pesos. A memória das duas placas continua separada. A RAM recebe o restante; não se deve dividir os 93,7 GB inteiros pela banda para prever cada token.
Dois tipos de offload
Especialistas calculados na CPU: na geração unitária, os pesos residentes na RAM são processados pelo Xeon. Não é necessário transportar todos os especialistas ativos pelo PCIe a cada token.
Operações transferidas à GPU: no prefill em lote, o backend pode copiar especialistas para processá-los na GPU. Aqui, PCIe e microbatch podem dominar. Não transfira automaticamente uma conclusão de geração para prefill. [8–9]
A tabela PLE merece alocação explícita na CPU; consulte o GGUF e o log. Mapeamento em disco só é vantagem se a pressão de memória justificar o custo de acesso.
O que foi observado em outras máquinas
| Origem | Condições | Resultado publicado | Aplicabilidade |
|---|---|---|---|
| Relato com duas RTX 3060 [8] | 7800X3D, 128 GB DDR5-3200; prompt sintético 8K; contexto configurado 131K | llama.cpp: ~303 t/s prefill, ~12 t/s geração; layer, todos os experts CPU, microbatch 2048 | Placas reais, CPU e kernels diferentes dos do Xeon. Relato comunitário de uma sessão, com resumo gerado por IA; tratar as tabelas como evidência exploratória. |
| Mesmo relato [8] | Troca de tensor para layer e aumento de microbatch | ~42 → ~303 t/s prefill; ik_llama chegou a ~407 t/s | Motiva teste A/B; não garante o mesmo ganho no Xeon ou em versões posteriores. |
| lukaLLM [9] | 9950X + RTX PRO 6000; limite artificial de VRAM | CPU ~8,3 t/s; limite de 8 GiB ~35,7 t/s | Não é benchmark de uma GPU de 8 GB. Mantém computação e banda da PRO 6000. Não foi usado como calibração do simulador. |
Comandos de diagnóstico · contexto 8K
Comece com llama.cpp com suporte a qwen4exp e CUDA para ambas as arquiteturas. Registre a versão exata; o benchmark [9] usou b10666 / 4e97ac86e. O suporte inicial não implica ausência de correções posteriores. Os comandos abaixo são pontos de partida, não configurações já validadas neste PC. Confirme as opções em --help. [9–10]
Substitua MODELO.gguf pelo primeiro shard e mantenha os demais na mesma pasta. Nos comandos, assumimos CUDA0 = 3060 e CUDA1 = 5060 Ti; confirme com llama-server --list-devices. Se só uma placa estiver instalada, ela pode ser CUDA0. Comandos independem das hipóteses do simulador: começam com todos os especialistas na CPU para medir uma referência simples. [10]
CPU: procurar o ponto de saturação
- Iniciar com 18 threads e testar 6, 9, 12, 18, 24 e 36. Hyper-threading não duplica a banda da RAM.
- Para CPU pura, comparar kernels/repacking do llama.cpp e ik_llama em builds equivalentes. Não presumir que a opção vencedora em CPU também beneficia offload.
- Comparar microbatch 128, 256 e 512 no prefill. Não usar o clock em repouso como frequência sustentada.
- Medir a RAM com STREAM, Intel MLC ou equivalente; um resultado de cópia sequencial não é a banda efetiva de MoE.
GPU: reservar espaço para o trabalho
- Testar uma placa por vez com todos os experts na CPU; comparar geração e prefill separadamente.
- Depois testar
--n-cpu-moe 46, 44, 40em execuções separadas, recuando ao esgotar a VRAM. Menos camadas na CPU consome mais VRAM. - Testar microbatch 256, 512, 1024, 2048, elevando o batch para ao menos o microbatch. Registrar pico de memória.
- Com ambas, iniciar em
--split-mode layer --tensor-split 40,60; testar 35/65 e 45/55. A proporção é só um começo e depende da ordem dos dispositivos. - Manter MTP desligado na referência. Só testar depois: pode piorar com especialistas na CPU. [8–10]
RAM, contexto, Windows e instalação
128 GB reportados pelo CPU-Z representam aproximadamente 128 GiB de capacidade instalada. GGUF de 87,3 GiB deixa ~40,7 GiB brutos antes de SO, buffers e caches, mas carregamento e duplicações podem consumir mais. Não confunda RAM “usada” com page cache recuperável. Comece em contexto 8192 e uma sequência; aumente para 32768 e 131072 somente após medir.
Compare --load-mode mmap com --load-mode none mantendo tudo igual. O segundo pode acelerar prefill, mas demanda memória residente. Evite paginação contínua. Não ative mlock indiscriminadamente. No Windows, monitore memória dedicada e compartilhada da GPU; compartilhada usa RAM e não amplia a VRAM na mesma velocidade.
Use driver e pacote CUDA compatíveis com Blackwell e Ampere; builds sem suporte a uma das arquiteturas não são comparáveis. Não é preciso instalar o toolkit para usar todo pacote pré-compilado. Compare Windows nativo e Linux apenas com mesma versão, modelo e parâmetros. WSL2 traz outra topologia de memória; não trate resultados como idênticos.
Antes de instalar a segunda placa, confira fonte, conectores e ventilação: o print informa 170 W na 3060, e a Palit consultada especifica 180 W na 5060 Ti; o CPU tem TDP de 120 W. A soma não é dimensionamento da fonte. O modelo e a capacidade da fonte não foram informados.
Transformar as hipóteses em medições
- Fixar o experimento: hash do GGUF, revisão do backend, SO, driver, threads, contexto, microbatch, tipo de KV e alocação por dispositivo. Registrar topologia com
nvidia-smi -qenvidia-smi topo -mquando suportado; verificar link sob carga. - Separar tarefas: prefill de 512, 2048 e 8192 tokens; geração de 256 tokens após prompt de 2048. Medir também geração com histórico ocupado de 8K e 32K. Contexto reservado e contexto efetivamente ocupado são coisas diferentes.
- Repetir: um aquecimento e cinco execuções por configuração, sem reutilização de prompt cache. Alternar A/B para reduzir viés térmico. Informar mediana e mínimo/máximo; não chamar esse alcance de intervalo de confiança.
- Coletar: t/s de prompt e geração, tempo até primeiro token, pico de RAM/VRAM, banda PCIe, clocks, temperaturas e paginação. Conferir coerência das respostas.
- Otimizar uma variável por vez: threads → loading → alocação → microbatch → contexto → especulação. Atualizar banda e custo residual do simulador com as medições; a extrapolação continua aproximada.
Estimativa de espera: tempo total ≈ tempo de carregamento (se frio) + tokens de entrada / prefill + tokens gerados / geração. Não há previsão numérica de prefill neste simulador: seria necessário caracterizar computação, cópias e lotes. Os relatos acima servem para escolher os testes, não para preencher números do seu PC.
Fontes e rastreabilidade
Consultadas em 12/09/2026. Prints fornecidos são evidência de hardware; não foram publicados aqui, nem foram interpretados como instruções.
- Intel · E5-2695 v4 — especificações do processador, canais e largura de banda.
- NVIDIA · RTX 3060 — 12 GB, GDDR6 de 192 bits, 360 GB/s.
- Palit · 5060 Ti Infinity 3 OC 16GB — 448 GB/s e 180 W; variante de referência, SKU comprado não confirmado.
- MSI · interface da família 5060 Ti — conector x16 com oito pistas; referência de outra variante.
- MACHINIST · MR9S — slots anunciados; validar revisão e largura elétrica instalada.
- Qwen · ficha oficial — arquitetura e parâmetros.
- Unsloth · GGUF — família de quantizações; confirmar arquivo e revisão usados.
- Relato original · duas RTX 3060 + 7800X3D — testes comunitários com tabela de resultados e configurações.
- lukaLLM · benchmark e artefatos — atenção à limitação artificial de VRAM em uma RTX PRO 6000.
- llama.cpp · opções oficiais do servidor — flags dependem da versão.
- Unsloth Studio · campos de configuração — rótulos, ordem e semântica da interface; valores dos perfis são recomendações desta análise.