I looked at using ollama when I started making FreeChat [0] but couldn't figure out a way to make it work without asking the user to install it first (think I asked in your discord at the time). I wanted FreeChat to be 1-click install from the mac app store so I ended up bundling the llama.cpp server instead which it runs on localhost for inference. At some point I'd love to swap it out for ollama and take advantage of all the cool model pulling stuff you guys have done, I just need it to be embeddable.
My ideal setup would be importing an ollama package in swift which would start the server if the user doesn't already have it running. I know this is just js and python to start but a dev can dream :)
Either way, congrats on the release!
Among the problems with Ollama include:
* Ollama silently adds a login item with no way to opt out: <https://github.com/jmorganca/ollama/issues/162>
* Ollama spawns at least four processes, some persistently in the background: 1 x Ollama application, 1 x `ollama` server component, 2 x Ollama Helper
* Ollama provides no information at install time about what directories will be created or where models will be downloaded.
* Ollama prompts users to install the `ollama` CLI tool, with admin access required, with no way to cancel, and with no way to even quit the application at that point. Ollama provides no clarity that about what is actually happening during this step: all it is doing is symlinking `/Applications/Ollama.app/Contents/Resources/ollama` to `/usr/local/bin/`
The worst part is that not only is none of this explained at install time, but the project README doesn’t tell you any of this information either. Potential users deserve to know what will happen on first launch, but when a PR arrived to at least provide that clarification in the README, Ollama maintainers summarily closed that PR and still have not rectified the aforementioned UX problems.
As an open source maintainer myself, I understand and appreciate that Ollama developers volunteer their time and energy into the project, and they can run it as they see fit. So I intend no disrespect. But these problems, and a seeming unwillingness to prioritize their resolution, caused me to delete Ollama from my system entirely.
As I said above, I think LLM[0] by Simon Willison is an excellent and user-friendly alternative.
nix-shell -p ollama
in two tmux windows, then ollama serve
in one and ollama run llama2
in the other.Exit and all the users, processes etc, go away.
https://search.nixos.org/packages?channel=23.11&show=ollama&...
[1] https://github.com/simonw/llm
[2] https://docs.nos.run/docs/blog/serving-llms-on-a-budget.html...
The install on Linux is the same. You’re essentially encouraged to just
curl https://ollama.ai/install.sh | sh
which is generally a terrible idea. Of course you can read the script but that misses the point in that that’s clearly not the intended behaviour.As other commenters have said, it is convenient. Sure.
from ollama import Client
client = Client(host='http://localhost:11434')
But I don't quite get how the example in "Usage" can work: import ollama
response = ollama.chat(model='llama2', messages=[
{
'role': 'user',
'content': 'Why is the sky blue?',
},
])
print(response['message']['content'])
Since there is no parameter for host and/or port.I was able to get the setup done with a single script for the end user and I used langchain to interact with Ollama.
I create a GIST with a quick and dirty way of generating a dataset for fine-tuning Mistral model using Instruction Format on a given topic: https://gist.github.com/ivanfioravanti/bcacc48ef68b02e9b7a40...
Imagine you have an API-endpoint where you can set the level of some lights and you give the chat a system prompt explaining how to build the JSON body of the request, and the user can prompt it with stuff like "Turn off all the lights" or "Make it bright in the bedroom" etc.
How low could the memory consumption of such a model be? We don't need to store who the first kaiser of Germany was, "just" enough to kinda map human speech onto available API's.
The problem is they are all still broadly trained and so they end up being Jack of all trades master of none. You'd have to fine tune them if you want them good at some narrow task and other than code completion I don't know that anyone has done that.
If you want to generate json or other structured output, there is Outlines https://github.com/outlines-dev/outlines that constrains the output to match a regex so it guarantees e.g. the model will generate a valid API call, although it could still be nonsense if the model doesn't understand, it will just match the regex. There are other similar tools around. I believe llama.cpp also has something built in that will constrain the output to some grammar.
Aside: I expect Apple will do exactly what you're proposing and that's why they're exposing more APIs for system apps
Now, models that have "reasoning" as an emergent property... I haven't seen anthing under 3B that's capable of making anything useful. The smaller I've seen is litellama and while it's not 100% useless, it's really just an experiment.
Also, everything requires new and/or expensive hardware. For GPU you really are about 1k€ at minumum for something decent for running models. CPU inference is way slower and forget about anythin that has no AVX and preferably AVX2.
I try models on my old thinkpad x260 with 8Gb ram, which is perfectly capable for developing stuff and those small task oriented I've told you about, but even though I've tried everything under the sun, with quantization etc, it's safe to say you can only run decent LLMs with a decent inference speed with expensive hardware now.
Now, if you want task like, language detection, classifying text into categories, etc, very basic Question Answering, then go on HugginFace and try youself, you'll be capable of running most models on modest hardware.
In fact, I have a website (https://github.com/iagovar/cometocoruna/tree/main) where I'm using a small flask server in my data pipeline to extract event information from text blobs I get scraping sites. That runs every day in an old Atom + 4Gb RAM laptop that I use as sever.
Experts in the field say that might change (somewhat) with mamba models, but I can't really say more.
I've been playing with the idea of dumping some money. But I'm 36, unemployed and just got into coding about 1.5 years ago, so until I secure some income I don't want to hit my saving hard, this is not the US where I can land a job easy (Junior looking for job, just in case someone here needs one).
Local LLMs are great! But, it would be more useful once we can _easily_ throw our own data for them to use as reference or even as a source of truth. This is where it opens doors that a closed system like OpenAI cannot - I’m never going to upload some data to ChatGPT for them to train on.
Could Ollama make it easier and standardize the way to add documents to local LLMs?
I’m not talking about uploading one image or model and asking a question about it. I’m referring to pointing a repository of 1000 text files and asking LLMs questions based on their contents.
I’ve implemented a RAG library if you’re ever interested but they are a dime a dozen now :)
In the meanwhile, we do have agreements in place with all of our AI providers to ensure none of our users information is used for training or any other purpose. Hope that helps!
If you use the API, they do not train on it.
(However, that doesn't mean they don't retain it for a while).
As others have said, RAG is probably the way to go - although I don't know how well RAG performs on local LLMs.
You can be 100% sure that OpenAI will do whatever they want whenever they want with any and every little bit of data that you upload to them.
With GPTs and their Embeddings endpoint, they encourage you to upload your own data en masse.
To index documents for RAG, Ollama also offers an embedding endpoint where you can use LLM models to generate embeddings, however AFAIK that is very inefficient. You'd usually want to use a much smaller embedding model like JINA v2[0], which are currently not supported by Ollama[1].
[0]: https://huggingface.co/jinaai/jina-embeddings-v2-base-en
It's meant to do exactly what you want. I've had mixed results.
It blocks until there is something on the mic, then sends the wav to whisper.cpp, which then sends it to llama which picks out a structured "remind me" object from it, which gets saved to a text file.
I’ll give this Python library a try. I’ve been wanting to try some fine tuning with LLMs in the loop experiments.
Install Ollama from https://ollama.ai and experiment with it using the command line interface. I mostly use Ollama’s local API from Common Lisp or Racket - so simple to do.
EDIT: if you only have 8G RAM, try some of the 3B models. I suggest using at least 4 bit quantization.
You can easily experiment with smaller models, for example, Mistral 7B or Phi-2 on M1/M2/M3 processors. With more memory, you can run larger models, and better memory bandwidth (M2 Ultra vs. M2 base model) means improved performance (tokens/second).
I have not ran into a llama that won't run, but if it doesn't fit into my GPU you have to count seconds per token instead of tokens per second
Since that post, we shipped experimental support in our product for Ollama-based local inference. We had to write our own client in TypeScript but will probably be able to switch to this instead.
All it took for me to get going is `make` and I basically have it working locally as a console app.
Recently, it got better (though maybe not perfect yet) at calculating how many layers of any model will fit onto the GPU, letting you get the best performance without a bunch of tedious trial and error.
Similar to Dockerfiles, ollama offers Modelfiles that you can use to tweak the existing library of models (the parameters and such), or import gguf files directly if you find a model that isn’t in the library.
Ollama is the best way I’ve found to use LLMs locally. I’m not sure how well it would fare for multiuser scenarios, but there are probably better model servers for that anyways.
Running “make” on llama.cpp is really only the first step. It’s not comparable.
[1]: https://msty.app
Nitro outstripped them, 3 MB executable with OpenAI HTTP server and persistent model load
If you do build from source, it should work (Instructions below):
https://github.com/ollama/ollama/blob/main/docs/development....
The reason why it's not in released builds is because we are still testing ROCm.
You can be a linux/python dev and set up rocm.
Or you can run llama.cpp's very slow OpenCL backend, but with easy setup.
Or you can run MLC's very fast Vulkan backend, but with no model splitting and medium-hard setup.
There a bunch of methods need to be implemented to work, but then usual OpenAI buts can be switched out to anything else, e.g. see the code stub in https://vanna.ai/docs/bigquery-other-llm-vannadb.html
Looking forward to more remixes for other tools too.
https://github.com/ollama/ollama/issues/1536
Not to mention, they hide all the server configs in favor of their own "sane defaults".
You can enable mlock manually in the /api/generate and /api/chat endpoints by specifying the "use_mlock" option:
{“options”: {“use_mlock”: true}}
Many other sever configurations are also available there: https://github.com/ollama/ollama/blob/main/docs/api.md#reque...
Try to, for example, set 'num_gpu' to 99 and 'use_mlock' to true.
For an OpenAI compatible API my current favorite method is to spin up models using oobabooga TGW. Your OpenAI API code then works seamlessly by simply switching out the api_base to the ooba endpoint. Regarding chat formatting, even ooba’s Mistral formatting has issues[1] so I am doing my own in Langroid using HuggingFace tokenizer.apply_chat_template [2]
[1] https://github.com/oobabooga/text-generation-webui/issues/53...
[2] https://github.com/langroid/langroid/blob/main/langroid/lang...
Related question - I assume ollama auto detects and applies the right chat formatting template for a model?
Also, you really want to wait until flash attention is merged before using mega context with llama.cpp. The 8 bit KV cache would be ideal too.
It is far more robust, integrates with any LLM local or hosted, supports multi-modal, retries, structure parsing using zod and more.
Ollama already exposes REST API that you can query with whatever language (or you know, just using curl) - why do I want to use Python or JS?
* Lightweight. Total runtime size is 30MB as opposed 4GB for Python and 350MB for Ollama. * Fast. Full native speed on GPUs. * Portable. Single cross-platform binary on different CPUs, GPUs and OSes. * Secure. Sandboxed and isolated execution on untrusted devices. * Modern languages for inference apps. * Container-ready. Supported in Docker, containerd, Podman, and Kubernetes. * OpenAI compatible. Seamlessly integrate into the OpenAI tooling ecosystem.
Give it a try --- https://www.secondstate.io/articles/wasm-runtime-agi/
For ollama, llama2:7b is 3.8 GB. See: https://ollama.ai/library/llama2/tags. Still I see ollama requires less RAM to run llama 2
“Please don't use HN primarily for promotion. It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity.”
That user almost exclusively links to what appears to be their own product, which is self promotion. They also do it without clarifying their involvement, which could come across as astroturfing.
Self promotion sometimes (not all the time) is fine, but it should also be clearly stated as such. Doing it in a thread about a competing product is not ideal. If it came up naturally, that would be different from just interjecting a sales pitch.
I haven’t downvoted them, but I came close.
Just use a sensibly named export, you were going to write a "how to use" code snippet for the top of your readme anyway.
Also means that all of the code snippets your users send you will be immediately sensible, even without them having to include their import statements (assuming they don't use "as" renaming, which only makes sense when there's conflicts anyway)