Lloyd's k-means algorithm is a standard ML algorithm for clustering.
This paper introduces e-means clustering algorithm which is [1] much faster than Lloyd k-means and [2] converges to lower losses, frequently even beating k-means++.
On a wide array of embeddings datasets, it beats the loss of Lloyd k-means at 25 epochs in 1.4 to 2.6 epochs,
As an example, e-means partitions DINO10B, a dataset of 10 billion DINO embeddings, into 16 million clusters in only 2.5 epochs, reaching a loss below Lloyd's at 25 epochs.
I publish Jeb as a decision model. It returns numbers your application can read. Your application still needs a rule for what happens next.
Take a support route. A choice question can return a probability for billing, technical support and account access. Those labels are an example, not a fixed set you have to use.
A top answer tells you which label won. It doesn't tell you whether the result clears your own bar for an automatic route. Keep that second decision in the application, where you can inspect and change it.
I'd start by saving the question, the option names, the probabilities and the action rule together. Review the cases near the boundary. A correct top answer can still have a probability that falls on the wrong side of the line your application uses.
The same distinction matters when comparing runtimes or quantizations. Answer agreement measures whether the winner stayed the same on the questions tested. It doesn't establish that the probabilities stayed identical. If those probabilities drive an action, compare them too.
The standalone server exposes POST /v1/systemone. The decide scripts are another way to get decision outputs. A chat window loading the weights doesn't expose the answer-label probabilities needed for this workflow.
Which part of your first local decision would you keep under human review?
🤗 I've released Sentence Transformers v6.3 and wrote a blogpost about its key new feature: token pooling-aware training, teaching multi-vector models to preserve retrieval quality with fewer document vectors. Details:
Multi-vector models keep a vector per token, letting different query tokens match different parts of a document. Great for retrieval, but those vectors add up! Token pooling makes the representations smaller by merging similar document vectors into cluster means.
Pooling-aware training teaches the encoder to preserve useful matches after those vectors are merged. With MultiVectorTokenPoolingLoss, you can wrap your standard retrieval loss to train on both full and pooled representations, reusing the same token embeddings without another encoder pass. In short: small overhead.
I trained two ModernBERT-base models on the same 120k MS MARCO triplets, changing just the loss. At ~49 vectors per document instead of 193, pooling-aware training raises NanoBEIR@13 mean nDCG@10 from 49.03 to 51.23. That's 97.8% of its own unpooled score with ~4x fewer document vectors, compared with 94.6% retention for ordinary training.
v6.3 also adds: - Adaptive token budgets, allocating vectors according to each document's content - Matryoshka training for shorter multi-vector token embeddings - Hugging Face kernels support for MaxSim, Ward clustering & supported transformers layers - Native AWS Neuron inference
You can combine pooling-aware and Matryoshka training to learn both fewer vectors and fewer dimensions, then stack these with quantization to reduce storage per coordinate. For kernels, install sentence-transformers[kernels] and set use_kernels=True.
The blog walks through the method, training code, checkpoints & evaluation, building on Stefan Josef's Learn to Pool and LightOn's pooling regularization work: ht tps://huggingface.co/blog/token-pooling
Most mobile AI agent demos show the agent controlling a phone screen.
What they don't show: when to not do that.
Aico's Phone Bridge layer routes per action - software fast path (calendar, contacts, clipboard, app launch) when available, HDMI + HID hardware control when not. Sometimes both in the same task.
The interesting design question isn't "can the agent control the screen?" It's "when should it bother?"
A 284B-parameter DeepSeek-V4-Flash now runs on a 64 GB desktop with 0 GPUs: llama-modchip shrinks the checkpoint to 56.56 GiB (1.71 bpw) and decodes at 9.1 to 14.7 tok/s.
The standard UD-IQ1_S build is 76.87 GiB, above the ~62.5 GiB usable on a 64 GB Linux box. The repo mixes precisions (routed experts mostly IQ1_S, MLA projections in a custom Fractal-64 type) and patches the CPU kernels. The model plus a 256K KV cache then sits at 57.61 to 58.9 GiB RSS with zero swap. The repo was created on 2026-10-29 and already has 744 stars and 470 points on Hacker News.
📊 The numbers • Size: 56.56 GiB, 20.31 GiB smaller than UD-IQ1_S • Prefill: 25.0 to 44.36 tok/s (+77%) on a 16-core Ryzen 9 9955HX • Decode: 5.91 tok/s unpatched, 9.06 to 9.95 tok/s at Top-6, 11.5 to 14.7 tok/s with the n-gram drafter
⚠️ Caveats • "Lossless" means bit-exact against the same re-quantized checkpoint. Versus UD-IQ1_S the author reports 0.9964 top-logit cosine similarity • The 98.5/100 quality score comes from the author's own gate, and the headline speeds come from one machine • The custom tensor type 40 is rejected by stock llama.cpp, Ollama and LM Studio
🛠️ Try it • Run scripts/check_cpu_readiness.py from the repo: it needs no model download • Run ./modchip bench for speed, then ./modchip eval to check the quality claims yourself
New post-training example: SFT on agent traces with TRL
→ A large model works as a coding agent in OpenCode, run through OpenEnv → The tasks it solves become the training data → A 2B model goes from 5.5% to 34.4% on held-out tasks
About 500 traces get most of the gain. Five times more add only 3 to 4 points, so SFT gets the agent working and RL has to do the rest
A 0.5B-active base trained on 60B tokens, rivals Qwen3.5-2B.
2.59B total and 553M active parameters. 12-task lm-eval average 58.3, vs Qwen3.5 2B 58.1, trained on only ~60B tokens.
Architecture: 23 GDN-2 + 9 MLA layers, mHC with 4 residual streams, Engram bigram/trigram hash tables before blocks 1 and 14, 120 latent experts per layer with top-6 routing + 2 shared experts, quantile load balancing. No positional encoding. Olmo 3 tokenizer.
Loads with transformers (trust_remote_code) or via pip install nenya without remote code. Mac users: pip install "nenya[mac]" gives a Metal engine at 127 tok/s on M4 and 74 tok/s on M1, ~4 GB memory. An 8-bit Metal variant is in the repo.
Known gaps: code is the weakest domain, 16K context, no scaling-law sweep yet.
