Truncated weights file after YOLO training transfer: signs and checks

You trained a custom YOLO detector, watched sensible boxes with sensible scores on the training machine, then copied the .weights file to another PC — and now everything in the image reports about 100 percent confidence. That combination has one dominant cause: the copy is shorter than the original, so the last layers of the network never received their values. Two checks prove it in under a minute: compare the byte count against the training machine, then compare a SHA-256 hash. This page also gives you the loss number that convicts a bad file after the fact, the five steps back to a working model, and the habit that stops a repeat — record the size and hash when training finishes, before any file ever moves.

The symptom pattern

On the training machine, boxes are tight and scores sit between roughly 60 and 95 percent. On the receiving machine, the same image returns a wall of boxes: nearly every class crosses your confidence threshold at once, many at or near 1.0. And if you restart training from the copied file, the log's avg value opens in the hundreds or thousands instead of near the finishing value of about 0.1.

The uniformity is what convicts the file. A preprocessing mismatch, a bad class list or a changed input resolution degrades detections unevenly — some classes survive, scores spread out. Truncated weights do the opposite. Darknet reads the file sequentially, one float per weight, and when the bytes run out the remaining layers load as zeros. A detector head fed zeros returns near-constant, saturated scores for every anchor and class, so everything passes the threshold at the cap. The restart symptom has the same root: the optimizer resumes from those zeros, and avg behaves as if the network had never trained at all.

Likely causes, most probable first

Rank the suspects like this when the failure starts exactly at the move:

1. Truncated transfer. The download hit a size cap or stopped early; hosted notebook sessions with time limits and browser download managers both do this silently. Highest probability, and the only cause that explains all three findings at once.
2. Mangled bytes at equal size. A text-mode transfer or a re-encoded archive changes content without changing length. Tested by the hash, not by the size.
3. Cfg and weights out of step. The weights were saved for a different cfg, with different filters or class counts, so layer sizes disagree at load time or the output is garbage. Tested by loading the pair on the training machine.
4. Class list out of step. A .names file that disagrees with the cfg's class count shifts or renames labels while scores stay sane. Tested by counting classes on both sides.
5. Changed input pipeline. A different input size, letterboxing or channel order on the receiving machine degrades scores without the 100-percent signature. Tested by running one identical image on both machines.

Byte size rules the first suspect in or out in under a minute, which is why it comes first.

Check 1: byte size against the training log

A Darknet .weights file is 20 bytes of header — three 32-bit version fields plus a 64-bit counter of images seen — followed by one 32-bit float per network weight. The complete size therefore follows from the cfg alone.

W is the total float count of your cfg. The reference value is the original file on the training machine, or the size you recorded when training finished.

Read exact bytes, not the rounded figure a file explorer shows. On Linux or macOS, ls -l model.weights prints them; on Windows PowerShell, (Get-Item .\model.weights).Length does the same.

Decision: copied bytes equal the source, the file advances to the hash check. Copied bytes run short, the copy is dead — fetch a fresh archive or a training backup, and never resume training from it.

Check 2: SHA-256 on both copies

Equal sizes do not prove equal content, so hash both files next. On Linux or macOS, run sha256sum model.weights; on Windows, certutil -hashfile model.weights SHA256. Equal hashes mean the bytes are identical and the file is innocent — continue with the cfg, class-list and input-pipeline checks from the causes list. Different hashes at equal size mean the transfer rewrote the content, typically a text-mode transfer or a re-compressed archive; pack the weights in a zip, move the archive once, and hash it on both ends before unpacking.

Check 3: what avg says on resume

Darknet's log prints avg after every batch — a moving average of the loss, roughly nine parts previous value to one part current batch. It is the fastest post-mortem you have, because it separates a bad file from a bad setup within a few hundred batches.

Reference numbers for a two-class detector: fresh or garbage-loaded weights open avg in the hundreds to thousands, and a converged model finishes near 0.05-0.5, with about 0.1 a common landing point. A model that ended at 0.1 and restarts at about 1,700 is telling you the loaded weights are worthless. Leave the learning rate alone; fetch the good backup.

Resume from a verified file at the original learning rate and avg typically returns to its previous range within roughly 100-500 batches. Still an order of magnitude high after 500 batches with a verified file? The weights are not the problem — look at the dataset, the annotation quality or the cfg.

Fix: get back to a working model

1. On the training machine, list the backups Darknet wrote during the run. Pick the last one written before the transfer and record its exact byte count and SHA-256 hash.
2. Pack that file alone into a zip archive and transfer the archive in one step; an archive either arrives whole or fails visibly.
3. Check the archive's size and hash on both ends, then unpack and hash the .weights file again on the receiving machine.
4. Run your validation images at the confidence threshold used during training. The same boxes and scores the training machine produced are the acceptance test for the transfer.
5. If the run must continue rather than restart, resume from the verified backup and read avg: back in its old range within a few hundred batches means the model is intact and training can proceed.

Do not skip steps 3 and 4. A model that has not passed a validation run on the receiving machine has not been transferred; it has only been downloaded.

Prevent it at the next training run

Record two numbers when training finishes and the failure cannot recur quietly: the byte count of the final weights file and its SHA-256 hash. Put them in the run notes beside the cfg revision, the class list and the final avg value, so every later copy on any machine gets a two-line verdict.

Keep several backups rather than one, and keep the cfg, the .names file and the weights together as a single versioned triplet. A weights file without its matching cfg is half a model, and mismatched halves fail in ways that mimic corruption. The same discipline protects deployed systems too — vision reader configuration backup before troubleshooting applies it at the reader.

Truncation is not unique to weights. A cut-off class definition produces its own web UI error after an upgrade, and the truncated class file fix shows the same size-first habit on that artifact. When a complete-looking weights file refuses to load at all, the Darknet YOLO custom weights walkthrough covers the load-time failure mode.

Running the model on a line-side controller

On the line, the detector runs on a vision controller that also drives lights and reads the area scan cameras feeding it. The checks travel with the file: byte count, hash, then one validation run on the controller itself before production goes live. Slot that acceptance test into the deployment sequence described in swapping a neural network model on edge vision hardware.

Size the controller to the model and the camera count, not to the file: a 35 MB weights file loads anywhere, while GPU memory at inference follows the cfg — why small neural network models use large GPU memory explains that gap. The range spans compact Intel N-series units through Core i5 and Core i7 machines, many with PoE camera ports.

All of the following take the same three-part acceptance test at go-live.

The MV-VC5525-256G70-NN pairs a Core i5 with 32 GB of memory, PoE camera ports and 8 built-in light channels. The MV-VC3301H-128G66 runs a Core i3 with 8 GB of memory and 4 built-in light channels, and ships with a VM6200Pro license. The MV-VC2140-128G40-1T is the compact option, Intel N-series with 8 GB of memory and a 1 TB hard drive.

For inference-only stations, an AI inference terminal such as the MV-VAC3504X-128G01 runs the verified model beside the cameras and lights.

And when training moves in-house instead of a rented session, a quad-GPU training server such as the MV-TS1004-256GR-960G16TR10 keeps the backups, the log and the hashes on hardware you control from batch one.

When the file is not the problem

Size and hash both match and the detector still misbehaves? Work down the remaining causes with one test each:

• Cfg and weights pairing. Load the pair on the machine where training ran. A filters or class-count mismatch fails there first, not at the bench.
• Class list. Count the classes in the cfg and the lines in the .names file; both must equal the number you trained. Wrong counts shift or misname labels while scores stay sane.
• Input pipeline. Same image, same threshold, both machines. A different input size, letterboxing or channel order changes scores — machine vision model file paths: fix deployment errors lists the file-side settings that most often differ after a move.
• Training-side faults. A mid-run crash, out-of-memory kills and driver mismatches are a separate failure family; YOLO training segmentation fault: GPU memory and CUDA fixes is the entry point there.

The verdict, case by case

Match your evidence to a row and the next action follows:

One habit carries most of this: record the size and the hash when training finishes, before any file moves. If a deployment is being planned around a freshly trained model, contact the applications team or request a quote for the controller side, and the verification steps above travel with the file.