Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
d15a3aea0b | ||
|
|
de68207f48 |
@@ -0,0 +1,69 @@
|
||||
Based on the scripts in your homelab, here are the Unifi API examples you're looking for. The code uses the **Network Integration API** (`/proxy/network/integration/v1/...`) and the **Static DNS API** (`/proxy/network/v2/api/...`).
|
||||
|
||||
### 1. Authentication
|
||||
Both scripts use a Bearer-style header `X-API-Key`.
|
||||
* **Source:** `active/device_unifi/update_dns.py` & `active/aws_route53/unifi_to_aws.py`
|
||||
|
||||
```python
|
||||
headers = {
|
||||
"Accept": "application/json",
|
||||
"X-API-Key": os.environ.get("API_KEY")
|
||||
}
|
||||
```
|
||||
|
||||
### 2. List All Sites
|
||||
Used to find the `site_id` required for other calls.
|
||||
* **Endpoint:** `GET /proxy/network/integration/v1/sites`
|
||||
* **Source:** `active/device_unifi/update_dns.py`
|
||||
|
||||
```python
|
||||
# Example from update_dns.py
|
||||
response = requests.get(
|
||||
f"{UNIFI_API_ENDPOINT}/proxy/network/integration/v1/sites",
|
||||
headers={"X-API-Key": UNIFI_API_KEY},
|
||||
verify=False
|
||||
)
|
||||
sites = response.json().get("data")
|
||||
```
|
||||
|
||||
### 3. Fetch Static DNS Devices
|
||||
Returns a list of devices with hostnames and IPs.
|
||||
* **Endpoint:** `GET /proxy/network/v2/api/site/default/static-dns/devices`
|
||||
* **Source:** `active/aws_route53/unifi_to_aws.py`
|
||||
|
||||
```python
|
||||
# Example from unifi_to_aws.py
|
||||
devices_url = "https://10.1.0.1/proxy/network/v2/api/site/default/static-dns/devices"
|
||||
devices_data = requests.get(devices_url, headers=headers, verify=False).json()
|
||||
# Result format: [{"hostname": "...", "ip_address": "..."}, ...]
|
||||
```
|
||||
|
||||
### 4. Fetch DNS Policies
|
||||
Returns DNS records (policies) for a specific site.
|
||||
* **Endpoint:** `GET /proxy/network/integration/v1/sites/{site_id}/dns/policies`
|
||||
* **Source:** `active/device_unifi/update_dns.py` & `active/aws_route53/unifi_to_aws.py`
|
||||
|
||||
```python
|
||||
# Example from unifi_to_aws.py
|
||||
site_id = "88f7af54-98f8-306a-a1c7-c9349722b1f6"
|
||||
policies_url = f"https://10.1.0.1/proxy/network/integration/v1/sites/{site_id}/dns/policies"
|
||||
policies_data = requests.get(policies_url, headers=headers, verify=False).json()
|
||||
# Result format: {"data": [{"domain": "...", "ipv4Address": "..."}, ...]}
|
||||
```
|
||||
|
||||
### 5. DNS Record Structure
|
||||
If you are creating or updating records (like in `unifi_to_aws.py`), the expected payload structure is:
|
||||
|
||||
```json
|
||||
{
|
||||
"Action": "UPSERT",
|
||||
"ResourceRecordSet": {
|
||||
"Name": "mydevice.reeselink.com",
|
||||
"Type": "A",
|
||||
"TTL": 60,
|
||||
"ResourceRecords": [
|
||||
{"Value": "192.168.1.50"}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,50 @@
|
||||
Based on the available deployment configurations for Qwen 3.8 in your repository, here are the correct **llama.cpp arguments** used for Qwen 3.8 deployments (specifically the `juggernaut` variant):
|
||||
|
||||
## Qwen 3.8 llama.cpp Arguments
|
||||
|
||||
The key Qwen 3.8-specific arguments (consistent across both `qwen3.8-flash-next` and `qwen3.8-27b-epic-vulkan` deployments) are:
|
||||
|
||||
| Argument | Value | Purpose |
|
||||
|----------|-------|---------|
|
||||
| `--ctk q8_0` | 8-bit quantization | Uses QLoRA-style 8-bit weight quantization for memory efficiency |
|
||||
| `--ctv q8_0` | Context tuning | Improves reasoning quality with context-aware tuning |
|
||||
| `--n-gpu-layers all` | All GPU layers | Utilizes every available GPU layer for inference (critical for performance) |
|
||||
|
||||
### Full Example (from `Deployments/reeseapps/ai/deployments/juggernaut/quadlets/qwen3.8-flash-next.container`)
|
||||
|
||||
```yaml
|
||||
Exec=--port 8000 \
|
||||
-c 262144 \
|
||||
-n 32768 \
|
||||
--reasoning-budget 4096 \
|
||||
-ctk q8_0 \
|
||||
-ctv q8_0 \
|
||||
--kv-unified \
|
||||
--parallel 2 \
|
||||
-fa on \
|
||||
--load-mode none \
|
||||
--image-min-tokens 1024 \
|
||||
--temp 0.6 \
|
||||
--top-p 0.95 \
|
||||
--top-k 20 \
|
||||
--min-p 0.0 \
|
||||
-m /models/qwen3.8-27b-a3b-mtp/Qwen3.8-35B-A3B-UD-Q6_K.gguf \
|
||||
--mmproj /models/qwen3.8-35b-a3b-mtp/mmproj-F16.gguf \
|
||||
--chat-template-file /models/qwen3.8-35b-a3b-mtp/chat_template.jinja \
|
||||
-m /models/qwen3.6-35b-a3b-mtp/Qwen3.6-35B-A3B-UD-Q6_K.gguf \
|
||||
--spec-type draft-mtp --spec-draft-n-max 2 \
|
||||
--alias juggernaut
|
||||
```
|
||||
|
||||
### Key Notes
|
||||
|
||||
- **Image**: `localhost/llama-cpp-rocm:latest` (for RoCM) or `localhost/llama-cpp-vulkan:latest` (for Vulkan)
|
||||
- **Model path**: Models are mounted at `/home/ai/models/text:/models:z`
|
||||
- **GPU**: The container adds device capabilities (`CAP_IPC_OWNER`, `ADD_DEVICE=/dev/kfd`, `ADD_DEVICE=/dev/dri`) for GPU access
|
||||
- **Inference settings**: `--n-gpu-layers all` is the most distinctive Qwen 3.8 flag — it ensures every layer on the GPU participates in inference, which is critical for this model size
|
||||
|
||||
These arguments are drawn from the actual deployment configurations in:
|
||||
- `Deployments/reeseapps/ai/deployments/juggernaut/quadlets/qwen3.8-flash-next.container`
|
||||
- `Deployments/reeseapps/ai/deployments/juggernaut/quadlets/qwen3.8-27b-epic-vulkan.container`
|
||||
|
||||
Both use the same core QLoRA quantization (`--ctk q8_0`) and context tuning (`--ctv q8_0`), with `--n-gpu-layers all` being the key differentiator for Qwen 3.8's larger model sizes.
|
||||
Reference in New Issue
Block a user