Direct answer
A mirror is interchangeable with a primary source only when the release policy identifies both as permitted origins for the same artifact and the client verifies the returned representation. A matching filename or successful HTTPS connection is insufficient. Bind model id, repository revision, format, expected length when established, and a trusted digest when available; then compare each response and the final bytes. A mirror should not silently change the artifact version, license record, tokenizer, or package structure. If identity cannot be established, treat the response as a different candidate and do not append it to existing partial bytes. The current ModelDownloader has a configured primary URL and optional mirror URL, and tries the mirror after certain connectivity failures. The E2B source is pinned to a repository commit in ModelConfig; its SHA-256 is empty, while E4B source metadata is described as placeholder and references a mutable branch. The code fact confirms mirror fallback exists, not that primary and mirror have been measured byte-identical. Never turn the presence of two URLs into a verified redundancy claim. The proper conclusion is that implementation needs an evidence record for mirror equivalence. The mirror validation contract should be prepared before the outage. For each artifact, store approved origin identifiers, immutable revision, format, size provenance, digest provenance, and the rule for redirects. Define whether a mirror may serve partial ranges and how the client binds a resumed response to earlier bytes. If the primary is unavailable, the client can use an approved mirror only after checking the same identity; it cannot make a new manifest from whatever file the mirror returns. If a digest is absent, state the weaker assurance accurately: source and revision pinning, TLS validation, length checks, and runtime load are different checks and do not equal cryptographic byte verification. Test mirror parity with controlled fixtures and real release records, not just by comparing URLs. Fetch the exact revision from each origin, record status and final URL, response range, content length, validators, and digest result. Repeat after a mirror refresh and after an interrupted download. A partial from origin A may only be resumed from origin B if the server metadata and trusted file identity prove representation continuity; otherwise restart from zero in a new candidate path. Do not merge responses based solely on equal lengths. There are operational tradeoffs. More mirrors may improve availability but expand the trusted-source set and increase the chance of stale revisions. A mirror that serves only one region may have different redirects or range behavior. Caching and reverse proxies may serve old data after a new source revision is published. Define freshness and revocation separately. A mirror response that fails validation should be recorded as rejected, and fallback should not loop through the same mirror repeatedly. User-facing copy should identify an unavailable or unverified source without exposing credentials or private URLs. Keep independent ledgers: source authorization, content identity, transfer state, and activation. TLS confirms a connection path to a host; an allowlist says the host is approved; a digest confirms byte equality only if its expected value came from a trusted channel; runtime loading confirms that the selected implementation accepted the file. None substitutes for all others. If a model vendor changes repository ownership or source terms, the trust decision must be reviewed rather than inherited automatically by a mirror. ### Procedure 1. Enumerate primary and mirror origins allowed for the exact model revision. Record who controls each origin, whether redirects are permitted, and which paths/versions each can serve. 2. Pin artifact metadata from an authoritative release record: revision, format, files, length and digest if trustworthy values exist. Label absent values unknown, not implicitly verified. 3. Fetch the same immutable object independently from each origin. Compare status, response metadata, full byte digest, and runtime/package validation; keep the logs tied to revision and test date. 4. Exercise failover and resume. Simulate origin outage, stale mirror, changed revision, partial transfer, ignored Range, and digest mismatch. Never append cross-origin bytes without representation continuity evidence. 5. Approve, reject, or quarantine each mirror result. Update the approved-source record when ownership or content changes, and prevent automatic loops through rejected origins. ### Acceptance criteria - Each permitted mirror is explicitly bound to the same immutable artifact identity, not just a similar filename. - Mirror fallback cannot override missing or mismatched revision metadata and cannot combine unrelated partial bytes. - Digest claims are made only when the expected digest has a documented trusted source; otherwise the remaining assurance is described narrowly. - Failure and stale-mirror fixtures reject the candidate while preserving the active artifact and user data. ### Comparison | Evidence | Establishes | Does not establish | |---|---|---| | Approved host or domain | The endpoint is allowed by release policy | That it serves the intended bytes | | Matching length and revision label | Basic metadata consistency | Cryptographic equality or publisher authenticity | | Trusted digest of each response | Byte equality to the expected digest | Runtime support, license, or task quality | ### FAQ **Can the app switch to any mirror when the main model URL times out?** No. A mirror must be approved in the artifact policy and return the same pinned representation. Connectivity failure alone does not authorize a new source or a different model revision. **Are matching filenames and file sizes enough?** No. Names and lengths are useful metadata but can match across different contents. Use an immutable revision and trusted digest when available; otherwise document that byte-level integrity is not established. **Can a partial download from one host resume from another?** Only when response metadata and trusted artifact identity establish continuity for the same representation and requested range. If that proof is absent, restart into a separate candidate instead of combining bytes. **Does mirror parity prove that the model is compatible?** No. Parity establishes content equivalence only for the checked artifact. The selected runtime must still load it and the declared task needs its own acceptance test; neither check creates a broad device claim.
A primary model host is unavailable during a partial transfer
A device has a partial temporary file from the configured primary repository. A connectivity failure makes the downloader consider a mirror. The app must preserve resumability without silently mixing a stale or different model revision.
Decision
Use the mirror only if release policy authorizes its origin and response identity proves it is the same immutable artifact; otherwise restart or stop with a clear state.
Expected outcome
A permitted mirror can be used with recorded evidence, while mismatch leaves the previous active model untouched and the partial candidate isolated.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Revision URL
- Length and digest
- Source-completion record
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
- Approve exact origins before failure. List primary and mirror origins, owners, permitted redirect targets, repository revision, and allowed artifact paths. Do not infer authorization from a matching host suffix or mirror label.
- Bind both endpoints to one artifact manifest. Record revision, format, expected length provenance, digest provenance, and tokenizer/package companions. Explicitly mark unavailable digest or placeholder size as unknown.
- Compare complete responses. Fetch the immutable artifact from each origin in a controlled test and compare status, final URL, range metadata, length, digest result, and runtime acceptance. Preserve records by revision and date.
- Validate cross-origin resume. Before appending, prove the mirror’s returned range is the same representation as saved partial bytes. If the validator or revision differs, isolate the candidate and restart only after policy permits.
- Test stale and rejected mirror paths. Simulate outage, stale content, redirects, ignored ranges, and digest mismatch. Confirm a rejected source is not retried in a loop and never replaces the active artifact.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Every allowed mirror is listed as a permitted origin for an exact immutable artifact revision.
- Matching filenames or lengths alone never permit resumed bytes or artifact activation.
- Missing trusted digest metadata is disclosed and never called a successful digest check.
- A stale or mismatched mirror candidate cannot replace the active model or erase user data.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Host allowlist | Source authorization | Approves an endpoint but does not prove its response content. |
| Revision, format, and length | Metadata consistency | Narrows identity but does not establish cryptographic byte equality. |
| Trusted digest comparison | Content parity check | Checks bytes only against a digest obtained through an approved channel. |
Failure patterns to prevent
- Trusting filenames
- Mixing mirror revisions
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
- IETF HTTP Semantics (range and representation metadata)
- Hugging Face Hub file download and revision pinning
- Hugging Face model repository history and commits
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
May any mirror be used after the primary times out?
No. Release policy must approve that origin, and the response must identify the same pinned representation. A connectivity error does not authorize a different source or revision.
Are filename and file size enough to prove mirrors match?
No. Different contents can share a name and length. Use an immutable revision and trusted digest when available; otherwise state clearly that cryptographic equality was not established.
Can a transfer resume on a different host?
Only when response metadata and trusted artifact identity prove that the returned range belongs to the same representation. Without that proof, restart in an isolated candidate path.
Does mirror parity prove device compatibility?
No. It proves content equality only for the tested artifact. Runtime loading and task acceptance are separate checks and do not establish compatibility for a wider device family.