huggingface / huggingface/candle

Future of `candle-transformers` / long-term plans

Open
#1,186 5 comments 26 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
21k
Forks
1.8k
Avg merge
16h 42m
Merged PRs (30d)
25

Description

Hi there!

Apologies for the vague issue title, but I was struggling to think of one that conveyed my sentiments.

I'm the primary maintainer of [rustformers/llm](https://github.com/rustformers/llm), which implements several common LLM architectures atop GGML as an easy-to-use library. In some sense, it can be considered a robust, consistent and extensible Rust library-ification of `llama.cpp` with support for other architectures.

Recently, I've been considering [winding down development on it](https://github.com/rustformers/llm/discussions/435) in favour of encouraging people to use `candle-transformers` instead, because Candle can evolve faster than we do, supports more models, and isn't held back by the free time I/our contributors have.

My initial plan was to get `llm` back up to speed with the latest in `llama.cpp` and elsewhere, and then add support for other backends, so that Candle could be a secondary backend and (likely) become the primary backend in future. However, chasing a moving target is quite difficult, and `candle-transformers` already covers much of the same ground.

With that in mind, people in that discussion have raised a few issues around switching to `candle-transformers` and think `llm` is still relevant. I think it'd be simpler for the ecosystem if there was a single place for LLMs, but the concerns raised have made it harder to provide a straightforward recommendation to switch to `candle-transformers`.

So, here are my questions:

1) What's the long-term plan for `candle-transformers`? Vague question, I know, but will it live in this repo forever? Will it become an ecosystem unto itself like Python `transformers`?
2) Will the models share a unified interface to make it easy to swap between architectures?
3) Similarly, are there any plans to offer a higher-level abstraction for model inference? I'm not *completely* happy with our own interface, but it makes common tasks (prompt-feeding, streamed inference) easy, and harder tasks (custom inference, custom models) doable:
4) Are there plans for Metal acceleration support in the near-future? I'm guessing this is tracked in #313, but I'm not sure what the timeline of that is.
5) Finally, do you think a library like `llm` is necessary? My gut feeling is that Candle (and `candle-transformers`) could grow to cover all of its territory, but there may still be some value in custom high-level abstractions and support for other backends. That would be obviated by Candle developing its own high-level abstractions and increasing its backend support, though.

Sorry about the wall of questions, but your input is hugely useful in figuring out our own direction. Knowing what you have planned will clarify some of the unknowns for us and let us figure out what to do next.

Thanks in advance! ❤️

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the linked rustformers/llm discussion and crates/llm/examples/inference.rs, then review issue #313 for the Metal acceleration question. The issue names no implementation file or test; done would be a maintainer-backed roadmap addressing the listed architecture, interface, backend, and ecosystem questions.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
machine-learning
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.