Who this blueprint is for
This blueprint was prepared for a confidential chain-store operations company. Management uses governed entry points for operational queries, daily reports, and store tasks, while store staff keep using their existing collaboration tool. Customer names, people, stores, business amounts, and platform accounts are not disclosed.
The model service runs inside a controlled enterprise network, while authoritative business data stays on the customer NAS.
DingTalk, the management entry, and the model never connect directly to the production database; the business API enforces access.
Revenue, rankings, payroll, and settlement are computed by SQL or rules; the model interprets, calls tools, and explains results.
Fixed reports, task records, and manual workflows remain available when the model or OCR is offline.
Two DGX Spark deployment baseline
Two DGX Spark systems connect through an NVIDIA-approved high-speed link and jointly serve one DeepSeek V4 Flash model. The target is the official (0731) build; final deployment follows the supplied model files, license, model card, and hash verification.
Ordinary office Ethernet is not a model-parallel link. Validate the high-speed fabric, drivers, runtime, and two-node communication first.
Prioritize the official FP4/FP8 mixed-precision package; do not promise memory, speed, or concurrency without measurements.
Start production validation at 16K or 32K context. Use chunking, retrieval, and summarization for long documents; confirm the limit by testing.
Prioritize SGLang or vLLM listed by the model card. Other runtimes enter the plan only after architecture compatibility is verified.
Reference business architecture
The model is not the business ledger. The business host handles workflows, imports, OCR orchestration, access, and audit; the NAS stores databases, screenshots, reports, tasks, and logs; the two Spark systems expose only an internal model API.
Stores and managers keep receiving, confirming, completing, and being reminded about tasks in DingTalk.
Managers use a governed WPS/Comate or agreed management interface for queries and task operations.
The model scheduler, business API, access checks, queue, and audit logs live in the business service layer.
Collaboration platforms receive only the minimum fields needed for a workflow; the NAS remains authoritative.
Typical digital-employee workflows
Natural-language interaction is limited to auditable tool calls. The model never directly edits official business records.
Extract store, task, quantity, and due date; check permissions; send the task and record confirmation, reminders, completion, or cancellation.
Fixed SQL and rules compute daily reports, rankings, and trends; the model explains the result in plain language.
Screenshots enter a review queue after OCR; a person confirms the values before they become official data.
Reports are reviewed by an owner first. No unreviewed shareholder broadcast is configured.
Acceptance and failure boundaries
The two Spark systems jointly carry the main model; they are not an active-passive disaster-recovery pair. A node or fabric failure may pause the model, while the ledger and model-independent workflows remain available.
Validate sustained operation, model loading, memory use, and node communication—not merely a successful startup.
Freeze time to first token, full response time, generation rate, maximum production context, and measured light concurrency.
The model accesses governed tools only, cannot execute arbitrary SQL, holds no DingTalk or WPS secrets, and is not public-facing.
Test node restart, service recovery, backup restore, model rollback, and manual fallback procedures.
Scope and confidentialityCustomer names, people, stores, business data, accounts, addresses, and internal configuration are anonymized. This is a deployment blueprint, not a guarantee of model performance, compliance, or purchase price; final terms follow the confirmed package, data flow, test conditions, and acceptance criteria.
Planning a local DeepSeek V4 Flash deployment?
Share the target model package, business entry points, data boundary, and concurrency requirements. We will validate the two-Spark design before fixing delivery and acceptance criteria.