antirez

My second short story release in English is ready: Tales of Illustrious Computer Scientists: Iola Varga, nun and computer scientist. invece.org/iola.html

The coreutils Rust rewrite story is pretty funny. Coreutils are tools like rm, mv, mkdir, etc. Unlike binutils, this isn't a fertile ground for memory safety bugs. But, the rewrite was completed, and in the spirit of progress, Canonical decided to switch. 🡇

@p_mbanugo GPT started to be good with the 5.2 series but 5.3 for me was a jump.

@antirez Does it matter if it's GPT 5.3 codex or GPT 5.4 or later? I'm curious if there's a min version you think was very well or good enough.

[blog post] Redis array: short story of a long development process => antirez.com/news/164

@antirez I am working on a knowledge base full of legislation, and IIUC this is _precisely_ what I would want. Markdown files, where the agent can grep through everything trivially. Thank you for this. I was searching for a solution for a long time.

There are projects that I develop not looking at the code, but looking and owning the concepts, algorithms, ideas, and product. But not for Redis, not yet at least. When in the future this will be possible, server software the way it is developed today will be over, there will be still projects I believe, but developed in a very different way. Programmers will do mainly what Linus did so far for the kernel.

@antirez Closely matches my own experiences with current SOTA AI. Extremely useful collaborator, far from being a replacement for human intelligence and creativity.

ARGREP was the *last* command I added to the specification. I realized that the Array type was perfect to store text files only very later during the development :) But I believe it is going to be my main use case in the short run.

I believe the fact that Redis is so well understood by LLMs and people, is remote, and this support will allow to create knowledge bases for agents that are not centralized, do not need to live in the filesystem, and are trivial to update / access.

ARGREP was the *last* command I added to the specification. I realized that the Array type was perfect to store text files only very later during the development :)

I believe the fact that Redis is so well understood by LLMs and people, is remote, and this support will allow to create knowledge bases for agents that are not centralized, do not need to live in the filesystem, and are trivial to update / access.

One thing to understand about the new Array type of Redis, and the support of ARGREP, is that you can store, in Redis keys, different markdown documents (skills) that are collectively used and updated by a multitude of remote agents.

@g_giovanii Yes

@antirez Is this the new data type that teased many times before?

I just submitted a PR for a new Redis Array type :) github.com/redis/redis/pu…

@pupposandro Basically DeepSeek v4 Lightning Indexer but as a component of existing models (even if with limitations compared to the DS4 architecture of course). Interesting idea.

We just released something new: Luce PFlash Long-context prefill is a silent killer for throughput speed. llama.cpp takes ~257 seconds to prefill 128K tokens of Qwen3.6-27B on a single RTX 3090. So we tried to solve the problem. A small Qwen3-0.6B drafter loads in-process, scores token importance across the whole prompt, and the heavy 27B target only prefills the spans that matter. 128K prompt in 24.8 seconds, ~10.4x faster TTFT, NIAH retrieval preserved at every measured context. It is a clean C++/CUDA port of FlashPrefill wired through Block-Sparse Attention, with a custom Qwen3-0.6B BF16 forward so drafter and target share one ggml allocator. The whole thing is a single daemon command (compress) in front of the existing dflash spec-decode stack. More details here: github.com/Luce-Org/luceb…

What I was able to achieve today was a *much* better slope in the prefill rate, that remains at 200 t/s even in very long contexts. This already makes the game a more fair one, since it does not start to degradate in a sensible way as you continue to work. In the M3 Ultra is much faster btw. I also tested there, 2x speed in prefill.

@antirez wonder what magic could be done to improve prefill rate. i think that's mostly what's holding things back at the moment.

DeepSeek v4 small KV cache + MacBook fast SSD disks = the idea that the disk is not a good target for KV cache is, in this context, totally obsolete. It works *great*. The session you see is opencode using my inference engine for DS4, saving, loading sessions from disk.

@lucastech 128 GB, with space for generous contexts. 2 bit asymmetric quantization where shared experts, routing and projections are taken at full quality.

@antirez The Apple nvme are dramatically faster than most ssd, which makes the disk access much more tenable than it would be in most other systems. How much ram do you need for that to run locally though?

@thought_sync Yep I'll make all of it MIT licensed. It will take some time as I believe in the AI space we see too many rushed things, so I want to make sure it works well before releasing it.

@antirez Is it possible to try out your inference engine!?

@danveloper Yep consider that this is an M3 Max not an M3 Ultra, in the Ultra I get 2x prefill speed, and the same speed with 4 bit quants instead of 2 bit (only for routed experts, all the other weights are as released by @deepseek_ai).

@antirez There are so many caches and hardware accelerators in the Apple Fabric, I'm sure you could make that even faster if you wanted to cut the ~6s off prefill. But, completely usable anyway!