Índice
Compressão de contexto determinística e segura para cache em agentes de codificação LLM: por que a desenvolvemos, como funciona e como se compara ao Headroom.
A cada passo que um agente de codificação dá, ele reenvia todo o seu histórico de trabalho para o modelo: cada apt-get Registros, todos os avisos do compilador, todas as barras de progresso. Em tarefas longas, o modelo relê a mesma saída de compilação dezenas de vezes, e você paga por cada leitura. OptScale Kompressor remove essa redundância em voo. Ele é executado dentro do OptScale AI e reescreve a saída da ferramenta gerada por máquina em um formato mais curto, totalmente rotulado e recuperável, sem afetar o agente, seus prompts ou seus resultados. Seu mecanismo é o projeto de código aberto compressor optscale: um único binário Rust determinístico.
Prefácio: por que construir o nosso próprio?
Altura interna é um compressor de contexto de código aberto (Apache 2.0) já estabelecido, e o OptScale Kompressor começou como uma adaptação de seus compressores algorítmicos. Então, por que não usar o Headroom? Porque A Headroom evoluiu de um compressor para uma plataforma, e nós precisávamos de um compressor.
O que a Headroom se tornou
Auditamos o Headroom v0.40.0 (branch principal, 10 de outubro de 2026) em comparação com o optscale-kompressor 0.13. As linhas brutas foram contadas da mesma forma para ambos os projetos, excluindo os testes.
| Contente | Formatos | O que o Kompressor faz |
|---|---|---|
| Construir e empacotar a saída | apartamento, dpkg, pip, npm, fazer, etapas de compilação e vinculação |
Dobra linhas repetidas em uma única linha mais [×N], com carimbos de data/hora, IDs e números normalizados |
| Registros | Registros e rastreamentos de pilha com carimbo de data/hora e marcação de nível. | Mesma estrutura; logs longos mantêm erros com contexto, primeiros avisos vistos, resumos e a cauda. |
| Diagnóstico do compilador | arquivo:linha:coluna: erro: de gcc/clang, TypeScript, Python |
Mantém todos os diagnósticos, descarta fontes repetidas e cursores quando menores. |
| Redesenhos do terminal | \r barras de progresso, medidores de download, loops de treinamento; fluxos de linha de modelo único |
Mantém apenas o último quadro; recolhe os fluxos de modelos. |
| JSON | Objetos e matrizes, incluindo conteúdo aninhado em strings. | Amostra matrizes longas, sempre mantendo erros, valores discrepantes e pontos de mudança. |
| Tabelas | CSV, TSV, Markdown | Exibe linhas, mantém o cabeçalho |
| Resultados da pesquisa | grep -n, ripgrep |
Agrupa por arquivo, mantém os arquivos principais e conta os demais. |
| Diferenças | Unificado e git diff |
Reduz os blocos às linhas ao redor de cada mudança. |
| Listagens e despejos | encontrar, ls -l, ps, df, docker ps; objdump, lerelf, nm, xxd |
Mantém uma amostra literal do início e do fim. |
| Código-fonte | Python, JavaScript, TypeScript, Go, Rust, Java, C#, C, C++ | Elimina corpos de funções longos, mantém as assinaturas; o resultado deve ser analisado novamente. |
| Configuração | YAML, TOML, INI | Remove comentários e linhas em branco; dobra blocos gerados repetidamente. |
| Misturado | Prosa com blocos embutidos | Comprime os blocos, deixando o texto em prosa idêntico em nível de byte. |
| HTML | Páginas da web e marcação | Detectado separadamente e dobrado como texto simples; sem extração de artigo. |
| Texto simples | Todo o resto | Dobra linhas duplicadas; os documentos nunca são dobrados seguindo o modelo. |
A compressão é uma das muitas tarefas do Headroom. O mesmo código-fonte é utilizado para a distribuição.
- memória do agente;
- um ciclo de aprendizagem que reescreve
CLAUDE.md; - modelagem de saída e um roteador modelo;
- um cache semântico e compressão de imagens;
- Rastreamento de assinaturas;
- Wrappers para 18 agentes de codificação e IDEs.
Essa abrangência é adequada para um otimizador de desktop personalizado para cada desenvolvedor. Não é o componente que precisávamos.
Por que isso importava
- Um componente, não uma plataforma. O Kompressor atende a várias equipes e agentes simultaneamente dentro do OptScale AI. O proxy de código aberto do Headroom é de usuário único: o estado reside em
~/.headroom, E a identidade só é aceita a partir do loopback. Centenas de configurações também teriam que ser fixadas e mantidas fixadas. - O determinismo decide o estoque, e o estoque decide a conta. A maior parte da entrada de um agente é cobrada como leituras de cache (seção 1). Se a mesma saída da ferramenta for comprimida de forma diferente na próxima interação, toda a conversa é precificada novamente. O Headroom envia a mensagem mais recente do usuário para seus compressores, e seu modelo de aprendizado de máquina é executado dentro de um limite de tempo, portanto, sua saída pode depender da pergunta e da carga da máquina. O nosso depende apenas da entrada: sem relógio, sem aleatoriedade, sem consulta.
- Elimine a redundância, não o significado. A sumarização apresenta ótimos resultados com a taxa de compressão. Quando adaptamos o compressor de prosa do Headroom, ele removeu mais 6,2 pontos, mas perdeu 12,9 pontos de detalhes que os agentes reutilizaram posteriormente. O Kompressor é baseado em regras, cada elisão é rotulada e recuperável, e seu comportamento pode ser auditado linha por linha.
- Um processo, um caminho. A compressão e a recuperação de dados coexistem em um único binário. O proxy injeta a ferramenta de recuperação e a executa por conta própria, de modo que nunca podem divergir quanto ao modo, locatário ou estado.
Mantivemos as melhores ideias do Headroom: compressão e recuperação, os compressores principais de JSON, log, busca e comparação, e suas descobertas sobre o Claude Code e o Codex por trás de um proxy. Removemos tudo que fazia a saída depender de algo além da entrada, e tudo que não fosse compressão.
Resumindo:
- Medido com base na nota real, tarefa por tarefa, no Terminal-Bench 2.1 com o desconto de cache de prompts incluído (configuração na seção 4).
- 22.7% custo menor do que sem compressão, 25% tokens de entrada a menos e nenhuma mudança significativa na taxa de resolução.
- Economia de aproximadamente 2 vezes em relação à Headroom. Com base nos mesmos parâmetros, o Headroom economizou 8,2% com suas configurações padrão e 11,6% em sua configuração mais agressiva. Em um confronto direto, o Kompressor é 15.8% mais barato e envia 24% tokens de entrada a menos. Sua taxa de resolução é estatisticamente a mesma (81,1% vs 81,6%).
- Compressão 2,8 vezes maior que o Headroom com o modelo ML ativado e 8,6 vezes maior sem ele. O Kompressor remove 62,8% de 34,2 milhões de caracteres da saída real da ferramenta, contra 22,6% e 7,3%, em cerca de 1/440 do tempo necessário para o modelo do Headroom. Todos os detalhes removidos permanecem recuperáveis.
- Melhor opção: Treinamento de aprendizado de máquina, compilações de código-fonte e pipelines de dados. 55–81% de saída da ferramenta são removidos e 26–37% são descontados da fatura.
- Pedidos menores: Solicitações acima de 200 mil tokens tornam-se 15 vezes mais raras, mantendo os agentes fora da janela de contexto.
O problema
Um agente de codificação executa um comando, lê a saída, pensa e executa o próximo, e a cada iteração envia toda a conversa de volta para o modelo. Três fatos se seguem:
- A maior parte da mensagem exibida é a saída da ferramenta. Corresponde a cerca de metade de todos os bytes de prompt em nossos rastreamentos. Quase todo o restante é raciocínio criptografado, que não pode ser comprimido.
- A saída da ferramenta é altamente redundante. As barras de progresso são redesenhadas, os gerenciadores de pacotes se repetem e os executores de teste imprimem linhas quase idênticas.
- O armazenamento em cache imediato altera a economia. Aproximadamente 93% de tokens de entrada são leituras de cache a um décimo do custo. Um compressor que corrompe o cache pode custar mais do que economiza.
Como funciona
agente → OptScale AI ──→ Kompressor ──→ provedor de modelo │ │ │ └─→ armazenamento de referência (temporário, por organização) │ └─ chamadas de modelo kompressor_retrieve(ref) → conteúdo original retornado
- Determinístico e baseado em regras. Sem chamadas de ML, sem chamadas de LLM. Mesma entrada, mesmos bytes, a cada iteração.
- Etiquetado e recuperável. Cada elisão se torna um marcador, como por exemplo...
[×37 ref:k_Qm9v…]ou[... 412 linhas de log omitidas [ref:k_…]; 3 ERROS, 1 AVISO]. O ID é um hash do conteúdo removido, e o modelo pode recuperá-lo em até uma hora. - Pior nunca, falha aberta. Um resultado que não seja menor é descartado, e qualquer erro envia a solicitação sem alterações.
- Somente saída da máquina. Mensagens do sistema, do desenvolvedor e do assistente, saídas com menos de ~512 caracteres e blocos que contêm pontos de interrupção de cache nunca são alterados.
- Pequeno e rápido. Um binário estático com cerca de 33 mil linhas de Rust, com um tempo de execução de aproximadamente 0,2 ms por KB de saída da ferramenta. Utiliza armazenamento SQLite e está disponível para Linux, macOS e contêineres.
A saída de cada ferramenta é classificada e enviada para um compressor desenvolvido especificamente para o seu formato:
| Contente | Formatos | O que o Kompressor faz |
|---|---|---|
| Construir e empacotar a saída | apt, dpkg, pip, npm, make, etapas de compilação e vinculação | Dobra linhas repetidas em uma única linha mais [×N], com carimbos de data/hora, IDs e números normalizados. |
| Registros | Registros e rastreamentos de pilha com carimbo de data/hora e marcação de nível. | Mesma estrutura; logs longos mantêm erros com contexto, primeiros avisos vistos, resumos e a cauda. |
| Diagnóstico do compilador | arquivo:linha:coluna: erro: de gcc/clang, TypeScript, Python | Mantém todos os diagnósticos, descarta fontes repetidas e cursores quando menores. |
| Redesenhos do terminal | Barras de progresso, medidores de download, loops de treinamento; fluxos de linha de modelo único | Mantém apenas o último quadro; recolhe os fluxos de modelos. |
| JSON | Objetos e matrizes, incluindo conteúdo aninhado em strings. | Amostra matrizes longas, sempre mantendo erros, valores discrepantes e pontos de mudança. |
| Tabelas | CSV, TSV, Markdown | Exibe linhas, mantém o cabeçalho |
| Resultados da pesquisa | grep -n, ripgrep | Agrupa por arquivo, mantém os arquivos principais e conta os demais. |
| Diferenças | Diferença unificada e git | Reduz os blocos às linhas ao redor de cada mudança. |
| Listagens e despejos | find, ls -l, ps, df, docker ps; objdump, readelf, nm, xxd | Mantém uma amostra literal do início e do fim. |
| Código-fonte | Python, JavaScript, TypeScript, Go, Rust, Java, C#, C, C++ | Elimina corpos de funções longos, mantém as assinaturas; o resultado deve ser analisado novamente. |
| Configuração | YAML, TOML, INI | Remove comentários e linhas em branco; dobra blocos gerados repetidamente. |
| Misturado | Prosa com blocos embutidos | Comprime os blocos, deixando o texto em prosa idêntico em nível de byte. |
| HTML | Páginas da web e marcação | Detectado separadamente e dobrado como texto simples; sem extração de artigo. |
| Texto simples | Todo o resto | Dobra linhas duplicadas; os documentos nunca são dobrados seguindo o modelo. |
O cavalo de batalha é desduplicação, não sumarizaçãoO modelo sempre mantém pelo menos uma instância real de cada linha distinta e sempre sabe o que foi removido e como recuperá-lo.
O que melhoramos em relação ao Headroom
O mecanismo do OptScale Kompressor foi desenvolvido a partir dos compressores algorítmicos do Headroom. As duas primeiras listas comparam as camadas determinísticas. A reprodução a seguir também avalia o Headroom com seu modelo de aprendizado de máquina ativado: detecção Magika e um modelo ModernBERT para texto simples e código. Optamos por não utilizar aprendizado de máquina.
Por que isso importava
As cinco primeiras linhas correspondem aos compressores da tabela na seção 2; as restantes são mecanismos novos.
| Contente | Efeito |
|---|---|
| Redesenhos do terminal | Um fluxo de treinamento de 30.807 caracteres tornou-se 274 caracteres. |
| Diagnóstico do compilador com fonte ecoada (o Headroom as lê como resultados do grep) | Em uma saída do gcc, 1.873 dos 2.334 caracteres eram ecos e acentos circunflexos. |
| Despejos binários e de desmontagem, endereços nunca normalizados | Uma linha de 880 lerelf A tabela ficou com cerca de 1.000 caracteres. |
| Fluxos de linha de modelo único | +2,3 pontos de cobertura |
Instala o pacote, todo Configurando ( ) linha mantida |
Um 27,6 mil apartamento O registro passou de 15% para 97% removido. |
Margens de números de linha (gato -n, sed -n, grep -n): números removidos, corpo comprimido pelo tipo, números recolocados |
33 cargas úteis foram removidas, passando de 0% para 54%. |
Enquadramento de arremesso de agente (Códice ID do bloco, Tempo na parede, código de saída): separado e reconectado literalmente |
Um resultado do Codex Python passou de 0% para 87% (removido). |
| Registros ou código dentro de strings JSON, comprimido pelo próprio compressor desse formato | — |
| recuperação à distância: recuperar um fragmento omitido por linhas, caracteres, ponteiro JSON ou grep | — |
Melhorado: coisas que ambos fazem
Embora ambos os mecanismos processem o mesmo conteúdo, o nosso vai além:
- Linhas repetidas, dobradas mesmo quando não são adjacentes;
- Texto simples, comprimido sem ML;
- cargas úteis mistas de prosa e dados;
- código-fonte truncado e em C/C++;
- Arquivos de configuração gerados.
O efeito medido pode ser visto na reprodução abaixo. O Kompressor também permanece independente de consultas e determinístico, verifica a saída de cada compressor de forma centralizada e estima os tokens com mais precisão.
Medido: o mesmo tráfego em ambos os casos, com e sem o ML da Headroom.
Reproduzimos as mesmas 6.255 saídas de ferramentas reais (34,2 milhões de caracteres) em três mecanismos diferentes, todos com as configurações padrão:
- optscale-kompressor 0.13;
- Altura livre de 0,40 com o modelo ML desligado;
- Headroom 0.40 com seu modelo de aprendizado de máquina ativado: detecção Magika mais seu modelo ModernBERT (a versão ONNX int8 de 274 MB), no ONNX Runtime.
| Tipo de conteúdo | Participação no tráfego | Compressor | Espaço livre, ML em | Espaço livre, ML desligado |
|---|---|---|---|---|
| Listagens e despejos | 27.8% | 81.8% | 22.6% | 7.0% |
| Texto simples | 25.3% | 41.0% | 20.6% | 5.2% |
| Saída e registros de compilação | 19.3% | 75.4% | 17.1% | 4.2% |
| Código-fonte | 13.8% | 35.0% | 31.9% | 0.0% |
| Resultados da pesquisa | 11.1% | 82.7% | 25.5% | 25.4% |
| Diferenças, configuração, HTML, JSON | 2.7% | 40.9% | 19.8% | 12.5% |
| Todas as saídas de ferramentas elegíveis | 100% | 62.8% | 22.6% | 7.3% |
| Tempo por KB de saída da ferramenta | 0,2 ms | 87 ms | 1,5 ms |
O modelo ML triplica a compressão do Headroom, e o Kompressor ainda remove 2,8 vezes mais, em cerca de 1/440 do tempo. O modelo da Headroom alcançou 5.273 das 6.255 saídas, mas comprimiu apenas 3.090 delas. Precisou de uma mediana de 0,3 s por saída e até 6,8 s, enquanto utilizava cerca de cinco núcleos. O código-fonte é o único tipo em que os dois se aproximam: 32% contra o nosso 35%.
O que o modelo faz. O modelo do Headroom mantém um subconjunto ordenado das palavras de entrada e descarta o restante, com um marcador de recuperação adicionado ao final. Espaços em branco e recuos desaparecem, e as linhas sem palavras mantidas são eliminadas. Alguns exemplos da reprodução:
| Entrada | Saída de ML com margem de segurança |
|---|---|
from __future__ import annotations / import asyncio / import functools |
anotações __future__ / assíncio / functools |
self.pre_approved = convite ou pré-aprovado |
auto.pré_aprovado ou |
43a020: andi $7, $3, 255 |
$7, $3, 255 |
O processo foi encerrado com o código 0. |
O processo foi encerrado com o código 0. |
Em Python, as importações perdem suas palavras-chave, as atribuições perdem seu lado direito e a desmontagem perde seus endereços e instruções. O Kompressor nunca reescreve uma linha que mantém. As linhas são mantidas literalmente ou substituídas por um marcador com rótulo.
Determinismo. Em novas execuções, tanto em modo ocioso quanto sob carga pesada da CPU, o modelo produziu resultados idênticos em nível de byte. No entanto, com o ONNX limitado a uma única thread, 3 das 400 saídas atingiram o limite de tempo de 20 segundos do Headroom e retornaram sem compressão. Portanto, a saída do Headroom ainda depende da velocidade da máquina. O Kompressor não possui limite de tempo a ser atingido.
Retenção dos dados que os agentes reutilizam. Para cada saída, extraímos os tokens concretos (caminhos de arquivos, identificadores, versões) que o agente utilizou em suas ações subsequentes. Em seguida, verificamos se cada token ainda estava visível no texto compactado:
| Compressor | Espaço livre, ML em | Espaço livre, ML desligado | |
|---|---|---|---|
| Caracteres removidos | 21,5 milhões | 7,7 milhões | 2,5 milhões |
| Tokens reutilizados ainda visíveis | 86.9% | 96.2% | 98.3% |
| Tokens reutilizados ocultos, removidos a cada milhão de caracteres | 34 | 28 | 39 |
| Tokens ocultos recuperáveis por meio de recuperação | 100% | 69% | 30% |
O Headroom exibe mais desses tokens em linha principalmente porque remove muito menos. Por caractere removido, os três mecanismos os ocultam em uma taxa semelhante. A diferença está no que acontece em seguida. Cada token que o Kompressor oculta fica dentro de um fragmento nomeado por uma referência em sua saída, a apenas uma recuperação de distância. Alguns dos tokens ocultos do Headroom são divididos por sua compactação de diretório sem perdas (./src/Makefile torna-se ./src/ e MakefileOs demais estão atrás do marcador de recuperação ou desapareceram.
Nossa visão sobre aprendizado de máquina no Headroom
Adicionar um modelo foi uma decisão sensata para o Headroom. Suas regras deixam a maior parte do tráfego do agente intacto: 7% removidos. O aprendizado de máquina (ML) é a maneira mais barata de lidar com o que as regras não processam. A reprodução mostra que funciona: o ML triplica a compressão do Headroom. Ele também encontra economias onde nossas regras param deliberadamente, removendo 28% do código-fonte e 12% do texto simples que o Kompressor deixa intactos. O modelo também é mais estável do que esperávamos: ocioso ou sob carga pesada, a mesma entrada produziu a mesma saída.
Ainda mantemos o aprendizado de máquina fora do caminho da requisição, por cinco motivos que derivam das mesmas medições:
- As regras deixam menos trabalho para o aprendizado de máquina. A maior parte do tráfego recuperado pelo modelo da Headroom é aquele que suas próprias regras deixam passar. Nossas regras, sozinhas, removem 62,81 TP3T do mesmo tráfego, contra 22,61 TP3T para as regras e o modelo da Headroom juntos. O aprendizado de máquina (ML) tem um impacto muito maior em uma base de 71 TP3T do que em uma de 631 TP3T.
- A latência afeta cada turno do agente. O custo computacional não é o problema: cerca de 4,3 horas de CPU para todos os 34,2 milhões de caracteres é pouco comparado à fatura do LLM. O problema é o tempo. O modelo adicionou uma mediana de 0,3 s por saída da ferramenta e até 6,8 s, quando utilizando cinco núcleos, e uma requisição geralmente carrega várias saídas. Nosso mecanismo leva 0,2 ms por KB. Com o tempo limite de 5 segundos do WebSocket do Codex, metade das saídas mais lentas foram cortadas e enviadas sem compressão.
- Um orçamento de tempo é uma fonte oculta de não determinismo. O modelo é determinístico, mas o orçamento de 20 segundos do Headroom não é. Em uma máquina mais lenta ou mais ocupada, uma saída que foi comprimida ontem passa pelo mesmo processo hoje, e o cache de prompts é recalculado. Cada requisição compartilha o orçamento, então a contenção torna isso mais provável em produção do que em nossa simulação.
- Eliminar palavras não é o mesmo que remover redundância. O modelo do Headroom mantém um subconjunto das palavras e acrescenta um único marcador no final. O modelo não consegue identificar onde as palavras desapareceram. A sintaxe também se perde: 2.241 das 2.441 saídas comprimidas com código indentado perderam toda a indentação. As atribuições perdem seus lados direitos e a própria linha de comando do agente, "Process exited with code 0" (Processo encerrado com código 0), torna-se "Process exited code 0" (Processo encerrado com código 0). Comparado apenas com as regras do Headroom, o modelo oculta 118 tokens a mais que os agentes reutilizam posteriormente. O Kompressor mantém cada linha exibida literalmente e marca cada elisão no local onde ocorreu.
Peso operacional. Enviar o modelo significa:
- um download de 274 MB em tempo de execução, ou agrupando-o;
- Um ambiente de execução ONNX por processo;
- um indicador de inicialização e uma fila de inferência;
- orçamentos de tempo e disjuntores, que são em si mesmos uma causa do ponto 3.
Isso explica grande parte do crescimento da plataforma descrito no prefácio.
Nossa conclusão não é "nunca mais usar aprendizado de máquina". Um modelo poderia ser implementado como uma opção opcional para processar os trechos de texto e código que nossas regras deixam intactos, a única área onde ele gera economia mensurável. Para isso, ele teria que atender aos mesmos critérios que o restante do mecanismo:
- Saída que não depende do tempo;
- Cada elisão indicava onde ela havia ocorrido;
- toda elisão recuperável;
- Uma frase mantida, jamais reescrita.
Os modelos de inserção de palavras atuais não atendem a nenhum desses requisitos, portanto, o mecanismo determinístico vem em primeiro lugar.
Onde a Headroom ainda faz mais
- HTML: O Headroom extrai o texto do artigo; nós incorporamos o HTML como texto.
- Lacunas que ainda não preenchemos:
- colapso do quadro de pilha;
pytestresumos;- Compactação CSV sem perdas;
- Uma gramática PHP;
- releituras com números de linha deslocados.
- O arquivo diz: O Headroom os protege por padrão. Nós os comprimimos, porque toda elisão é recuperável.
Como medimos
| Benchmark ao vivo | Terminal-Bench 2.1, 89 tarefas; Codex CLI em GPT-5.5 ($5.00 / $0.50 / $30.00 por M de tokens não armazenados em cache / armazenados em cache / de saída); Harbor, 3 testes simultâneos |
| Braços | Sem compressão · Margem livre, configurações padrão com seu modelo de aprendizado de máquina · Margem livre, configuração mais agressiva (recuperação desativada, tamanho mínimo de 120 tokens, no máximo 8 itens na matriz) · OptScale Kompressor via OptScale AI |
| Métrica | Custo e tokens cobrados pelo provedor por teste. |
| Análise | Médias por tarefa, comparadas entre os grupos ao longo das 87 tarefas concluídas por cada grupo; diferenças testadas quanto à significância estatística. As porcentagens por coorte e por tarefa são calculadas a partir de dados não arredondados, portanto, podem diferir em um ponto percentual dos valores recalculados a partir de valores de tabela arredondados. |
| Exclusões | Testes que falharam na configuração do agente por motivos externos (metadados do repositório de pacotes expirados, falha no download) e 7 testes do Kompressor afetados por um defeito conhecido de integração de streaming. |
| Repetição | 6.255 saídas de ferramentas com pelo menos 512 caracteres (34,2 milhões de caracteres) dos nossos rastreamentos do Terminal-Bench; optscale-kompressor 0.13 e Headroom 0.40 com seu modelo de aprendizado de máquina ativado e desativado. |
Cada economia feita aqui representa a diferença entre contas reais, com o desconto de cache incluído. Economias autodeclaradas, que precificam os tokens removidos à taxa de lista sem cache, não são utilizadas.
Antes de qualquer alteração nas naves Kompressor, o teste é repetido em dois conjuntos de dados. O primeiro consiste em nossos próprios rastreamentos do Terminal-Bench 2.1. O segundo é um conjunto separado de 715 milhões de caracteres de saída da ferramenta, proveniente de execuções públicas do Terminal-Bench 4.0, abrangendo dez combinações de agentes e modelos. Cada repetição verifica a cobertura, o determinismo, a estabilidade do cache e se os detalhes reutilizados pelos agentes são preservados.
Resultados
Todos os números se referem à execução completa das 87 tarefas concluídas por cada braço.
| Por execução completa | Sem compressão | Altura interna | Compressor |
|---|---|---|---|
| Custo | $107.89 | $99.04 | $83.40 |
| Tokens de entrada | 96,1 milhões | 95,5 milhões | 72,2 milhões |
| Tokens de entrada não armazenados em cache | 6,68 milhões | 5,16 milhões | 4,46 milhões |
| Tarefas resolvidas | 82.2% | 81.6% | 81.1% |
| Tempo médio de ensaio | 4,8 min | 5,3 min | 4,5 min |
O dobro da economia
| Sem compressão | Custo | Resolvido |
|---|---|---|
| Compressor | −22,7% | 81.1% |
| Espaço livre, configuração mais agressiva | −11,6% | 85.1% |
| Altura interna, padrão | −8.2% | 81.6% |
A economia do Kompressor é 2.0× A configuração mais agressiva do Headroom e 2.8× É o padrão. A economia de custos e tokens é estatisticamente significativa; as diferenças nas taxas de resolução, não.
Em confronto direto com a Headroom
| Compressor vs. Espaço Livre | Mudar |
|---|---|
| Custo | −15,8% |
| Tokens de entrada | −24,4% |
| Tokens de entrada não armazenados em cache | −13,6% |
| Taxa de resolução | −0,5 pt (81,1% vs 81,6%, não significativo) |
O Kompressor foi mais barato em 54 das 87 tarefas. A diferença concentra-se em tarefas longas e com grande volume de operações logarítmicas: treinamento de aprendizado de máquina, compilação cruzada e modelagem estatística. Em tarefas curtas, nenhuma das ferramentas apresenta grandes vantagens em termos de custo-benefício.
Por grupo de tarefas
| Coorte de tarefas | Saída da ferramenta por tarefa | Removido | Bill vs. sem compressão |
|---|---|---|---|
| Treinamento, amostragem e avaliação de aprendizado de máquina (17 tarefas) | 598 mil caracteres | 81% | −26% |
| Engenharia reversa e segurança (12) | 310 mil caracteres | 69% | −5% |
| Compilando software a partir do código-fonte (10) | 1.178 mil caracteres | 64% | −28% |
| Configuração de serviço e git (10) | 262 mil caracteres | 58% | −14% |
| Pipelines de dados e mídia (9) | 288 mil caracteres | 55% | −37% |
| Texto, documentos e sequências (7) | 120 mil caracteres | 51% | −23% |
| Algoritmos, matemática e quebra-cabeças (22) | 99 mil caracteres | 48% | −8% |
Aprendizado de máquina (ML), compilações de código-fonte e pipelines de dados geram 83% da economia total. O apêndice detalha cada grupo tarefa por tarefa. Eles geram a maior quantidade de resultados de ferramentas e têm o maior custo de execução. A compressão é mais fraca onde os resultados são pequenos (tarefas algorítmicas) e onde se trata de texto que não deve ser compactado.
pedidos menores
Um token em cache é barato, mas ainda assim é enviado e preenche a janela de contexto.
| Sem compressão | Altura interna | Compressor | |
|---|---|---|---|
| Mensagem enviada a cada execução. | 96,1 milhões de tokens · ~418 MB | 95,5 MB · ~415 MB | 72,2 MB · ~314 MB |
| solicitação do 90º percentil | 106,9 mil tokens · ~465 KB | 110,5 mil · ~481 KB | 66,5 mil · ~289 KB |
| Solicitações acima de 100 mil tokens | 11.2% | 12.0% | 3.2% |
| Solicitações acima de 200 mil tokens | 1.9% | 0.6% | 0.13% |
O tamanho estimado em bytes é de 4,35 bytes de JSON de requisição por token, medido em execuções sem compressão.
- Janela de contexto. Sem compressão, 1,9% de requisições passaram por 200K da janela de 258K do GPT-5.5, e duas tentativas tiveram que compactar seu contexto. Com o Kompressor, esse número foi de 0,13%, e apenas uma tentativa foi compactada.
- Contexto ideal em tarefas complexas.
mcmc-sampling-stanatingiu um pico de 60 mil tokens em vez de 165 mil;café-cifar-10por 68 mil em vez de 152 mil. - Sem cache de prompts. Nos casos em que um provedor ou nível de serviço não armazena dados em cache, o tráfego cortado no protocolo 25% é lançado diretamente na fatura.
Conclusão
Regras determinísticas, quando aplicadas corretamente, superam uma plataforma maior com um modelo de aprendizado de máquina. No Terminal-Bench 2.1, o OptScale Kompressor se destaca. 22,7% de desconto na conta real, cerca do dobro da economia da Headroom., sem nenhuma alteração mensurável no sucesso da tarefa. No mesmo tráfego, remove 2,8 vezes mais do que o Headroom com seu modelo de aprendizado de máquina, em uma fração do tempo, e cada detalhe removido permanece a apenas uma recuperação de distância. Seu maior benefício ocorre onde os agentes geram mais resultados de máquina: treinamento de aprendizado de máquina, compilação de código-fonte e pipelines de dados.
Experimente:
- Código aberto: executar optscale-kompressor como um único binário.
- Na OptScale AI: Ative o Kompressor no OptScale AI. e todos os agentes subsequentes começam a salvar a partir da próxima solicitação, sem alterações para o cliente.
Apêndice: resultados tarefa por tarefa
- Removido é a parcela ponderada pela faturação da saída elegível de cada tarefa, retirada na reprodução. Elegível significa saídas com pelo menos 512 caracteres.
- Altura interna Nessa coluna, o modelo de aprendizado de máquina foi executado com o programa ligado, assim como nas execuções ao vivo.
- Custo e Resolvido vêm das corridas ao vivo.
- Duas tarefas,
qemu-startupeqemu-alpino-ssh, falha na configuração do agente em todas as execuções compactadas e não são listadas.
Treinamento, amostragem e avaliação de aprendizado de máquina.
Removido 81% (Espaço livre 21%) · fatura −26% (Espaço livre +10%) · resolvido 84% (Espaço livre 84%, nenhum 88%). O grupo mais forte. Os loops de treinamento e os amostradores imprimem o progresso e as métricas aos milhares, e o custo por tentativa foi reduzido pela metade. mcmc-sampling-stan, café-cifar-10 e placar de líderes mteb. O valor discrepante é trem-texto rápidoA remoção do 96%, porém, resultou em um contexto mais barato que permitiu ao agente consultar uma longa sequência de treinamento por mais tempo. Mesmo assim, o custo foi muito menor do que com o Headroom.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
trem-texto rápido |
2.807 mil | 96% · 21% | $3.16 · $8.85 · $5.12 | 1/2 · 1/3 · 2/3 |
mcmc-sampling-stan |
2.089 mil | 74% · 17% | $3.69 · $3.19 · $1.15 | 2/2 · 2/3 · 3/3 |
café-cifar-10 |
1.727 mil | 72% · 20% | $4.79 · $3.04 · $2.30 | 2/2 · 3/3 · 3/3 |
placar de líderes mteb |
940 mil | 46% · 40% | $2.15 · $2.52 · $1.04 | 1/2 · 3/3 · 3/3 |
rstan-para-pystan |
585 mil | 64% · 24% | $1.37 · $1.47 · $1.08 | 2/2 · 3/3 · 3/3 |
amostrador de rejeição adaptativa |
512 mil | 71% · 21% | $1.22 · $0.80 · $0.84 | 2/2 · 3/3 · 3/3 |
llm-inferência-em-lotes-agendador |
241 mil | 50% · 30% | $0,68 · $0,76 · $0.66 | 2/2 · 3/3 · 1/2 |
sam-cell-seg |
203 mil | 37% · 34% | $1.13 · $0.77 · $0.83 | 2/2 · 3/3 · 3/3 |
pytorch-model-cli |
198 mil | 51% · 18% | $0,76 · $0,79 · $0.72 | 2/2 · 3/3 · 3/3 |
paralelismo de pipeline torch |
174 mil | 50% · 38% | $0,74 · $0,62 · $0.75 | 2/2 · 2/3 · 3/3 |
reshard-c4-dados |
168 mil | 75% · 19% | $0,99 · $0,88 · $1.00 | 2/2 · 3/3 · 3/3 |
contagem-de-tokens-do-conjunto-de-dados |
141 mil | 20% · 23% | $0,42 · $0,39 · $0.36 | 2/2 · 3/3 · 3/3 |
mteb-recuperar |
125 mil | 41% · 26% | $0,42 · $0,36 · $0.24 | 2/2 · 3/3 · 3/3 |
gpt2-codegolf |
125 mil | 42% · 8% | $2.43 · $1.96 · $1.26 | 1/2 · 2/3 · 2/3 |
recuperação de modelo pytorch |
63 mil | 62% · 9% | $0,44 · $0,41 · $0.43 | 1/2 · 0/3 · 0/3 |
paralelismo de tensores de tocha |
53 mil | 54% · 37% | $0,44 · $0,53 · $0.50 | 2/2 · 3/3 · 2/3 |
inferência de modelo hf |
20 mil | 6% · 21% | $0,47 · $0,40 · $0.44 | 2/2 · 3/3 · 2/3 |
Engenharia reversa e segurança
Removido 69% (Espaço livre 27%) · fatura −5% (Espaço livre −16%) · resolvido 76% (Espaço livre 86%, nenhum 83%). A desmontagem, as tabelas de símbolos e as listas de palavras são muito bem compactadas. Mas essas tarefas são curtas e baratas, então seu custo varia mais com o caminho percorrido pelo agente do que com o contexto. Este é o único grupo em que o Headroom se destacou claramente.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
rastreamento de caminho reverso |
1.032 mil | 76% · 35% | $1.34 · $1.49 · $1.54 | 2/2 · 3/3 · 2/3 |
corrigir-vulnerabilidade-de-código |
718 mil | 77% · 29% | $0,43 · $0,37 · $0.50 | 2/2 · 3/3 · 3/3 |
traçado de caminho |
687 mil | 66% · 21% | $3.30 · $0.95 · $2.22 | 2/2 · 3/3 · 3/3 |
crack-7z-hash |
563 mil | 69% · 19% | $0,76 · $1,16 · $1.35 | 2/2 · 3/3 · 3/3 |
segredo vulnerável |
157 mil | 59% · 25% | $0.19 · $0.21 · $0.39 | 2/2 · 3/3 · 3/3 |
extrato-elfo |
135 mil | 41% · 30% | $0,60 · $0,53 · $0.47 | 1/2 · 1/3 · 1/3 |
recuperação de senha |
119 mil | 38% · 10% | $0,41 · $0,28 · $0.52 | 2/2 · 3/3 · 3/3 |
filtro-quebra-js-de-html |
103 mil | 41% · 20% | $0,50 · $0,56 · $0.27 | 2/2 · 3/3 · 0/1 |
criptanálise feal-linear |
66 mil | 38% · 24% | $0,61 · $0,71 · $0.51 | 2/2 · 3/3 · 3/3 |
filtrar-js-de-html |
56 mil | 25% · 32% | $0,53 · $0,66 · $0.63 | 0/2 · 0/3 · 0/3 |
extração de modelo-relu-logits |
52 mil | 11% · 3% | $0,44 · $0,56 · $0.41 | 1/2 · 3/3 · 2/3 |
criptanálise diferencial feal |
34 mil | 27% · 18% | $0,56 · $0,68 · $0.40 | 2/2 · 3/3 · 3/3 |
Construindo software a partir do código-fonte
Removido 64% (Espaço livre 26%) · fatura −28% (Espaço livre −6%) · resolvido 80% (Espaço livre 83%, nenhum 80%). A ferramenta com maior volume de resultados de qualquer grupo, cerca de 1,2 milhão de caracteres por tarefa: instalações de pacotes, configurar verificações, linhas do compilador e diagnósticos. make-mips-interpreter, construir-pmars e construção-pov-ray O custo foi reduzido aproximadamente à metade. É aqui que a diferença para a Headroom fica mais evidente.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
make-doom-for-mips |
3.177 mil | 65% · 28% | $10.28 · $8.85 · $6.80 | 0/2 · 0/3 · 0/3 |
corrigir-ocaml-gc |
1.701 mil | 67% · 24% | $2.27 · $2.48 · $1.74 | 2/2 · 3/3 · 3/3 |
make-mips-interpreter |
1.538 mil | 69% · 34% | $2.75 · $4.17 · $1.42 | 0/2 · 2/3 · 1/3 |
compile-compcert |
1.483 mil | 62% · 22% | $3.74 · $2.81 · $3.18 | 2/2 · 3/3 · 3/3 |
construção-pov-ray |
925 mil | 64% · 22% | $1.95 · $1.33 · $0.98 | 2/2 · 2/3 · 3/3 |
build-cython-ext |
801K | 46% · 27% | $1.43 · $1.97 · $1.86 | 2/2 · 3/3 · 3/3 |
falha de heap de memória personalizada |
715 mil | 63% · 20% | $0,96 · $0,88 · $0.58 | 2/2 · 3/3 · 3/3 |
construir-pmars |
683 mil | 72% · 18% | $1.02 · $0.81 · $0.52 | 2/2 · 3/3 · 3/3 |
sqlite-com-gcov |
403 mil | 67% · 20% | $0,63 · $0,48 · $0.44 | 2/2 · 3/3 · 3/3 |
instalar-windows-3.11 |
357 mil | 38% · 8% | $1.97 · $1.65 · $2.03 | 2/2 · 3/3 · 2/3 |
Configuração de serviço e git
Removido 58% (Espaço livre 15%) · fatura −14% (Espaço livre 0%) · resolvido 69% (Espaço livre 60%, nenhum 85%). Instalações de serviços e varreduras de repositórios grandes são bem compactadas (sanitize-git-repo, 79%). Comandos git curtos e pequenas diferenças passam quase intactos, por design. kv-store-grpc e servidor pypi Falhou em todos os testes de compressão com ambas as ferramentas.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
sanitize-git-repo |
1.256 mil | 79% · 3% | $1.74 · $1.32 · $1.58 | 2/2 · 1/3 · 2/3 |
carteiro |
916 mil | 45% · 26% | $2.14 · $1.69 · $1.79 | 2/2 · 2/3 · 2/2 |
configure-git-webserver |
141 mil | 67% · 20% | $0,79 · $1,08 · $0.65 | 1/2 · 1/3 · 1/3 |
fix-git |
96 mil | 1% · 8% | $0,36 · $0,82 · $0.36 | 2/2 · 2/3 · 3/3 |
git-multibranch |
79 mil | 18% · 10% | $0.92 · $1.01 · $0.67 | 2/2 · 3/3 · 3/3 |
registro de solicitações do nginx |
67 mil | 28% · 4% | $0.31 · $0.35 · $0.26 | 2/2 · 3/3 · 3/3 |
kv-store-grpc |
34 mil | 12% · 21% | $0,48 · $0,36 · $0.31 | 1/2 · 0/3 · 0/3 |
servidor pypi |
20 mil | 20% · 9% | $0.31 · $0.39 · $0.32 | 1/2 · 0/3 · 0/3 |
recuperação de vazamento de git |
10 mil | 2% · 7% | $0.24 · $0.24 · $0.30 | 2/2 · 3/3 · 3/3 |
certificado autoassinado openssl |
4K | 4% · 0% | $0.10 · $0.13 · $0.08 | 2/2 · 3/3 · 3/3 |
Pipelines de dados e mídia
Removido 55% (Espaço livre 15%) · fatura −37% (Espaço livre −38%) · resolvido 78% (Espaço livre 81%, nenhum 72%). Ambas as ferramentas reduziram a conta em valores semelhantes; o Headroom apresentou uma ligeira vantagem em termos de custo e resolveu um número ligeiramente maior de problemas. A maior parte da economia se deve a... extrair-movimentos-de-vídeo, onde ambos os agentes seguiram um caminho muito mais barato do que o não comprimido. Onde o conteúdo decide, o Kompressor sai na frente: processador de documentos financeiros caiu de $1,23 para $0,37 por tentativa.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
extrair-movimentos-de-vídeo |
1.012 mil | 59% · 14% | $10.83 · $4.75 · $5.89 | 2/2 · 3/3 · 3/3 |
recuperação de db-wal |
650 mil | 48% · 20% | $0,96 · $1,45 · $1.21 | 0/2 · 1/3 · 1/3 |
processador de documentos financeiros |
351 mil | 54% · 20% | $1.23 · $1.32 · $0.37 | 1/2 · 3/3 · 3/3 |
sparql-universidade |
260 mil | 36% · 34% | $0,67 · $0,39 · $0.68 | 2/2 · 3/3 · 3/3 |
processamento de vídeo |
194 mil | 55% · 3% | $1.79 · $1.26 · $1.23 | 0/2 · 0/3 · 0/3 |
otimização de consulta |
76 mil | 9% · 4% | $1.10 · $0.81 · $0.78 | 2/2 · 3/3 · 2/3 |
intervalos de datas de resumo de logs |
22 mil | 77% · 39% | $0.15 · $0.14 · $0.11 | 2/2 · 3/3 · 3/3 |
sqlite-db-truncar |
20 mil | 7% · 12% | $0.19 · $0.20 · $0.23 | 2/2 · 3/3 · 3/3 |
fusão de dados de múltiplas fontes |
10 mil | 17% · 17% | $0.18 · $0.20 · $0.22 | 2/2 · 3/3 · 3/3 |
Texto, documentos e sequências
Removido 51% (Espaço livre 32%) · fatura −23% (Espaço livre +3%) · resolvido 62% (Espaço livre 57%, nenhum 43%). Documentos gerados por máquina são bem compactados: código G em gcode-para-texto (76%) e arquivos de estrutura de proteína em montagem de proteínas (61%). A prosa não faz isso, por definição: LaTeX em caixa-h cheia é 18%. Em montagem de DNA, A altura interna se comprime mais do que nós.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
montagem de proteínas |
297 mil | 61% · 27% | $1.17 · $1.42 · $1.26 | 0/2 · 2/3 · 2/3 |
caixa-h cheia |
161 mil | 18% · 16% | $0,58 · $0,74 · $0.48 | 1/2 · 3/3 · 1/3 |
montagem de DNA |
156 mil | 37% · 58% | $1.23 · $1.20 · $0.94 | 1/2 · 0/3 · 3/3 |
gcode-para-texto |
128 mil | 76% · 28% | $1.30 · $1.55 · $0.75 | 0/2 · 1/3 · 1/3 |
inserção de dna |
93 mil | 53% · 48% | $0,53 · $0,44 · $0.41 | 0/2 · 0/3 · 0/3 |
edição de texto em grande escala |
3 mil | 0% · 6% | $0,72 · $0,46 · $0.49 | 2/2 · 3/3 · 3/3 |
registro de regex |
<1K | — · — | $0.34 · $0.21 · $0.22 | 2/2 · 3/3 · 3/3 |
Algoritmos, matemática e quebra-cabeças
Removido 48% (Espaço livre 25%) · fatura −8% (Espaço livre −11%) · resolvido 95% (Espaço livre 94%, nenhum 93%). Principalmente raciocínio, com resultados pequenos: a mediana é de 270 caracteres, abaixo do limite de compressão. O custo total da análise para toda a coorte é de aproximadamente $15 por execução, portanto, há pouca economia a ser feita, e os resultados das duas ferramentas ficam dentro de uma margem de erro semelhante.
| Tarefa | Saída da ferramenta | Removido: Compressor · Espaço livre | Custo por teste: nenhum · Espaço livre · Compressor | Resolvido: nenhum · Espaço livre · Compressor |
|---|---|---|---|---|
avaliação metacircular semelhante a esquema |
485 mil | 65% · 31% | $1.29 · $1.18 · $1.37 | 2/2 · 3/3 · 3/3 |
guerras-núcleo-média-vencedoras |
338 mil | 37% · 24% | $1.45 · $1.84 · $1.14 | 2/2 · 3/3 · 3/3 |
tarefa merge-diff-arc-agi |
156 mil | 55% · 14% | $0.84 · $0.81 · $0.69 | 2/2 · 3/3 · 3/3 |
sintonia-mjcf |
151 mil | 20% · 18% | $1.12 · $0.93 · $0.47 | 2/2 · 3/3 · 3/3 |
cobol-modernização |
140 mil | 45% · 35% | $0,99 · $0,72 · $1.20 | 2/2 · 3/3 · 3/3 |
otimização de portfólio |
136 mil | 53% · 28% | $0,43 · $0,49 · $0.36 | 2/2 · 3/3 · 3/3 |
encaixe raman |
132 mil | 46% · 6% | $1.72 · $0.71 · $1.44 | 0/2 · 0/3 · 0/3 |
xadrez-regex |
130 mil | 28% · 30% | $2.31 · $1.33 · $2.04 | 1/2 · 2/3 · 2/2 |
circuito-fibsqrt |
104 mil | 60% · 41% | $0,81 · $0,78 · $0.90 | 2/2 · 3/3 · 1/1 |
maior autovalor |
81 mil | 36% · 18% | $0,70 · $0,94 · $0.84 | 2/2 · 3/3 · 3/3 |
compressor de escrita |
65 mil | 23% · 8% | $0,74 · $0,72 · $0.53 | 2/2 · 3/3 · 3/3 |
melhor-movimento-no-xadrez |
52 mil | 66% · 66% | $0.36 · $0.31 · $0.36 | 2/2 · 3/3 · 3/3 |
terminal sem cabeça |
46 mil | 73% · 30% | $0,42 · $0,37 · $0.45 | 2/2 · 3/3 · 3/3 |
modernizar-pilha-científica |
40 mil | 50% · 26% | $0.18 · $0.21 · $0.16 | 2/2 · 3/3 · 3/3 |
bn-fit-modify |
35 mil | 6% · 23% | $0.29 · $0.34 · $0.35 | 2/2 · 3/3 · 3/3 |
agendamento de restrições |
25 mil | 52% · 0% | $0.16 · $0.16 · $0.15 | 2/2 · 3/3 · 3/3 |
pesquisa de distribuição |
23 mil | 42% · 3% | $0.20 · $0.27 · $0.24 | 2/2 · 3/3 · 3/3 |
poliglota-ferrugem-c |
15 mil | 36% · 32% | $0,71 · $0,52 · $0.72 | 2/2 · 3/3 · 3/3 |
poliglota-c-py |
7 mil | 35% · 16% | $0,48 · $0,69 · $0.48 | 2/2 · 3/3 · 3/3 |
cancelar-tarefas-assíncronas |
5 mil | 76% · 22% | $0.16 · $0.23 · $0.20 | 2/2 · 3/3 · 3/3 |
código-a-imagem |
2K | 0% · 0% | $0.13 · $0.13 · $0.12 | 2/2 · 3/3 · 3/3 |
prove-mais-com |
1K | 0% · 2% | $0.09 · $0.09 · $0.12 | 2/2 · 3/3 · 3/3 |
Perguntas frequentes
Precisamos alterar nossos agentes, prompts ou código para usar o Kompressor?
Não. O Kompressor funciona em linha dentro do gateway de IA da OptScale como um proxy — você direciona seus agentes para o gateway e a compressão é aplicada a cada solicitação automaticamente, sem afetar o agente, seus prompts ou seus resultados. Não há migração de SDK nem instrumentação por agente, e adiciona cerca de 0,2 ms por KB de saída da ferramenta.
A compressão afetará o cache de prompts ou fará com que uma solicitação custe mais tempo?
Não. O Kompressor é determinístico: a mesma saída da ferramenta é comprimida para os mesmos bytes a cada iteração, sem relógio, aleatoriedade ou dependência da pergunta do usuário, portanto as leituras do cache do provedor — cerca de 93% de tokens de entrada, cobradas a aproximadamente um décimo do preço — permanecem válidas. Ele também falha aberto, então qualquer resultado que não seja menor é descartado e qualquer erro passa a solicitação sem alterações.
Será que o Kompressor pode remover algo que o modelo realmente precise?
O sistema remove duplicatas em vez de resumir, de modo que o modelo mantém pelo menos uma cópia real de cada linha distinta, e cada elisão é rotulada e recuperável — o modelo pode recuperar o original por até uma hora através de uma chamada de recuperação executada pelo gateway. Ele só interage com a saída da ferramenta gerada por máquina em cerca de 512 caracteres, nunca com mensagens do sistema, do desenvolvedor ou do assistente. No teste de desempenho, a taxa de resolução permaneceu estatisticamente inalterada (81,1% versus 82,2% sem compressão).
Quais cargas de trabalho se beneficiam mais com o Kompressor?
A economia depende da carga de trabalho. Os maiores ganhos são obtidos no treinamento de aprendizado de máquina, em compilações a partir do código-fonte e em pipelines de dados, onde são removidos de 55 a 811 TP3T de saída das ferramentas, reduzindo os custos em aproximadamente um quarto a um terço. Tarefas curtas e que exigem muito raciocínio, assim como textos simples, têm pouco a ser removido por definição, portanto, espere pouca economia nesses casos.
Como podemos confirmar a economia em nosso próprio tráfego?
Cada valor de referência representa a diferença entre as faturas reais do provedor, já com o desconto de cache incluído, e não os tokens precificados na tarifa de lista sem cache. No seu próprio tráfego, você pode reservar uma parcela como grupo de controle não formatado e comparar os tokens faturados lado a lado, rotulados como medidos versus estimados. Quando um provedor ou plano não utiliza cache, a redução de aproximadamente 25% no tráfego imediato é lançada diretamente na fatura.