35 lines
2.7 KiB
Markdown
35 lines
2.7 KiB
Markdown
## Shared Test Docker Host
|
|
|
|
- Use SSH alias `test-docker` / `docker-test` for the shared test Docker host.
|
|
- Host: `docker-test.cin.su` (`192.168.200.61`)
|
|
- SSH user: `test`
|
|
- Preferred Docker endpoint when Docker CLI is available: `ssh://test-docker`
|
|
- Portainer: `http://docker-test.cin.su:9000/`, user `admin`
|
|
- Do not store the password in repositories or project files; use an SSH key for persistent access.
|
|
|
|
## GPU Docker Host
|
|
|
|
- This project works with local LLM models and uses GPU resources.
|
|
- Use `upo_test` as the default 1C test database `base_id` for adapter checks in this project.
|
|
- Use `docker-gpu.cin.su` as the deployment target for GPU workloads.
|
|
- Prefer GPU-capable Docker deployments on `docker-gpu.cin.su` when running or serving local models.
|
|
- For training/download containers on `docker-gpu`, sync the current repo into `Z:\LLM\model-chat-app` first. These containers should read code from the synced app directory, not directly from `Z:\codex\LLM`.
|
|
- Do not store credentials, tokens, model secrets, or host passwords in repositories or project files.
|
|
|
|
## Test-system security profile
|
|
|
|
- This project currently runs as an isolated test system; use the minimum security profile unless the user explicitly requests production hardening.
|
|
- Network-level access control is sufficient for test web interfaces. `ONEC_ADAPTER_SERVICE_TOKEN` is optional when `ONEC_ADAPTER_ALLOW_UNAUTHENTICATED_ADMIN=true` is explicitly set.
|
|
- Do not block test deployment only because a service token is absent when the explicit unauthenticated-admin flag is enabled.
|
|
- Even in the minimum profile, never commit credentials or passwords, never return stored passwords through APIs, and keep runtime credential files outside git.
|
|
|
|
## Architecture
|
|
|
|
- Use the `core + plugins` architecture.
|
|
- Put shared platform capabilities in `core`: model registry, inference, storage, training, evals, deployment, and monitoring.
|
|
- Put task-specific logic in `plugins`: text, translation, audio, video, and 1C.
|
|
- Design every plugin as a future standalone service: keep its API, pipelines, datasets, evals, and configuration inside the plugin folder.
|
|
- Keep model binaries and large datasets out of git. Store only manifests, model cards, metadata, scripts, and reproducible deployment configuration.
|
|
- For 1C, start with RAG and tool integrations before fine-tuning. Use LoRA or adapter-based fine-tuning when enough curated examples are collected.
|
|
- For 1C adapter work, treat object names as the primary selector. When solving tasks, start from names or public refs such as `РегистрСведений.Имя` or `InformationRegister.Name`; if the implementation needs GUIDs, SQL numbers, or internal codes, resolve them internally from the provided names instead of requiring callers to know storage identifiers.
|