News

Supersonic Labs, a small AI lab from Brazil, has released Julia 1. It is a compact decision model, not a chatbot. You pass it context, a question, and 2 to 20 candidate answers. It picks one and returns a probability for every option. The model has 144.3M parameters and runs on a plain CPU. Is it deployable? Yes. The weights are on Hugging Face under Apache 2.0 and run locally with Python 3.11+ on CPU or a BF16-capable GPU. An ONNX build also runs in the browser via WebGPU. A hosted API is announced but not open yet. What Julia 1 Does Julia 1 handles three decision types through one API: choice: pick one label from 2 to 20 described options (classification, routing). score: return the expected index on an ordered rubric, such as low, medium, high. noul: return the probability that a yes-or-no statement is true. Results come back in the caller’s option order with full softmax probabilities. Caller IDs such as billing are returned unchanged. The model does not generate text. Architecture and Training Budget Julia 1 starts from JHU CLSP’s mmBERT-small, a 140M-parameter multilingual ModernBERT encoder trained on 1,800+ languages. Supersonic Labs kept the encoder and tokenizer, added a decision head, and trained on decision-format examples. The lab states Julia 1 is not a fine-tuned Qwen model. The runtime supports 8,192 combined tokens, but published benchmarks used a 1,024-token limit. Total cloud GPU spend for training and experiments was about R$540 (US$104.08). The FP32 weights occupy 550.5 MiB. The private training pipeline is not released. Julia 2, with the lab’s own foundation architecture, is in development. Benchmark Results The September 24, 2026 evaluation ran on H200 BF16 with strict encoding. The comparison baseline is TypeSafe’s Jev, using reference values from the Jev benchmark protocol, not a new Jev run. Typed Decisions: 73.15% (1,463/2,000) vs 72.70% reference. AG News, 4 labels: 94/100 vs 91% reference. DAIR Emotion, 6 labels: 86/100 vs 48% reference. Banking77, 72 labels: 64/100 vs 87% reference. This is the clear failure. MASSIVE, 18 scenarios: 71.50% macro accuracy across 52 locales; 86.25% pt-PT, 86.75% en-US. The classification pilots use only 100 examples each. A September 25 CPU run reproduced most numbers: 72.55% on Typed Decisions and 60/100 on Banking77 with 3 abstentions. On-Device Latency The lab published per-device measurements. On an Apple M4, one decision per call took a 33.15 ms median. On a Samsung SM-X510 tablet via ONNX Runtime, the median was 203 ms with 393.1 MB peak RSS. On an Intel Core i5-1235U, AG News decisions took a 107.83 ms median. Banking77 took 3,713.54 ms because it narrows 72 labels first. On X, @supersonicai claims Julia 1 classifies 5x faster than Jev on an i5 laptop. Treat that carefully. The Jev pilot measured Jev as a hosted service called from France, so latencies are not like-for-like. Introducing Julia-1:Our first classification model that runs on almost anything. Learn more https://t.co/YJCdEeIBSo pic.twitter.com/3cizsbG9ZB — Supersonic Labs (@supersonicai) September 26, 2026 Interactive Explainer Julia 1 vs Closest Competitors Feature Julia 1 TypeSafe Jev GLiNER2.5 Multi Developer Supersonic Labs TypeSafe AI Fastino Access Open weights Hosted API, early access Open weights License Apache 2.0 Proprietary Apache 2.0 Parameters 144.3M Not disclosed 287M Base encoder mmBERT-small Not disclosed mDeBERTa-v3-base Decision types Choice, score, yes/no Typed structured decisions Classification, NER, relations, records Options per call 2 to 20 (Router for more) Up to 255 Label list per schema Runs locally on CPU Yes No Yes Input price per 1M tokens $0.025 (planned API) $0.042 Free (self-hosted) AG News pilot 94% 91% 70% DAIR Emotion pilot 86% 48% 44% Banking77 pilot 64% 87% 61% Sources: Julia 1 model card, TypeSafe launch post, GLiNER2.5 Multi card, Jev benchmark pilot. Julia 1 pilots ran separately from the Jev and GLiNER runs. Limitations Julia 1 compares the answers you supply. It cannot be counted on for missing facts, algebra, or multi-step calculation. The Router can drop the correct label during narrowing. It is not a drop-in Transformers pipeline, and no Hugging Face inference provider serves it. Supersonic Labs advises evaluating on your own questions and keeping humans in the loop for consequential decisions. Key Takeaways Julia 1 is a 144.3M-parameter, Apache 2.0 decision model that runs on CPU. One API covers choice, ordered score, and yes-or-no decisions over 2 to 20 options. It beat Jev references on 3 of 4 pilots but trailed badly on 72-label Banking77. Median latency hit 33.15 ms per decision on an Apple M4. Training cost about US$104 in cloud GPUs; a $0.025/MTok API is planned. Check out the Model Weights, ONNX/WebGPU build, and Technical details. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Supersonic Labs Releases Julia 1: A 144.3M-Parameter Open Decision Model That Runs on a CPU appeared first on MarkTechPost.

Sarvam AI has released Saaras V4, the newest generation of its speech recognition model. It covers all 22 scheduled Indian languages plus English, now including global English accents. Sarvam reports state-of-the-art accuracy across all 22 languages. Is it deployable? Yes, through Sarvam’s API today, using model=”saaras:v4″. Weights are not public, and Sarvam’s SageMaker self-hosting docs currently cover Saaras v3 only. What is Inside Saaras V4 Saaras V4 is an encoder-decoder system. An audio encoder converts the waveform into embeddings that carry phonetic and acoustic detail. A temporal-downsampling adapter then shortens that sequence and projects it into the language model’s embedding space. This keeps long recordings inside the decoder’s context budget. The decoder is Sarvam-3B, a 3B-parameter hybrid state-space language model trained from scratch in-house. It reads the audio features alongside a text prompt. It then emits the transcript autoregressively, feeding each token back as input for the next. Benchmark Results English: Sarvam evaluated 7 English datasets. Six come from Hugging Face’s Open ASR Leaderboard: AMI, GigaSpeech, LibriSpeech clean, LibriSpeech other, SPGISpeech and VoxPopuli. The seventh is AI4Bharat’s Indian-accented Svarah. Scoring follows the leaderboard’s normalization code. Saaras V4 posts the lowest average WER among the models Sarvam benchmarked. Indic: On Vistaar, Sarvam reports results across 10 Indian languages using both WER and LLM-WER. LLM-WER adds a semantic check. It separates real meaning errors from harmless spelling or formatting variants common in Indic scripts. Noisy audio: On Kathbath Noisy, measured with LLM-WER, Sarvam says Saaras V4’s error rate is under half that of Deepgram Nova-3 and GPT-4o Transcribe. The set includes compressed, clipped and background-heavy recordings. Language ID: On verified IndicVoices utterances, language identification error is 2.9% across the top 10 Indian languages. It is 5.22% across all 22. It is important to note that all numbers above are vendor-reported. Independent reproduction has not been published yet. 5 Output Modes From 1 Model The same audio can return 5 representations, selected through the mode parameter: transcribe (default): native script with numbers and dates normalized. verbatim: every word as spoken, fillers and spoken numbers kept. codemix: native script, with English words left in English. translit: the full utterance in Latin script. translate: an English translation with numbers normalized. Sarvam’s argument is simple. Handling these inside the model removes post-processing steps that can compound errors. Keyterm Prompting Keyterm prompting is new in V4 and works only with saaras:v4. You pass a JSON list under keyterms, with up to 50 terms of 64 characters each. Keyterms bias recognition; they do not guarantee output. Use codemix mode when a brand such as PhonePe must stay in Latin script. On IndicContextEval (paper, Interspeech 2026), Saaras V4 reports 16.03% WER in the L5 keyword-prompting setting. Sarvam says that is the lowest score on the benchmark. Streaming, Long Audio and Pricing Streaming: WebSocket with partial results and time to first token below 150 ms. REST: synchronous transcription for clips up to 30 seconds. Batch: asynchronous jobs up to 2 hours per file, with optional speaker diarization. SDKs: Python 3.9+ and Node.js 18+, plus LiveKit Agents, Pipecat and Vercel AI SDK integrations. Price: Sarvam lists speech-to-text at ₹30 per hour for real-time, streaming and batch, and ₹45 per hour with diarization. Saaras v3 stays the default model. V4 uses the same request shape, so switching is a 1-line change. Saaras V4 vs Closest Competitors These are the 3 systems Sarvam benchmarked against. Figures come from each vendor’s public docs and pricing pages, checked on September 26, 2026. Feature Sarvam Saaras V4 Deepgram Nova-3 ElevenLabs Scribe v2 OpenAI GPT-4o Transcribe Indian scheduled languages (of 22) 22 11 14 Not listed per language Total languages 23 (22 Indian + English) 45+ 90+ Multilingual Keyterm biasing Up to 50 terms Yes, paid add-on Up to 1,000 (batch), 50 (realtime), paid add-on Free-text prompt Built-in output modes 5 (transcribe, verbatim, codemix, translit, translate) Transcript plus Smart Formatting Verbatim or no_verbatim Transcript Real-time streaming WebSocket, under 150 ms TTFT (vendor claim) Yes (WebSocket) Scribe v2 Realtime, about 150 ms File streaming; live via Realtime API Speaker diarization Batch API Yes Up to 32 speakers Separate gpt-4o-transcribe-diarize model List price ₹30/hour $0.0052/min (multilingual, pre-recorded) $0.22/hour (batch) ~$0.006/min Self-hosting Not for V4 yet (v3 on SageMaker) Yes Cloud API Cloud API Key Takeaways Saaras V4 covers all 22 Indian languages plus global English in 1 model. A 3B hybrid state-space decoder, trained from scratch, sits behind an audio encoder. Keyterm prompting accepts up to 50 terms and scored 16.03% WER on IndicContextEval L5. 5 output modes and sub-150 ms streaming TTFT come from the same model. API-only today at ₹30 per hour; self-hosting docs still cover v3. Check out the Technical Details. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Sarvam AI Releases Saaras V4: A Speech-to-Text Model for All 22 Indian Languages and Global English appeared first on MarkTechPost.

Perplexity Research published a new post-training study. It trains a model inside Perplexity Computer on real user sessions, including failed ones. The method pairs rejection sampling fine-tuning with hint-guided self-distillation. In a live A/B test, tool-call failures fell from 2.24% to 1.77% between 2 trained checkpoints. Perplexity team reports this as a statistically significant 21.2% relative reduction. Is it deployable? Not directly. Perplexity has not released the post-trained weights or training code. The model runs only as a model option inside Perplexity Computer. The base model, GLM 5.2, is openly available on Hugging Face. Why Outcome-Only Filtering Falls Short Standard rejection sampling fine-tuning (RFT) judges each session and imitates only the successful ones. A successful outcome does not mean every step was correct. An agent can recover from a bad tool call and still deliver the right answer. Imitating that full trajectory can reinforce the error. Discarding failed sessions also throws away clear evidence of avoidable mistakes. Imitate, Correct, or Keep as Context Perplexity team separates 2 decisions: which sessions hold behavior worth imitating, and which turns hold mistakes worth correcting. Each assistant turn gets 1 of 3 treatments: Imitate: non-error turns in successful sessions receive cross-entropy (CE) loss. Correct: error turns with a validated hint receive Kullback-Leibler (KL) divergence loss, in any session. Keep as context: remaining turns stay in the input but receive no loss. Successful sessions can supply both imitation and correction targets. Unsuccessful sessions supply only correction targets. How a Hint Becomes a Training Signal A hint is a short corrective instruction grounded in information the model already had. In one example, a search call set recency_filter to ‘year.’ The schema allowed only ‘day,’ ‘week,’ or ‘month.’ The hint names the failed call, includes the validation error, and suggests an allowed value or omitting the optional field. The corrective part uses On-Policy Self-Distillation (OPSD). The trainer runs the same GLM 5.2 checkpoint twice on the recorded turn. The teacher pass sees the hint; the student pass does not. Both use teacher forcing, so no replacement answer is generated. The teacher’s next-token probabilities are detached and act as a soft target through forward KL. The combined loss is (CE + λ × KL), divided by the number of imitated tokens. Setting λ to 0 recovers standard SFT. The CE term matters. Correction-only training can let teacher and student agree by ignoring context. Tracing Complaints to the Real Mistake The pipeline draws from training-eligible Computer sessions served by GLM 5.2. Sessions with personally identifiable information and users who opted out are excluded. An LLM judge keeps tasks rated 4 or 5 on a 5-point difficulty scale. Two LLM judges must both approve the final delivery for a session to count as successful. For user feedback, threes LLM judges locate the responsible turn, and at least 2 must agree. This is important because the last assistant turn before a complaint is the root cause only about half the time. Each hint is also checked against information available before the mistake. That check reduces hindsight bias. One example: a user asked for their ‘w3’ on Paychex. The model assumed a W-2 typo and searched for the wrong form. The hint targets that earlier interpretation, not just the final answer. Interactive Explainer What the Evaluations Show Hints work before training: On 985 held-out tool-error turns, the unchanged base model avoided the original failure in 93.7% of cases with hints, up from 75.1%. The share taking the corrected action rose from 60.6% to 82.3%. On user-feedback turns, fixed or on-track rates rose from 40.0% to 75.0% for explicit evidence. For inferred intent, they rose from 32.5% to 80.0%. Offline tool errors fell: Recorded tool-error rates were 2.79% for stock GLM 5.2 and 1.35% for RFT only. The RFT plus OPSD checkpoint reached 0.87%. Perplexity notes these checkpoints used different training data, so this is not a matched ablation. Task-level benchmark results on suites like BrowseComp and SpreadsheetBench were mixed. Live results are narrower: Each A/B test used about 100,000 users per condition. An early checkpoint versus stock GLM 5.2 showed 2.82% versus 2.94% failures, which was not significant. The later checkpoint comparison produced the significant 21.2% drop, without hints at inference. Strong dissatisfaction moved from 2.58% to 2.54%, which was also not significant. Perplexity did not compare the later checkpoint directly against stock GLM 5.2 online. Key Takeaways Perplexity learns from failed sessions, not just successful ones. Validated hints turn avoidable mistakes into KL correction targets. 1 model acts as teacher (with hint) and student (without). Live tool-call failures fell from 2.24% to 1.77%. User dissatisfaction showed no significant change. Check out the Technical Details. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Perplexity Trains Its Computer Agent on Real Mistakes With Hint-Guided Self-Distillation appeared first on MarkTechPost.

Aikido Security has released Altar-1, its first open-weight security model. It is a compressed version of Z.AI’s GLM-5.3, built to run inside infrastructure the customer controls. Altar-1 powers Aikido Machine, the company’s autonomous pentesting appliance for on-prem and air-gapped networks. Is it deployable? Yes, the weights are public on Hugging Face and run with vLLM on a single node of 4x NVIDIA H200 GPUs. The Problem: Security Context Cannot Leave the Network Closed frontier models run on someone else’s infrastructure. Using them sends source code, architecture docs, and unremediated findings outside the network. Aikido points to banks under data-residency mandates and OT operators with no internet route. Open-weight models solve the residency problem but create a deployment gap. Mixture-of-experts (MoE) models must store every expert, even when a workload uses only a few of them. Security agents also build long-running context. That KV cache competes with model weights for the same GPU memory. How Altar-1 Was Built GLM-5.3 is a 753B parameter MoE model. Each token routes to 8 of 256 experts per layer, which is about 40B active parameters. Aikido applied 2 compression steps: Step 1-Quantization: Altar-1 starts from the cyankiwi GLM-5.3-AWQ-INT4 checkpoint. AWQ stores routed expert weights in 4 bits, with 16-bit activations (W4A16). Attention, the shared expert, dense layers, and the head stay in BF16. Step 2- Expert pruning: Aikido used Cerebras REAP (Router-weighted Expert Activation Pruning). REAP scores each expert by router weight and output magnitude, not just by how often it is selected. Altar-1 keeps 168 of 256 routed experts per layer and removes 88 (34.4%). No retraining is involved. Calibration used traces from Aikido’s pentesting harness, plus coding, tool calling, reasoning, and multilingual Wikipedia text. Aikido states no customer data was used. Each expert is scored by its largest share of any single domain’s routed work. That protects the specialist experts for code, rare languages, and structured output. Routing is unchanged. The router still picks 8 experts per token, now from 168, with about 40B active parameters. Checkpoint Stored weights GLM-5.3, BF16 1,506.7 GB GLM-5.3, AWQ INT4 488.2 GB Altar-1, pruned W4A16 328.0 GB Altar-1 is 78.2% smaller than BF16 and 32.8% smaller than the AWQ parent. On fidelity, Altar-1 has a KL divergence of 0.506 nats against full BF16 on a sealed 25-prompt panel. An EXL3 build of the same cut scores 0.511. The details are in the public fidelity study. Benchmark Results Aikido team tested Altar-1 on its internal CVE benchmark. The benchmark covers 32 known vulnerabilities across 30 repositories, with 3 runs per case. Model Avg recall per run Found at least once GLM-5.3, BF16 65.6% 25 of 32 GLM-5.3, AWQ INT4 61.5% 23 of 32 Altar-1 60.4% 23 of 32 Compared with the AWQ checkpoint, pruning cost about 1 point of recall and no coverage. Compared with the parent, Altar-1 keeps 23 of 25 covered vulnerabilities (92%) at 5.2 points lower recall. The benchmark’s scope is narrow. It measures targeted CVE rediscovery inside a pipeline that uses other models for the surrounding stages. It does not measure blind discovery, exploit validation, or fix proposals. Aikido also reports that Altar-1 found a valid critical-severity vulnerability during a client’s production pentest. That is a single result reported by the vendor. Deployment and License The model card requires Hopper GPUs (H100 or H200). Aikido says 328 GB across 4x H200 leaves room for a 128k-context KV cache at production batch sizes. Copy CodeCopiedUse a different Browser vllm serve AikidoSec/altar-1 –tensor-parallel-size 4 –trust-remote-code –max-model-len 131072 vLLM selects the Marlin MoE kernel automatically. A 4x H100 80 GB node has only 320 GB of memory, which is less than the 328 GB of weights. Altar-1 inherits the GLM-5.3 License. The license permits commercial use, modification, and redistribution. Model-as-a-Service operators with more than $10B in revenue over 12 months must first pass a Z.AI security review. Altar-1 is open-weight, not OSI-approved open source. Altar-1 also powers Aikido Attack, AI Code Analysis, and Deep Review. Next, Aikido plans to try lower-bit formats like EXL3 so it can keep more experts. It also plans to fine-tune models for security workflows. Key Takeaways Altar-1 compresses GLM-5.3 from 1,506.7 GB to 328 GB, a 78.2% cut. REAP pruning keeps 168 of 256 experts per layer, with 8 active per token. Recall drops from 65.6% to 60.4%, keeping 92% of the parent’s CVE coverage. It runs on 1 node of 4x H200 with vLLM, including air-gapped setups. The GLM-5.3 License allows commercial use, with a review clause above $10B revenue. Check out the Model Weights and Technical Details. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Aikido Security Releases Altar-1: An Open-Weight Security Model Pruned From GLM-5.3 to 328 GB appeared first on MarkTechPost.

Liquid AI has announced LFM2.5-VL-3B-DSpark, an experimental speculative-decoding draft model for its LFM2.5-VL-3B vision-language model. The drafter adds about 280M parameters and speeds up decoding without changing the model’s output. Liquid AI team reports up to 3.13x faster decoding on Apple silicon and up to 2.66x on an NVIDIA H100. Is it deployable? Yes, Weights are live on Hugging Face in Safetensors and GGUF, with day-one support in SGLang, MLX-VLM, and llama.cpp. Liquid AI team labels the release experimental, and it ships under the LFM Open License v1.0, which allows free commercial use only for companies under $10M in annual revenue. What Speculative Decoding Changes for a VLM A standard model generates one token per forward pass. Speculative decoding adds a small drafter that proposes several tokens ahead. The large target model then checks the whole block in one pass and keeps the tokens it agrees with. DSpark follows the recipe from Liquid AI’s text-model DSpark drafters, described in the DSpark paper. The drafter reads the target model’s hidden states from several layers and predicts the next k tokens. The key design point: modality does not matter to the drafter. By the time tokens reach the hidden layers, text and image patches are both just tensors. So Liquid AI team reuses the exact same inference algorithm for its vision-language model. Drafter Architecture and Training The drafter is a simplified attention-only model. Ablations picked 4 layers and a block size of 9. Liquid AI recommends a block size of 8 or 9 at inference, depending on hardware. Apple silicon runs use 8. Component Parameters Decoder stack (4 layers) 193.0M Hidden-state projection 21.0M Markov head 65.5M Norms + confidence head 6.4k Total 279.5M The embedding and LM head are tied to the target, so the drafter does not carry them. Liquid AI says this raises the deployed parameter count by 8.9%. Training used supervised fine-tuning data covering common vision-language tasks for 10 epochs. All ablations and training ran exclusively on AMD hardware. Benchmark Results Evaluation follows the MMSpec benchmark across 6 task types: General VQA, Text VQA, Image Captioning, Chart VQA, Complex Reasoning, and Multi-turn Conversation. All runs used batch size 1, temperature 0, and 16-bit weights for the vision encoder and backbone. Data was collected on Pipette, Liquid AI’s public device-benchmarking infrastructure. Stack Decode speedup End-to-end speedup Accepted tokens per pass MLX-VLM, M5 Max MacBook Pro (block 8) 2.30x to 3.13x 1.56x to 2.62x 3.24 to 4.34 llama.cpp, M3 Ultra (block 8) 1.57x to 2.14x 1.30x to 1.77x 3.31 to 4.50 SGLang, 1x H100 80GB (block 9) 2.04x to 2.66x 1.64x to 2.27x 3.46 to 4.57 The ‘up to’ decode and end-to-end figures often come from different tasks. On the M5 Max, 3.13x decode is from COCO captioning, while 2.62x end-to-end is from MMMU-Pro. Acceptance landed in a similar range on both Apple stacks. Liquid AI reads this as acceptance depending on the drafter and workload, not the runtime. At higher concurrency, DSpark kept a throughput advantage at every measured level on a single H100 in SGLang. The gap narrows as concurrency rises. Output Quality and Temperature Under greedy decoding, the target verifies every proposed token, so output is identical to the base model. At non-zero temperatures with matched sampling, speculative decoding preserves the target’s output distribution, as proven by Leviathan et al. Temperature does affect speed. Higher temperatures spread probability across more candidate tokens, so drafter and target disagree more often. In Liquid AI’s tests, this lowered acceptance and throughput. Why End-to-End Gains Are Smaller on Edge Speculative decoding only accelerates decoding. Image encoding and prefill run at the same speed. A VLM must encode the image, then process hundreds of visual tokens alongside the prompt. On edge devices with less compute than data center GPUs, prefill takes a larger share of latency. Liquid AI frames this as Amdahl’s law: total speedup is bounded by the part left unaccelerated. This explains cases like TextVQA on the M5 Max, where 2.69x faster decoding yields 1.56x end to end. How to Run It SGLang requires v0.5.19 or newer. Launch LiquidAI/LFM2.5-VL-3B with –speculative-algorithm DSPARK and point –speculative-draft-model-path at the drafter. On Apple silicon, MLX-VLM v0.7.2 or newer accepts the drafter through –draft-model. DSpark in MLX-VLM currently supports greedy sampling only, so set temperature to 0. For llama.cpp, pair the GGUF drafter with the LFM2.5-VL-3B-GGUF target. Integration work is public in the llama.cpp, SGLang, and MLX-VLM pull requests. Acceleration of quantized models is outside the scope of this release. Key Takeaways A 279.5M drafter adds 8.9% parameters to LFM2.5-VL-3B. Decoding runs up to 3.13x faster on M5 Max, 2.66x on H100. Output is identical under greedy decoding; distribution preserved when sampling. Prefill and vision encoding cap end-to-end gains, especially on edge. Tested at 16-bit only; quantized acceleration is not covered yet. Check out the Technical Details. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Liquid AI Releases LFM2.5-VL-3B-DSpark: Speculative Decoding for Vision-Language Models With Up to 3.13x Faster Decoding appeared first on MarkTechPost.

Contrastive-LM has released CLM-8B, the first open model in a new class called Contrastive Language Models (CLMs). CLM does not generate text. It scores a set of candidate actions against the current state and returns probabilities. Their main baseline is Jev, the proprietary System One model from TypeSafe AI. Is it deployable? Yes. The Apache-2.0 head weighs 75 MB. It runs on 1 NVIDIA GPU under Linux, with vLLM serving the Qwen3-8B encoder. What a System One Model Does Jev entered limited early access on 15 September 2026. It returns typed values with probabilities instead of text. CLM targets the same interface. The CLM GitHub repo serves CLM-8B behind a TypeSafe-compatible API. It exposes 3 question types: Noul: returns the probability that a statement is true. Choice: picks one option from a declared set, with probabilities. Score: returns an expected level on an ordered rubric. A request written for TypeSafe’s API can be replayed through CLM’s Python client. How CLM Works CLM trains a state encoder and an action encoder with a bidirectional InfoNCE loss. Each encoder is a frozen Qwen3-8B backbone plus a 20M-parameter trainable projection head. Training pulls each state toward the action actually taken and pushes it away from the others. At inference, CLM scores each candidate by the dot product of the state and action embeddings. A softmax over those scores becomes the answer distribution. The same primitive ranks best-of-N solutions, routes tools and answers typed decisions. This design disaggregates states and actions. In an agent loop, the state changes every step while the action set stays mostly fixed. clm-serve reserves a slab of GPU memory, similar to vLLM’s KV cache, and reuses cached vectors. On 1 RTX 4090 with 3 actions, revisited states drop from 1.7 ms to 0.6 ms. The model card reports CLM running 13× faster than Jev with about 1,000 candidates. A 3-Stage Training Recipe Pre-training on ~60M Nemotron DQA question-answer pairs. Mid-training on ~30M synthetic hard negatives generated by Gemini 2.5 Flash-Lite. Post-training on ~1M agent trajectories from Agent Data Protocol, Endless-Terminals and LiteCoder-Terminal-SFT. On ~100K held-out questions, pre-training alone reaches 52.1% top-1 accuracy. Mid-training lifts it to 69.2%. Training on hard negatives from the start peaks at 62.4%, then overfits. Zero-Shot Results Against Jev Task CLM-8B latency Jev latency CLM-8B success Jev success T-Rex game 16.5 ms 149.8 ms 5/5 5/5 Tool calling (BFCL v4) 76.8 ms 125.5 ms 95.2% 99.2% WikiRacing 79.8 ms 225 ms 26/30 30/30 Super Mario 33.5 ms 132.6 ms 5/5 5/5 The 9× figure comes from the T-Rex game, where actions repeat across states. CLM matches Jev on T-Rex and Super Mario. It trails on tool calling and WikiRacing while running faster on every task. CLM as a Verifier for Coding Agents Here a generator samples several candidate solutions and the verifier picks one. Opus 5 produced DeepSWE candidates (best-of-4). Fable 5 produced Terminal-Bench 2.1 candidates (best-of-5). The team evaluated 38 held-out DeepSWE tasks and 30 held-out Terminal-Bench 2.1 tasks. Latency was measured on an H100. Benchmark Pass@1 CLM (fine-tuned) Jev CLM latency Jev latency DeepSWE 73.7% 81.6% 71.1% 79 ms 449 ms Terminal-Bench 2.1 84.0% 87.6% 83.1% 32 ms 131 ms The research team reports these as new SOTA verifier results. Jev scores below pass@1 on both benchmarks, so selecting with Jev is worse than taking 1 sample. CLM runs 4.1× to 5.7× faster. These numbers use lightweight fine-tuned heads, not the zero-shot checkpoint. They are held-out subset results, not full leaderboard submissions. Interactive Explainer Key Takeaways CLM-8B scores candidate actions instead of generating text. Up to 9× lower latency than Jev in zero-shot tests. Fine-tuned heads reach 81.6% on DeepSWE and 87.6% on Terminal-Bench 2.1 subsets. Cached state and action vectors cut agent-loop latency. Apache-2.0 head, self-hosted on 1 NVIDIA GPU. Check out the Blog, Code and Data & Models. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Contrastive-LM Releases CLM-8B: An Open System One Model That Scores Agent Actions Up to 9× Faster Than Jev appeared first on MarkTechPost.

This week, world leaders descended on Manhattan for the UN General Assembly. It’s also New York Climate Week—investors, policymakers, advocates, and journalists are colliding at panels, talks, and fancy dinners. With so many climate voices in one place, the discourse can feel a little louder than usual. This year, the unavoidable topic is artificial intelligence. There’s been a growing tension bubbling up about AI’s impacts on climate and climate tech. Depending on where you stand, you might point to AI’s potential for advancing research, or to the way funding and attention from Big Tech is trickling into energy startups. Or you might focus on the emissions-heavy natural-gas buildout that’s unfolding to meet the sector’s electricity demand. Everyone seems to agree that AI is important. The big question for those in the climate world, and the conversation I’m constantly having and hearing this week, involves how you see its influence unfolding. UN Secretary-General António Guterres highlighted the AI and climate crossover in a speech on the first day of the assembly. “The climate crisis fuels instability and displacement,” Guterres said. “Artificial intelligence could help solve all these challenges, or it could make them worse.” It feels relevant that this year is the first that the world has really had to grapple with the fact that climate goals are slipping out of reach. A recent report from the UN Environment Program said that the world has nearly passed the point where we could possibly keep warming to less than 1.5 °C above preindustrial levels. Since we’ve essentially missed this target, the report lays out the need not only to quickly and drastically reduce greenhouse-gas emissions, but also to employ carbon removal to help suck up emissions that have already been released into the atmosphere. The billion-dollar question is whether AI could help with any of this.  The energy-intensive technology is certainly shining a spotlight on the need to build out electricity supplies and shore up grid reliability. The result is more attention and money for energy technologies, some of which happen to be low- or zero-emissions. As I’ve covered before, startups across the energy and climate sectors are benefiting. Firms in nuclear, geothermal, wind, and solar power have signed deals with the likes of Google, Meta, and others looking to power their new or growing data centers. Global climate-tech investment from venture capital hit $26 billion in the first half of 2026, according to data from Currence, a finance tracker for the industry. That’s 55% higher than last year, and products and services for data centers are getting a massive slice of that pie. But as a Semafor piece about the report points out, some sectors are slipping through the cracks: Carbon management and low-carbon fuels saw VC investment plummet this year. These are important solutions for addressing climate change but may not be able to sell themselves to a data center. So far, the data center buildout has come with a hefty emissions toll. A few years ago, Microsoft, Google, and Meta all had ambitious goals to reduce greenhouse-gas emissions. Now they’ve all seen emissions rise, largely because of data centers that are needed to power AI. Some people are optimistic. AI could help speed up progress in areas like the search for new catalysts, as Evelyn Wang, MIT’s VP of energy and climate, pointed out during a panel. And data centers won’t add to climate and water problems forever, Wang told the Associated Press. (She puts the timeline at about a decade until data centers no longer add to planet-warming emissions.) But a whole lot of natural gas is coming online to meet the immediate demand created by new data centers. And once those power plants are built, they have a decades-long lifetime.  That’s partly why public pushback to AI is growing—people are seeing more pollution and noise near these data centers and the power plants that provide them with electricity. Overall, what I’m hearing this week is that many in the climate sector are skeptical of AI, at best.  “AI leaders are now on thin ice when it comes to license to operate and sinking deep underwater when it comes to public support,” said UN climate chief Simon Stiell in a speech this week. “Tech titans need to start showing why the benefits of AI outweigh its skyrocketing costs—for the many, not just the tiny few.”  This article is from The Spark, MIT Technology Review’s weekly climate newsletter. To receive it in your inbox every Wednesday, sign up here.