2
gustavoulyssea
1 min de leitura ·

Giga-Token - provedor de LLM - Parte 2

Recentemente criei o primeiro post sobre o Giga-Token. O projeto Giga-Token é um provedor de LLM sem cobrança de uso por token com versão grátis para quem está começando.

O intuito do post de hoje é atualizar sobre o andamento do projeto e o que foi implementado baseado nos feedbacks do post.

Em primeiro lugar gostaria de agradecer a todos que testaram o serviço e deram feedback. Hoje já temos usuários constantemente ativos.

Novas implementações, novidades adicionadas ao projeto:

  • Adicionada opção de Chat no site onde o usuário pode testar direto pelo site o serviço antes de iniciar o processo de integração;
  • Adicionados novos modelos de LLM mais novos e com melhor velocidade e qualidade;
  • Preços corrigidos em dólar e real;
  • Mudanças na infra-estrutura para mitigar instabilidades de alguns modelos;
  • Adicionado relatório de uso do usuário com tokens e requests.

Quando ler este post, te convido para acessar o site do projeto e testar com a funcionalidade de chat e integrações com a API. O projeto dá acesso as LLMs em nível gratuito.

Link para o primeiro post: Giga-Token - provedor de LLM ilimitado - dicas para entrar no mercado

E aí o que você achou das atualizações ?

O que mais acredita que possa melhorar ?

Estamos no caminho certo ?

Muito obrigado!

Carregando publicação patrocinada...
1
1

Obrigado, Esmerio!

Muito orgulhoso de saber que já tem gente confiando no projeto!

Aos poucos estou aumentando o número e qualidade dos modelos disponíveis.

Use bastante, o volume de acessos me ajuda a medir o potencial da estrutura.

1

Tentei instalar no opencode hoje a tarde. E depois de bater muito a cabeça, o nome do modelo estava incorreto no exemplo de python. Mudei de "GLM4.5:106b" p "GLM4.7" e respondeu no script.

Mas sempre vem uma mensagem de erro gigante no opencode. Pesquisando com agents parece ter algum coisa a ver com um array retornando vazio. Parece que o Opencode espera as palavras picadas e o Giga-token retorna a resposta de outra forma.

Sou leigo, entao nao sei o que pode ser.

1
1

Testei com stream false e true. O Erro é recebido nas duas configurações no opencode.json

Pedi o deepseek para analisar o erro. De repente, te ajuda a encontrar onde o problema. Primeiro, vou colar o erro que recebo ao conversar com o Giga-token. E depois o que o deepseek falou (troquei de modelo).

Pergunta ao giga-token: você está online?

Resposta do giga-token:Sim, estou online e pronto para ajudar.

Abaixo da resposta do giga-token vem o erro:

Type validation failed: Value: {"id":"chat*cmpl-bea967ac305add26006cd6ee","object":"chat.completion.chunk","created":1782214846,"model":"glm-4.7","choices":[{"index":0,"delta":[],"finish_reason":"stop"}]}. Error message: [ { "code": "invalid_union", "errors": [ [ { "expected": "object", "code": "invalid_type", "path": [ "choices", 0, "delta" ], "message": "Invalid input: expected object, received array" } ], [ { "expected": "object", "code": "invalid_type", "path": [ "error" ], "message": "Invalid input: expected object, received undefined" } ] ], "path": [], "message": "Invalid input" } ]

Resposta do deepseek:

O problema está claro: a Giga Token está retornando a resposta streaming final com "delta": [] (array vazio) em vez de "delta": {} (objeto vazio), que é o formato OpenAI esperado.
Causa raiz:
No último chunk do streaming (finish_reason: "stop"), a API da Giga Token envia:
"delta": []
Mas o formato OpenAI-compatible espera:
"delta": {}
O validador do opencode rejeita o array e espera um objeto, daí o erro "Invalid input: expected object, received array".
Soluções possíveis:

  1. Reportar pra Giga Token — o bug está no lado deles, o delta final deveria ser {} e não [].
  2. Desabilitar streaming — se você não precisa de streaming, mude "stream": false (ou remova a linha) no opencode.json. (Edit meu: Testei e nao resolveu o problema)
  3. Aguardar fix do opencode — se o opencode tratar esse caso como tolerância a erro do provider."
1

Fiz mais algumas analises aqui e consegui contornar o erro usando um script. Mas no final, não deu pra usar com opencode pq o modelo não chama ferramentas. Mandei o deepseek fazer um resumo para tentar ajudar:

Contexto: Usando Open WebUI com provedor GigaToken (API: https://api.giga-token.com/rest/V1) modelo GLM-4.7. Criamos um proxy local para corrigir o formato do "delta":[] que a API retorna no lugar de "delta":{} nos chunks finais do streaming.
Regressão identificada: O function calling não funciona. O Open WebUI envia corretamente "tools" no body da requisição, mas o modelo/API ignora e responde apenas com texto simples (finish_reason:"stop"), sem nunca chamar as ferramentas disponíveis.
Exemplo concreto:

  • Prompt: leia o arquivo README.MD e ajude a planejar um ERP
  • Request 1 (sem tools, primeira chamada): resposta "Plano de implementação ERP" — sem tool call
  • Request 2 (com tools, retorno do resultado do ReadFile executado localmente): resposta "Lendo o arquivo README.MD..." — sem tool call também
    Evidência:
    [1] body received (2530 bytes, tools:undefined, tool_choice:auto, last_msg:user)
    [2] body received (33552 bytes, tools:true, tool_choice:true, last_msg:user)
    Ambas as respostas retornam apenas delta.content com texto, finish_reason:"stop". O modelo nunca retorna tool_calls no delta.
    Problemas adicionais:
  • Streaming retorna "delta":[] (array vazio) no último chunk — formato inválido, deveria ser "delta":{} (objeto vazio). Isso quebra validadores de schema no cliente.
  • Streaming demora ~20-25s para iniciar a resposta (TTFT alto).