Cloudflare Clef vs Jev: testei o Q4_K_M localmente no Ollama

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Cloudflare Clef vs Jev: I Tested Q4_K_M Locally in Ollama · Canal: Prompt Engineer 48 · 13:02 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos locais e open source, Modelos multimodais

Resumo

O vídeo testa o pacote quantizado Q4_K_M de Cloudflare Clef em um laptop com GPU RTX 4060 de 8 GB, usando Ollama para uma solicitação de suporte e uma imagem. O modelo carregou localmente e gerou respostas em JSON válido quando recebeu um schema, mas duas solicitações repetidas sobre uma interrupção tiveram equipes diferentes como resultado. A análise dos arquivos e do caminho de execução indica que o teste não carregou o joint schema head oficial nem produziu as probabilidades nativas das opções. A comparação com Jev usa avaliações publicadas por Cloudflare, não testes feitos no laptop. A conclusão é que o experimento local é promissor, mas não reproduz por completo o decision model oficial.

Pontos-chave

O teste foi feito com o pacote Q4_K_M de Clef Flash no Ollama, em um laptop com GPU RTX 4060 e 8 GB de VRAM.
Uma solicitação para retornar JSON no prompt produziu uma resposta inválida; o uso de um schema JSON no runtime gerou uma saída válida.
Duas solicitações repetidas sobre uma interrupção retornaram equipes diferentes, apesar de usarem temperatura zero e os mesmos campos permitidos.
Na solicitação sobre uma fatura, o modelo selecionou billing, marcou urgência como falsa e atribuiu gravidade minor.
Em uma imagem estática, o modelo identificou um sinal de paz e indicou que a pessoa não segurava uma bebida.
O teste local gerou respostas estruturadas, mas não carregou o joint schema head oficial usado para pontuar as opções permitidas.
Os tempos e resultados locais não devem ser comparados diretamente com os dados hospedados publicados, pois hardware e caminhos de inferência diferem.
Os resultados publicados de Clef Flash e Jev variam conforme a tarefa; nenhum deles vence em todos os benchmarks mencionados.

Capítulos

Início	Capítulo	Resumo
00:00	O que é um decision model	O vídeo apresenta a ideia de escolher valores estruturados e explica que formato válido não garante uma decisão correta.
03:05	Configuração local e teste de suporte	O modelo quantizado é executado no Ollama e testado com solicitações de suporte, incluindo JSON inválido, saída com schema e resultados inconsistentes.
07:16	Teste com imagem e limite do caminho de inferência	O modelo identifica um gesto em uma imagem estática, mas a análise dos arquivos indica que o teste não usou o joint schema head oficial.
09:53	Comparação com Jev e avaliações publicadas	O vídeo compara resultados publicados de Clef Flash e Jev e ressalta que eles não medem o pacote quantizado executado localmente.
11:28	Veredito e recomendações	O pacote funciona no laptop, mas o teste não reproduz a experiência completa do decision model da Cloudflare.

Citações

Um espaço de respostas restrito ajuda na integração, mas não torna a decisão automaticamente correta. — 01:33

Uma solicitação repetida sobre a interrupção retornou billing em vez de technical. — 06:13

Não devemos chamar nossas respostas geradas de saída nativa de probabilidades. — 09:21

Esse teste no Ollama não executou o decision head oficial. — 12:31

Conceitos e entidades

decision model (conceito): Modelo que escolhe entre opções definidas por um schema e pode fornecer probabilidades para essas opções.
schema (conceito): Conjunto de campos e valores permitidos que define a estrutura das decisões esperadas.
quantization (conceito): Técnica aplicada à versão testada para reduzir o tamanho do modelo e permitir sua execução local.
Cloudflare (empresa): Empresa que lançou a família Clef e publicou as avaliações comparadas no vídeo.
Clef (modelo): Família de decision models da Cloudflare, incluindo a versão menor testada localmente.
Clef Flash (modelo): Modelo da Cloudflare cuja versão quantizada foi testada no Ollama.
Jev (modelo): Modelo apresentado pela Typesafe e usado como referência na comparação com resultados publicados.
Ollama (ferramenta): Runtime usado para carregar o pacote quantizado e enviar solicitações ao modelo local.
joint schema head (conceito): Componente separado da arquitetura oficial que pontua as opções permitidas pelo schema.
Bartowski (pessoa): Nome associado ao pacote de quantização instalado para o teste local.
RTX 4060 (ferramenta): GPU do laptop usado no teste, com 8 GB de memória de vídeo.

Tradução completa (pt-BR)

00:00 A Cloudflare lançou o KFFT, uma família de decision models. Eu queria responder a uma pergunta prática: dá para pegar a versão pequena, colocá-la em um Llama em um laptop comum e realmente usá-la? Foi isso que testei. Hoje, são apenas duas demonstrações: uma solicitação de suporte e uma imagem. E há uma surpresa importante nos resultados. Carregar os pesos é só parte da história. Vamos manter o foco. Primeiro, o que torna um decision model útil? Depois, a configuração local, as duas demonstrações e uma comparação com o

00:31 modelo original Jev, da Typesafe. O objetivo é entender o que você pode executar hoje e o que os resultados realmente significam. Não há aqui uma enorme coleção de exemplos. Vamos dedicar tempo a analisar cuidadosamente os poucos exemplos que realmente executamos. Imagine que seu aplicativo recebe um chamado de suporte. Alguém precisa decidir qual equipe vai atendê-lo e se ele exige atenção. Uma resposta normal em linguagem natural fornece um parágrafo. Seu aplicativo precisa de um valor, algo como técnico, cobrança ou vendas. Um decision model é feito para esse tipo de situação. Você fornece as

01:02 informações e define as respostas disponíveis antes que o modelo tome sua decisão. O esquema é simplesmente o menu de decisões. Uma pergunta pode ter como resposta sim ou não. Outra seleciona um departamento. Uma terceira escolhe um nível de gravidade em uma escala ordenada. Isso facilita a integração da saída a um software comum. O aplicativo ao redor sabe o que cada campo significa. Ele pode encaminhar o chamado, gerar uma notificação ou deixá-lo em uma fila sem tentar interpretar uma explicação longa. Há outro componente útil:

01:33 as probabilidades entre as opções permitidas. Pense em uma mensagem que poderia ser sobre cobrança ou suporte técnico. Em vez de forçar todas as situações a receberem uma resposta confiante, um aplicativo pode usar a incerteza para decidir quando uma pessoa deve assumir o caso. O limiar é uma escolha do aplicativo. Ainda é necessário usar exemplos e evals para encontrar um limiar que faça sentido para seus clientes. Um espaço de respostas restrito ajuda na integração, mas não torna a decisão automaticamente correta. Cobrança é um departamento válido, mesmo quando a mensagem

02:03 deveria ter sido encaminhada ao suporte técnico. Essa distinção fica muito evidente em nosso teste local. Ao acompanhar, mantenha duas perguntas separadas: a saída seguiu o formato? E a resposta selecionada fez sentido? Passar na primeira pergunta não resolve a segunda. O modelo original Jev é a comparação aqui. A Typesafe o apresentou como um modelo System 1, com estado não estruturado como entrada e decisões probabilísticas tipadas como saída. É uma referência útil para entender essa categoria. A comparação neste vídeo

02:35 usa o anúncio original e os resultados de avaliação publicados. Não fiz uma solicitação ao vivo ao Jev neste laptop. Embora eu não tenha medições de tempo de uma execução própria do Jev para mostrar, o lançamento menor da Cloudflare é o Clef. O model card descreve um backbone de 9 bilhões de parâmetros com entradas visuais, além de uma cabeça separada de esquema conjunto que pontua as decisões. Os pesos estão disponíveis sob a licença Apache 2.0. Essa combinação torna interessante fazer experimentos localmente. Podemos inspecionar o lançamento e testar uma versão quantizada,

03:05 em vez de apenas ler sobre uma API por trás de um serviço hospedado. Aqui está a máquina usada neste vídeo: um laptop com GPU Nvidia RTX 4060 e 8 GB de memória de vídeo. Ollama versão 0.35.0. O modelo instalado é Bartowski Cleft Flash Quantization Q4_K_M. Ele já estava instalado quando comecei o teste. Portanto, estas são verificações de inference. Não estou apresentando o download como algo que aconteceu durante esta gravação. O cartão de quantização lista o arquivo do backbone

03:36 com cerca de 5,84 GB. O Llama mostra cerca de 6,8 GB para o pacote instalado, que também inclui o projetor visual. São medidas de tamanho diferentes. Durante o teste, o Llama informou uma combinação de execução em CPU e GPU, com cerca de 87% na GPU. É uma execução em laptop, com um context window modesto, não a configuração hospedada publicada. O caminho local básico é simples: selecione o repositório do Hugging Face e a tag Q4_K_M pelo Ollama.

04:07 Nossas solicitações são então enviadas ao endpoint local do Ollama. Para estes testes, usei um context window de 48 tokens e um limite curto de saída. Essas configurações mantêm este experimento pequeno. Elas não testam um context window longo e não nos dizem como uma carga de produção grande se comportaria. A boa notícia é que o modelo carregou e respondeu. Temos uma saída real da máquina local. Isso já é útil se você quiser saber se o pacote quantizado consegue rodar neste hardware. Mas um carregamento bem-sucedido, por si só, não nos diz se o Ollama está

04:39 executando o mesmo mecanismo de decisão usado pela Cloudflare. Para descobrir, precisamos analisar tanto a saída quanto os arquivos do lançamento. Nossa primeira demonstração é uma solicitação curta de suporte: “O checkout está falhando para todos os clientes há uma hora”. Pedimos três campos: urgência, equipe e gravidade. Nesse menu simples, a equipe pretendida é a técnica, porque estamos descrevendo uma falha generalizada do serviço. Crítica é um nível de impacto razoável, e a urgência deve ser verdadeira. A entrada é deliberadamente curta para que possamos inspecionar a resposta sem nos escondermos atrás de

05:11 um prompt enorme. Na primeira solicitação, pedimos JSON no prompt. Aqui está a saída real. O modelo disse que a urgência era verdadeira e mencionou técnico e crítico, mas a string não era JSON válido. Algumas chaves e valores não tinham a estrutura necessária. Isso é uma falha real para um software que espera um objeto JSON. A solicitação a frio levou cerca de 18 segundos dentro do Ollama, a maior parte do tempo para carregar o modelo. Em seguida, forneci um esquema JSON de verdade pelo Ollama. Em vez de

05:41 depender apenas das palavras “retorne JSON”, o esquema define urgência como um booleano e fornece um conjunto fixo de strings permitidas para equipe e gravidade. A saída resultante foi interpretada corretamente. Isso é uma melhoria importante para um aplicativo com Ollama. Mostra o benefício de restringir o formato no nível do runtime. Ainda resta a questão da qualidade da decisão. A primeira solicitação de falha, com restrição de esquema, retornou equipe técnica, urgência verdadeira e gravidade crítica. Um Llama informou cerca de 2,27 segundos para essa solicitação aquecida.

06:13 Essa é uma resposta plausível para o exemplo. Se essa fosse a única saída que mostrássemos, pareceria um sucesso bem claro. Mas houve outro resultado na mesma série de demonstrações, e isso muda o grau de confiança com que devemos descrever o experimento. Uma solicitação repetida sobre a falha, ainda com temperatura zero e os mesmos campos permitidos, retornou cobrança em vez de técnico. Manteve a urgência verdadeira e a gravidade crítica. O tempo de relógio foi de cerca de 1,96 segundo. Estou mantendo os dois resultados no vídeo. Como este é um pequeno experimento local, não podemos diagnosticar a causa com base em uma única

06:44 repetição. O que podemos dizer é que esse caminho testado não produziu uma seleção estável de equipe. Para testar o outro lado da mesma demonstração de encaminhamento, usei uma solicitação comum sobre uma fatura: “Por favor, envie uma cópia da minha fatura por e-mail. Não houve falha nem disputa de pagamento. Posso esperar até a próxima semana”. A resposta foi cobrança, urgência falsa e gravidade baixa. O tempo de relógio foi de cerca de 1,55 segundo. Essa resposta combina bem com a entrada. Portanto, temos um sucesso claro e um caso em que as saídas repetidas divergiram. A demonstração de suporte

07:16 nos diz algo bem específico. O pacote quantizado consegue responder localmente, e o Ollama consegue restringir a resposta gerada a um JSON válido. Também mostra por que uma boa captura de tela não basta para julgar a confiabilidade. Um aplicativo que encaminha automaticamente cada chamado deve ser avaliado com um conjunto significativo de exemplos. Nossas duas entradas ilustram o comportamento; não são um benchmark de precisão do KF ou do Jev. Para a segunda demonstração, usei a imagem da webcam visível na captura de tela fornecida. Recortei a imagem incorporada para que o modelo

07:47 visse o gesto da mão em vez da área de trabalho inteira. Este é um teste com imagem estática. Não gravei uma transmissão ao vivo da webcam. A pergunta é simples: qual gesto com a mão está visível e a pessoa está segurando uma bebida? Os gestos permitidos são definidos antes da solicitação. As solicitações com imagem retornaram “sinal de paz” e “segurando bebida: falso”. Observando a entrada, essas respostas fazem sentido. Dois dedos estendidos estão visíveis, e não há bebida na mão. O tempo de relógio foi de cerca de 1,35 segundo para a

08:18 solicitação. Mais uma vez, trata-se de uma resposta JSON gerada pelo Ollama. É uma evidência útil de que esse pacote aceita imagens, mas é apenas uma foto. O repositório de webcam vinculado demonstra um caminho de execução diferente. Ele usa o lançamento original e seu código de inference de referência para produzir decisões tipadas com probabilidades a partir de quadros da webcam. O início rápido documentado tem como alvo um Mac com Apple Silicon e pelo menos 32 GB de memória. Nosso experimento com Ollama no Windows usa um pacote quantizado. O repositório é uma referência útil, mas não executei

08:50 a configuração para Mac nesse laptop. Agora chegamos ao detalhe importante. O lançamento oficial lista arquivos separados para uma joint schema head. O loader de referência carrega explicitamente essa head junto com o backbone. Ele usa a head para pontuar as opções permitidas. Verifiquei nosso arquivo de quantização local e os tensores listados nele. O arquivo inspecionado continha os tensores usuais do backbone, e não encontrei nenhuma joint schema head separada sendo carregada pelas requisições que enviamos. Os logs das requisições deixam essa distinção ainda mais clara. O Ollama

09:21 informa os tokens de saída gerados para essas respostas. A resposta de imagem com restrições usou 21 tokens de saída. As respostas de suporte usaram cerca de 30. Essas são strings geradas que analisamos como JSON. A interface oficial de decisão pontua opções de schema por meio da sua head. Não devemos chamar nossas strings geradas de saída nativa de probabilidades, mesmo que o pacote tenha «cleft» no nome. Portanto, a afirmação honesta é que executamos o pacote backbone quantizado Cleft Flash pelo Ollama e testamos as respostas geradas. Verificamos o carregamento local de

09:53 uma entrada visual, com formatação de saída restrita. Não reproduzimos a head oficial de decisão no Ollama. Não há probabilidades nativas das opções nesses logs, e não vou inventar barras de confiança para fazer a demonstração parecer com a interface original de decisão. Para a comparação com Jev, precisamos trocar as fontes de evidência. Os números a seguir vêm da avaliação publicada pela Cloudflare, não do nosso laptop. Cleft Flash marcou 93,11 no API Bank, contra 88,19 de Jev, mas Jev ficou à frente em quando chamar: 80,97 contra

10:25 65,58. Os resultados publicados mostram pontos fortes dos dois lados. Os resultados de workflow contam uma história parecida. Em atendimento ao cliente, foram 77 para Cleft Flash e 76 para Jev. O processamento de faturas favoreceu Jev: 61,88 contra 57,1. A observabilidade de rastros de agent também favoreceu Jev: 71,6 contra 69,8. Esses são resultados de avaliação divulgados. Eles não certificam o desempenho desta quantização e

10:56 não devem virar uma afirmação genérica de que um modelo vence todas as tarefas. A Cloudflare também relata uma latência mediana muito menor para a avaliação hospedada do Cleft Flash do que para Jev nessa mesma avaliação. É um resultado publicado interessante, mas nossos números locais respondem a outra pergunta. Hardware diferente, caminho de inference diferente e saída gerada em vez da head de decisão. Colocar o tempo do laptop ao lado do tempo de Jev hospedado e declarar um vencedor apagaria essas diferenças. Mantenha as medições identificadas pelo lugar e pelo método em que foram produzidas. O que me faria

11:28 escolher uma dessas abordagens? Eu começaria pelo aplicativo. Ele precisa de imagens? Precisa de pesos locais? Precisa de probabilidades de tipo por meio de uma interface compatível? Depois, eu testaria o workflow real com exemplos desse aplicativo. Os resultados publicados ajudam a decidir o que investigar. Eles são muito menos úteis como substitutos para testar o caminho de deploy que você realmente vai usar. Para o caminho do Ollama que testamos, eu manteria o schema explícito e validaria os campos selecionados. Também analisaria os casos em que a

11:59 resposta é ambígua ou tem consequências importantes. A repetição da interrupção é um bom motivo para fazer isso. Se o objetivo é ter a experiência completa do decision model, a próxima etapa de implementação é um runtime que realmente carregue a joint schema head. Pedir que uma resposta gerada inclua um número de confiança não resolveria essa lacuna. Meu veredito é animador, mas específico. O pacote Q4_K_M roda localmente neste laptop de 8 GB. Ele aceitou a imagem e produziu o resultado esperado para o gesto. A saída de suporte com schema restrito foi válida, com comportamento de roteamento misto em requisições repetidas sobre a interrupção.

12:31 A principal limitação é o caminho de inference. Este teste no Ollama não executou a head oficial de decisão. Essa é a diferença entre um experimento local funcional e afirmar que reproduzimos o decision model completo da Cloudflare. Essa é uma maneira útil de encarar o CLF hoje. O lançamento open source torna a experimentação possível, e a entrada visual é uma adição significativa a essa categoria. O Jev original continua sendo uma comparação importante, com resultados publicados competitivos em várias tarefas. Nós

13:02 limitamos este vídeo a duas famílias de demonstração e salvamos os logs reais. Se você testar o mesmo caminho local, confira a saída e o runtime, porque o nome do modelo, por si só, não informa qual mecanismo está em execução.

Transcrição original

[00:00] Cloudflare has released KFFT a family of decision models. I wanted to answer one practical question. Can we take the small version put it into a llama on an ordinary laptop and actually use it. So that is what I tested. Just two demos today. A support request and an image. And there is an important surprise in the results. Loading the weights is only part of the story. We will keep this focused. First, what makes a decision model useful? Then the local setup. the two demos and a comparison with the

[00:31] original Jeff model from Typesafe. The goal is to understand what you can run today and what the results really mean. There is no giant collection of examples here. We will spend time looking carefully at the few examples we actually ran. Imagine your application receives a support ticket. Someone has to decide which team handles it and whether it needs attention. Now, a normal language response gives you a paragraph. Your application needs a value, something like technical, billing or sales. A decision model is built around that situation. You give it the

[01:02] information and define the available answers before the model makes its decision. The schema is simply the menu of decisions. One question might be a yes or no. Another selects a department. A third chooses a severity level from an ordered scale. That makes the output easier to put into ordinary software. The surrounding application knows what each field means. It can route the ticket, raise a notification, or leave the ticket in a queue without trying to interpret a long explanation. There is another useful ingredient,

[01:33] probabilities across the allowed options. Think about a message that could belong to billing or technical support. Instead of forcing every situation into a confident answer, an application can use uncertainty to decide when a person should take over. The threshold is an application choice. You still need examples and evaluation to find a threshold that makes sense for your actual customers. A constrained answer space helps with integration, but it does not make the decision automatically correct. Billing is a valid department even when the message

[02:03] should have gone to technical support. That distinction becomes very visible in our local test. Keep two questions separate while watching. Did the output follow the format and did the selected answer make sense? Passing the first question does not settle the second. The original Jev model is the comparison here. Types safe introduced it as a system one model with unstructured state going in and typed probabilistic decisions coming out. That is a useful baseline for understanding this category. The comparison in this video

[02:35] uses the original announcement and published evaluation results. I did not run a live Jev request on this laptop. Though there is no homemade jev timing to show, the smaller CloudFlare release is Clef. Its model card describes a 9 billion parameter backbone with visual inputs plus a separate joint schema head that scores the decisions. The weights are available under Apache 2.0. That combination is why local experimentation is interesting. We can inspect the release and test a quantized version

[03:05] rather than only reading about an API behind a hosted service. Here is the machine used for this video. An Nvidia RTX 4060 laptop GPU with 8 GB of video memory. Oama version 0.35.0. The installed model is the Bartowski Cleft Flash Quantization Q4KM. It was already present when I started the test. So, these are inference checks. I’m not presenting the download as something that happened during this recording. The quantization card lists the backbone

[03:36] file at about 5.84 GB. Lama shows about 6.8 GB for the installed package which also includes the visual projector. Those are different size measurements. During the test, Lama reported a mixture of CPU and GPU execution with about 87% on the GPU. This is a laptop run with a modest context, not the published hosted setup. The basic local route is straightforward. Select the hugging face repository and the Q4KM tag through OAM.

[04:07] Our requests then go to the local OAMA endpoint. For these tests, I used a48 token context and a short output limit. Those settings keep this experiment small. They do not test a long context window and they do not tell us how a large production workload would behave. The good news is that the model loaded and responded. We have actual output from the local machine. That is already useful if you want to know whether the quantise package can run on this hardware. But a successful load alone does not tell us whether Ola is

[04:39] executing the same decision mechanism used by Cloudflare. To find that out, we have to look at both the output and the release files. Our first demo is a short support request. Checkout has been failing for every customer for the last hour. We ask for three fields. Urgent, team, and severity. In this simple menu, technical is the intended team because we are describing a widespread service failure. Critical is a reasonable impact level and urgent should be true. The input is deliberately short so we can inspect the answer without hiding behind

[05:11] a huge prompt. The first request asked for JSON in the prompt. Here is the actual output. The model said urgent was true and mentioned technical and critical but the string was not valid JSON. Some keys and values were missing the required structure. That is a real failure for software that expects a JSON object. The cold request took about 18 seconds inside Ola. Most of it loading the model. Next, I supplied an actual JSON schema through AMA. Instead of

[05:41] relying only on the words return JSON, the schema defines urgent as a boolean and gives team and severity a fixed set of allowed strings. The resulting output parsed correctly. This is an important improvement for an OAMA application. It shows the benefit of constraining the format at the runtime level. It still leaves us with the question of decision quality. The first schema constraint outage request returned technical urgent true and critical. A llama reported about 2.27 seconds for that warm

[06:13] request. That is a plausible answer to the example. If this were the only output we showed, it would look like a very clean success. But there was another result from the same demo family and it changes how confidently we should describe the experiment. A repeated outage request still with zero temperature and the same allowed fields returned billing instead of technical. It kept urgent true and critical. The wall clock time was about 1.96 seconds. I’m keeping both results in the video. This is a small local experiment so we cannot diagnose the cause from one

[06:44] repeat. What we can say is that this tested path did not give stable team selection. To check the other side of the same routing demo, I used an ordinary invoice request. Please email a copy of my invoice. There is no outage and no payment dispute. I can wait until next week. That returned billing, urgent false, and minor. The wall clock time was about 1.55 seconds. This answer fits the input well. So, we have one clear success and one case where repeated outputs disagreed. The support demo

[07:16] tells us something quite specific. The quantise package can respond locally and Olama can constrain its generated answer to valid JSON. It also shows why one good screenshot is not enough to judge reliability. An application that automatically roots every ticket should be evaluated on a meaningful set of examples. Our two inputs are an illustration of behavior, not an accuracy benchmark for KF or Jev. For the second demo, I used the webcam image visible in the supplied screenshot. I cropped the embedded image so the model

[07:47] sees the hand gesture rather than the entire desktop. This is a still image test. I did not record a live webcam stream. The question is simple. Which hand gesture is visible and is the person holding a drink? The allowed gestures are fixed before the request. The image requests returned peace sign and holding drink false. Looking at the input, those answers make sense. Two extended fingers are visible and there is no drink in the hand. The wall clock time was about 1.35 seconds for the

[08:18] request. Again, this is a generated JSON answer through Olma. It is useful evidence that this package accepts images, but it is only one picture. The linked webcam repository demonstrates a different execution path. It uses the original release and its reference inference code to produce type decisions with probabilities from webcam frames. Its documented quick start targets an Apple Silicon Mac with at least 32 GB of memory. Our Windows Olama experiment uses a quantized package. The repository is a useful reference, but I did not run

[08:50] its Mac setup on this laptop. Now we reach the important detail. The official release lists separate files for a joint schema head. The reference loader explicitly loads that head alongside the backbone. It uses the head to score the allowed options. I checked our local quantise file and its listed tensors. The inspected file contained the usual backbone tensors and I found no separate joint schema head being loaded by the requests we sent. The request logs make the distinction even clearer. Olama

[09:21] reports generated output tokens for these answers. The constrained image response used 21 output tokens. The support responses used around 30. These are generated strings that we parsed as JSON. The official decision interface score schema options through its head. We should not call our generated strings the native probability output even though the package has cleft in its name. So the honest claim is that we ran the cliff flash quantise backbone package through Olama and tested its generated answers. We verified local

[09:53] loading one visual input in constraint output formatting. We did not reproduce the official decision head in Alama. There are no native option probabilities in these logs and I will not invent confidence bars to make the demo look like the original decision interface. For the comparison with Jev, we need to switch evidence sources. The following numbers come from Cloudflare’s published evaluation, not from our laptop. Cleft Flash scored 93.11 on API Bank versus Jev at 88.19, but Jev led on when to

[10:25] call 80.97 versus 65.58. The published picture has strengths on both sides. The workflow results tell a similar story. Customer service was 77 for Cleft Flash and 76 for Jeff. Invoice processing favored Jeff 61.8 8 against 57.1. Agent trace observability also favor Jev 71.6 against 69.8. These are reported evaluation scores. They do not certify the performance of this quantization and

[10:56] they should not become a blanket claim that one model wins every task. Cloudflare also reports a much lower median latency for its hosted cliff flash evaluation than for Jev in that same evaluation. That is an interesting published result, but our local numbers answer a different question. Different hardware, different inference path and generated output instead of the decision head. Putting the laptop time beside a hosted Jeff time and declaring a winner would erase those differences. Keep the measurements labeled by where and how they were produced. What would make me

[11:28] choose one of these approaches? I would start with the application. Does it need images? Does it need local weights? Does it need type probabilities through a supported interface? Then I would test the actual workflow on examples from that application. Published scores help decide what to investigate. They are much less useful as a substitute for testing the deployment path you will actually use. For the amma path we tested. I would keep the explicit schema and validate the selected fields. I would also review the cases where the

[11:59] answer is ambiguous or consequential. The outage repeat is a good reason to do that. If the goal is the full decision model experience, the next implementation step is a runtime that actually loads the joint schema head. Asking a generated answer to include a confidence number would not fix that gap. My verdict is encouraging but specific. The Q4KM package runs locally on this 8 GB laptop. It accepted the image and produced the expected gesture result. Schema constrained support output was valid with mixed routing

[12:31] behavior across repeated outage requests. The key limitation is the inference path. This Olama test did not execute the official decision head. That is the difference between a working local experiment and claiming we reproduced Cloudflare’s complete decision model. That is the useful way to look at CLF today. The open release makes experimentation possible and the visual input is a meaningful addition to this category. The original Jev remains an important comparison with competitive published results on several tasks. We

[13:02] kept this video to two demo families and save the actual logs. If you try the same local route, check the output and the runtime because the model name alone does not tell you which mechanism is running.