User capacity cannot be determined from memory alone. One employee asks a short question, another submits a long document, and a third processes a meeting recording. These jobs have different resource requirements and completion times.
Distinguish registered users from active work
Many employees may have accounts while only a few request generation simultaneously. Retrieval, recognition and generation also need not use one model. Separate interactive requests from background processing before selecting equipment.
Ollama's documentation notes the relationship between memory demand, parallel requests and context length. This is one reason to test the actual runtime and workload rather than infer capacity from a mini PC specification. Ollama · FAQ ↗
Example: a busy sales morning
Several managers prepare replies while an archive is being indexed. Without scheduling rules, background work may degrade interactive waiting times. A proposed arrangement gives short requests their own queue and limits large imports or schedules them elsewhere.
Make queue state visible. Users should know a request was accepted, be able to cancel it and avoid submitting duplicates through repeated clicks. A failed job should explain its cause and support retrying without duplicating its output.
Build a representative workload test
- Include short, medium and the heaviest normal assignments. - Use a realistic number of simultaneous active requests. - Measure time to first response and to the completed document. - Repeat alongside indexing and backup activity.
Respond to the actual bottleneck
If quality is acceptable but waiting is excessive, consider a smaller model, less irrelevant context or different background scheduling. If failures originate in poor source data, more powerful hardware will not fix them. Expand the station after identifying the constraint. AI Office roles can be introduced as workloads are tested, without promising every conceivable function will run concurrently.