Case study

A fine-tuned model, and the system that serves it

How Mixtral-8x7B-v0.1 was adapted with QLoRA, deployed to SageMaker, and put behind an API Gateway and Lambda path that this application invokes for real.

01

Problem

Instruction-following was the goal. Available memory decided how it could be reached.

Mixtral-8x7B-v0.1 is a base sparse mixture-of-experts checkpoint, not an instruction-tuned one. Reliable instruction-following required supervised fine-tuning on an instruction corpus.

Full fine-tuning at this parameter scale was not feasible on the available hardware. The binding constraint was memory, and it dictated the whole approach: the model had to be made smaller to train before it could be trained at all.

02

Fine-Tuning Approach

Freeze a quantized base, train small adapters.

Full fine-tuning updates every parameter and carries optimizer state proportional to the model. Ruled out by the constraint.

LoRA over a 16-bit base cuts trainable parameters but still holds the full-precision base resident. Still too large.

QLoRA holds the base in 4-bit NF4 and trains low-rank adapters above it, leaving roughly 3.96% of parameters receiving gradients. That is the trade-off that made the run possible; the costs are a quantized base and an adapter the deployment has to carry alongside it.

  1. 01
    Dolly 15K
    Instruction-tuning corpus
  2. 02
    Mixtral-8x7B-v0.1
    Base checkpoint
  3. 03
    4-bit NF4
    Memory reduction for training
  4. 04
    QLoRA Fine-Tuning
    Low-rank adapter training
  5. 05
    Model Artifact
    Packaged deployable
  6. 06
    SageMaker Deployment
    Hosted inference
03

QLoRA Training Architecture

One training step: a frozen quantized base does the work, and only the adapters change.

The base is quantized to 4-bit NF4 once, before training, and never updated again. LoRA A/B adapters attach to it and are the sole destination of gradients — roughly 3.96% of parameters. Forward and backward computation runs in BF16 above the quantized weights.

That asymmetry is the whole design: the expensive tensor stays read-only and can be held in 4 bits, while the tensors that must be written are small enough to keep in higher precision. The final step yields an adapter artifact, which is what gets deployed.

INPUTDolly 15Kinstruction · context · responseTokenizationprompt template appliedBASE PREPARATIONMixtral-8x7B-v0.1sparse MoE base4-bit NF4 quantizationbitsandbytesFrozen base weightsno gradient · no updateattachLoRA adapters A / Brank 64 · alpha 16batch + assembled modelTRAINING STEP · BF16 COMPUTATIONForward passBF16 computeLossnext-token objectiveBackpropagationBF16 computegradientsUpdate LoRA adapters only~3.96% of parametersfrozen base weights receive no updatenext stepafter final stepOUTPUTTrained artifactadapter + configSageMaker deploymenthosted endpointFrozenquantized Mixtral base · receives no updatesTrainableLoRA A/B adapters · gradients applied hereComputeBF16 where applicable
Illustrates the training loop as it ran on SageMaker. No training runs in this browser, and no figure here is a measurement.
04

Training Configuration

The recorded run configuration, grouped by the problem each setting solves.

Anything never recorded is shown as unrecorded rather than filled with a plausible default, because a fabricated hyperparameter is worse than a missing one. No loss curve, validation figure, or utilization number appears here: none was captured.

Model & data

Base modelMixtral-8x7B-v0.1
DatasetDatabricks Dolly 15K
Fine-tuningQLoRA

A base checkpoint adapted to follow instructions, using the corpus whose prompt format the runtime reproduces exactly.

Memory strategy

Quantization4-bit NF4
Gradient checkpointingEnabled

QLoRA holds the base read-only in 4-bit NF4 so optimizer state scales with the adapters, not the model. Gradient checkpointing recomputes activations in the backward pass instead of holding them, trading compute for headroom.

Compute precision

Compute dtypeBF16

Arithmetic runs in BF16 above the quantized weights: it keeps the exponent range of FP32 at half the width, so the step stays numerically stable without loss scaling.

Adapter capacity

LoRA rank64
LoRA alpha16
Trainable parameters~3.96%

Rank sets how much the adapter can express; alpha scales how strongly it acts on the frozen base. Together they bound how far the model can move, and they are why so few parameters carry the update.

Optimization

Epochs2
Batch size2
Learning rate2e-4

The recorded schedule for the run that produced the deployed artifact.

05

AWS Training & Deployment

Corpus to training job to artifact to a served endpoint, with two links attested by console evidence.

Two points in the chain can be shown rather than asserted: that the training job completed, and that the endpoint reached service. Both are console readings reported by the project owner — this application did not measure them, and no utilization, throughput, or cost figure is claimed.

Evidence is supplied by the project owner and reviewed by hand before it is committed. The application performs no automated redaction, so what a screenshot or recording contains is a publication decision made deliberately, not one the code enforces.

Training Data
Dolly 15K
SageMaker Training
managed training job
console evidence below
QLoRA Fine-Tuning
adapters over frozen 4-bit base
Model Artifact
adapter + config
SageMaker Endpoint
hosted inference
console evidence below
Runtime Inference
invoked by this application
The job that produced the adapterCompleted · approximately 7 hours
SageMaker training job list showing a completed QLoRA fine-tuning job.
The endpoint that serves itInService
SageMaker endpoint detail showing status InService.
Watch the run finish1528/1528 steps · SUCCESS
06

Runtime Inference Architecture

A request crosses one trust boundary, and credentials never cross it.

The browser calls this application's own route handler and nothing else. The endpoint URL and API key are read server-side and are never bundled into client JavaScript, returned in a response, or included in an error.

Next.js
Route Handler
API Gateway
HTTPS
Lambda
Invoke
SageMaker
Endpoint
Mixtral
8x7B + adapter
Response
Normalized
BROWSERSERVERtrust boundaryConsole UIholds no credentialsRoute handler → AWS chainAPI Gateway · Lambda · SageMakerinstruction, paramstext, duration, statusnever crosses· API Gateway invoke URL· API key· upstream response body· endpoint identifiers
Errors returned to the browser carry a code and a message only. Upstream bodies and diagnostics stay in the server log.
07

Inference Request

How a single request is issued, and what the application records about it.

The console below issues a request through the server-side path described above: the browser posts an instruction to this application's route handler, which forwards it to the configured endpoint and normalizes the reply.

Whether that endpoint is reachable at any given moment is reported by the status line, not asserted here. Any figure shown is measured by the application for the request that produced it.

08

Evaluation & Observability

Only what the application actually observed.

Session telemetry covers real requests: total round-trip, HTTP status, whether parameters were transmitted, and output size. Statistics over an empty set return nothing rather than zero, and every aggregate carries its sample size.

There is no quality score, benchmark result, or base-model comparison here, because none was measured.

No runs observed in this session.

09

Engineering Decisions

The choices that shaped this system, and what each one cost.

Decision

Adapt the model with QLoRA rather than full-weight fine-tuning.

Constraint

Full fine-tuning carries optimizer state proportional to the model, which did not fit the available hardware.

Trade-off

Confining updates to adapters made the run possible at all. The costs are a quantized base and an adapter the deployment has to carry alongside it. With a smaller model or a larger memory budget, full fine-tuning would have been a viable option; here it was not.

Recorded asQLoRA
Decision

Hold the frozen base in 4-bit NF4.

Constraint

The base had to stay resident for every step, and at full precision it was too large to keep there.

Trade-off

Quantization buys residency and spends fidelity in the frozen weights. This is a memory decision for this hardware, not a claim that 4-bit storage is preferable once memory stops being the binding constraint.

Recorded as4-bit NF4
Decision

Train low-rank adapters and freeze the base weights.

Constraint

Only a small parameter budget could receive gradients.

Trade-off

About 3.96% of parameters carry the update, which keeps optimizer state small and the resulting artifact portable. The base cannot move, so anything that would require shifting the base representations is outside what this approach can reach.

Recorded as~3.96% trainable
Decision

Run forward and backward computation in BF16.

Constraint

Arithmetic needed more dynamic range than the 4-bit storage format carries, without paying full FP32 width.

Trade-off

BF16 keeps the exponent range of FP32 at half the width, so steps stay numerically stable without loss scaling. It gives up mantissa precision against FP16 at equal width. Appropriate for this run's hardware rather than a universally correct precision.

Recorded asBF16
Decision

Enable gradient checkpointing.

Constraint

Once the base was quantized, activation memory rather than weight memory was the remaining ceiling.

Trade-off

Activations are recomputed during the backward pass instead of being stored, which buys headroom and spends wall-clock time. A direct exchange of compute for memory, worth making only while memory is what binds.

Recorded asEnabled
Decision

Set adapter rank to 64 with alpha 16.

Constraint

Rank bounds what the adapter can express: too low limits what it can learn, too high erodes the parameter savings the approach exists to provide.

Trade-off

64 is the capacity this run was configured with. No comparison against other ranks is recorded for this project, so it is presented as a configured choice rather than a tuned optimum. A lower rank would shrink the artifact further; a higher one would spend more of the efficiency.

Recorded asrank 64 · alpha 16