Olá a todos!
Disclamer: Primeiro: a Tiny League não é minha. É um projeto do Nuno Donato, e além do nome próprio e do gosto por modelos que cabem em máquinas normais, não partilhamos mais nada: Ele não me pediu este texto nem me pagou por ele. Segundo: os números que vou citar foram tirados do site a 7 de novembro de 2026, com a última atualização datada da véspera. O site mexe com frequência (e ainda bem), por isso é provável que, quando leres isto, já lá estejam modelos novos e uma ou outra correção. Terceiro: as contas de memória e de velocidade que faço por cima desses números são minhas, aproximadas, e servem para pensar. Pf não as coloques num caderno de encargos.
No último post andei a passear pelo r/LowEndLocalAI: a PS5 desbloqueada a correr um modelo de 27B a 2 bits, o Game Boy Color com um modelo de linguagem lá dentro que não serve para nada mas que é maravilhoso, o 1080 Ti esquecido num Proxmox a servir um 9B enquanto o Jellyfin transcodifica no mesmo servidor. A ideia central era simples: antes de comprar, descobre o que a tua máquina aguenta, e há uma comunidade inteira disposta a ajudar-te a descobrir sem te fazer sentir mal por teres um portátil de 2017.
Fechei com um convite para tirar a máquina velha da gaveta. Quem fizer isso a sério chega, mais cedo ou mais tarde, a uma segunda pergunta, e essa é bem mais traiçoeira que a primeira.
“Ok, a minha máquina aguenta um modelo de 9B. Mas qual?”
O problema das tabelas de lançamento
Quem acompanha isto sabe como funciona. Todas as semanas (talvez menos?) sai um modelo novo. Cada lançamento vem com o seu gráfico de barras, cuidadosamente escolhido, onde o modelo novo aparece à frente de três ou quatro concorrentes. Os benchmarks escolhidos para esse gráfico são, por acaso, aqueles onde o modelo novo ganha. Os concorrentes escolhidos são, também por acaso, os que perdem nesses benchmarks. Às vezes compara-se com a versão anterior de um rival que entretanto já foi atualizada. Às vezes compara-se o Terminal-Bench 2.0 de um com o 2.1 de outro e ninguém repara.
Isto não é uma questão de mentir. É marketing, e o marketing faz o que sempre fez: mostra o melhor ângulo. O problema é para quem está do lado de cá, com 11 GB de VRAM e uma tarde livre, a tentar decidir que ficheiro de 6 GB vale a pena descarregar. Para tomar essa decisão com alguma sensatez precisavas de juntar as tabelas de vinte lançamentos diferentes, alinhar os benchmarks que são realmente iguais, deitar fora os que só um modelo reporta, e depois ainda cruzar tudo isso com aquilo que o teu hardware consegue fazer.
Ninguém faz isso numa tarde livre. Eu, pelo menos, nunca fiz. Acabava sempre por ir pelo que estava na moda no sub nessa semana, o que não é um critério horrível (a comunidade filtra muito ruído) mas também não é propriamente um método.
E há uma segunda camada neste bolo red velvet de problema, que me interessa ainda mais. As tabelas de lançamento falam de qualidade. Mas quase nunca falam do custo. Dizem-te quanto o modelo acerta no GPQA Diamond, mas não te dizem quanta memória vai comer a cache quando lhe deres um PDF de 80 páginas, nem a que velocidade vai escrever numa gráfica com a largura de banda de uma gráfica de 2017. Para quem tem uma 4090 ou um Mac com 128 GB, isso é uma nota de rodapé ou um bocejo. Para quem anda pelo r/LowEndLocalAI, é Hamlet inteiro.
O que é a Tiny League
A Tiny League é, nas palavras do próprio site, uma tabela de benchmarks para modelos open-weight pequenos, feita para comparar modelos lado a lado, perceber quais são mais baratos de correr e filtrar os que cabem no teu hardware. Foi lançada a 4 de setembro de 2026 com 26 modelos e, no dia em que escrevo, vai em 36 modelos, 95 benchmarks e 651 pontuações. Desses 36, 15 aceitam imagens.
A página divide-se em quatro peças.
A primeira é a tabela de modelos: parâmetros totais, parâmetros ativos por token, contexto nativo, tipo de arquitetura (denso ou MoE), licença e data de lançamento. Até aqui, nada que não encontres a cavar nos cartões do Hugging Face. A diferença está em duas colunas extra, de que já falo com calma: a memória da cache KV a 128K tokens e uma estimativa de velocidade de geração.
A segunda é um heatmap, com uma linha por modelo e uma coluna por benchmark. A cor é calculada dentro de cada coluna, por isso o verde-escuro quer dizer “o melhor deste grupo neste teste” e não “bom em absoluto”. O melhor de cada coluna leva uma medalha. Há uma vista “Core”, que mostra só os benchmarks reportados por cinco ou mais modelos (30 colunas), e uma vista “All”, com os 95.
A terceira são gráficos de dispersão, onde podes pôr qualquer métrica num eixo e qualquer outra no outro. Há predefinições para GPQA Diamond, Terminal-Bench 2.1, HLE, IFBench, KV a 128K e velocidade, e podes escolher os eixos à mão.
A quarta são 48 gráficos de comparação, um por benchmark, com os dez melhores sempre que pelo menos quatro modelos reportam esse teste.
Não há um ranking geral. Não há uma pontuação única que diga “este é o melhor modelo pequeno do momento”. Ao início estranhei. Depois de uma hora a mexer no site, acho que é a melhor decisão do projeto inteiro, e volto a isso mais à frente.
As regras de entrada
Antes dos números, vale a pena ler os critérios de inclusão, porque dizem bastante sobre a forma como o site pensa.
Entram modelos entre 1,5B e 284B parâmetros. O limite de baixo era 2B até 27 de outubro e desceu para acomodar a nova vaga de modelos de 1,7B. Só contam pesos oficiais: nada de versões quantizadas, nada de re-uploads com fine-tuning de terceiros. Só entram modelos lançados a partir de 5 de abril de 2026. E só a versão atual de cada um: quando sai a versão nova, a antiga sai da tabela.
O teto de 284B fez-me sorrir. Um modelo de 284B não tem nada de “tiny” para quem tem um portátil com 16 GB de RAM. O maior da tabela, o DeepSeek-V4-Flash-DSpark, tem precisamente esses 284B no total, com 13B ativos por token. Correr isto em casa pede uma máquina que a maior parte de nós não tem mesmo recorrendo a truques marados como tem aparecido nos ultimos tempos
Mas lembra-te do que dizia o próprio r/LowEndLocalAI sobre a sua definição de “low end”: é uma restrição, não uma etiqueta de preço. Um Mac Studio com 96 GB cabe lá, se o dono estiver a esticar a máquina até ao limite. Com a Tiny League passa-se algo parecido. “Pequeno” é relativo à fronteira, e a fronteira, em 2026, anda pelos biliões de parâmetros servidos em centros de dados. Ao lado disso, um MoE com 13B ativos é pequeno. O que interessa é que a tabela inclui o espetro inteiro e te deixa a ti a tarefa de filtrar pelo que a tua máquina aguenta. É a mesma lógica do sub, aplicada à escolha do modelo em vez da escolha da máquina.
A regra dos pesos oficiais também merece um parágrafo. Por um lado, é a única forma de comparar: se cada pessoa testasse a sua quantização favorita, não havia duas linhas comparáveis. Por outro lado, quer dizer que nenhuma das pontuações da tabela corresponde exatamente ao ficheiro que vais correr em casa. Tu não vais correr o Qwen3.8-27B em BF16 numa gráfica de 11 GB. Vais correr um GGUF a 4 bits feito por alguém, e esse GGUF vai ser um bocadinho pior do que o original. Quanto pior depende do modelo, do método de quantização e da tarefa. A 4 ou 5 bits, para a maior parte dos usos, a diferença é pequena. A 2 bits, como na PS5 do último post, já não é.
A coluna que me fez escrever este post: KV @128K
Se tivermos de olhar para uma só coluna da Tiny League, que seja esta.
Recapitulando o que escrevi no outro post: para correr um modelo, tens de ter memória para os pesos e para a cache KV. A cache é onde o modelo guarda o que já leu da conversa, para não ter de reprocessar tudo a cada token novo. Cresce com o contexto. Cada token que o modelo lê ocupa um bocadinho de memória, e esse bocadinho multiplica-se por todos os tokens da conversa. Disse na altura que o contexto não é gratuito. O que não disse, porque não tinha números arrumados para o mostrar, é que o preço varia de forma absurda de modelo para modelo, mesmo entre modelos do mesmo tamanho.
A coluna KV @128K dá-te exatamente esse número: quanta memória ocupa a cache de uma única conversa com 128 mil tokens, em BF16. O site calcula-a a partir do `config.json` de cada modelo e confirma-a nos pesos publicados. E deixa claro que não é um benchmark: é um custo de hardware.
Vê estes números, tirados da tabela.
O Nemotron-3.5-Lightning-30B-A3B da NVIDIA, com 31,6B parâmetros, precisa de 0,75 GiB para 128K tokens de contexto. O Ling-3.0-tiny, com 7,9B, precisa de 0,84 GiB. O gemma-4-12B-it fica nos 2,31 GiB. O Qwen3.8-27B, denso, pede 8 GiB.
Agora o outro lado. O granite-4.2-8b, com 8,8B parâmetros, pede 20 GiB. O granite-4.2-30b pede 32 GiB. E o Nanbeige4.2-3B, um modelo com 4,2B parâmetros, pede 22 GiB para os mesmos 128K tokens.
Leste bem. Um modelo de 4B cuja cache, com o contexto todo, ocupa várias vezes o tamanho dos próprios pesos. Quantizado a 4 bits, o Nanbeige4.2-3B anda à volta dos 2,5 GB. A cache a 128K são 22 GiB. Se olhares só para o tamanho do modelo, e é isso que quase toda a gente faz, concluis que ele cabe folgado na tua GTX 1060 de 3 GB. Cabe, sim, mas com muito pouco contexto.
Fiz as contas para o perceber melhor. 22 GiB a dividir por 131.072 tokens dá cerca de 176 KiB por token. Com 8K tokens de contexto são cerca de 1,4 GiB. Com 32K são 5,5 GiB. Numa gráfica de 3 GB, com 2,5 GB ocupados pelos pesos, sobra espaço para uns poucos milhares de tokens, e isto antes de contar com o que o próprio motor precisa para trabalhar. O Nemotron Lightning, por comparação, gasta cerca de 6 KiB por token. É quase trinta vezes menos.
Isto muda completamente a conversa sobre o que cabe onde. Pega no meu exemplo preferido do post anterior, o 1080 Ti com 11 GB.
O gemma-4-12B-it, a 4 bits, ocupa mais ou menos 7,2 GB de pesos. Junta-lhe 2,31 GiB de cache para 128K tokens e ficas nos 9,5 GB, mais coisa menos coisa. Cabe no 1080 Ti com o contexto nativo quase todo, sem quantizar a cache. O granite-4.2-8b, mais pequeno nos pesos (uns 5,3 GB a 4 bits), com 128K de contexto precisaria de mais de 25 GB. Para o pôr no mesmo 1080 Ti tens de te ficar pelos 16K a 24K tokens de contexto, ou quantizar a cache a 8 bits e aceitar o que isso custa.
Ou seja: o modelo “maior” cabe melhor que o “mais pequeno”, se a tua tarefa precisar de contexto longo. Sem esta coluna, só descobrias isso ao tentar carregar o modelo e ver o llama.cpp a queixar-se de falta de memória. Ou, pior, a fazer offload silencioso para a RAM e a velocidade a cair para metade sem perceberes porquê.
Há truques para reduzir a cache. O llama.cpp deixa quantizá-la a 8 ou até a 4 bits, o que corta o número para metade ou para um quarto. Podes também simplesmente pedir menos contexto do que o nativo, e para muita coisa 16K chegam e sobram. Mas, para escolher entre dois modelos, é muito útil saber à partida que um deles te vai custar trinta vezes mais memória por token do que o outro.
Para quem quer resumir PDFs à noite, que era um dos usos que dei como exemplo no último post, esta coluna vale mais do que metade dos benchmarks da página.
A velocidade estimada, e porque é que um 1080 Ti está mais perto do que parece
A segunda coluna de custo é a velocidade de geração estimada, em tokens por segundo. O site faz a conta para uma RTX 4090 a metade da sua largura de banda, ou seja, cerca de 504 GB/s, e dá dois valores: com o contexto vazio e depois de ler uma cache de 128K. A página avisa, com todas as letras, que são estimativas e não medições. É uma conta de largura de banda: quantos bytes é preciso ler da memória para gerar cada token, a dividir pela velocidade a que a memória os consegue entregar.
Quem leu o post anterior já sabe porque é que isto funciona. A geração de texto num modelo local está quase sempre limitada pela largura de banda da memória, não pela capacidade de cálculo. Para cada token, o motor tem de ler todos os pesos ativos. Se a tua memória entrega X GB por segundo e o modelo tem Y GB de pesos ativos, o teto teórico são X a dividir por Y tokens por segundo. Na prática ficas abaixo disso, mas a ordem de grandeza bate certo.
Agora o pormenor que me fez rir quando reparei. A “metade de uma 4090” que o site usa como referência, 504 GB/s, está quase em cima da largura de banda de um GTX 1080 Ti: 484 GB/s. A gráfica de 2017 que andava esquecida num Proxmox, no post anterior, é praticamente a máquina de referência desta tabela. Uma PS5 anda pelos 448 GB/s. Uma RTX 2060 pelos 336. Uma RTX 4060, que muita gente recomenda como “a gráfica para começar”, fica-se pelos 272 GB/s, quase metade.
Atenção a um pormenor, porém. Pelas minhas contas, os valores da tabela assumem os pesos em BF16, ou seja, dois bytes por parâmetro. O Qwen3.8-27B tem 27,8B parâmetros, o que dá cerca de 55,6 GB em BF16. 504 a dividir por 55,6 dá 9,1, que é exatamente o valor que a tabela mostra. Em casa, vais correr quantizado. A 4 bits, com o formato Q4_K_M, andas pelos 0,6 bytes por parâmetro, um terço do BF16. O teto sobe na mesma proporção.
Por isso, a forma de ler esta coluna, para quem está no low end, é esta: usa-a para ordenar os modelos, não para prever o número exato que vais ver no ecrã. Um modelo com 84 tok/s estimados vai ser bastante mais rápido do que um com 9 tok/s, em qualquer máquina. Quanto mais rápido, depende de ti.
E os números ordenam muito. O Ling-3.0-tiny, um MoE de 7,9B com 1,3B ativos, está estimado em 194 tok/s. O LFM2.5-8B-A1B em 168. O LFM2.5-24B-A2B em 126. Os três MoE de 35B com 3B ativos da tabela (o Ornith-1.5-35B-A3B, o Qwen-AgentWorld-35B-A3B e o Nemotron Lightning) aparecem nos 84 tok/s. Do outro lado, o Qwen3.8-27B denso fica nos 9,1 e o Nanbeige4.3-33B, o mais lento da tabela, nos 7,6.
O segundo valor, depois de ler 128K de cache, é onde a coluna de KV e a coluna de velocidade se encontram. Lembra-te de que, a cada token, o motor tem de ler os pesos e também a cache inteira. Se a cache é grande, a velocidade cai à medida que a conversa cresce. No Nemotron Lightning, com a cache minúscula, a velocidade passa de 84 para 74 tok/s. No Nanbeige4.2-3B, com a cache de 22 GiB, passa de 60 para 16. No granite-4.2-8b, de 29 para 13.
Isto explica, de resto, um dos relatos que citei no outro post: a RTX 2060 a correr o Qwen3.6-35B-A3B a 23 tok/s com o contexto vazio e a cair para 15 com 90 mil tokens. Não era a máquina a aquecer nem azar. Era a cache a pesar em cada token. A Tiny League mostra-te esse efeito antes de o sentires.
Denso contra MoE. Again
Se juntares as duas colunas de custo ao tipo de arquitetura, aparece um padrão que já tinha aflorado no último post e que esta tabela torna difícil de esquecer.
Os modelos MoE (Mixture of Experts) têm muitos parâmetros no total mas usam poucos por token. O Ornith-1.5-35B-A3B tem 36B parâmetros, mas cada token só passa por 3B deles. Para a velocidade, conta o que é lido por token, e são esses 3B. Para a capacidade, contam os 36B, que têm de estar algures na memória.
Para o low end, isto é ouro, porque o “algures” pode ser a RAM do sistema. Foi exatamente o que vimos na RTX 2060 de 6 GB com 32 GB de DDR4: os pesos mais usados ficam na gráfica, os especialistas ficam na RAM, e como cada token só toca numa fração deles, a velocidade aguenta-se em valores perfeitamente usáveis. Na Tiny League há agora uma mão-cheia de modelos com esse perfil, com cerca de 3B ativos e 30B a 36B no total: o Ornith-1.5-35B-A3B, o Qwen-AgentWorld-35B-A3B, o Nemotron-3.5-Lightning-30B-A3B, o MiniCPM-V-4.7-35B-A3B. Todos candidatos naturais para quem tem uma gráfica pequena e RAM generosa.
Os modelos densos de 27B a 33B, como o Qwen3.8-27B e o Nanbeige4.3-33B, contam outra história. Aparecem bem nos benchmarks. Nas leituras que consegui fazer do heatmap, ambos andam à volta dos 89 pontos no GPQA Diamond, e o Nanbeige4.3-33B leva a medalha no Terminal-Bench 2.1. Mas pagam isso na velocidade e na memória. Um Qwen3.8-27B a 4 bits são uns 16,7 GB só de pesos. Numa gráfica de 24 GB cabe, mas com o contexto todo (8 GiB de cache) já não. Ficas pelos 64K tokens, ou quantizas a cache. Numa gráfica de 11 GB, nem pensar sem offload, e offload de um modelo denso para a RAM é muito mais doloroso do que de um MoE, porque cada token tem de ir buscar tudo.
Não quero com isto dizer que os MoE ganham sempre. Há tarefas onde um denso bem treinado de 9B ou 12B é melhor do que um MoE com 3B ativos, e o heatmap mostra isso em várias colunas. Mas, quando tens pouca VRAM e muita RAM, que é o perfil mais comum entre quem tem um PC de secretária com uns anos, os gráficos de dispersão da Tiny League tornam muito fácil ver onde estão os modelos que dão mais por cada GB por segundo que a tua memória consegue entregar.
Porque é que gosto de não haver um vencedor
Prometi voltar a isto.
Há sites de comparação que pegam em vinte benchmarks, fazem uma média ponderada qualquer e dão-te um número de 0 a 100. É confortável. Também é quase sempre enganador, porque a ponderação esconde decisões que não são tuas. Se o teu uso é etiquetar faturas digitalizadas, não te interessa nada que um modelo seja excelente no AIME 2026. Interessa-te o OCRBench, o OmniDocBench e talvez o IFBench, para ele respeitar o formato que lhe pedes.
A Tiny League não te dá esse número. Dá-te a grelha inteira e obriga-te a decidir o que conta. E toma duas decisões de desenho que acho muito honestas. Uma coluna só aparece se pelo menos dois modelos reportarem exatamente aquele benchmark, e as versões nunca se juntam: o Terminal-Bench 2.0 e o 2.1 são colunas diferentes, o AIME 2025 e o 2026 também. É precisamente a mistura que as tabelas de lançamento fazem às vezes, e aqui não passa.
O efeito colateral é que o heatmap tem muitos buracos. Cada modelo reporta os benchmarks que quer, e há modelos com cinco pontuações e outros com trinta. À primeira vista parece um defeito. Eu leio-o como informação. Quando um modelo que diz ser bom em agentes não reporta nenhum dos benchmarks de agentes que os concorrentes reportam, isso diz-te alguma coisa. Não necessariamente que é mau, mas que convém testar antes de acreditar.
Como eu usaria a tabela
No outro post deixei um método de sete passos para começar com o r/LowEndLocalAI, que acabava em “mede, e só depois compra”. A Tiny League encaixa entre esses passos como uma luva. Fica assim, na versão alargada:
- Faz o inventário da máquina: VRAM, RAM do sistema e, sobretudo, largura de banda. A ficha técnica da tua gráfica tem o valor em GB/s. Para a RAM, uma DDR4-3200 em dual channel anda pelos 51 GB/s, o que explica porque é que tudo o que sai da gráfica fica tão mais lento.
- Decide quanto contexto precisas de verdade: Uma conversa curta para reescrever emails vive bem com 8K. Resumir um relatório de 60 páginas pede 32K ou mais. Este número, multiplicado pela coluna KV, diz-te quanta memória vais gastar só em cache.
- Filtra a tabela pelo que cabe. Regra de bolso: a 4 bits, conta com 0,6 GB por cada bilião de parâmetros totais. Soma-lhe a cache para o teu contexto (KV @128K a dividir pela proporção do contexto que queres) e deixa um GB ou dois de margem. Se a gráfica não chega, olha para os MoE com poucos parâmetros ativos e pensa em offload para a RAM.
- Escolhe dois ou três benchmarks que se pareçam com a tua tarefa. IFBench e IFEval se precisas que siga instruções à letra. τ²-bench ou BFCL v4 para chamar ferramentas. LiveCodeBench ou SWE-bench Verified para código. OCRBench e OmniDocBench para documentos digitalizados. MRCR ou RULER se o contexto longo for a questão.
- Abre um gráfico de dispersão: Põe o benchmark que mais te interessa num eixo e a velocidade ou a KV no outro. Os candidatos estão na fronteira: os modelos para os quais não existe nenhum outro que seja melhor e mais barato ao mesmo tempo.
- Vai ao sub procurar uma máquina parecida com a tua a correr esse modelo: As estimativas da tabela dizem-te o que deveria acontecer. Os relatos do r/LowEndLocalAI dizem-te o que aconteceu.
- Mede tu: `llama-bench` para os números crus de processamento do prompt e de geração. Depois a tua tarefa real, com os teus dados, durante uns dias. Compara com a estimativa: se estiveres muito abaixo do teto teórico, há qualquer coisa mal configurada.
- Publica o resultado: Com a especificação completa, claro.
A mudança em relação ao método anterior é o passo 5. Antes, a escolha do modelo era feita a olho, pelo que estava na moda. Agora há onde ver os candidatos todos lado a lado, com custo e qualidade na mesma imagem. Continuas a precisar dos passos 6 e 7, porque uma estimativa não é uma medição. Mas chegas lá com dois ou três candidatos em vez de quinze.
Um exemplo, só para tornar isto concreto. Imagina o T5810 com o 1080 Ti do último post, com 11 GB de VRAM, 484 GB/s e a tarefa de resumir PDFs à noite com 32K de contexto. Pela tabela, o Ornith-1.5-9B (9,7B denso, 4 GiB de cache a 128K, logo cerca de 1 GiB a 32K) a 4 bits ocupa uns 5,8 GB de pesos mais 1 GiB de cache. Cabe com folga. O teto teórico ronda os 80 tok/s e, na prática, deves ver metade disso, o que bate com os 35 tok/s que aquele utilizador reportava para um 9B. O gemma-4-12B-it também cabe, como vimos. Entre os dois, vais ao heatmap ver quem se porta melhor nos benchmarks de documentos e de contexto longo que ambos reportam, e testas esses dois. Uma tarde, não um mês.
O que a tabela não te diz
No último post deixei uma secção inteira sobre o que o sub não te dá. Seria desonesto não fazer o mesmo aqui.
As pontuações vêm, tanto quanto percebo, do que os próprios laboratórios reportam nos lançamentos. A Tiny League organiza-as, alinha-as e filtra-as, mas não corre os benchmarks de raiz. Isto quer dizer que herda todos os problemas desses números: configurações de avaliação diferentes, prompts afinados para o teste, possível contaminação dos dados de treino com as perguntas dos benchmarks. Não é uma crítica ao site, que é transparente sobre o que faz. É uma limitação de quase todas as comparações deste género. Correr 95 benchmarks em 36 modelos de forma independente custava uma fortuna em computação.
Como já disse, os números referem-se aos pesos oficiais em precisão total. O GGUF que vais descarregar não é isso. Para a maior parte dos modelos, a 4 ou 5 bits, a perda é pequena. Para modelos muito pequenos, de 2B ou menos, e para quantizações agressivas, pode não ser. A tabela não te pode dizer quanto perdes; o sub, às vezes, pode.
As velocidades são estimativas de largura de banda numa máquina de referência. Não contam com o tempo de processar o prompt, que num PDF grande pode demorar mais do que a resposta toda. Não contam com o offload para a RAM, nem com a diferença entre CUDA, ROCm, Vulkan e Metal, que no low end é muitas vezes o limite mais duro. Usa-as para ordenar, não para prometer.
Olha para a coluna da licença. A maior parte dos modelos está em Apache 2.0 ou MIT, mas os LFM e os Nemotron aparecem como “Other”. Para brincar em casa não faz diferença. Se estiveres a pensar pôr aquilo a trabalhar num projeto de um cliente, lê a licença antes.
O critério de “pesos oficiais” protege a tabela, mas não te protege a ti. Quando fores descarregar a versão quantizada, vais descarregá-la de alguém. Repito o aviso do outro post: prefere quantizações de quem tem reputação a perder, e desconfia de “versões melhoradas” de origem desconhecida.
E, por fim, a fragilidade que mencionei no outro post a propósito do GPU Poor LLM Arena: as ferramentas da comunidade morrem. A Tiny League é, tanto quanto sei, um projeto de uma pessoa. As atualizações estão no changelog da página (a correção dos parâmetros ativos do Ornith-1.5-122B a 6 de novembro, a entrada do Nanbeige4.3-33B a 2 de novembro, o redesenho com a coluna de KV a 28 de outubro) e mostram um ritmo de manutenção que dá trabalho a sério. Se te for útil, diz ao autor. Se encontrares um erro, reporta. É assim que estas coisas se mantêm vivas.
Porque é que isto encaixa no caminho
No post anterior escrevi que a coisa que mais me importava no r/LowEndLocalAI era tirar a vergonha da equação. Mostrar que o portátil velho serve, que a gráfica de 2017 serve, que não é preciso gastar dois mil euros para começar.
Há uma segunda vergonha, mais silenciosa, que aparece depois. É a de não saber escolher. Abres o Hugging Face, vês duzentos modelos novos este mês, cada um com o seu gráfico de barras a dizer que é o melhor, e sentes que toda a gente percebe aquilo menos tu. Acabas por descarregar o que viste num vídeo, e se correr mal achas que o problema és tu ou a tua máquina.
A Tiny League não resolve tudo, mas tira-te muito desse ruído. Põe os modelos lado a lado com regras claras, não esconde os buracos e, acima de tudo, põe o custo ao lado da qualidade. Para quem tem uma 4090, as colunas de KV e de velocidade são uma curiosidade. Para nós, são a razão para abrir o site.
E isto liga-se a uma ideia que me é cara desde o início desta série de posts: soberania sobre os dados passa por saber correr modelos em casa, e saber correr modelos em casa passa por saber escolher. Se a única forma de escolher bem for comprar o melhor hardware e experimentar tudo, a IA local fica para quem tem dinheiro. Ferramentas como esta, feitas por alguém no seu tempo livre e abertas a toda a gente, puxam a balança para o outro lado.
Da última vez pedi-te que tirasses o portátil da gaveta. Desta vez o pedido é mais modesto: antes de abrires a carteira para uma gráfica nova, abre a Tiny League, mete a tua largura de banda e a tua VRAM na cabeça, e vê quantos modelos já cabem naquilo que tens. Aposto que são mais do que pensas. E se encontrares algum que a tabela diz que devia voar e na tua máquina rasteja, melhor ainda: tens assunto para o próximo post no sub.
Afinal, se um Game Boy tem um modelo lá dentro, o teu 1080 Ti merece pelo menos um gráfico de dispersão.
Até ao próximo post!
Nuno
—
Documentação:
O projeto
– https://tinyleague.nunodonato.com/ (Tiny League: tabela de benchmarks e custos de hardware para modelos open-weight pequenos)
– https://nunodonato.com/ (site do autor da Tiny League)
A comunidade
– https://www.reddit.com/r/LowEndLocalAI/ (o subreddit de que falei no post anterior, onde se encontram relatos de máquinas parecidas com a tua)
Ferramentas
– https://github.com/ggml-org/llama.cpp (llama.cpp, inclui o `llama-bench` para medir prompt e geração)
– https://lmstudio.ai/ (LM Studio, para quem está a começar)
– https://ollama.com/ (Ollama, para ter um serviço sempre ligado)
Posts anteriores referidos
– https://blog.nuneshiggs.com/uma-ps5-a-correr-um-modelo-de-27b-um-game-boy-com-um-llm-la-dentro-e-um-1080-ti-esquecido-num-proxmox-o-r-lowendlocalai-e-onde-se-aprende-o-que-a-tua-maquina-aguenta/ (a PS5, o Game Boy, o 1080 Ti e o r/LowEndLocalAI)
Disclamer: Sim…. foi feito com o auxilio de um LLM privado 🙂