Explore setting up an "Olmo" LLM model ("32B-Instruct") Fedora playground #24
Labels
No labels
good first issue
help wanted
huge
needs
changes
needs
reporter feedback
needs
triage
quickfix
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
type
docs
type
packaging
type
skills
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ai-ml/tickets#24
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What?
Olmo 3 is a "truly transparent" LLM model by the non-profit, Allen Institute for AI. In my limited testing, it is still very rough and currently lags behind other semi-open models in terms of performance.
The reason why I suggest Olmo is that it opens up the "the entire model flow – not just its endpoint". Meaning, "the full lifecycle of a Language Model: every stage, checkpoint, dataset, and dependency required to create and modify it" (from their announcement on Olmo 3.)
Why?
"Olmo" family of models are the closest LLM models that align with Fedora's spirit in terms of transparency and openness.
Which model to choose?
They have
32B-Base,32B-Think, and32B-Instructmodels. Once Fedora has sufficient AI hardware, we should go for the most capable one,32B-Instruct.References:
This issue came up in a conversation I was in recently. It made me curious what the wider Fedora community thinks. I created a new Fedora Discussion topic to solicit input and opinions.
Discussed in 2026-10-14 FRCL meeting.
During the October 14, 2026 FRCL sync, participants evaluated Allen Institute's OLMo as part of our strategic analysis on AI model alignment. On the plus side, OLMo represents the gold standard for software and data transparency under the Four Freedoms, providing completely public training datasets, open modeling code, and permissive licensing that allows full auditability. However, OLMo currently exhibits significant drawbacks: its capability, reasoning quality, and task effectiveness lag noticeably behind leading open-weight alternatives, and its high compute and energy overhead poses real ecological and operational cost concerns. Additionally, OLMo lacks turnkey availability across upstream inference providers, creating contributor tooling hurdles unless Fedora operates its own dedicated hosting. Because deploying such a model effectively depends on shared project infrastructure, this ticket is being closed until the community is positioned to drive toward centralized contributor inference services.
Follow-up Items: