It’s less the calculations and more about memory bandwidth. To generate a token you need to go through all the model data, and that’s usually many many gigabytes. So the time it takes to read through in memory is usually longer than the compute time. GPUs have gb’s of RAM that’s many times faster than the CPU’s ram, which is the main reason it’s faster for llm’s.
Most tpu’s don’t have much ram, and especially cheap ones.
Reasonable smart… that works preferably be a 70b model, but maybe phi3-14b or llama3 8b could work. They’re rather impressive for their size.
For just the model, if one of the small ones work, you probably need 6+ gb VRAM. If 70b you need roughly 40gb.
And then for the context. Most models are optimized for around 4k to 8k tokens. One word is roughly 3-4 tokens. The VRAM needed for the context varies a bit, but is not trivial. For 4k I’d say right half a gig to a gig of VRAM.
As you go higher context size the VRAM requirement for that start to eclipse the model VRAM cost, and you will need specialized models to handle that big context without going off the rails.
So no, you’re not loading all the notes directly, and you won’t have a smart model.
For your hardware and use case… try phi3-mini with a RAG system as a start.
You realise there is no algorithm behind Lemmy, right?
Of course there is. Even “sort by newest” is an algorithm, and the default view is more complicated than that.
You aren’t being shoved controversial polarizing content subliminally here.
Neither are you on TikTok, unless you actively go looking for it
I’ve seen Skype do that. It was a weird folder name, but gallery found it and displayed the images.
Which is how I noticed it in the first place
I wonder what bpm Moby’s thousand starts at… Maybe it can reach both limits
Hah as if. In the early 00s the mods were in maybe once or twice a day and there was tons of CP being posted.
Worst I saw was a little girl chopped into pieces, and a many -page discussion / argument if it should be sorted as CP or Necro porn. That was the old 4chan.
Even for 4chan that’s fucked up.
Oh, sweet summer child…
On occasion their strategy has been “if we send in enough people, they’ll eventually run out of bullets”
They out-Zapp Brannigan’ed Zapp Brannigan. That should terrify you on multiple levels
Koboldcpp
I’m waiting for them to find a better spot on durability, weight /bulkiness and hardware like cameras.
They’re still too big and bulky for me, the other components are usually a bit behind, and the screen durability seems a bit too eeh still.
Which is to say, I’m interested in one, but they’re not there yet for me.
I gotta ask… were you around and actively using xmpp around that time?
Because I was. And xmpp struggling had nothing to do with Google
Goatse, for the connoisseur
deleted by creator
He’s arguably a big enough target to actually worry about custom hardware modification attacks.
Some radios:
For the nfs shares, there’s generally two approaches to that. First is to mount it on host OS, then map it in to the container. Let’s say the host has the nfs share at /nfs, and the folders you need are at /nfs/homes. You could do “docker run -v /nfs/homes:/homes smtpserverimage” and then those would be available from /homes inside the image.
The second approach is to set up NFS inside the image, and have that connect directly to the nfs server. This is generally seen as a bad idea since it complicates the image and tightly couples the image to a specific configuration. But there are of course exceptions to each rule, so it’s good to keep in mind.
With database servers, you’d have that set up for accepting network connections, and then just give the address and login details in config.
And having a special setup… How special are we talking? If it’s configuration, then that’s handled by env vars and mapping in config files. If it’s specific plugins or compile options… Most built images tend to cast a wide net, and usually have a very “everything included” approach, and instructions / mechanics for adding plugins to the image.
If you can’t find what you’re looking for, you can build your own image. Generally that’s done by basing your Dockerfile on an official image for that software, then do your changes. We can again take the “postgres” image since that’s a fairly well made one that has exactly the easy function for this we’re looking for.
If you would like to do additional initialization in an image derived from this one, add one or more *.sql, *.sql.gz, or *.sh scripts under /docker-entrypoint-initdb.d (creating the directory if necessary). After the entrypoint calls initdb to create the default postgres user and database, it will run any *.sql files, run any executable *.sh scripts, and source any non-executable *.sh scripts found in that directory to do further initialization before starting the service.
So if you have a .sh script that does some extra stuff before the DB starts up, let’s say “mymagicpostgresthings.sh” and you want an image that includes that, based on Postgresql 16, you could make this Dockerfile in the same folder as that file:
FROM postgres:16
RUN mkdir /docker-entrypoint-initdb.d
COPY mymagicpostgresthings.sh /docker-entrypoint-initdb.d/mymagicpostgresthings.sh
RUN chmod a+x /docker-entrypoint-initdb.d/mymagicpostgresthings.sh
and when you run “docker build . -t mymagicpostgres” in that folder, it will build that image with your file included, and call it “mymagicpostgres” - which you can run by doing “docker run -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 mymagicpostgres”
In some cases you need a more complex approach. For example I have an nginx streaming server - which needs extra patches. I found this repository for just that, and if you look at it’s Dockerfile you can see each step it’s doing. I needed a bit of modifications to that, so I have my own copy with different nginx.conf, an extra patch it downloads and applies to the src code, and a startup script that changes some settings from env vars, but that had 90% of the work done.
So depending on how big changes you need, you might have to recreate from scratch or you can piggyback on what’s already made. And for “docker script to launch it” that’s usually a docker-compose.yml file. Here’s a postgres example:
version: '3.1'
services:
db:
image: postgres
restart: always
environment:
POSTGRES_PASSWORD: example
adminer:
image: adminer
restart: always
ports:
- 8080:8080
If you run “docker compose up -d” in that file’s folder it will cause docker to download and start up the images for postgres and adminer, and port forward in 8080 to adminer. From adminer’s point of view, the postgres server is available as “db”. And since both have “restart: always” if one of them crashes or the machine reboots, docker will start them up again. So that will continue running until you run “docker compose down” or something catastrophic happens.
Hilarious for a system which main point / feature is photo backup