{
  "protocolo": "sd-server com o modelo ja carregado; 5 requests por braco e resolucao, o PRIMEIRO descartado (warmup); s/it lido do 'sampling completed' do log do proprio servidor (isola o denoise: exclui load, encode de prompt e decode da VAE); os 3 backends no mesmo pod A100-80 PCIe, simultaneos; 4 steps, euler, cfg 1.0, --diffusion-fa",
  "por_que_este_numero_e_nao_o_do_sd_cli": "a medicao via sd-cli (1 invocacao por imagem) inclui overhead de setup por invocacao e produziu uma ordenacao que nao se sustenta em regime permanente (o Q4_K_M, menor modelo, aparecia quase tao lento quanto o FP16). O card foi corrigido.",
  "resolucao_1024": {
    "fp16":   {"s_per_it": 0.853, "request_total_s": 4.15, "encode_prompt_s": 0.09},
    "tq3p":   {"s_per_it": 0.865, "request_total_s": 4.21, "encode_prompt_s": 0.11},
    "q4_k_m": {"s_per_it": 1.312, "request_total_s": 6.07, "encode_prompt_s": 0.14}
  },
  "resolucao_768": {
    "fp16":   {"s_per_it": 0.460, "request_total_s": 2.31, "encode_prompt_s": 0.10},
    "tq3p":   {"s_per_it": 0.487, "request_total_s": 2.43, "encode_prompt_s": 0.12},
    "q4_k_m": {"s_per_it": 0.752, "request_total_s": 3.51, "encode_prompt_s": 0.15}
  },
  "leitura": {
    "tq3p_vs_fp16": "empate: +1.4% a 1024, +5.9% a 768, com 2.44x menos bytes no DiT",
    "tq3p_vs_q4km": "tq3p 1.52x mais rapido a 1024 e 1.54x a 768, com arquivo 26% maior",
    "hipotese_nao_isolada": "o gate CUDA roteia TQ{K}P por dequant->cuBLAS (mesmo caminho de GEMM do FP16); o Q4_K passa pelo kernel mmq, menos eficiente neste regime de ~4096 tokens de imagem por passo"
  }
}