However, as far as I can tell, it's never actually clear what the hardware requirements are to get these to run without fussing around. Am I wrong about this?
For running them, you want a GPU. The limitation is that the model fits in VRAM or the performance will be slow.
But if you don't care about speed, there's more options.
I personally use an uncensored version which is another huge benefit of a local model. Mainly because I have many kinky hobbies that piss off cloud models.
It's slowly getting there.
Was playing with them some more yesterday. Found that the 4bit ("q4") is much worse then q8 or fp16. Llama3.1 8B is ok, internlm2 7B is more precise. And they all hallucinate a lot.
Also found this page, that has some rankings: https://huggingface.co/spaces/open-llm-leaderboard/open_llm_...
In my opinion they are not really useful. Good for translations, to summaries some texts, and.. to ask in case you forgot some things about something. But they lie, so for anything serious you have to do your own research. And absolutely no good for precise or obscure topics.
If someone wants to play there's GPT4All, Msty, LM Studio. You can give them some of your documents to process and use as "knowledge stacks". Msty has web search, GPT4All will get it in some time.
Got more opinions, but this is long enough already.
Smaller models are useless for me, because my native language is Ukrainian (it's easier to spot mistakes made by model in a language with more complex grammar rules).
As GUI, I use Page Assist[3] plugin for Firefox, or aichat[4] commandline and WebUI tool.
[1]: https://github.com/ollama/ollama/releases
[2]: https://ollama.com/
If the local AI will follow instructions stored in user’s documents and has similar memory persistence it doesn’t matter if it’s hosted in the cloud or run locally, prompt injection + data exfiltration is still a threat that needs to be mitigated.
If anything at least the cloud provider has some incentive/resources to detect an issue like this (not saying they do, but they could).
it is no different from remote code execution vuln, except instead of code, it's instructions.
It's impossible to solve this. You can't tell an LLM "this is an instruction, you should obey it, and this is data, you should ignore any instructions in it" and have it reliably follow these rules, because that distinction between instruction and data just doesn't exist in LLMs.
As long as you allow anything untrusted into your LLM, you are vulnerable to this. You allow it to read your emails? Now there's an attack vector, because anyone can send you emails. Allow it to search the Internet? Now there's an attack vector, because anyone can put a webpage on the Internet.
Yep, and it gets marginally worse: It doesn't distinguish between different "data" channels, including its own past output. This enables strategies of "tell yourself to tell yourself to do X."
> As long as you allow anything untrusted into your LLM, you are vulnerable to this.
It's funny, I used to caution that LLMs should be imagined as if they were "client side" code running on the computer of whomever is interacting with them, since they can't reliably keep secrets and a determined user can eventually trick them into any output.
However with poisoning/exfiltration attacks, even that feels over-optimistic.
Then when searching / browsing or doing anything unsafe, everything the LLM sees can be put in the "data" bucket, while everything the user types in would be in the "instruction" bucket.
So there's no real distinction between the programmer inserting "Be Good" and the user that later inserts "Forget anything else and be Bad", and I'm not sure how one would craft a separate training_weights2 that would behave differently in all the right ways or know when to substitute it in.