What I connected in Xiaomai this week, and which failures still need work

What we got done

I first prepared this issue on October 15. More work followed, so I have now brought together the main work I can substantiate for the week of October 12–18. If I only describe the final large-model update, it is hard to see why I first needed the small models, save checks, and failure cases. It would also be easy to mistake work from different versions for one version that did everything in a single run.

At the start of this part of the week, I was still working through the R20 results. Text sampling matched the original sampler, but the reply still had a schema error. The research-method replies were also rejected after the allowed corrections, before method execution or new-task evaluation. Separately, 17 research-gradient tensors matched using the same captured features, and a source-bound, read-only bitwise audit of the earlier update data matched too. The original harness rejection remains. These checks support different claims.

One concrete step on October 13 was the comparison of a single MLP block from the original model. With real weights cast to FP32, artificial inputs, and artificial upstream gradients, its specified forward and backward calculations met the original tolerance. I also used small CPU cases to examine BF16 rounding. Computing in FP32 and rounding only at the end differs from rounding at each original operation. Passing one FP32 block does not establish native BF16 equivalence.

The Claude CPU work then made attention, GDN, normalization, and output-layer forward and manual backward calculations available for individual checks. I compared them on artificial CPU cases so that differences could be located within a calculation. Matching component cases and matching a multilayer composition are separate checks. The later multilayer failures remain in the record.

On October 15, I began reconnecting these calculations to the original callers. On reduced models, I joined forward calculation, manual backward calculation, updates, saving, and the next step in a new process, then checked parameter ownership, update flags, and optimizer state. The deployed GDN and normalization variants had separate comparisons. Text learning, research credit, Group, Decision, and the original graph checkpoint format each have their own CPU records. The original startup and constructors were later included in a small-model flow too. I kept the supported configurations separate rather than combining their largest sizes into one supposed full 9B run.

On October 16, I extended the reduced CPU workflow and BF16 cases. I moved beyond an empty research context to a nonempty one, while stating the rules for BF16 storage, FP32 research calculations, and master state. This is a mixed-precision policy, so it does not mean every operation follows native BF16 arithmetic. A wider configuration has only a focused state-value comparison, checking the calculation that uses those state values. It has not completed the whole update and cold-start flow.

I also checked failures that happen after an update has already written some data. In a reduced FP32 active Group case, I injected a failure after the third actual write, then checked rollback and continuation in a new process. Rejecting a request before any data changes would not answer that question. Some gradients, rollback backups, and hashing were also changed to use chunks or disk. The model, optimizer state, and full materialization during saving still have costs, so this does not settle the overall memory bound.

A save is not settled merely because a file appears. On October 17, I tested missing data, interrupted saves, and a failure after the latest pointer had advanced but before the ledger was complete. In the last case, default loading rejects the checkpoint. Recovery requires explicitly selecting the previous valid checkpoint. The multiple-file save is therefore still non-atomic: a failure does not guarantee that all files remain at one complete version.

That day, I also moved the specified code, dependencies, checkpoint data, and runtime to another root, then used a new process to continue and compare the saved state and next step. Earlier checkpoint relocation checks were a precursor; this case also moved the runtime. Both were still on the same Windows machine. I have not treated that as a restore on another computer or in a separately installed environment.

Another piece of work whose name can be misleading is the offline research-evidence memory tool. It connects original receipts, failures, and manual notes, with export, restore to another destination, and Chinese retrieval checks. For me, the point is to avoid keeping only a polished conclusion and losing the record of how it was obtained. The tool does not call a model. It is not yet Xiaomai's model-level long-term memory or automatic learning.

The formal entry work also moved forward across October 17–18. On a hidden-size-8, three-layer model and one GPU, bounded checks covered update, save, restore in a new process, and another update. Of the ten gates, four ran on the current source version, five reuse bounded historical evidence from their own versions, and one mixes current and historical evidence. This was not a same-version rerun of all ten gates. The current nonempty state-value comparison passed, but only 486 of the source's 491 tokens were encoded. The final five were outside the check. Earlier failures and timeouts remain.

In the new compute environment on October 18, I first restored the saved research data, set up a separate execution environment, and ran small checks before continuing with the model. I compared gradients for the staged CUDA path on small models and added input checks around the update transaction. I also added a prefix cache with a memory limit: it is used when space is available and falls back otherwise. The specified enabled, disabled, and fallback cases matched. Fewer calls alone do not establish an actual speedup.

The 9B-class model on A100 then completed two actual updates for 47 selected parameter tensors. Six changed in the first update. In a new process, the recorded projections of parameters, optimizer state, other declared saved state, and RNG state matched the first record. The next update changed nine parameter tensors and saved a different checkpoint. This establishes continuation within this bounded flow. A third new process has not loaded the second checkpoint, so that next part is still open.

Alongside the implementation, I spent time preserving the work. On October 13, I saved the successful and failed records from ended experiments, checked their readback, and retired the earlier GPU instance. The known important scientific data was preserved, not the host's entire latest filesystem. The October 14 sources and raw results were also stored privately. A completed data handoff and a failed scientific admission are recorded separately; uploading the files did not change the failed result.

For the public record, on October 15 I organized the work into a catalogue of 38 families. Three historical reports received result review; listing the others does not mean their research was admitted. I reorganized the GitHub home page into research, evidence, examples, and documentation, and made a body-map illustration to explain the components and their limits. On October 18, I published and read back suitable figures, failures, and limits. The website keeps its existing weekly-update entry, with Chinese and English content and separate initial and supplement dates.

When organizing older versions on October 17, I retained a complete baseline and the actual differences, checked the reconstructed contents of four historical packages, and dealt with duplicates and ended experiments. There is a cost to state clearly: some old traces and states are no longer fully retained. Those historical runs can no longer be rechecked value by value or resumed exactly. A result card helps explain what happened, but it is not a complete runnable recovery package.

The A100 code, experiment records, and saved state were also placed in a private archive and checked. That operation only verified the archive; it did not extract the entire package and restart it in another environment. I therefore separate preserved data from a completely replayable software environment. Public material remains selected results and limits. Core code, weights, private checkpoints, and raw tensors are withheld. Public hashes allow a later check against the originals; a summary alone cannot reproduce the private model.

What didn't work

The main unresolved numerical result is still the October 14 test of 14 fresh-seed multilayer artificial CPU cases: 0/14 under the original FP32 tolerance, with shared negative controls at 104/112. The complete protocol failed. A later compensated candidate reduced some out-of-bound coordinates, but all 14 cases still failed and it was slower, so it was not installed in the main flow. Some coordinates also exposed incompatible requirements from the two references. The mathematical target and framework compatibility need to be stated separately. The noncontiguous-data control fix was kept separate from the frozen results.

The engineering failures remain too. One intermediate run ended normally at the outer process level while its actual model entry failed to complete an update. The original first-update harness recorded JOB_TIMEOUT, and the first recovery pointer recorded FAIL. Correcting the pointer and continuing later did not rewrite those records. New small-model checks passed their own conditions; they do not close the earlier multilayer FP32 failures, which use different models, sources, and criteria.

The large-model input was still fixed by the host: literal prefix a and target b. Xiaomai did not propose the research content. Updating 47 selected parameter tensors is not all-parameter training. Recorded 32-layer execution observations have not established complete 32-layer general numerical or input acceptance. Arbitrary freeform input, long input, native BF16 per-operation rounding equivalence, and complete general True takeover still have separate evidence gaps.

For me, this week made the supported conditions for connecting calculations, updates, and persistence more concrete, and made the failure locations clearer. Whether Xiaomai can reframe a problem, propose a method that was not already written, or retain a useful capability requires separate transfer, ablation, and causal comparisons. Tensor-operation records are not a complete value-level causal explanation. The research-loop adapter's engineering tests did not call a model. Naming a tool research, memory, or tracing does not establish those capabilities, and overall acceleration remains unverified.

What's next

Next, the A100 work needs to start from the second checkpoint in a third new process, then check an update and save with different input. Restoring the first checkpoint and continuing after the second save are separate checks. I still need to run the latter. Preparing this public issue did not rerun the model; these are planned checks, not new execution results.

On CPU, I can continue investigating the original multilayer differences and reference requirements, controls, save faults, and general entry paths. I will keep active BF16 Group, complete checkpoint memory costs, and cross-environment recovery as explicit gaps. Real-size GPU numerical checks and more general inputs then need their own acceptance runs. For me, the weekly record should retain those connections: which part ran this week and which part is missing, without counting a flow's precursors, repairs, and backups as separate capability gains.