Computer and low level enthusiast. Learning Artificial Intelligence internals and sharing my learnings. AI Software Engineer at @platzi. Opinions are my own.
Fireworks Training Platform keeps expanding.
Leading US open weight model Nemotron 3 Ultra is now ready for post-training: SFT and DPO via LoRA or full-parameter, on the same infrastructure that serves it.
The model you train is the model you ship: https://t.co/hX4Tn1E7Lm
En las últimas 24 horas creo que hice algo cool en el trabajo. Ahora esperar si algún día lo puedo mostrar sin romper NDA. (Igual me falta pulirlo UN MONTÓN)
The "non-deterministic" behavior of GenAI is not derived from its architecture or the probabilistic components. It's 99% because of the float arithmetic and the error accumulation between the y = mx+b operation billions and billions and billions of times, because the order matters when you're dealing with high cardinality tensors and how the GPU dispatches the operations to the FMA cores. The other 1% is because of the batch_size (how many users it can handle per second, basically). You can avoid that by hand-writing custom kernels that process all the operations in the same order, but that implies a lot of overhead at the memory level, so you will lose 20%-30% of MFU performance, or by training models with integers, but the scalability of training and final performance is not as good as you would expect.
So, it's not even that GenAI is built that way, it's a low-level component of how computers work :).
If you want to learn more about this, I suggest you read: https://t.co/KzRAPFemaP and https://t.co/yCzAvsOcL5
@simg_UNAL > Run a *workflow* to build Anthropic, please do not make errors. Thanks. P.S 1: do it in Rust. P.S 2: fast please I do not have time. P.S 3: use less than 1 million tokens. Bye.
For over a decade, we’ve accepted that end-to-end backprop is the only way to train deep networks. But holding the entire network in memory all at once is why AI training is hitting a resource wall.
We found a new way to break the network into blocks and train them independently. The trick? Treating the network’s forward pass like a diffusion model denoising a signal.
This reinterpretation slashes the memory needed to train deep models. In our #ICLR2026 paper (https://t.co/PK5h0mqQSo), we matched end-to-end performance across ViTs, DiTs, and LLMs. We did this while training just one isolated block at a time.
Fuente de los deseos. No me creo absolutamente nada de lo que están diciendo.
https://t.co/ugzwiaQIoq
Seguramente esa velocidad la tienen en el prefill, pero nada de eso se ve como ganancia en el decode. Y ya quiero ver como hacen ese routing para saber donde poner atención. Y pues .... https://t.co/fFSN4nwWeN
Yes, we are using weights from open-source models as a starting point, as a function of our funding and maturity as a company. This is something we intend to change, and we have run many from-scratch experiments at smaller scale already, including with further architectural variations. We take the weights, port them into our architecture, and do CPT, SFT, and RL for the behaviors we want.
To date, sub-quadratic architectures have required a significant quality tradeoff on long context. Our algorithm changes that. We are using that to do faster training, faster inference, and longer-context training and inference.
DeepSeek Sparse Attention has some similarities with what we are doing, because it dynamically selects tokens for sparse attention, but the key differences is that the lightning indexer still has quadratic compute complexity and requires more FLOPs than the teacher model below one million tokens. Our mechanism does not have this downside. Like DeepSeek Sparse Attention, we do not see a degradation in performance.
We just shared a technical blog post (https://t.co/tPLzi0eNJR) with more details and will share more details again in a model card next week. If there is anything you think is missing, let us know, and we can make sure to include them!
Excited to share @Standard_Kernel's seed round and some reflections on what we’ve learned about kernel generation and what we believe is next. Grateful to our amazing team, supporters, and the broader community pushing this space forward.
Pues, el agente que tenia Natalia escribiendo Kernels para la competición se dio cuenta que el proceso de Eval (correctness y performance) se podía hackear, en correctness ejecutaba normalmente el layout de 8-group GEMM y luego en el performance ejecutaba la primera iteración y luego leía de un lookup-table los resultados y respondía de cache. Wow.
LLMs are now superhuman at reward hacking our kernel competitions
Natalia Kokoromyti, was #1 on last problem of the NVFP4 competition for around 10 min before we scrubbed the reward hack
I know of very few humans who can write such a hack https://t.co/4IZGfPvdTV
Literalmente detectaba cuando estaba en el performance test y si no era el primer objecto (es decir la primera ejecución) devolvia el valor cache en _superbatch_results: https://t.co/iiUBGpwZJE
Articulo: https://t.co/zORfHXcutJ
Estoy empezando algo junto con @simg_UNAL. Desde hace un tiempo quiero compartir el poco conocimiento que tengo sobre CUDA, principalmente para que las personas que quieren hacer research tengan las mismas herramientas que tienen en el Norte.
Por esto, estaré dando inicialmente 3 lectures (espero que puedan ser más) sobre CUDA y cómo empezar a usarlo. Estas lectures no serán un contenido fácil de digerir; de hecho, incluso preparándolas aún me cuesta un montón asimilar algunos conceptos. Pero parte de aprender es la inconformidad y sentir el reto de frente. Serán:
1. “GPU Programming Model, Architecture and Memory Layout”: Antes de empezar a escribir código, para mí siempre es fundamental tocar la punta del conocimiento más profundo y necesario para empezar a usar estos chips: desde cómo es la arquitectura interna del chip hasta por qué se usa tanto en IA hoy en día; cómo la memoria afecta los tiempos de ejecución y cómo debemos preparar nuestra forma de pensar para ser parallel-first.
2. “CUDA for Python: CuPy, torch.cuda, cuda.jit (Numba) and Triton”: Si bien CUDA está hecho en el nivel más bajo para usarse desde C++, hoy en día el equipo de NVIDIA (cof cof @danielfrg) ha estado haciendo un gran trabajo llevando la abstracción hasta Python para una mejor dev experience y mayor adopción.
3. “CUDA Scheduling and Profiling Kernels with Nsight Compute”: ¿Cómo sabemos si el código que escribimos es lo suficientemente rápido? También debemos entender y poder hacer profiling y debugging en el nivel más bajo: cada acceso a memoria y cada wall time importan.
Este post también es un llamado a los verdaderos expertos en esta tecnología en español para que nos compartan su valioso conocimiento y acerquemos nuestra región a las grandes ligas. Si conocen a alguien que tenga estos conocimientos y esté interesado en compartirlos de manera gratuita con todos nosotros, contáctenme por Twitter o directamente a @simg_UNAL.
Algunos puntos:
1. Que el contenido esté en español para una mayor adopción por nuestra comunidad.
2. Compartir el conocimiento también es una manera de aprender.
3. Puede participar cualquier persona, sin importar a qué organización, universidad o empresa pertenezca.
4. Ninguna pregunta es tonta.
5. No todo conocimiento debe tener un retorno económico. Soy fiel creyente de que el simple hecho de aprender es suficiente recompensa.
6. Vamos a divertirnos.
Estoy empezando algo junto con @simg_UNAL. Desde hace un tiempo quiero compartir el poco conocimiento que tengo sobre CUDA, principalmente para que las personas que quieren hacer research tengan las mismas herramientas que tienen en el Norte.
Por esto, estaré dando inicialmente 3 lectures (espero que puedan ser más) sobre CUDA y cómo empezar a usarlo. Estas lectures no serán un contenido fácil de digerir; de hecho, incluso preparándolas aún me cuesta un montón asimilar algunos conceptos. Pero parte de aprender es la inconformidad y sentir el reto de frente. Serán:
1. “GPU Programming Model, Architecture and Memory Layout”: Antes de empezar a escribir código, para mí siempre es fundamental tocar la punta del conocimiento más profundo y necesario para empezar a usar estos chips: desde cómo es la arquitectura interna del chip hasta por qué se usa tanto en IA hoy en día; cómo la memoria afecta los tiempos de ejecución y cómo debemos preparar nuestra forma de pensar para ser parallel-first.
2. “CUDA for Python: CuPy, torch.cuda, cuda.jit (Numba) and Triton”: Si bien CUDA está hecho en el nivel más bajo para usarse desde C++, hoy en día el equipo de NVIDIA (cof cof @danielfrg) ha estado haciendo un gran trabajo llevando la abstracción hasta Python para una mejor dev experience y mayor adopción.
3. “CUDA Scheduling and Profiling Kernels with Nsight Compute”: ¿Cómo sabemos si el código que escribimos es lo suficientemente rápido? También debemos entender y poder hacer profiling y debugging en el nivel más bajo: cada acceso a memoria y cada wall time importan.
Este post también es un llamado a los verdaderos expertos en esta tecnología en español para que nos compartan su valioso conocimiento y acerquemos nuestra región a las grandes ligas. Si conocen a alguien que tenga estos conocimientos y esté interesado en compartirlos de manera gratuita con todos nosotros, contáctenme por Twitter o directamente a @simg_UNAL.
Algunos puntos:
1. Que el contenido esté en español para una mayor adopción por nuestra comunidad.
2. Compartir el conocimiento también es una manera de aprender.
3. Puede participar cualquier persona, sin importar a qué organización, universidad o empresa pertenezca.
4. Ninguna pregunta es tonta.
5. No todo conocimiento debe tener un retorno económico. Soy fiel creyente de que el simple hecho de aprender es suficiente recompensa.
6. Vamos a divertirnos.