mchiang

we are learning the usage patterns to be able to price this more properly.

login does not mean payment. It is free to use. It costs us to perform the web search, so we want to make sure it is not subject to abuse.

sorry that you feel the way you feel. :(

I'm not sure which package we use that is triggering this. My guess is llama.cpp based on what I see on social? Ollama has long shifted to using our own engine. We do use llama.cpp for legacy and backwards compatibility. I want to be clear it's not a knock on the llama.cpp project either.

There are certain features we want to build into Ollama, and we want to be opinionated on the experience we want to build.

Have you supported our past gigs before? Why not be more happy and optimistic in seeing everyone build their dreams (success or not).

If you go build a project of your dreams, I'd be supportive of it too.

Thanks for the kind words.

Since the new multimodal engine, Ollama has moved off of llama.cpp as a wrapper. We do continue to use the GGML library, and ask hardware partners to help optimize it.

Ollama might look like a toy and what looks trivial to build. I can say, to keep its simplicity, we go through a deep amount of struggles to make it work with the experience we want.

Simplicity is often overlooked, but we want to build the world we want to see.

Ollama is not run by Facebook. We are a small team building our dreams.

we have always been building in the open, and so is Ollama. All the core pieces of Ollama are open. There are areas where we want to be opinionated on the design to build the world we want to see.

There are areas we will make money, and I wholly believe if we follow our conscious we can create something amazing for the world while making sure we can keep it fueled to keep it going for the long term.

Some of the ideas in Turbo mode (completely optional) is to serve the users who want a faster GPU, and adding in additional capabilities like web search. We loved the experience so much that we decided to give web search to non-paid users too. (Again, it's fully optional). Now to prevent abuse and make sure our costs don't go out of hand, we require login.

Can't we all just work together and create a better world? Or does it have to be so zero sum?

Ollama at its core will always be open. Not all users have the computer to run models locally, and it is only fair if we provide GPUs that cost us money and let the users who optionally want it to pay for it.

we keep it for backwards compatibility - all the newer models are implemented inside Ollama directly

Thanks for the kind words. Sorry about that, we are working out some of the initial experience for Ollama.

In the app settings now, there is a toggle for "Expose Ollama to the network" - it allows for other devices or services on the network to access Ollama.

This is a feature we are looking into supporting. Thank you for reaffirming the need.

Rightful worry, and we had the same doubts before we embarked on this. Ollama serves developers, there is no doubt about that. The CLI isn’t getting dropped, in fact, what we’ve learned in building it is having the interface interacting with Ollama is a great way for us to dogfood Ollama while building it.

There are so many choices for having an interface, and as a developer you should have a choice in selecting the UI you want. It will all continue to work with Ollama. Nothing about that changes.

unfortunately, I don't think gemma 3 supports tool calling well. It's not trained into the model, and the 'support' for tool calling is post model training.

We are working with Google, and trying to give the feedback on improving tool calling capabilities for future Gemma models. Fingers crossed!

We work closely with majority of research labs / model creates directly. Most of the times we will support models on release day. There are sometimes where the release window for major models are fairly close - and we just have to elect to support models where we believe will better support a majority of users.

Nothing out of spite, and purely limited by the amount of effort required to support these models.

We are hopeful too -- where users can technically add models to Ollama directly. Although there is definitely some learning curve.

the model is running locally - you can check by turning off the wifi.

One of the maintainers. The logo and all the illustrations are done by a human artist.

This is just wrong. Ollama has moved off of llama.cpp and is working with hardware partners to support GGML. https://ollama.com/blog/multimodal-models

Ben, we've had private conversations about this previously. I don't see any VC money grab nor am I aware of any.

Building a product that we've dreamed of building is not wrong. Making money does not need to be evil. I, and the folks who worked tirelessly to make Ollama better will continue to build our dreams.

We don't have this kind of power, and in fact, most our posts gets deleted so we don't post. We do read comments and help if we can.

Negative comments help us grow and make Ollama better any way. We can take harsh feedback to make Ollama better.

Choice is good but here is why prefer Ollama over others (I'm biased because I work on Ollama).

Supporting multiple backends is HARD. Originally, we thought we'd just add multiple backends to Ollama - MLX, ROCm, TRT-LLM, etc. It sounds really good on paper. In practice, you get into the lowest common denominator effect. What happens when you want to release Model A together with the model creator, and backend B doesn't support it? Do you ship partial support? If you do, then you start breaking your own product experience.

Supporting Vulkan for backwards compatibility on some hardware seems simple right? What if I told you in our testing, there is a portion of the supported hardware matrix getting -20% decrease in performance. What about just cherry picking which hardware to use Vulkan vs ROCm vs CUDA, etc? Do you start managing a long and tedious support matrix, where each time a driver is updated, the support may shift?

Supporting flash attention sounds simple too right? What if I told you over 20% of the hardware and for specific models, enabling it will cause non-trivial amount errors pertaining to specific hardware/model combinations? We are almost in a spot, where we can selectively enable flash attention per type of model architecture and hardware architecture.

It's so easy to add features, and hard to say no, but given any day, I will stand for a better overall product experience (at least to me since it's very subjective). No is temporary and yes is forever.

Ollama focuses on running the model the way the model creators intended. I know we get a lot of negativity on naming but often times, it's what we work with the model creators on naming (which surprisingly may or may not be how another platform named it on release). Overtime, I think this means more focus on top models to optimize more and add capabilities to augment the models.

one of the maintainers for Ollama. I don't see it as a pivot. We are all developers ourselves, and we use it.

In fact, there are many self-made prototypes before this from different individuals. We were hooked, so we built it for ourselves.

Ollama is made for developers, and our focus in continually improving Ollama's capabilities.

this is something we are working on. I don't have a specific timeline since it's done when its done, but it is being worked on.

Linux does not have the interface right now, and there are a lot of options for users. Open WebUI is an awesome project.

https://github.com/open-webui/open-webui

I'm one of the maintainers who ran that example. I am Chinese.

The English translation, I thought was pretty spot on. We don't hide the mistakes of the models or fake the demos.

Overtime, of course I hope the models to improve much more

We partner with Cloudflare R2 to minimize the cost of hosting. Check out their pricing.

The website is so minimal right now because we have been focused on the GitHub repo.

Can confirm it doesn't. Many Ollama posts get pushed off the front page too despite having hundreds of points. Over time I understood. If they did this for YC companies, it would ruin the trust of HN, YC, and probably the most important to YC companies, the reputation of the startup itself.

I’m one of the maintainers of Ollama.

It’s amazing to see others build on top of open-source projects. Forks like RamaLama are exactly what open source is all about. Developers with different design philosophies can still collaborate in the open for everyone’s benefit.

Some folks on the Ollama team have contributed directly to the OCI spec, so naturally we started with tools we know best. But we made a conscious decision to deviate because AI models are massive in size - on the order of gigabytes - and we needed performance optimizations that the existing approaches didn’t offer.

We have not forked llama.cpp, We are a project written in Go, so naturally we’ve made our own server side serving in server.go. Now, we are beginning to hit performance, reliability and model support problems. This is why we have begun transition to Ollama’s new engine that will utilize multiple engine designs. Ollama is now naturally responsible for the portability between different engines.

I did see the complaint about Ollama not using Jinja templates. Ollama is written in Go. I’m listening but it seems to me that it makes perfect sense to support Go templates.

We are only a couple of people, and building in the open. If this sounds like vendor lock-in, I'm not sure what vendor lock-in is?

You can check the source code: https://github.com/ollama/ollama

Ollama has the ability to pull models off Hugging Face as well:

https://huggingface.co/docs/hub/en/ollama

the 671B model is now available:

4 bit quantized: ollama run deepseek-r1:671b

(400GB+ VRAM/Unified memory required to run this)

https://ollama.com/library/deepseek-r1/tags

8 bit quantization still being uploaded

Did you mean the tags or the specific names from the distilled models?