---
id: "2060260022047666222"
created_at: "2026-05-29T07:20:41+00:00"
lang: en
in_reply_to: null
in_reply_to_user: null
thread_root: "2060260022047666222"
kind: retweet
original_id: "2059739380785271033"
external_status: ok
urls:
  - expanded: "https://huggingface.co/antirez/deepseek-v4-gguf"
---

RT @VitalikButerin: Updates since then:

* Deepseek v4 is out. There *is* a 2-bit quant that can run within 90 GB ( https://t.co/X3AFAsiH02…

---

### Original `2059739380785271033` vitalik.eth @VitalikButerin

Updates since then:

* Deepseek v4 is out. There *is* a 2-bit quant that can run within 90 GB ( 
https://
huggingface.co/antirez/deepse
ek-v4-gguf
… ), and it works, however it's only fast on Apple hardware (I've head ~35 tok/s). On AMD, it's ~7 tok/s. IMO actually taking the effort to properly support more than one hardware manufacturer is a great example of the difference between mere "decentralized AI" and genuine "CROPS AI". I hope we can become better at this.
* 
https://
github.com/vbuterin/messa
ging-daemon
… also has alpha telegram support now. However, the path to adding your account is quite janky
* 
https://
github.com/Luce-Org/luceb
ox-hub
… looks promising as a way to run "dense" models (eg. Qwen 27B) more efficiently. It's janky, but on my 5090 laptop it seems to be ~2x more tok/s than llama.cpp
* VoxTerm (local AI recording, no third-party servers) continues to be developed 
https://
github.com/dmarzzz/VoxTerm

And there's a lot more projects coming on the horizon.

One other thing that has been on my mind is that there's actually a lot of intersection between "CROPS ethereum access layer" and "CROPS AI". For example, we want a ZK way to make (paid) calls to remote LLMs. But if we have this, then it's just as useful for solving another problem: private RPC reads in Ethereum.

Another example: application-specific finetuned LLMs. Leanstral ( 
https://
mistral.ai/news/leanstral ; I get ~38 tok/s on AMD) fits into < 70 GB, but can hold its own against 1T models on writing Lean code. Things like this are a huge boon for writing more secure code ( 
https://
vitalik.eth.limo/general/2026/0
5/18/fv.html
… ). We should have models finetuned for Ethereum-related use cases as well.