Pretty amazing for just 4 sparks.

all of these benchmarks are bullshit. on real agentic work, i have glm 5.3 flash vs opus 4.8, it's not even close. opus 4.8 wall clock is up to 8x faster. It's not just the tps because i'm running sparks, it's efficiency. Opus uses half the tool calls. local is not frontier yet.

use local inference labs nvfp4, it’s significantly better than libert! forums.developer.nvidia.com/…

I got my first contribution to vllm v0.28.0! github.com/vllm-project/vllm… github.com/vllm-project/vllm…

after a week of dsv4 flash on 4 sparks, i've decided to switch back to glm 5.2. but i discovered that i can offload kv cache to disk to avoid long cold pre-fills on agentic sessions. 600k max context windows x 8!? amazing.

there’s a big issue with dsv4 flash on jasl vllm. after 80k tokens with parallel sessions, it can corrupt, been debugging it for multiple days now, anyone else run into this?

4 sparks with cooling serving glm / dsv4. can’t wait to see what’s next!

dsv4 flash (no quant) losing its mind. has anyone else seen this?

dsv4 flash on 4 dgx spark is fast, but the token efficient is way worse than glm 5.2, wall clock is similar on my internal coding benchmarks, but dsv4 uses 10x the amount of tokens. is it better? maybe. speed wise yes, but it thinks harder not smarter.

Exciting new feature for @SQLMesh. Custom signals / triggers. SQLMesh's built-in scheduler controls which models are evaluated when the sqlmesh run command is executed. It determines whether to evaluate a model based on whether the model's cron has elapsed since the previous evaluation. For example, if a model's cron was @daily, the scheduler would evaluate the model if its last evaluation occurred on any day before today. Unfortunately, the world does not always accommodate our data system's schedules. Data may land in our system after downstream daily models already ran. The scheduler did its job correctly, but today's late data will not be processed until tomorrow's scheduled run. You can now use signals to prevent this problem! Just write a function in Python to determine which intervals are ready to be processed. sqlmesh.readthedocs.io/en/la…

⚠️⚠️Read this before you start using dbt's microbatch models. There are three large gaps that could lead to serious data issues. Due to fundamental architectural design choices of dbt, the microbatch implementation is very limited. At its core, dbt is a stateless scripting tool with no concept of time, meaning it is the user's responsibility to figure out what data needs to be processed. 1. dbt's microbatch can lead to silent data gaps 2. dbt's lack of scheduling requires manual orchestration which could lead to incomplete and incorrect data 3. Mixed time granularities in microbatch can cause incomplete data and wasted compute tobikodata.com/dbt-increment…