FredyRivera-dev (Fredy Rivera)

reacted to their post with ❤️ 7 days ago

Post

46

I ported Evo 2 inference to plain PyTorch and Transformers so the official checkpoints load through AutoModelForCausalLM with no Vortex, Transformer Engine, or custom kernels required.

What is included:

- GitHub repo with the port, a Vortex to HF converter, and a gene completion repro script: https://github.com/Aquiles-ai/Evo2-transformers

- Aquiles-ai/Evo2-1B-Base: the 1B base checkpoint (8k context) in Transformers format: Aquiles-ai/Evo2-1B-Base

- Aquiles-ai/Evo2-7B: the 7B checkpoint (1M context) in Transformers format: Aquiles-ai/Evo2-7B

Both repos vendor the modeling files, so loading needs trust_remote_code=True. The tokenizer matches the original byte level behavior, including the vortex_tokenize and vortex_detokenize helpers.

One honest note: this port is less efficient than the original Vortex stack. It has no FlashAttention, no FP8 path, and no recurrent state decoding, so generation recomputes the prefix and long contexts are slow. For large scale or 1M context work, use the original implementation or NVIDIA NIM.

All credit for the model, data, and research goes to the Evo 2 team at Arc Institute and collaborators. Original project: https://github.com/ArcInstitute/evo2. Paper: https://www.nature.com/articles/s41586-026-10176-5

Feedback and corrections are welcome as GitHub issues on the port repo.

posted an update 7 days ago

Post

46

I ported Evo 2 inference to plain PyTorch and Transformers so the official checkpoints load through AutoModelForCausalLM with no Vortex, Transformer Engine, or custom kernels required.

What is included:

- GitHub repo with the port, a Vortex to HF converter, and a gene completion repro script: https://github.com/Aquiles-ai/Evo2-transformers

- Aquiles-ai/Evo2-1B-Base: the 1B base checkpoint (8k context) in Transformers format: Aquiles-ai/Evo2-1B-Base

- Aquiles-ai/Evo2-7B: the 7B checkpoint (1M context) in Transformers format: Aquiles-ai/Evo2-7B

Both repos vendor the modeling files, so loading needs trust_remote_code=True. The tokenizer matches the original byte level behavior, including the vortex_tokenize and vortex_detokenize helpers.

One honest note: this port is less efficient than the original Vortex stack. It has no FlashAttention, no FP8 path, and no recurrent state decoding, so generation recomputes the prefix and long contexts are slow. For large scale or 1M context work, use the original implementation or NVIDIA NIM.

All credit for the model, data, and research goes to the Evo 2 team at Arc Institute and collaborators. Original project: https://github.com/ArcInstitute/evo2. Paper: https://www.nature.com/articles/s41586-026-10176-5

Feedback and corrections are welcome as GitHub issues on the port repo.

replied to branikita's post 16 days ago

Looks great!

reacted to branikita's post with 🔥 16 days ago

Post

2223

SO-ARM 102 goes open source in the next few weeks.

What's new:
- A parallel gripper: the jaws stay parallel through the whole stroke instead of pivoting around the object as they close.
- PET-CF instead of PLA+ for a much stiffer frame.
- A topology-optimized structure.
- Wider joint rotation and folding range.
- STS3250 servos on the first shoulder joint.

Compared with the SO-ARM 101, that adds up to 2.5x the payload, roughly 2x better positioning accuracy, roughly 1.6x the movement speed, and about 36 mm more reach.

It runs on Hugging Face LeRobot, so the same tooling, training pipeline and tutorials for the SO-ARM 101 work on it from day one.

1 reply

·

reacted to sergiopaniego's post with 🔥 17 days ago

Post

2080

Can you do RL over taste?

I've spent some time reproducing, in the open, Surya N's idea of training a model to paint with code. It's a coding model that learns to paint watercolours by writing JS code, trained with GRPO. I used TRL and OpenEnv for this, with the whole pipeline running on Hugging Face.

The interesting part is that the reward has no correct answer, unlike a math problem. In this case it's based on the artistic preferences of the person who builds the dataset.

Everything is published: the environment, the reference pool, the trained adapters, every painting of every run with the code that made it, and a write-up with all the decisions, including the ones that went wrong.

Blog post: https://huggingface.co/blog/train-to-paint-with-code

reacted to salma-remyx's post with 🚀 24 days ago

Post

2355

We just published two training-free 🧩 Modular Diffusers community pipelines that push off-the-shelf FLUX to 4096².
No fine-tuning, no extra weights, no upscaler.

The methods take different routes around positional extrapolation:

✅ **HRDiT:** resolution ladder + NTK RoPE + spatial-position alignment + structure guidance

✅ **DyPE:** single-pass, timestep-dynamic RoPE (κ=t²), plus an optional SEGA spectral mode that removes high-frequency speckle

Because both expose the same block interface, you can A/B the two methods on the same FLUX.1-Krea-dev weights by swapping the repo ID:

import torch
from diffusers import ModularPipeline

repo_id = "remyxai/dype-flux-modular"
# or "remyxai/hrdit-flux-modular"

pipe = ModularPipeline.from_pretrained(
    repo_id,
    trust_remote_code=True,
)
pipe.load_components(dtype=torch.bfloat16)
pipe.to("cuda")

img = pipe(
    prompt="...",
    height=4096,
    width=4096,
).images[0]

Both implementations address open diffusers requests (#14480, #14520).

Check out the collection! https://huggingface.co/collections/remyxai/training-free-high-resolution-generation-with-flux

reacted to salma-remyx's post with ❤️ 25 days ago

Post

2720

If you can’t explain why your AI-generated contribution belongs in the repo, don’t put it in a maintainer’s queue 🙅🏻‍♀️

Before asking for review, you should be able to answer:

1. What project need does it address?
2. Where does it fit, and does it duplicate existing work?
3. What evidence shows it works, and will you own it through review?

If you can’t answer those, you haven’t saved anyone time. You’ve passed the buck to the maintainer.

Outrider has made us better contributors by doing more of this work before upstream review by
* reading contribution rules, accepted PRs, and open issues
* finding needs and integration points
* drafting the code, tests, and context.

We still decide what deserves to go upstream, verify the claims, coordinate with maintainers and contributors, and stay involved through review.

On huggingface/peft, only 4 of 20 Outrider runs opened draft PRs. Two contributions have now merged:

✅ Riemannian-preconditioned LoRA: https://github.com/huggingface/peft/pull/3382
✅ Super-Tuning: https://github.com/huggingface/peft/pull/3518

We have more contributions in review and far more ideas were filtered out before they reached a maintainer.

Full case study: https://remyx.ai/case-study
Outrider: https://github.com/remyxai/outrider

11 replies

·

reacted to their post with 🚀 about 1 month ago

Post

3441

I've written a technical blog post about how we create a multimodal model:

Kairos: a multimodal model built with LFM2.5-2.6B as the LLM, MoonViT-3D (the vision tower of Kimi-K2.6) as the vision encoder, and a custom projector.

The original plan was LLaVA's approach, two stages: first align the projector with the LLM frozen, and then train the projector + LLM together. The first stage worked in terms of loss (ablation with +3.7 nats in favor of the image), but in free generation the image shifted the logits without changing the argmax: the model received the image and ignored it. That's why we jumped directly to early fusion, with a reasoning dataset.

For that, we created Kairos-Multimodal-Reasoning: 116,357 examples with explicit reasoning traces, generated through distillation (60,041 from LLaVA-CC3M, 2,295 from WebSight, and 54,021 from Zebra-CoT), with GPT 5.6 Luna, Inkling, Qwen 3.6 27B, and Qwen 3.7 Plus as teachers.

The training, in two phases:

1. Projector through backbone with 80k image-text pairs (Kairos-Proj-80k).
2. Projector + LoRA (r=16) with 30k examples from the reasoning dataset (Kairos-Alig-30k).

Everything is open source:

- Full blog post with the process: https://aquiles-ai.vercel.app/blog/kairos-a-multimodal-model
- Implementation: https://github.com/Aquiles-ai/Kairos

To be honest: the checkpoints are not a competent model, they are experimental artifacts. But they validated the approach and precisely defined what the next iteration needs.

https://huggingface.co/collections/Aquiles-ai/kairos

Aquiles-ai/MoonViT-3D

LiquidAI/LFM2.5-2.6B

posted an update about 1 month ago

Post

3441

I've written a technical blog post about how we create a multimodal model:

Kairos: a multimodal model built with LFM2.5-2.6B as the LLM, MoonViT-3D (the vision tower of Kimi-K2.6) as the vision encoder, and a custom projector.

The original plan was LLaVA's approach, two stages: first align the projector with the LLM frozen, and then train the projector + LLM together. The first stage worked in terms of loss (ablation with +3.7 nats in favor of the image), but in free generation the image shifted the logits without changing the argmax: the model received the image and ignored it. That's why we jumped directly to early fusion, with a reasoning dataset.

For that, we created Kairos-Multimodal-Reasoning: 116,357 examples with explicit reasoning traces, generated through distillation (60,041 from LLaVA-CC3M, 2,295 from WebSight, and 54,021 from Zebra-CoT), with GPT 5.6 Luna, Inkling, Qwen 3.6 27B, and Qwen 3.7 Plus as teachers.

The training, in two phases:

1. Projector through backbone with 80k image-text pairs (Kairos-Proj-80k).
2. Projector + LoRA (r=16) with 30k examples from the reasoning dataset (Kairos-Alig-30k).

Everything is open source:

- Full blog post with the process: https://aquiles-ai.vercel.app/blog/kairos-a-multimodal-model
- Implementation: https://github.com/Aquiles-ai/Kairos

To be honest: the checkpoints are not a competent model, they are experimental artifacts. But they validated the approach and precisely defined what the next iteration needs.

https://huggingface.co/collections/Aquiles-ai/kairos

Aquiles-ai/MoonViT-3D

LiquidAI/LFM2.5-2.6B

reacted to Banaxi-Tech's post with 👀 about 1 month ago

Post

3746

We're releasing BananaMind 2.1 Unified, a 35M three-tower relay model where the two output towers can only talk to each other through a silent middle tower that has no output head and no loss term.

Tower B trains entirely on indirect gradient. It was never told what to predict. It woke up anyway. Jacobian lens shows it carrying the correct answer ("Paris", "oxygen", "blue") at its deepest layer. Its bridge gates grew 4-47x from init. Feed it from only one side and the representations collapse to junk — it needs both outer towers to become semantic.

The PIQA result is the cleanest demonstration: Tower A alone scores 50.11 (chance). Tower C alone 52.12. Full system 61.75. All physical reasoning lives in the integration. The 35M three-tower beats the 50M single-tower BananaMind 2 Medium on PIQA.

Trained on 38B tokens in ~7.5 hours on 8x RTX PRO 6000. Ships with 7 ablation modes so you can surgically cut the model apart without retraining. Full training logs, J-lens fits, and eval outputs for every mode included.

This is a research model. It is interesting because you can take it apart.
BananaMind/BananaMind-2.1-Unified

Follow us for more:

BananaMind

@Banaxi-Tech

11 replies

·

reacted to their post with 🚀 about 2 months ago

Post

6410

We wrote a full technical guide on how to train a bilingual (ES/EN) LLM from scratch: TinyQwen.

Covers:
- Hybrid architecture based on Qwen3.5
- Pre-training with 15B tokens
- Cost benchmark between H200 and B200
- Post-training with SFT + LoRA
- Full code and data, open source

With ~$11 of compute on an H200 we ran an initial training run, enough to validate the full architecture and pipeline.

Blog post: https://aquiles-ai.vercel.app/blog/tinyqwen-from-scratch

Technical feedback welcome, especially from anyone looking to replicate the pipeline with more compute.

3 replies

·

posted an update about 2 months ago

Post

6410

We wrote a full technical guide on how to train a bilingual (ES/EN) LLM from scratch: TinyQwen.

Covers:
- Hybrid architecture based on Qwen3.5
- Pre-training with 15B tokens
- Cost benchmark between H200 and B200
- Post-training with SFT + LoRA
- Full code and data, open source

With ~$11 of compute on an H200 we ran an initial training run, enough to validate the full architecture and pipeline.

Blog post: https://aquiles-ai.vercel.app/blog/tinyqwen-from-scratch

Technical feedback welcome, especially from anyone looking to replicate the pipeline with more compute.

3 replies

·

Fredy Rivera

AI & ML interests

Recent Activity

Organizations

Fredy Rivera

AI & ML interests

Recent Activity

Organizations

FredyRivera-dev's activity