DeepSeek Model Fingerprint: Why a GPT Label Is Not Proof

A DeepSeek model fingerprint result can show which enrolled model an API’s output resembles. It cannot, by itself, establish who trained the model or which provider served a particular request. That distinction matters when a detector assigns a confident GPT label to DeepSeek even though DeepSeek is absent from its reference bank.

DeepSeek’s October 17, 2026 release announcement confirms DeepSeek-V4.1-Flash-1017 and says it is available through the website, app, and API. The separate allegation that a fingerprint proves the service is GPT-6 Astra is not established by that announcement or by the classification method examined here. The useful security question is how to investigate model identity without turning a similarity score into an unsupported accusation.

What the DeepSeek fingerprint controversy actually establishes

The decisive limitation is visible in the detector’s own documentation. The ModelTrace README lists 18 candidates from the GPT and Claude families, with no DeepSeek entry. It warns that an unenrolled model can still receive an existing candidate’s label and that results are not decisive evidence of identity. Its reference collection also spans different service environments: GPT samples come from Codex subscriptions, while Claude samples come from a third-party service. Those are reference-channel descriptions, not independent attestations of underlying weights.

This changes the interpretation of the result before any comparison with DeepSeek begins. The experiment cannot select a DeepSeek label that does not exist in its candidate set. A high score for another label therefore requires investigation of the detector’s coverage and calibration before it supports investigation of the provider. That is a limitation of the inference, not proof that the detector has no practical value.

The figures supplied with the reported screenshot—84.66% for GPT-6 Astra and 90.71% for the GPT family—should be treated as reported detector outputs. We have not reproduced those figures with fresh model calls, verified the exact reference-bank revision used to generate them, or established a chain of custody for the original run. They are not measured probabilities that DeepSeek routes requests to another vendor.

Three claims that must stay separate

The strongest clarification is also the most easily lost: showing that one argument is insufficient does not prove the opposite allegation false. An incomplete candidate bank undermines the inference from a GPT label to a GPT backend. It does not authenticate DeepSeek’s hosted implementation. The current evidence supports withholding the accusation; it does not support certifying an infrastructure that has not been independently examined.

There are three distinct questions. First, what product did the vendor announce? A vendor announcement directly answers that question. Second, what observable system answered a particular request? That requires evidence tied to the endpoint, request, and time. Third, what is the model’s training ancestry? That requires a provenance investigation. Moving from an answer to the first question into a conclusion about the second or third is a change of claim, even when the product names stay the same.

A related naming trap concerns the detector’s own labels. A reference-bank entry called GPT-6 Astra is the project’s enrolled label. The existence of that string in a repository does not independently certify which weights produced its reference responses. Before treating any candidate as ground truth, an investigator needs to document how that reference was collected and authenticated. Reference provenance is part of the experiment, not a clerical detail.

What a model fingerprint measures

A behavioral fingerprint is a set of output characteristics used to compare an unknown system with reference systems. It can capture preferences that ordinary task accuracy hides. Two models may both answer a question correctly while differing in their token choices, formatting, or response to carefully controlled prompts. The fingerprint represents those observable tendencies under particular test conditions.

This differs from hashing a model file. A cryptographic digest checks whether a particular byte sequence matches another byte sequence. Behavioral testing observes a service across a boundary that the investigator does not control. The response may depend on the model, system instructions, prompt formatting, generation settings, and intermediate processing. A behavioral match consequently needs an experimentally justified interpretation.

The operational target also needs a precise definition. Identifying a release, identifying a model family, detecting a change in one endpoint, and establishing training ancestry are four different tasks. A method that performs well on one task does not automatically perform well on the others. An investigator should state the claim being tested before choosing probes or interpreting their scores.

How ModelTrace turns integer outputs into an attribution

ModelTrace uses three integer-generation challenges. Its fingerprint implementation defines a range of 1 through 355 and combines distributional and ordered-sequence features. The documented combination weights the Hellinger-based component at 0.75 and the ordered component at 0.25; scores are then normalized with softmax, and family values sum the scores assigned to member models. The README describes projection of estimated environment directions as part of its comparison process.

The method compares extracted behavior with enrolled references. It does not inspect a remote provider’s parameter files or trace its server-to-server traffic. Interpreting the selected label as proof of the remote infrastructure crosses a gap that the measurement itself does not close.

Environment correction is useful in principle, but its effectiveness must be evaluated on the environments encountered in deployment. Removing variation estimated from reference data cannot be assumed to remove every future system-prompt or serving change. This is an evaluation requirement, not a finding that the project’s correction necessarily fails for DeepSeek.

Why a confident score can still identify the wrong model

Softmax distributes a fixed total across the candidates supplied to it. For scores s and scale β, the value assigned to candidate i is exp(βsᵢ) divided by the sum of exp(βsⱼ) across the candidate set. That denominator contains the enrolled alternatives. It does not automatically contain a hypothesis for an unknown model, an unseen configuration, or an invalid test.

The following synthetic calculation illustrates the normalization issue. It is an educational example, not a ModelTrace reproduction, a DeepSeek measurement, or an implementation of the project’s calibration. Only Python’s standard library is needed; it makes no network requests.

from math import exp

scores = {"candidate_A": 0.70, "candidate_B": 0.55}
beta = 12.0
maximum = max(scores.values())
weights = {k: exp(beta * (v - maximum)) for k, v in scores.items()}
total = sum(weights.values())
for candidate, weight in weights.items():
    print(candidate, round(100 * weight / total, 2))

The rounded output is 85.81 for candidate_A and 14.19 for candidate_B. The calculation has no input describing whether either candidate actually generated the sample. Increasing the scale makes the distribution more concentrated without adding evidence that the true model belongs to the set. The numerical similarity to a reported percentage would have no evidentiary significance.

Calibration must match the question being asked. Accuracy on held-out examples from enrolled candidates estimates performance within that evaluation setup. It does not establish the false-attribution rate for every model excluded from the bank. Repeatedly receiving the same incorrect label would demonstrate consistency, while leaving correctness unresolved.

Even a family-level result needs care. Summing candidate values produces the family aggregate specified by the detector. It does not create an independent measurement of corporate origin or training lineage. Changing which candidates are enrolled can change the normalized allocation, so reports should retain the bank itself alongside the output.

What “100% historical accuracy” would need to mean

A perfect accuracy display is meaningful only with its denominator, sampling unit, and test design. Ten correct runs and ten thousand correct runs have the same point estimate but substantially different uncertainty. Repeated combinations of the same underlying responses are also not equivalent to fresh, independently collected observations. A report should disclose what was held out, how much data was collected, and whether the evaluation includes unknown models.

The project’s bank-building implementation constructs calibration records by holding out challenge identifiers, refitting reference artifacts, and scoring held-out responses from enrolled models. It fits a softmax scale by minimizing classification loss. This is a concrete calibration procedure, but its candidate labels remain the enrolled model set. The procedure does not, by itself, measure how often an excluded DeepSeek release receives a confident GPT label.

There is a practical distinction between identifying an enrolled model and rejecting an unenrolled one. An evaluation can succeed at the first while never testing the second. The appropriate additional result is an unknown-model false-acceptance rate: among systems deliberately excluded from enrollment, how often does the detector nevertheless accept a known identity at the selected threshold? Report that alongside known-model identification accuracy and the rate at which legitimate known samples are rejected.

As a hypothetical statistical example, zero false acceptances in 100 independent unknown-model trials still does not establish a zero error rate. Under an independent, identically distributed Bernoulli model, a one-sided 95% upper confidence bound is 1 − 0.05 raised to the power 1/100, approximately 2.95%. Real API samples may share prompts, backend configuration, or collection batches, so the independence assumption itself needs examination. The example shows why an impressive percentage needs an experimental frame.

Separate model substitution from distillation

Model substitution is a serving claim: a request advertised as reaching one model was actually handled by another. Distillation is a training claim: a student learned from a teacher’s outputs or related supervision. Shared behavior can be relevant to either investigation, but these claims require different evidence. A locally running student could resemble a teacher without contacting that teacher during inference.

A verified downloadable checkpoint would establish that an independently deployable artifact is available. It would not prove that every hosted request uses that artifact, establish its training-data provenance, or rule out conditional routing. For this article, the supplied Hugging Face checkpoint URL could not be retrieved independently, so checkpoint availability is not used as a verified premise. The official announcement remains the source for the release statement.

Provenance research also has a narrower scope than social-media conclusions often imply. The ACL 2026 paper Fingerprinting LLMs via Prompt Injection introduces LLMPrint and reports evaluation across five base models and approximately 700 post-trained or quantized variants. Its results concern the authors’ experimental setting; they do not independently establish a relationship between DeepSeek and GPT-6 Astra. The paper is relevant because it frames provenance as a defined verification problem rather than a nearest-label screenshot.

A reproducible DeepSeek model fingerprint investigation

A useful study should distinguish at least three hypotheses: the endpoint is consistent with the claimed model under its serving configuration; the endpoint differs because the configuration differs; or the endpoint uses a different backend for some requests. These hypotheses can produce overlapping observations. The design needs controls that make the alternatives easier to separate.

Begin by freezing the detector revision, complete reference bank, prompts, scoring configuration, and output parser. Record the advertised model identifier and request time. Preserve every raw response, including malformed or truncated ones. Discarding inconvenient samples without a rule decided beforehand can make a detector appear more reliable than it is.

Enroll relevant alternatives through trusted channels where practical. Include the claimed DeepSeek release and other families that might otherwise be forced into existing labels. Reserve fresh requests for evaluation rather than comparing reference samples with themselves. A hold-one-model-out exercise is especially informative: remove a known candidate and measure how the procedure behaves when the correct answer is unavailable.

Permit an inconclusive outcome. A rejection rule can consider absolute distance, separation between candidates, and repeated-sample variability, but its threshold must be evaluated with independent known and unknown examples. A convenient cutoff chosen after seeing the disputed screenshot is not a validated unknown-model detector.

Compare the hosted API with a verified local deployment

If the exact checkpoint becomes independently available, record its revision and file digests before deployment. Retain the tokenizer, chat template, inference engine, numerical precision, generation settings, and hardware details. Match the visible hosted configuration as closely as documentation allows, while explicitly recording hidden or unavailable settings.

First measure variation within each environment. Multiple local runs and multiple hosted runs establish how much ordinary variability exists before a cross-environment difference is judged. Compare groups of outputs rather than expecting identical strings. If hosted-local differences are no larger than routine within-environment differences under the chosen metric, that supports consistency for that metric and test set. It does not establish universal equivalence.

If a discrepancy persists, vary one controllable factor at a time. A template difference can otherwise be mistaken for a weight difference. If the hosted service exposes no exact release pin, record that limitation instead of silently treating a moving alias as a fixed version. Independent routing evidence or provider cooperation may still be necessary to resolve the serving claim.

A minimum experiment matrix that tests competing explanations

The following is a proposed design, not a completed benchmark. Each row answers a different question. Enrolling more models is necessary to address coverage, but it should not be the only change: without fresh evaluation data, a larger bank can merely produce a more elaborate explanation of the same samples.

Set the success criteria before unblinding. For example, require acceptable unknown-model rejection on held-out families before using the system for identity decisions. Choose any numeric threshold from the cost of a false accusation and from validation data, rather than selecting a reassuring percentage after viewing the disputed result. A system that cannot meet the requirement can still serve as a change detector if its output is labeled accordingly.

Preserve invalid-output rates too. An evaluator who retries until three well-formed sequences appear has measured behavior conditional on successful completion. That is a defensible protocol if disclosed, but it differs from measuring every request. If refusal or truncation rates differ by provider, excluding them can remove a material part of the comparison. Record both the raw sample population and the subset used for scoring.

Use blind tests and keep probe behavior in scope

Have the evaluator score samples without knowing their source labels, then reveal the labels after the scoring rules are fixed. Keep enrollment, threshold selection, and final evaluation separate. Report failures by model and configuration, rather than relying on one aggregate accuracy number that conceals where the detector misidentifies unknown inputs.

A provider could also serve specialized probes differently from ordinary traffic. That possibility does not establish that any provider does so. It explains why predictable public challenges alone cannot attest to all production requests. A stronger study checks several probe families and ordinary representative tasks, while keeping the resulting claim limited to observed behavior.

What would materially strengthen a backend substitution claim?

The strongest evidence would connect the disputed request with the system that actually processed it. Depending on available access, that could include independently audited provider-side routing records, trustworthy deployment attestation, or corroborated operational records tying the request to another backend. Such evidence has its own authenticity and scope requirements. A response field containing a model name is still supplied by the service being investigated.

Latency, token counts, familiar wording, and refusal style can provide investigative leads. None uniquely identifies a backend: caching can change latency, prompt templates can change wording, and different models can share conventions. Several correlated clues should not be counted as several independent confirmations if they arise from the same response or shared configuration.

A verified local checkpoint offers a useful counterexample to a universal “only a remote wrapper exists” claim: it would show that an independent artifact can execute. It would still leave a narrower question about the hosted service. Conversely, a statistically convincing hosted-local discrepancy would establish inconsistency before it establishes the identity of an alternative backend. Moving from “different” to “this specific model” requires validated discrimination among realistic alternatives.

For a distillation claim, even confirmed backend records would answer the wrong question. Training ancestry needs a method validated against plausible unrelated models, shared datasets, and post-training changes, plus corroborating provenance evidence where available. Similar outputs can motivate that work; they cannot substitute for it.

Turn fingerprinting into an API supply-chain control

For an organization buying model access, a practical use of fingerprinting is detecting a behavioral change that deserves review. Establish an approved baseline for a specific endpoint and configuration, then compare new samples over time. Preserve billing records, contractual model descriptions, provider notices, request identifiers when available, and the client configuration used for collection.

An alert should initially mean that the service differs from the approved baseline. Investigation can then examine legitimate upgrades, parameter changes, proxy modifications, caching, and routing. Automatically replacing the provider because a detector selected another label would allow an uncertain measurement to drive a consequential operational change.

Keep probes free of customer secrets and production credentials. Use dedicated test access where available and collect only the evidence needed to reproduce the observation. A fingerprint result cannot establish data residency or confirm where a prompt traveled; those questions need contractual, infrastructure, or other independently grounded evidence.

Questions about DeepSeek model fingerprints

Does a GPT-6 Astra fingerprint prove DeepSeek is using GPT-6 Astra?

No. A label from a candidate bank that excludes DeepSeek cannot establish that conclusion. It identifies a preferred enrolled candidate under the detector’s procedure.

Is 84.66% the probability that the allegation is true?

No. The reported number is a detector allocation under a particular candidate set and scoring setup. Interpreting it as a real-world origin probability requires evidence that the setup does not supply.

Can asking a model its name verify its identity?

Self-identification is another output to evaluate. A model’s statement about its name does not authenticate the provider’s routing or disclose its training history.

Would a matching local model settle the question?

It would support behavioral consistency for the tested checkpoint, settings, and prompts. It would not establish what happens on every hosted request or settle training provenance.

What should an investigator publish with a fingerprint claim?

Publish the detector revision, reference-bank identity, prompts, raw outputs, settings, rejection rules, and blind-test results, with credentials removed. Clearly separate reproduced findings from proposed experiments.

The evidence to seek next

The next useful result would be a controlled comparison that includes DeepSeek, evaluates excluded models, and preserves the raw material for independent review. Until that exists, the defensible conclusion is limited: the examined detector can assign a known-model label to an unknown input, and the reported screenshot does not establish DeepSeek’s underlying provider. Treat the label as a lead, test the alternatives, and make the final claim no broader than the evidence.