1.0.0-beta.19 • Published 8 months ago

lllms v1.0.0-beta.19

Weekly downloads
-
License
MIT
Repository
github
Last release
8 months ago

lllms

Libraries and server to build AI applications doing local inference in node. Use it within your application, or as a microservice. Adapters to llama.cpp via node-llama-cpp and gpt4all. And transformers.js using ONNX!

The project includes a model resource pool, an inference queue and a HTTP API server. Model file management is abstracted away as much as possible - configure a URL and go. This package is useful for quick model evaluations and experiments (in JavaScript), small-scale chatbots, resource efficient assistants on edge devices, or any applications where private & offline are interesting criteria. For other - not node-based solutions - check out the related solutions section.

⚠️ This package is currently in beta. APIs may change. Things may break. Help is welcome.

Features

  • Configure as many models as you want, they will be downloaded and cached to disk. You may provide them as abs file paths if you already have models downloaded.
  • Adjust the pool concurrency, and the models maxInstances, ttl and contextSize to fit your usecase. Combine multiple pools for more complex setups.
  • Can be tuned to either use no resources when idle or to always keep a model ready with context preloaded.
  • A chat session cache that will effectively reuse context across multiple turns or stateless requests.
  • OpenAI spec API endpoints. See HTTP API docs for details. A "native" HTTP API is not yet implemented.
  • BYO web server or use the provided express server and middleware. Incoming requests are queued - stall, if needed - and processed as soon as resources are available.
  • Have as many ModelServers running as you want, they can share the same cache directory. (Multiple processes can as well)
  • Use the ModelPool class directly for a lowerlevel transaction-like API to aquire/release model instances.
  • Use custom engines to combine multiple models (or do RAG) behind the scenes.

Usage

Example with minimal configuration:

import { ModelServer } from 'lllms'

const llms = new ModelServer({
  log: 'info', // default is 'warn'
  models: {
    'my-model': { // Identifiers can use a-zA-Z0-9_:\-\.
      // Required are `task`, `engine`, `url` and/or `file`.
      task: 'text-completion', // text-completion models can be used for chat and text generation tasks
      engine: 'node-llama-cpp', // each engine comes with a peer dep. `npm install node-llama-cpp@3`
      url: 'https://huggingface.co/HuggingFaceTB/smollm-135M-instruct-v0.2-Q8_0-GGUF/blob/main/smollm-135m-instruct-add-basics-q8_0.gguf',
    },
  },
})
await llms.start()
const result = await llms.processChatCompletionTask({
  model: 'my-model',
  messages: [
    {
      role: 'user',
      content: 'Why are bananas rather blue than bread at night?',
    },
  ],
})
console.debug(result)
llms.stop()

Or, to start an OAI compatible HTTP server with two concurrent instances of the same model:

import { startHTTPServer } from 'lllms'
import OpenAI from 'openai'

const server = await startHTTPServer({
  listen: { port: 3000 }, // apart from `listen` options are identical to ModelServer
  concurrency: 2, // two inference processes may run at the same time
  models: {
    'smollm': {
      task: 'text-completion',
      engine: 'node-llama-cpp',
      url: 'https://huggingface.co/HuggingFaceTB/smollm-135M-instruct-v0.2-Q8_0-GGUF/blob/main/smollm-135m-instruct-add-basics-q8_0.gguf',
      maxInstances: 2, // two instances of this model may be loaded into memory
      device: {
        cpuThreads: 4, // limit cpu threads so we dont occupy all cores
      }
    },
  },
})

const client = new OpenAI({
  baseURL: 'http://localhost:3000/openai/v1/',
  apiKey: 'yes',
})
const completion = await client.beta.chat.completions.stream({
  stream_options: { include_usage: true },
  model: 'smollm',
  messages: [
    { role: 'user', content: 'lets count to 10, but only whisper every second number' },
  ],
})
for await (const chunk of completion) {
  if (chunk.choices[0]?.delta?.content) {
    process.stdout.write(chunk.choices[0].delta.content)
  }
}
server.stop()

More usage examples:

Currently supported inference engines are:

EnginePeer Dependency
node-llama-cppnode-llama-cpp >= 3.0.0
gpt4allgpt4all >= 4.0.0
transformers-js@huggingface/transformers >= 3.0.0

See engine docs for more information on each.

Limitations and Known Issues

Only one model can run on GPU at a time

Llama.cpp bindings currently do not support running multiple models on gpu at the same time. This can/will likely be improved in the future. See GPU docs for more information on how to work around that.

System Messages

System role messages are supported only as the first message in a chat completion session. All other system messages will be ignored. This is only for simplicity reasons and might change in the future.

Chat Context Cache / Reusing the correct instance on stateless requests

Note that the current context cache implementation only works if (apart from the final user message) the same messages are resent in the same order. This is because the messages will be hashed to be compared during follow up turns, to match requests to the correct session. If no hash matches everything will still work, but slower. Because a fresh context will be used and the whole input conversation will be reingested, instead of just the new user message.

Function Calling

Only available when using node-llama-cpp and a model that supports function calling. tool_choice can currently not be controlled and will always be auto. GBNF grammars cannot be used together with function calling.

Huge node_modules when installing all engines

CUDA binaries are distributed with each engine seperately, which leads to an extra 0.5-1GB of disk use. Unfortunately there is nothing I can do about that.

TODO / Roadmap

Not in any particular order:

  • Automatic download of GGUF's with ipull
  • Engine abstraction
  • Model instance pool and queue
  • Basic OpenAI API compatibility
  • POC of chat context reuse across requests
  • Tests for context reuse and context leaking
  • Logging Interface
  • Better Examples
  • GPU support
  • node-llama-cpp context reuse
  • Instance TTL
  • Allow configuring model hashes / verification
  • Improve template code / stop trigger support
  • Support configuring a timeout on completion processing
  • Logit bias / Token bias support
  • Improve tests for longer conversations / context window shifting
  • Embeddings APIs
  • Improve node-llama-cpp token usage counts / TokenMeter
  • Reuse download logic from node-llama-cpp to support split ggufs.
  • Support preloading instances with context, like a long system message or few shot examples
  • transformers.js engine
  • Support custom engine implementations
  • Make sure nothing clashes if multiple servers/stores are using the same cache directory
  • See if we can install supported engines as peer deps
  • Improve types, simpler node-llama-cpp grammar integration
  • Restructure docs, add function calling & grammar usage docs
  • TTL=0 should immediately dispose of instances instead of waiting (currently on avg 30s) for the next TTL check
  • Expose node-llama-cpp context shift strategy, lora, allow json schema as input for grammar
  • Improve types for tool definitions / json schema
  • Make pool dispose / stop more robust
  • Tests for cancellation and timeouts
  • transformer.js text embeddings
  • transformer.js image embeddings
  • transformer.js multimodal image/text embeddings (see jina-clip-v1 and nomic-embed-vision issues.)
  • Allow "prefilling" (partial) assistant responses like outlined here
  • non-chat text completions: Allow reuse of context
  • non-chat text completions: Support preloading of prefixes
  • Add some light jsdoc for server/pool/store methods
  • utilize node-llama-cpp's support to reuse LlamaModel instances with multiple contexts
  • Support transformer.js for text-completion tasks (not yet supported in Node.js)
  • Implement more transformer.js tasks (imageToImage, textToImage, textToSpeech?)
  • Infill completion support https://github.com/withcatai/node-llama-cpp/blob/beta/src/evaluator/LlamaCompletion.ts#L322-L336
  • Find a way to type available custom engines (and their options?)
  • Rework GPU+device usage / lock (Support multiple models on gpu in cases where its possible)
  • Add engine interfaces for resource use (and estimates, see https://github.com/ggerganov/llama.cpp/issues/4315 and https://github.com/withcatai/node-llama-cpp/blob/beta/src/gguf/insights/utils/resolveContextContextSizeOption.ts)
  • Allow configuring a pools max memory usage
  • Test deno/bun support
  • Add image generation endpoint in oai api
  • Add transcript endpoint in oai api
  • Add n parameter support to node-llama-cpp chat completions
  • CLI
  • Replace express with tinyhttp
  • Add stable-diffusion engine

Contributing

If you are using this package - let me know where you would like this to go. Code also welcome. You find things im planning to do (eventually) above, and the wishlist below.

Possible Future Goals

  • See if it would make sense to implement engines for leejet/stable-diffusion.cpp and onnxruntime-node
  • Create a separate HTTP API thats independent of the OpenAI spec and stateful. See discussion.
  • Add a clientside library (React hooks?) for use of above API.
  • Provide a Docker image. And maybe a Prometheus endpoint.
  • Logprobs support for node-llama-cpp.

Currently not the Goals

  • A facade to LLM cloud hoster HTTP API's. The strengths here are local/private/offline use.
  • Worry too much about authentication or rate limiting or misuse. Host this with caution, it's likely DDoS-able.
  • Some kind of distributed or multi-node setup. That should probably be something designed for this purpose from the ground up.
  • Other common related tooling like vector stores, Chat GUIs, etc. Scope would probably get out of hand.

Related Solutions

If you look at this package, you might also want to take a look at these other solutions:

  • ollama API - Uses llama.cpp and provides a HTTP API. Also has experimental OpenAI API compatibility.
  • llama.cpp Server - The official llama.cpp HTTP API.
  • VLLM - A more production ready solution for hosting large language models.
  • LM Studio - Also has a local server.
  • LocalAI - Similar project in go.
  • Petals - Local (and distributed!) inference in python.
  • cortex.cpp