361 Local · Field Guide

AI That Runs Inside
Your Company

"Air-gapped" and "zero token cost" sound good. This page answers the questions that actually decide the project: where are local models good enough, what hardware do you need, when should you go to the cloud — and how we guarantee data never leaves the building.

Measure it on your own machine Security page

Section 1

Three ways to run AI locally

Local AI is not a single deployment shape. 361 supports all three, and they are not mutually exclusive — they can run side by side in the same organization.

Path	What it means
361 Local (embedded)	llama.cpp is embedded inside the platform. No external installation is required: the runtime binary is downloaded automatically and no API key is needed. You do not buy a separate product or hand-install software on the server to turn local AI on.
Ollama	If your team already runs Ollama, 361 connects over the local address. You install it; 361 treats it as a provider.
LM Studio	External installation, connected through its OpenAI-compatible interface. A familiar path for teams already experimenting with models on the desktop.

They do not exclude each other. You can run production workloads on the embedded engine while the team experiments through Ollama or LM Studio.

Section 2

Hardware: where you start, where you are comfortable

The first question every IT team asks. These are the platform's own requirements — not estimates.

Item	Requirement
Operating system	Windows Server 2019+ or Windows 10/11 · .NET Framework 4.8
Minimum	16 GB RAM 8 CPU cores Enough for small models, evaluation and pilot workloads.
Recommended	32 GB+ RAM CUDA-capable NVIDIA GPU Comfortable headroom for quality models and heavy document/OCR pipelines.

The platform scans the machine automatically

You do not have to inventory the hardware yourself. At setup the platform scans the machine and decides what it can use.

RAM capacity — determines which model size will fit.
CPU instruction sets — AVX2 / AVX512 support is detected and the matching runtime is selected.
CUDA and VRAM capacity — if a GPU is present, its capacity is measured.
Vulkan support — an alternative acceleration path when CUDA is unavailable.

CUDA → Vulkan → CPU

That is the acceleration order. If one fails, the system falls back to the next one automatically — the install does not stall on a GPU driver.

The "will it fit" badge. You do not guess when picking a model: each model file's size is calculated against the machine's RAM/VRAM, and models that do not fit are flagged in the list. Downloading the wrong model and locking up the server is off the table.

The embedded starter set

The models that ship in the box. Which one you start with depends on your hardware and the type of work.

Model	Size	Use
Qwen2.5 0.5B	~398 MB	Low-end hardware / fast trial. Answers "does local AI work here?" within minutes.
Qwen2.5 3B Default	~2 GB	Multilingual including Turkish, supports tool calling, runs reasonably on CPU. The starting point for most organizations.
Qwen2.5 7B	~4.7 GB	The quality option. A GPU with at least 6 GB VRAM is recommended.
Qwen2-VL 2B	~2.2 GB	Vision-capable chat — talk over screenshots, scanned forms and field photos.

An honest note. We do not publish concrete speed or concurrency figures here, because they depend entirely on your hardware. They are measured on your own machine during the POC, and the numbers become yours.

Section 3

The local stack is more than chat

"Local AI" usually brings a lone chat box to mind. The 361 local stack is a document–voice–image pipeline: all of it runs inside the machine, at zero token cost.

Capability	How
Chat + tool calling + streaming	The embedded llama.cpp engine. Answers stream word by word; the model can call tools inside your business modules.
Vision-capable chat	A vision-language model. Ask questions over photos and screenshots.
Embeddings / RAG (semantic search)	ONNX Runtime + a multilingual embedding model (~470 MB and ~1.11 GB options). Meaning-based search across your corporate documents.
OCR — text from scanned PDFs and images	A local OCR engine (~12.6 MB models). Scanned archive documents become text without leaving the machine.
Speech to text	Whisper small (~500 MB). Meeting and call recordings turned into transcripts.
Text to speech	Piper — a Turkish voice model ships as the default.
Image generation	SDXL-Turbo (~6.6 GB). Note: the image generation model's licence is assessed separately for commercial use.

All of it inside the machine. Document reading, semantic search, speech transcription and voice output send no request outside — so there is no per-use charge for these workloads either.

Section 4

What stays local, what goes to the cloud?

This is guidance, not a benchmark claim. Not a hard rule; we decide it together with your own data during the POC.

Workload	Recommendation	Why
Regulated / personal data processing	Local	Data never leaves the machine.
Document summarization, classification, tagging	Local	Small models are good enough here, volume is high, cost is zero.
Semantic search / RAG embedding generation	Local	The embedding model already runs locally; no token cost.
OCR, speech transcription, voice output	Local	All of it is in the local stack.
Long multi-step reasoning, complex code generation	Cloud	Larger models are required.
Very large context (hundreds of pages at once)	Cloud	The local context window is limited (4096 by default).

Hybrid is the default. You are not forced into a one-time local-or-cloud choice: the same governance gate can route to a local model or a cloud model. Sensitive work stays inside, heavy reasoning goes out — the rule is yours.

Section 5

`localOnly` = a guarantee you can put in the contract

Not a policy statement — a technical switch. When it is on, the system behaves differently.

Categorical refusal

Cloud models are not listed

With localOnly on, cloud models do not appear in the selection list. If a cloud model is requested anyway, the request is refused categorically — the "it went out by accident" scenario disappears.

Air-gap

Fully offline installation

Every layer — runtime binary, language model, embeddings, OCR, speech and image — can be fed from its own local source list. External internet access can be shut off entirely.

Extra governance

Allow-list and daily quota

Even in hybrid mode you can define a domain-based allow-list and a daily request quota. Where and how much traffic goes out is a management decision.

Key management

Cloud keys never descend

Cloud provider keys stay with the platform administrator; they never descend into the customer workspace and are always shown masked in the panel.

Section 6

Resilience — the question IT actually asks

"What happens if the model crashes, who protects my server, who fills my disk?" Answers below.

The model runs in a separate child process. A model crash can never take the platform down — your business modules keep running.
Crash-loop protection. If there are 3 crashes within 5 minutes the model is stopped, with guidance to "try a smaller model or lower the GPU layer count". No infinite restart loop.
Idle models are unloaded. After 30 minutes by default a model is released from memory; the number of concurrently loaded models can be capped.
Shared models. More than 100 customer workspaces can share the same loaded model — no separate copy per workspace.
Model downloads never start on their own. Which model is downloaded, and its disk cost, is the operator's decision; the system does not pull gigabytes behind your back.

AI That Runs InsideYour Company