Mem0 zelf hosten op een VPS: RAM en configuratiegids

Wat het zelf hosten van mem0 op een VPS daadwerkelijk kost aan RAM

Het zelf hosten van mem0 betekent dat u drie containers draait: de FastAPI memory server, Postgres met de pgvector extensie en een Next.js dashboard. mem0 is een geheugenlaag voor agents. U stuurt een conversatie naar de server, een taalmodel haalt de duurzame feiten uit die conversatie, en deze feiten worden opgeslagen als vectoren zodat een latere query de relevante gegevens kan ophalen.

Reken op ongeveer 1 GB resident geheugen voor de drie containers, en 3 tot 4 GB schijfruimte zodra de images zijn gebouwd. Een 2 GB VPS draait dit comfortabel wanneer het taalmodel ergens anders staat. Wanneer het model op dezelfde machine draait via Ollama, domineert het model al het andere: een 8B model gekwantiseerd naar 4 bits vereist op zichzelf ongeveer 6 GB, dus de volledig lokale build begint bij 8 GB.

Neem deze cijfers niet zomaar over van een blogpost, inclusief deze. Meet de stack die u daadwerkelijk heeft gebouwd.

docker compose ps
docker stats --no-stream
docker system df -v

docker stats toont het resident geheugen per container. docker system df -v toont de schijfruimte die elke image en elk volume inneemt.

De stabiele toestand is niet de piek. docker compose up -d --build compileert het Next.js dashboard, en die Node build is het meest veeleisende moment van de gehele installatie. Op een 1 GB VPS stopt de out-of-memory killer van de kernel het proces en eindigt de build met exit code 137. Bevestig de oorzaak voordat u op zoek gaat naar een Docker-bug:

dmesg -T | grep -i "killed process"

Als een server te veel overhead voelt voor wat u nodig heeft, zijn er kleinere opties beschikbaar. een lokale agent memory store zonder server en geheugen dat binnen Claude Code zelf leeft slaan beide de database over. Kom hier terug wanneer meerdere agents, of meerdere machines, hetzelfde geheugen moeten kunnen lezen.

Heb ik Neo4j nodig voor mem0 graph memory?

Nee. Als een handleiding u adviseert om een Neo4j-container toe te voegen, dan is die handleiding ouder dan de code.

Graph memory in mem0 betekende voorheen een externe graph database, geconfigureerd onder een graph_store-sleutel waarbij enable_graph op true was ingesteld. Het nieuwe memory-algoritme, dat in april 2026 werd uitgebracht, heeft beide sleutels uit de open source SDK verwijderd. Entity extraction wordt nu uitgevoerd binnen het standaard add-pad en de entiteiten worden weggeschreven naar een tweede pgvector-collectie die is vernoemd naar uw hoofdcollectie met _entities als achtervoegsel. Er hoeft geen migratie te worden uitgevoerd. Ingebouwde entity linking begint te werken bij de eerstvolgende add-aanroep.

Het verwijderen van de graph store bespaart een JVM-container, het bijbehorende heap-geheugen en enkele honderden megabytes aan image-grootte. Op een 2 GB VPS is dat het verschil tussen draaien en swappen.

Dit is wat u inlevert, kort en bondig: zoekresultaten bevatten voorheen een relations-veld met een lijst van edges tussen entiteiten. Dat veld is verdwenen. Entity-matches verhogen nu de positie van een memory in de gecombineerde score, en er is geen structuur meer die u kunt doorlopen. Als uw applicatie die relaties doorliep, dan bevat mem0 deze niet langer en dient u zelf een graph database buiten mem0 te onderhouden, gevoed door uw eigen code.

Het compose-bestand in de repository is een development compose

server/docker-compose.yaml declareert name: mem0-dev, en dat is precies wat het doet. Lees het bestand voordat u het uitvoert, want er staan vijf zaken in die onjuist zijn voor een server.

• Het bouwt vanuit server/dev.Dockerfile en mount uw checkout over de image met .:/app, waardoor de container alles uitvoert wat in die map staat in plaats van wat u heeft gebouwd.
• Het commando is rm -rf /app/packages && pip install -q --force-reinstall --no-deps mem0ai && alembic upgrade head && uvicorn main:app --reload. Dit installeert mem0ai bij elke start opnieuw vanaf PyPI, waardoor de versie die uw server draait kan veranderen tijdens een herstart waarvan u niet dacht dat het een upgrade was.
• Door diezelfde pip-stap mislukt een herstart zonder uitgaand netwerkverkeer voordat uvicorn überhaupt draait. Uw memory server is dan offline omdat PyPI onbereikbaar was.
• --reload start de file watcher van uvicorn. Deze is bedoeld om het proces te herstarten wanneer u code bewerkt, en het kost geheugen en een extra proces terwijl het in productie niets nuttigs doet. De productie-Dockerfile bevat ook --reload in zijn CMD, dus u overschrijft het commando hoe dan ook.
• De gepubliceerde poorten zijn "8888:8000", "8432:5432" en "3000:3000". Een gepubliceerde poort zonder voorafgaand adres bindt aan 0.0.0.0, waardoor Postgres vanaf het moment dat de stack start reageert op het publieke internet via 8432.

Dat laatste punt verdient een eigen waarschuwing. Docker publiceert een poort door eigen regels te schrijven vóór de keten die ufw beheert, dus ufw deny 8432 sluit een gepubliceerde containerpoort niet af. Docker publiceert poorten direct voorbij ufw bespreekt de betrokken regels.

Een compose-bestand voor een productieserver

Werk binnen server/, behoud init-db.sh op de huidige locatie en vervang docker-compose.yaml door het onderstaande.

name: mem0

services:
  mem0:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:8888:8000"
    networks: [mem0_network]
    volumes:
      - mem0_history:/app/history
    depends_on:
      postgres:
        condition: service_healthy
    command: >
      sh -c "alembic upgrade head &&
             uvicorn main:app --host 0.0.0.0 --port 8000"
    environment:
      - PYTHONUNBUFFERED=1
      - DASHBOARD_URL=https://mem0.example.com
      - APP_DB_NAME=mem0_app
      - AUTH_DISABLED=false
      - MEM0_TELEMETRY=false

  postgres:
    image: pgvector/pgvector:pg17
    restart: unless-stopped
    shm_size: "128mb"
    networks: [mem0_network]
    environment:
      - POSTGRES_USER=${POSTGRES_USER:-postgres}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -q -U ${POSTGRES_USER:-postgres}"]
      interval: 5s
      timeout: 5s
      retries: 5
    volumes:
      - postgres_db:/var/lib/postgresql/data
      - ./init-db.sh:/docker-entrypoint-initdb.d/init-db.sh

  mem0-dashboard:
    build: ./dashboard
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    networks: [mem0_network]
    environment:
      - NEXT_PUBLIC_API_URL=https://mem0.example.com
      - API_INTERNAL_URL=http://mem0:8000
    depends_on:
      mem0:
        condition: service_started

volumes:
  postgres_db:
  mem0_history:

networks:
  mem0_network:
    driver: bridge

Er zijn vijf belangrijke wijzigingen, elk met een specifieke reden.

Elke ports-vermelding begint met 127.0.0.1, zodat de kernel deze verbindingen alleen accepteert vanaf de server zelf. Al het verkeer van buitenaf komt binnen via de reverse proxy; dit is de enige component die een certificaat beheert.

Postgres bevat geen ports-blok. De mem0-container bereikt de database via mem0_network op basis van de servicenaam. Het publiceren van 8432 biedt geen voordeel en resulteert enkel in een onnodig openstaande poort. Gebruik docker compose exec postgres psql -U postgres wanneer u een shell nodig heeft.

De opslag van de geschiedenis is verplaatst van een ./history bind mount naar een named volume. Een bind mount koppelt de data aan een specifiek pad en een specifieke uid op de host, terwijl een named volume een object is dat Docker kan back-uppen en verplaatsen. Named volumes versus bind mounts legt uit wanneer u welke optie kiest.

Het commando verwijdert --reload en behoudt alembic upgrade head. Sla deze migratiestap niet over. Zonder deze stap start de applicatie met een database zonder tabellen, waardoor elk verzoek bij de eerste query faalt.

NEXT_PUBLIC_API_URL is de URL die uw browser aanroept; dit moet het publieke HTTPS-adres zijn en niet http://mem0:8000. Next.js verwerkt elke NEXT_PUBLIC_-waarde tijdens het build-proces. Het wijzigen van deze waarde vereist daarom docker compose up -d --build mem0-dashboard. Een eenvoudige herstart behoudt de oude waarde die in de JavaScript-bestanden is ingebakken, waardoor het dashboard het verkeerde adres aanroept.

Geheimen horen thuis in .env, en .env blijft buiten het internet

cd server
cp .env.example .env
openssl rand -hex 32    # paste into JWT_SECRET
openssl rand -hex 32    # paste into ADMIN_API_KEY
chmod 600 .env

Stel POSTGRES_PASSWORD, JWT_SECRET en ADMIN_API_KEY in. Laat AUTH_DISABLED=false ongewijzigd. De naam geeft eerlijk aan wat deze flag doet: als deze is ingeschakeld, geeft de server alle informatie in het geheugen door aan iedereen die de poort kan bereiken. Stel MEM0_TELEMETRY=false in als u niet wilt dat het onboarding-event naar upstream wordt verzonden.

ADMIN_API_KEY wordt vergeleken met de X-API-Key-header via secrets.compare_digest, en bij een overeenkomst wordt elke database-opzoeking overgeslagen. Dit is een root-referentie voor de gehele API. Behandel deze als zodanig: sla deze niet op in de shell-history, zet deze niet in git en plak deze niet in een prompt. Compose env-bestanden en waar geheimen daaruit lekken en API-sleutels buiten de context van een agent houden zijn beide direct van toepassing, aangezien de aanroepers van deze server agents zijn.

Waarden die vanuit env_file worden geladen, bevinden zich in de container-omgeving en docker inspect print deze volledig. Iedereen in de docker-groep kan deze lezen, en iedereen in de docker-groep is in feite root op de host.

Plaats TLS voor de API in plaats van poort 8888 te openen

De API reageert op 127.0.0.1:8888 en het dashboard op 127.0.0.1:3000. nginx handelt de TLS (transport layer security) af op poort 443 en stuurt het verkeer door naar beide.

server {
    listen 443 ssl;
    server_name mem0.example.com;

    ssl_certificate     /etc/letsencrypt/live/mem0.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mem0.example.com/privkey.pem;

    location ~ ^/(memories|search|configure|auth|api-keys|docs|openapi.json) {
        proxy_pass http://127.0.0.1:8888;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 180s;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

proxy_read_timeout is belangrijker dan het lijkt. Een add-aanroep blokkeert terwijl het taalmodel de conversatie leest en feiten extraheert. Een lokaal 8B-model op de CPU duurt regelmatig langer dan de standaard time-out van 60 seconden van nginx, waarna de aanroeper 504 Gateway Time-out ziet terwijl het model nog bezig is en het geheugen nog steeds wordt geschreven. U eindigt dan met een geheugen waarvan werd gemeld dat het mislukt was.

Sluit de rest af met een standaard deny ufw-beleid, waarbij alleen 22 en 443 open blijven. Vraag het certificaat aan met certbot op Ubuntu 24.04 achter nginx. Als de server al andere applicaties ontsluit met Traefik voor het routeren van meerdere Compose-apps, voeg mem0 dan toe aan die router in plaats van een tweede proxy te installeren.

Smoke test: voeg één geheugenitem toe en lees dit terug

export MEM0_KEY='<the ADMIN_API_KEY from .env>'

curl -sS -X POST http://127.0.0.1:8888/memories \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $MEM0_KEY" \
  -d '{"messages":[{"role":"user","content":"I deploy with Docker Compose and I run Postgres 17."}],"user_id":"smoke"}'

Een correcte respons is een JSON-object met een results-lijst, waarbij elk item een id, de geëxtraheerde memory-tekst en "event": "ADD" bevat. Het huidige algoritme retourneert uitsluitend ADD-gebeurtenissen. UPDATE- en DELETE-gebeurtenissen zijn verwijderd; hun afwezigheid is dus geen bug.

curl -sS -X POST http://127.0.0.1:8888/search \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $MEM0_KEY" \
  -d '{"query":"which database do I run?","filters":{"user_id":"smoke"},"top_k":5}'

Het feit over Postgres 17 zou met een score moeten terugkeren. Geef de identifier door via filters, zoals getoond. Een user_id op het hoogste niveau werkt nog steeds en de server logt Top-level user_id in /search is deprecated. Use filters={...} instead. telkens wanneer u dit gebruikt.

Ruim na afloop uw gegevens op zodat de testdata echte zoekopdrachten niet vervuilt:

curl -sS -X DELETE "http://127.0.0.1:8888/memories?user_id=smoke" \
  -H "X-API-Key: $MEM0_KEY"

Als de zoekopdracht minder rijen retourneert dan verwacht, controleer dan de standaardinstellingen voordat u de retrieval de schuld geeft. In de huidige release staat top_k standaard op 20, in plaats van 100, en threshold staat standaard op 0.1 in plaats van geen, waardoor zwakke matches nu automatisch worden gefilterd. Zodra dit werkt via curl, zijn dit dezelfde endpoints die u koppelt aan een agent, hetzij direct, hetzij via een MCP-server die op dezelfde VPS draait.

mem0 uitvoeren zonder OpenAI-sleutel

Begin bij het blokkerende punt, aangezien u hier binnen vijf minuten tegenaan loopt. De server-image bevat een vaste set provider-bibliotheken en /configure weigert alles wat daarbuiten valt:

LLM provider 'ollama' is not bundled in this image. Bundled providers: openai, anthropic, gemini. To use another provider, install its Python package, rebuild the container, and extend BUNDLED_LLM_PROVIDERS in server/main.py.

U hoeft niets opnieuw te compileren. Ollama biedt een OpenAI-compatibele API op /v1, die /v1/chat/completions en /v1/embeddings dekt, en de openai-provider van mem0 accepteert een openai_base_url. Wijs die sleutel naar Ollama en de ingebouwde controle slaagt, omdat de provider daadwerkelijk openai is. Alleen het adres wijzigt.

Voeg Ollama toe aan hetzelfde Compose-project:

  ollama:
    image: ollama/ollama
    restart: unless-stopped
    networks: [mem0_network]
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama_models:/root/.ollama

Voeg ollama_models: toe onder de hoofd-key volumes: en haal vervolgens één chatmodel en één embedding-model op:

docker compose up -d ollama
docker compose exec ollama ollama pull llama3.1:8b
docker compose exec ollama ollama pull nomic-embed-text

Als Ollama al op de host draait als systemd-unit, zoals beschreven in Ollama direct op een VPS draaien, wijs de container dan niet naar 127.0.0.1:11434. Binnen de mem0-container is 127.0.0.1 de mem0-container zelf. Geef de mem0-service extra_hosts: ["host.docker.internal:host-gateway"], stel Environment="OLLAMA_HOST=0.0.0.0:11434" in via een systemd drop-in zodat Ollama luistert op een adres dat de bridge kan bereiken, en houd poort 11434 gesloten in de firewall.

Vraag het model naar de embedding-dimensie voordat u iets configureert

Deze ene stap bepaalt of retrieval überhaupt werkt.

De pgvector-store van mem0 maakt de tabel aan met een vaste vectorbreedte, vector vector(1536), omdat embedding_model_dims standaard op 1536 staat, de breedte van OpenAI's text-embedding-3-small. nomic-embed-text retourneert 768 waarden. Niets in mem0 vergelijkt deze twee getallen, dus de mismatch komt bij de eerste insert vanuit Postgres naar boven:

expected 1536 dimensions, not 768

Vertrouw ook niet op het getal in deze paragraaf. Vraag het aan het model:

curl -sS http://127.0.0.1:11434/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{"model":"nomic-embed-text","input":"dimension check"}' \
  | python3 -c "import json,sys; print(len(json.load(sys.stdin)['data'][0]['embedding']))"

Dit print de breedte die uw collectie moet gebruiken. Schrijf de configuratie naar een bestand; het plakken van een Postgres-wachtwoord via shell-quoting is de manier waarop typefouten in productie terechtkomen.

{
  "vector_store": {
    "provider": "pgvector",
    "config": {
      "host": "postgres",
      "port": 5432,
      "dbname": "postgres",
      "user": "postgres",
      "password": "<POSTGRES_PASSWORD from .env>",
      "collection_name": "memories_local_768",
      "embedding_model_dims": 768
    }
  },
  "llm": {
    "provider": "openai",
    "config": {
      "model": "llama3.1:8b",
      "api_key": "ollama",
      "openai_base_url": "http://ollama:11434/v1",
      "temperature": 0.2
    }
  },
  "embedder": {
    "provider": "openai",
    "config": {
      "model": "nomic-embed-text",
      "api_key": "ollama",
      "openai_base_url": "http://ollama:11434/v1"
    }
  }
}

curl -sS -X POST http://127.0.0.1:8888/configure \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $MEM0_KEY" \
  -d @config.json

curl -sS http://127.0.0.1:8888/configure -H "X-API-Key: $MEM0_KEY"

De tweede aanroep leest de configuratie terug; dit is de controle of de schrijfactie is geslaagd. Herhaal daarna de bovenstaande smoke test.

Vier details in die JSON zijn niet voor de hand liggend, en elk detail veroorzaakt problemen als u het verkeerd doet.

api_key is de string ollama en Ollama negeert de waarde ervan. Deze mag niet leeg zijn, omdat de OpenAI-clientbibliotheek een foutmelding geeft voordat een verzoek het proces verlaat wanneer er geen sleutel is ingesteld. Elke niet-lege string werkt.

embedding_model_dims hoort bij de vector store en er is bewust geen embedding_dims op de embedder. mem0 verstuurt de OpenAI dimensions-parameter alleen wanneer u embedding_dims instelt, en backends die geen Matryoshka-truncatie implementeren, wijzen die parameter direct af. Stel de breedte in waar de tabel wordt aangemaakt en laat de embedder met rust.

collection_name is nieuw. mem0 maakt de tabel aan met CREATE TABLE IF NOT EXISTS, dus een andere breedte toewijzen aan een bestaande collectie doet niets: de oude vector(1536)-kolom blijft bestaan en elke insert mislukt. Een wijziging in de breedte vereist een nieuwe collectienaam, of u moet de oude tabel handmatig verwijderen.

De host in openai_base_url is de Compose-servicenaam ollama, niet localhost. Containers bereiken elkaar via de servicenaam op hun gedeelde netwerk.

Wat het volledig lokale pad u kost

Wees eerlijk tegen uzelf over de kwaliteit. De gepubliceerde benchmarkscores van mem0 zijn gemeten met frontier-modellen die de extractie uitvoerden; beschouw deze dus als een plafond in plaats van een prognose voor een 8B-model op uw VPS. Een klein model schrijft vagere feiten en retourneert soms proza waar JSON werd gevraagd, wat zichtbaar is als een add-aanroep die een lege results-lijst zonder foutmelding teruggeeft.

Snelheid is de andere kostenpost. Extractie op enkel de CPU kost seconden per add-aanroep, en elk bericht dat u opslaat betaalt die prijs. Als die latentie van belang is, is een VPS met een GPU de eerlijke oplossing. Meer CPU-cores toewijzen aan een 8B-model helpt veel minder dan mensen verwachten.

Eén regel geldt ongeacht uw keuze: meng nooit embedding-modellen binnen één collectie. Twee verschillende modellen die toevallig dezelfde breedte hebben, produceren vectoren die niet vergelijkbaar zijn. De insert slaagt, de zoekopdracht retourneert rijen, en de rijen zijn onjuist, zonder dat er ergens een foutmelding verschijnt.

Backups: er zijn twee databases, niet één

De meest gemaakte fout bij een mem0-backup is het dumpen van slechts één database. init-db.sh maakt mem0_app aan naast de standaard postgres database, en deze bevatten verschillende gegevens. De postgres database bevat de pgvector-collecties, oftewel de herinneringen. mem0_app bevat gebruikers, sessies, API-keys en request-logs.

Herstel alleen postgres en de herinneringen keren terug, maar elk account en elke API-key is verdwenen, waardoor authenticatie om ze te lezen onmogelijk is. Dump beide, inclusief rollen, in één commando:

docker compose exec -T postgres pg_dumpall -U postgres --clean \
  | gzip > "mem0-$(date +%F).sql.gz"

Het history-volume staat los van Postgres en vereist een eigen kopie:

docker run --rm -v mem0_mem0_history:/data -v "$PWD:/backup" \
  alpine tar czf /backup/mem0-history.tgz -C /data .

Docker voegt het projectnaam-voorvoegsel toe aan volumenamen, dus controleer de uwe met docker volume ls voordat u uitgaat van mem0_mem0_history.

Herstel naar een scratch-container en controleer het aantal rijen voordat u de backup als betrouwbaar beschouwt:

gunzip -c mem0-2026-08-03.sql.gz \
  | docker compose exec -T postgres psql -U postgres -d postgres

Een backup die u nooit heeft hersteld, is slechts een aanname. Zodra de dumps correct zijn, verplaatst u ze van de server met restic snapshots naar externe opslag, want een backup die op dezelfde server staat als de data die hij moet beschermen, biedt geen bescherming.

Foutmodi en de exacte meldingen die u zult zien

{"detail":"Authentication required. Provide a Bearer token or X-API-Key header."} betekent dat de header ontbreekt of verkeerd gespeld is. De naam is X-API-Key en curl verstuurt headernamen letterlijk.

{"detail":"At least one identifier (user_id, agent_id, run_id) is required."} bij een toevoeging betekent dat het verzoek er geen bevatte. Een geheugen moet aan iets gekoppeld zijn, omdat zoekfilters precies op die velden filteren.

LLM provider 'ollama' is not bundled in this image met HTTP 400 betekent dat u "provider": "ollama" heeft verstuurd. Gebruik "provider": "openai" met openai_base_url gericht op Ollama.

expected 1536 dimensions, not 768 vanuit Postgres betekent dat de collectie is aangemaakt met een bepaalde breedte en de embedder een andere teruggeeft. Stel embedding_model_dims in op de vector store en gebruik een nieuwe collection_name.

Zoekopdrachten retourneren onlogische resultaten na een modelwijziging, zonder enige foutmelding. De breedte komt nog steeds overeen, dus de database functioneert naar behoren, maar twee modellen plaatsen dezelfde zin op verschillende posities. Start een nieuwe collectie en voeg de gegevens opnieuw toe.

Connection refused in de mem0-logs tijdens het bereiken van Ollama betekent meestal 127.0.0.1 in openai_base_url. Binnen de container verwijst dat adres naar de container zelf. Gebruik de servicenaam of de host gateway wanneer Ollama op de host draait.

504 Gateway Time-out vanuit nginx bij een toevoeging betekent dat het model er langer over deed dan proxy_read_timeout. Verhoog deze waarde en controleer of het geheugen al was weggeschreven voordat u het verzoek opnieuw probeert.

exit code 137 tijdens docker compose up --build is de out-of-memory killer die het buildproces van het dashboard stopt. Voeg swap toe of bouw de image op een machine met meer geheugen en push deze naar een registry.

error: port 3000 is already in use is afkomstig van het make up-target van de repository, dat weigert te starten wanneer 3000 of 8888 in gebruik zijn. Zoek de eigenaar van het proces met lsof -iTCP:3000 -sTCP:LISTEN.

FAQ

Heb ik nog steeds Neo4j nodig om mem0 met graph memory te draaien?

Nee. Het nieuwe geheugenalgoritme, dat in april 2026 werd uitgebracht, heeft de configuratiesleutels graph_store en enable_graph uit de open source SDK verwijderd. Entiteit-extractie vindt nu plaats tijdens een normale toevoeging en schrijft naar een tweede pgvector-collectie genaamd <collection_name>_entities. Er is dus geen externe graph database, geen extra container en geen migratiestap meer nodig. Het nadeel is dat het veld relations in zoekresultaten niet langer bestaat. Entiteiten verhogen nu de ranking van een geheugen in plaats van dat ze u randen bieden om te doorlopen; een applicatie die die relaties doorliep, heeft daarvoor nu een eigen graph store buiten mem0 nodig.

Wat is de kleinste VPS die een zelfgehoste mem0-server kan draaien?

Wanneer het taalmodel elders wordt gehost, zijn 2 GB RAM en ongeveer 4 GB vrije schijfruimte voldoende voor de API-container, Postgres en het dashboard. Het kritieke moment is de eerste build, omdat het compileren van het Next.js-dashboard meer geheugen verbruikt dan het draaien ervan; bij een 1 GB-server wordt het build-proces beëindigd met exit code 137. Als Ollama op dezelfde server draait, moet u rekening houden met de grootte van het model: een 8B-model met 4-bit kwantisatie heeft op zichzelf ongeveer 6 GB nodig, dus plan voor 8 GB.

Kan ik mem0 draaien zonder een OpenAI API-sleutel?

Ja, via het OpenAI-compatibele eindpunt van Ollama. Het instellen van "provider": "ollama" mislukt, omdat de server-image alleen de openai-, anthropic- en gemini-bibliotheken bevat en een HTTP 400-foutmelding geeft. Behoud in plaats daarvan "provider": "openai" en stel "openai_base_url": "http://ollama:11434/v1" in met een willekeurige niet-lege api_key, zowel voor de llm als de embedder. Ollama negeert de sleutel en de ingebouwde providercontrole slaagt omdat de provider daadwerkelijk openai is.

Waarom geeft mem0 geen resultaten terug nadat ik ben overgestapt op een lokaal embedding-model?

Omdat de pgvector-tabel met een vaste breedte is aangemaakt. embedding_model_dims staat standaard op 1536, nomic-embed-text geeft 768 terug en Postgres weigert de insert met expected 1536 dimensions, not 768. mem0 maakt de tabel aan met CREATE TABLE IF NOT EXISTS, dus het wijzigen van alleen het getal heeft geen effect op een bestaande collectie. Stel embedding_model_dims in op de werkelijke breedte van uw model, bevestig die breedte door /v1/embeddings aan te roepen en de waarden te tellen die het teruggeeft, en geef de vector store tegelijkertijd een nieuwe collection_name.