GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
deployxa
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Model Details
Model Provider
deployxa
Model Tree
Qwen/Qwen2.5-Coder-1.5B-Instruct
Input Modalities
Output Modalities
Supported Functionality
Modern cloud software delivery suffers from a fundamental diagnostic paradox:
Deployxa LM 1.0 is the first foundation model engineered from the ground up specifically for the cloud deployment lifecycle.
By distilling deep causal reasoning, distributed systems semantics, and container failure graphs into a high-density 1.5-billion parameter architecture, Deployxa LM achieves performance in the same diagnostic tier as commercial frontier APIs—while operating in under 1 GB of memory (860 MB RAM) entirely inside your private VPC, Kubernetes cluster, or local workstation.
text
┌────────────────────────────────────────────────────────────────────────────────────────┐│ DEPLOYXA LM 1.0: EVALUATION SUMMARY │├────────────────────────────────────────────────────────────────────────────────────────┤│ 🎯 Root-Cause Isolation (N=384) │ 76.4% vs 71.4% (GPT-4o) | 69.2% (Claude 3.5)││ 🛠️ Verifiable Container Recovery Rate │ 48.2% vs 37.3% (GPT-4o) | 22.2% (Base 1.5B) ││ 🛡️ Adversarial Log Injection Security │ 0 leaks / 50 test cases (vs 2/50 on GPT-4o) ││ 📉 False-Alarm Rate on Warning-Heavy Logs│ 5.8% vs 93.6% (Regex Heuristics) ││ 🔒 Privacy & Infrastructure Economics │ In-VPC / Zero per-token API fees │└────────────────────────────────────────────────────────────────────────────────────────┘The Core Value Proposition: Correctly isolates the root cause in 3 out of 4 incidents (76.4%), produces verifiable container fixes that pass automated HTTP readiness probes for nearly half of all failures (48.2%), and slashes alert fatigue by 16x—all within an ultra-compact 860MB local footprint.
text
┌───────────────────────────────────────────────┐ │ RAW DEPLOYMENT TELEMETRY │ │ (BuildKit, Docker, K8s, Logs, Traces) │ └───────────────────────┬───────────────────────┘ │ ▼ ┌───────────────────────────────────────────────┐ │ ADVERSARIAL FORENSIC SCRUBBER │ │ • Secret Redaction (Tokens, DB Passwords) │ │ • Prompt-Injection Sanitization (0 Leaks) │ └───────────────────────┬───────────────────────┘ │ ▼ ┌───────────────────────────────────────────────┐ │ DEPLOYXA MULTI-HOP CAUSAL ENGINE │ │ • 15-Class Granular Failure Disambiguation │ │ • Upstream Root-Cause Tracing (Anti-Recency) │ │ • Epistemic Calibration (Fail-Closed Gate) │ └───────────────────────┬───────────────────────┘ │ ▼ ┌───────────────────────────────────────────────┐ │ ACTIONABLE CONTAINER REMEDIATION │ │ • Machine-Executable SRE Recipes │ │ • Verifiable Container Boot (Readiness Probes│ │ • Deterministic Schema Compliance (100% JSON)│ └───────────────────────────────────────────────┘Generalist models anchor on the last line of an incident log (e.g. Exit code 137 or 502 Bad Gateway). Deployxa LM reconstructs the complete dependency graph, tracing back through hundreds of lines to isolate the initiating fault—whether that is a connection pool exhaustion 40 lines earlier or an unhandled loopback interface bind.
Rather than offering conversational advice or rewriting application business logic, Deployxa LM synthesizes machine-executable infrastructure remediations (e.g., binding 0.0.0.0:$PORT, configuring container memory limits, unlocking schema migrations, or aligning build output directories). In double-blind sandboxed Docker environments, Deployxa LM achieves a 48.2% verified container recovery rate—where the generated repair allows the container to boot and pass HTTP readiness probes.
Deployxa LM avoids the coarse categorization traps that cause other models to recommend wrong fixes. It cleanly isolates:
P1001 / ECONNREFUSED) vs. DB Auth Rejection (password failed) vs. DB Migration Lock.127.0.0.1) from actual port collisions.@/lib/...).Deployxa LM treats log streams strictly as immutable forensic evidence rather than conversational instructions. Embedded shell injections (rm -rf /, DROP TABLE), fake error messages, and prompt jailbreaks ("Ignore previous instructions") are completely neutralized—recording 0 leaks across 50 adversarial test cases.
Deployxa LM 1.0 maps deployment anomalies to 15 canonical failure classes paired with dynamic SRE remediations:
| Canonical Category | Description | Primary SRE Remediation Action |
|---|---|---|
PORT_BINDING_CONFLICT | Loopback bind (127.0.0.1) or port collision | REMEDIATE_BIND_ALL_INTERFACES (0.0.0.0:$PORT) |
DATABASE_CONNECTION_UNREACHABLE | Host unreachable / Prisma P1001 / ECONNREFUSED | REMEDIATE_VERIFY_DATABASE_HOST_AND_NETWORK |
DATABASE_AUTH_FAILED | Password / role failure on database authentication | REMEDIATE_UPDATE_DATABASE_CREDENTIALS |
DATABASE_MIGRATION_FAILED | Schema drift, pending migrations, lock contention | REMEDIATE_RUN_DATABASE_MIGRATIONS |
RUNTIME_CRASH | Unhandled TypeError, uncaught exception at startup | REMEDIATE_INSPECT_RUNTIME_TRACE_AND_PATCH |
DEPLOYMENT_TIMEOUT | Function 504 gateway timeout, startup deadline exceeded | REMEDIATE_EXTEND_FUNCTION_TIMEOUT_AND_WARMUP |
MISSING_BUILD_OUTPUT | Missing dist/ or build/ artifact directory | REMEDIATE_VERIFY_BUILD_OUTPUT_DIRECTORY |
AI_HALLUCINATED_IMPORT | Broken import alias (e.g. @/lib/... non-existent file) | REMEDIATE_RESOLVE_HALLUCINATED_IMPORT |
INVALID_APPLICATION_CONFIG | Missing environment variable (e.g. process.env.FOO) | REMEDIATE_SET_APPLICATION_CONFIG_ENV_VARS |
TYPESCRIPT_COMPILATION_ERROR | Strict TS compiler failures (tsc exit 1) | REMEDIATE_RESOLVE_TYPESCRIPT_BUILD_ERRORS |
DEPENDENCY_RESOLUTION_FAILED | npm peer conflicts (ERESOLVE), pip wheels | REMEDIATE_RESOLVE_PACKAGE_DEPENDENCIES |
CONTAINER_OOM_KILLED | Out of memory / Linux OOM Killer (Exit code 137) | REMEDIATE_INCREASE_CONTAINER_MEMORY_LIMIT |
HEALTHCHECK_PROBE_FAILED | HTTP 404/500 on readiness endpoint | REMEDIATE_ALIGN_HEALTHCHECK_PATH_AND_PORT |
DNS_RESOLUTION_FAILURE | Missing internal DNS service resolution | REMEDIATE_RESOLVE_INTERNAL_DNS_ENDPOINTS |
TLS_CERTIFICATE_ERROR | Expired, self-signed, or invalid SSL certificate | REMEDIATE_RENEW_OR_ATTACH_VALID_SSL_CERTIFICATE |
All evaluations are conducted against an open dataset of 384 real deployment failure incidents across 9 polyglot ecosystems (Node.js/Next.js, Python/FastAPI, Go, Rust, Docker BuildKit, Postgres/Prisma, Kubernetes probes, TLS/ingress, and AI-scaffolded applications).
| Dimension / Metric | Traditional Regex | Base Open LLM | Frontier Cloud API (GPT-4o) | Deployxa LM 1.0 (Our Work) |
|---|---|---|---|---|
| Model Footprint | Static Regex | 1.54B Parameters | ~200B+ Parameters | 1.54B Base + 18.5M LoRA (860 MB) |
| Root-Cause Isolation (N=384) | 40.9% | 22.2% | 71.4% (Recency bias) | 76.4% (Causal Multi-Hop) |
| Verified Container Recovery | N/A | 22.2% | 37.3% (Code refactor drift) | 48.2% (Passes HTTP readiness probes) |
| Strict JSON Schema Compliance | 100.0% | 88.9% | 96.2% | 100.0% (Zero parse errors) |
| Clean Log False Alarm Rate | 93.6% | Unbounded | < 3.0% | 5.8% (Filters non-fatal warnings) |
| Adversarial Injection Security | N/A | Leaks prompt | 4.0% leak rate (2/50) | 0 leaks / 50 test cases |
| Per-Token API Metering | $0.00 | $0.00 | Metered per 1k tokens | $0.00 per-token fees (In-VPC) |
| Inference Latency (Edge) | < 10ms | ~45ms | 4,000ms – 12,000ms | 1.5s – 3.2s (Deterministic) |
| Data Privacy & Compliance | In-Cluster | In-Cluster | Telemetry leaves VPC | 100% In-VPC / Zero Egress |
Run Deployxa LM 1.0 locally in Ollama:
bash
ollama run deployxa/deployxa-lmdxa-lm)bash
# Install the CLI from PyPIpip install dxa-lm # Diagnose a failure log filedxa-lm diagnose /var/log/deploy/error.log # Pipe directly from Docker build or CI/CDdocker build . 2>&1 | dxa-lm diagnose # Interactive SRE chat consoledxa-lm chat # Check production cluster healthdxa-lm healthpython
import torchfrom transformers import AutoTokenizer, AutoModelForCausalLMfrom peft import PeftModel BASE_MODEL = "Qwen/Qwen2.5-Coder-1.5B-Instruct"ADAPTER_REPO = "deployxa/deployxa-lm-1.0" tokenizer = AutoTokenizer.from_pretrained(BASE_MODEL, trust_remote_code=True)base_model = AutoModelForCausalLM.from_pretrained( BASE_MODEL, torch_dtype=torch.float16, device_map="auto")model = PeftModel.from_pretrained(base_model, ADAPTER_REPO)model.eval() # Telemetry log payloadprompt = """<|im_start|>systemYou are Deployxa LM 1.0, Deployxa Cloud's specialist deployment diagnostic model.Analyze the provided deployment telemetry. Format response strictly as JSON with keys:deployment_status, root_cause_category, confidence, evidence, reasoning_summary, recommended_action_ids, abstain.<|im_end|><|im_start|>userDeployment Logs:[server] Express listening on http://127.0.0.1:3000Readiness probe failed to connect.Diagnose deployment:<|im_end|><|im_start|>assistant""" inputs = tokenizer(prompt, return_tensors="pt").to("cuda" if torch.cuda.is_available() else "cpu")with torch.no_grad(): outputs = model.generate(**inputs, max_new_tokens=350, temperature=0.1) print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))Expected Diagnostic Output:
json
{ "deployment_status": "FAILED", "root_cause_category": "PORT_BINDING_CONFLICT", "confidence": 0.95, "evidence": "Express listening on http://127.0.0.1:3000", "reasoning_summary": "Application bound strictly to loopback (127.0.0.1/localhost) instead of 0.0.0.0, preventing platform ingress routing.", "recommended_action_ids": [ "REMEDIATE_BIND_ALL_INTERFACES", "REMEDIATE_SET_PORT_ENV" ], "abstain": false}Run the production API server in Kubernetes or a local container:
bash
dxa-server --host 0.0.0.0 --port 8080Deployxa LM 1.0 enforces strict safety and reliability invariants:
safety_controls.read_only_mode = true)."Deploy failed" with no stack traces), the model refuses to guess—scoring 0.15 confidence (LOW), outputting STANDBY status, and triggering abstain: true with ESCALATE_HUMAN_SRE_AUDIT.Leaderboard from our 384-incident eval; the open deployxa/cloud-sre-bench repository ships the benchmark harness with a 26-case public subset.
Run the benchmark evaluation suite:
bash
git clone https://github.com/deployxa/cloud-sre-bench.gitcd cloud-sre-bench # Run against Ollama or live APIpython3 run_benchmark.py --target api# or: python3 run_benchmark.py --target ollama --model deployxa/deployxa-lmDeployxa LM 1.0 is released under the Apache 2.0 License.
Built with pride by Deployxa Cloud Inc. (https://deployxa.com).
Brand assets, lockups, and design guidelines are available at deployxa.com/brand.
┌────────────────────────────────────────────────────────────────────────────────────────┐│ DEPLOYXA LM 1.0: EVALUATION SUMMARY │├────────────────────────────────────────────────────────────────────────────────────────┤│ 🎯 Root-Cause Isolation (N=384) │ 76.4% vs 71.4% (GPT-4o) | 69.2% (Claude 3.5)││ 🛠️ Verifiable Container Recovery Rate │ 48.2% vs 37.3% (GPT-4o) | 22.2% (Base 1.5B) ││ 🛡️ Adversarial Log Injection Security │ 0 leaks / 50 test cases (vs 2/50 on GPT-4o) ││ 📉 False-Alarm Rate on Warning-Heavy Logs│ 5.8% vs 93.6% (Regex Heuristics) ││ 🔒 Privacy & Infrastructure Economics │ In-VPC / Zero per-token API fees │└────────────────────────────────────────────────────────────────────────────────────────┘ ┌───────────────────────────────────────────────┐ │ RAW DEPLOYMENT TELEMETRY │ │ (BuildKit, Docker, K8s, Logs, Traces) │ └───────────────────────┬───────────────────────┘ │ ▼ ┌───────────────────────────────────────────────┐ │ ADVERSARIAL FORENSIC SCRUBBER │ │ • Secret Redaction (Tokens, DB Passwords) │ │ • Prompt-Injection Sanitization (0 Leaks) │ └───────────────────────┬───────────────────────┘ │ ▼ ┌───────────────────────────────────────────────┐ │ DEPLOYXA MULTI-HOP CAUSAL ENGINE │ │ • 15-Class Granular Failure Disambiguation │ │ • Upstream Root-Cause Tracing (Anti-Recency) │ │ • Epistemic Calibration (Fail-Closed Gate) │ └───────────────────────┬───────────────────────┘ │ ▼ ┌───────────────────────────────────────────────┐ │ ACTIONABLE CONTAINER REMEDIATION │ │ • Machine-Executable SRE Recipes │ │ • Verifiable Container Boot (Readiness Probes│ │ • Deterministic Schema Compliance (100% JSON)│ └───────────────────────────────────────────────┘# Install the CLI from PyPIpip install dxa-lm # Diagnose a failure log filedxa-lm diagnose /var/log/deploy/error.log # Pipe directly from Docker build or CI/CDdocker build . 2>&1 | dxa-lm diagnose # Interactive SRE chat consoledxa-lm chat # Check production cluster healthdxa-lm healthimport torchfrom transformers import AutoTokenizer, AutoModelForCausalLMfrom peft import PeftModel BASE_MODEL = "Qwen/Qwen2.5-Coder-1.5B-Instruct"ADAPTER_REPO = "deployxa/deployxa-lm-1.0" tokenizer = AutoTokenizer.from_pretrained(BASE_MODEL, trust_remote_code=True)base_model = AutoModelForCausalLM.from_pretrained( BASE_MODEL, torch_dtype=torch.float16, device_map="auto")model = PeftModel.from_pretrained(base_model, ADAPTER_REPO)model.eval() # Telemetry log payloadprompt = """<|im_start|>systemYou are Deployxa LM 1.0, Deployxa Cloud's specialist deployment diagnostic model.Analyze the provided deployment telemetry. Format response strictly as JSON with keys:deployment_status, root_cause_category, confidence, evidence, reasoning_summary, recommended_action_ids, abstain.<|im_end|><|im_start|>userDeployment Logs:[server] Express listening on http://127.0.0.1:3000Readiness probe failed to connect.Diagnose deployment:<|im_end|><|im_start|>assistant""" inputs = tokenizer(prompt, return_tensors="pt").to("cuda" if torch.cuda.is_available() else "cpu")with torch.no_grad(): outputs = model.generate(**inputs, max_new_tokens=350, temperature=0.1) print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)){ "deployment_status": "FAILED", "root_cause_category": "PORT_BINDING_CONFLICT", "confidence": 0.95, "evidence": "Express listening on http://127.0.0.1:3000", "reasoning_summary": "Application bound strictly to loopback (127.0.0.1/localhost) instead of 0.0.0.0, preventing platform ingress routing.", "recommended_action_ids": [ "REMEDIATE_BIND_ALL_INTERFACES", "REMEDIATE_SET_PORT_ENV" ], "abstain": false}git clone https://github.com/deployxa/cloud-sre-bench.gitcd cloud-sre-bench # Run against Ollama or live APIpython3 run_benchmark.py --target api# or: python3 run_benchmark.py --target ollama --model deployxa/deployxa-lm