DEV Community: Pragalva Sapkota

Observing the Probabilities

Pragalva Sapkota — Thu, 24 Sep 2026 17:09:44 +0000

Originally published at pragalva.me.

Abstract

The observations here come from a small experiment following A Neural Probabilistic Language Model (Bengio et al., 2003). In the last blog, we looked at how predicting the next word could help a model learn relationships between words. Here, I wanted to see that happen in the embedding matrix itself.

I highly suggest reading the paper or my last blog, Viewing Language Through a Probabilistic Lens, which covers the theory behind this experiment.

Seeing the C learn

Our entire corpus is:

the cat sat on the mat the dog sat on the rug

Twelve words, with 7 unique words in the vocabulary. The model uses two words of context to predict the next one, giving us 10 training examples.

C is the embedding matrix. It has the shape [V, m], where V is the vocabulary size and m is the embedding dimension. Here, that is [7, 5]: one row of five numbers for each word. We start by filling it with random numbers.

With those initial values, here is what the model predicts:

Context	Expected word	Model predicts	Probability of the expected word
the cat	sat	cat	0.001
the dog	sat	the	0.011
on the	mat	the	0.000

Probabilities are rounded to three decimal places. That last value is very small, rather than exactly zero.

The model has no useful representation of these words yet. To learn, it compares its predictions with the actual next words using cross-entropy loss. Backpropagation gives us the gradients, and we use them to adjust the parameters in the direction that reduces the loss. This includes the rows of C used for that prediction.

Meaning, when the model gets "the cat" wrong, the numbers representing "the" and "cat" also get updated. We never tell it what a cat is. Its representation changes because it helps predict what comes next.

Let's follow the same examples through training:

Step	sat after "the cat"	sat after "the dog"	mat after "on the"
0	0.001	0.011	0.000
10	0.637	0.286	0.001
25	0.875	0.840	0.052
50	0.931	0.940	0.393
1000	0.997	0.998	0.499

The model learns to predict sat after both "the cat" and "the dog". But mat after "on the" only reaches about 0.5, even after 1000 steps. We will come back to why.

For this run, the embedding dimension is 5 and the hidden layer has 8 units, with the model's direct connections enabled. I used seed 42, standard normal initialisation, and 1000 full-batch gradient descent steps at a learning rate of 0.1. The implementation is in embedding-models-from-scratch.

Chasing the cross-entropy to null

As the parameters change, the loss falls from 6.41 to 0.18 in the first 100 steps. But the remaining 900 steps only take it to 0.1415. The updates to C also become much smaller.

We have 256 free parameters for just 10 examples. So why does the loss stop falling?

Does a perfect model need a loss of 0?

Look at these two examples from our corpus:

on the → mat
on the → rug

The model receives exactly the same input for both. It cannot give mat a probability of 1 in one example and rug a probability of 1 in the other. Each occurs once, so the best it can do across these examples is split the probability equally.

Cross-entropy for one example is −ln P(target). A probability of 1 gives a loss of 0, but a probability of 0.5 gives about 0.693. Even if the model gets the other eight examples perfectly right, the lowest average loss is:

(8 × 0 + 2 × (−ln 0.5)) / 10 ≈ 0.1386

Our model reaches 0.1415, already very close. And the 0.499 we saw for mat makes sense now. The model is leaving almost the other half for rug.

In natural language, this uncertainty comes up all the time. After "I drank a cup of", the next word could be tea, coffee, milk, or water. Given only that context, there may be several valid answers. The loss left even when a model matches their probabilities is called irreducible loss, or the entropy of the next word given the context.

For our tiny corpus, the context matters quite literally. With four words instead of two, the model could distinguish "cat sat on the" from "dog sat on the". The ambiguity disappears from these examples. So 0.1386 is the floor for this corpus with our two-word window, not a fixed limit of language.

We do not need a loss of 0 to say the model has learned these probabilities.

The relationship we wanted but couldn't have

Normal n-gram models can predict the next word too. What interested me here was whether learning to predict would also bring related words closer together in C.

Cat and dog play similar roles in our corpus. So do mat and rug. We can see that when we read it, but does it show up in their representations?

I used cosine similarity to compare the rows of C. It measures how closely two vectors point in the same direction: 1 means the same direction, 0 means perpendicular, and -1 means opposite directions.

Cat and dog move a little closer, from -0.13 to 0.13. Mat and rug actually become less similar, going from 0.35 to 0.23. After training, cat's closest word is sat, with a similarity of 0.81.

The predictions improved, but the relationships I expected were barely there.

The embedding that never learns

Rug's row in C does not change at all. After 1000 steps, its gradient is still:

[0.0, 0.0, 0.0, 0.0, 0.0]

Go back to the corpus. Rug is the last word. It appears as a target, but never as part of the context used to predict another word.

The lookup C[X] only selects rows for words in the context. Since rug is never selected, its row never receives a gradient. There is nothing updating its embedding.

The model can still learn to predict rug because the output weights are trained separately. But the row representing rug as an input stays exactly as it started. The mat/rug similarity changed only because mat moved.

Dog and cat

Cat and dog both appear in the context, and both help predict sat and on. Their embeddings do move in similar directions during training. So why do they end up only slightly closer?

They start with different random values, and the model learns these few examples before the embeddings have changed very much. As the predictions approach the best probabilities for this corpus, the overall gradient gets smaller. There is less left to update.

With 256 parameters, the model has enough room to fit these examples while keeping cat and dog quite different. Making their embeddings similar is not a separate goal in the loss function.

I also tried 10 different random seeds. The average final similarity was 0.31 for cat/dog and -0.09 for mat/rug. So changing the starting numbers did not resolve it either.

What if we add more text?

I first copied the same 10 training examples 50 times. We now have 500 examples, but the vocabulary is still 7 words, and there are still only 9 distinct context/target pairs.

Training data	Examples	Distinct context/target pairs	cat/dog similarity	mat/rug similarity
Original	10	9	0.31	-0.09
Examples copied 50 times	500	9	0.31	-0.09

These are averages over 10 seeds, with 1000 training steps per run.

No improvement. We calculate the loss as an average, so repeating every example equally leaves that average, and its gradient, unchanged. The model keeps receiving the same update at each step.

Joining the text into one long repeated string adds two contexts at the joins: "rug the" → cat and "the rug" → the. Rug finally gets used as an input, but the similarities still barely change: 0.34 for cat/dog and -0.07 for mat/rug.

We gave it more text, but almost nothing new to learn from.

What if the corpus had more combinations?

Next, I used every combination of 4 animals, 3 verbs, and 4 things in this sentence pattern:

the {cat, dog, fox, cow} {sat, lay, slept} on the {mat, rug, sofa, bed} .

That gives us 48 sentences and a vocabulary of 14 tokens, including the full stop. The full stop also means rug can now appear in a context before the sentence ends.

I kept out the 8 sentences containing "fox slept" or "cow lay", and trained on the other 40. The model sees all the words during training, but not those combinations. The held-out loss measures how well it predicts on the sentences we kept aside. Lower is better.

For this larger corpus, I trained for 3000 steps per run. These results, and the remaining comparisons, are averages over 10 seeds.

cat/dog similarity	mat/rug similarity	Training loss	Held-out loss
0.69	0.54	0.529	1.240

Now the relationships are more visible. Cat and dog become much closer, and mat and rug improve too.

But the model still does much better on the sentences it trained on. The training loss is almost at this corpus's floor of 0.526, while the held-out loss is 1.240. More combinations helped, but there is still room to improve on the unseen sentences.

What if the model had less capacity?

I reduced the embedding dimension from 5 to 2 and the hidden layer from 8 units to 4. On the larger vocabulary, that takes the model from 424 parameters to 174. The corpus and training steps stay the same.

Model	cat/dog similarity	mat/rug similarity	Training loss	Held-out loss
Original size	0.69	0.54	0.529	1.240
Smaller	0.94	0.92	0.536	0.872

Both pairs become much closer, and the held-out loss falls. The smaller model fits the training examples slightly less well, but does better on the sentences it has never seen.

Reducing the size does not guarantee similar embeddings. In this experiment, though, giving the model less room to fit each combination separately helped it learn representations that worked across the combinations.

What if we add weight decay?

The paper uses weight decay, which I had left out of this setup. I added it to the original-sized model on the larger corpus.

Weight decay adds a penalty for large parameter values. Here, that penalty is λ times the sum of squared values in C, H, U, and W. The biases are left out, and λ controls how strong the penalty is.

Weight decay	cat/dog similarity	mat/rug similarity	Training loss	Held-out loss
None	0.69	0.54	0.529	1.240
0.001	0.83	0.69	0.542	0.937
0.01	1.00	1.00	0.670	0.724

The losses shown here are cross-entropy alone, without the added penalty, so we can compare them with the previous runs.

At 0.01, the paired embeddings point in almost the same direction. This setting also gives the lowest held-out loss of the ones I tried, even though its training loss is higher.

That makes sense for the corpus we built. Every animal and every thing can occupy its group's slot in the sentence. Real language has more differences to preserve. Cat and dog having almost identical directions here does not mean that should be our goal for every corpus.

Conclusion

In our previous blog, we covered the architecture and tried understanding the underlying mechanism. In this blog, I tried running it. This is not the current state-of-the-art model, and it is way behind the frontier. The purpose of the blog was to understand how complex relationships are learned and represented in vectors.

While the world is busy chasing the frontier, I think understanding its foundations is just as important. The purpose of this blog and the entire series is to build intuition. In a way, I am trying to build my own embedding matrix C such that I start building the correct research intuition.

Understanding LLMs

Pragalva Sapkota — Mon, 10 Aug 2026 18:59:52 +0000

Motivation

This is the beginning of a blog series where I try to understand large language models by reading Build a Large Language Model (From Scratch) by Sebastian Raschka and writing down what I learn along the way.

Introduction to LLMs
Architectures behind LLMs
- Recurrent and convolutional architecture
- Transformer architecture
- Self-attention mechanism
BERT vs GPT
Understanding GPT architecture

What's an LLM?

A large language model is a neural network that is designed to understand, generate, and respond to text. The fundamental understanding here is that large language models are trained on huge datasets, from web-scraped data to Wikipedia.

They utilize the transformer architecture, but note that there are some LLMs that are based upon alternative architectures like recurrent and convolutional architectures.

Recurrent Architecture

A recurrent neural network reads the text sequentially.

The model processes a sentence like "I grew up in Nepal, so I speak ..." in this order:

I      -> update memory
grew   -> update memory
up     -> update memory
in     -> update memory
Nepal  -> update memory
...
speak  -> use memory to predict next token

Languages are mostly sequential. Therefore, prediction is possible using RNNs, but the main problem here lies in efficiency. After reading each token, or word, the model requires a compressed memory of everything so far. Using this memory, the model predicts the next token.

This works for small sentences, but for larger sentences this architecture can lead to context loss if the memory was compressed badly.

Convolutional Architecture

A convolutional language model does not process the sequence recurrently one token at a time like an RNN. Instead, it applies filters over local token windows. But if it is used as a language model, it can still be trained to predict the next token.

For example:

The food I ate at the restaurant last week was really good compared to the restaurant I ate at yesterday.

Here we take filter size = 4 and stride = 2.

Filter size, or kernel size, determines how many neighboring tokens the model looks at once. Stride determines how many tokens the window shifts each time.

The food I ate
I ate at the
at the restaurant last
restaurant last week was
week was really good
...
I ate at yesterday

It learns local patterns. Words alone can have a different, or even reverse, meaning when nearby words are accounted for. But this still does not directly solve it entirely, as the association between the food being great can be mistaken for "week was really good" when accounted for locally. A convolutional model needs stacked layers to gradually expand its view.

Transformer Architecture

A transformer is a deep neural network architecture that consists of two submodules: an encoder and a decoder. This architecture was originally designed for machine translation.

In simple words, the encoder processes the input text and encodes it into a series of numerical representations: vectors that capture the contextual information of the input. Then, the decoder module takes these encoded vectors and generates the output text.

Let's take an example. "My name is Pragalva" is an input text that will be preprocessed before it enters the encoder. Preprocessing means converting raw input text into numerical input embeddings that a transformer can process. These embeddings are then converted into vectors, and the decoder decodes those vectors to generate text in the target language.

These explanations are surface level and will be explored in depth in the coming blogs as I continue my reading.

Self-Attention Mechanism

Self-attention is a key component of transformer architecture, and it sets transformers apart from the architectures we explored previously. This mechanism allows the model to weigh the importance of different tokens in a sequence relative to each other.

This also helps solve the problem we discussed with CNNs. With a self-attention mechanism, the model is able to capture long-range dependencies and contextual relationships within the input data, resulting in more contextually relevant output.

BERT vs GPT

BERT and GPT are two variants that originated from the transformer architecture. BERT, short for Bidirectional Encoder Representations from Transformers, focuses on the encoder side of the transformer architecture. GPT, short for Generative Pre-trained Transformer, was built on the decoder submodule.

Understanding GPT Architecture

Compared to the original transformer architecture we covered earlier, the general GPT architecture is relatively simple. Essentially, it is just the decoder part.

Since decoder-style models like GPT generate text by predicting text one word at a time, they are considered a type of autoregressive model. Autoregressive models incorporate their previous outputs as inputs for future predictions. Consequently, in GPT, each new word is chosen based on the sequence that precedes it, which improves the coherence of the resulting text. GPT architecture is the foundation for the majority of the models that we currently use in our daily workflows.

As seen above, the GPT architecture only uses the decoder portion of the transformer. GPT is also designed for unidirectional processing, left to right in this case, and is well suited for next-token prediction and text generation.

While simpler decoder-only models like GPT are aimed at next-token prediction, they are also capable of performing tasks that they were not initially trained for. This phenomenon is called emergent behavior, meaning the capability was not explicitly taught during training but emerges naturally. For example, GPT models trained for next-token prediction can also perform translations as a natural consequence of the model's exposure to vast quantities of multilingual data in diverse contexts.

Summary

In this blog, we mainly discussed LLMs and the architecture behind them. While we might have just scratched the surface, these foundational topics are required as we dive further into these concepts.

Originally published at pragalva.me.

How I Made My Homelab Declarative

Pragalva Sapkota — Mon, 10 Aug 2026 16:24:53 +0000

Motivation

Prior to this, all of the applications that were installed in devata (my homelab cluster) were installed through helm install. I wanted to explore GitOps and wanted to adopt a declarative approach rather than an imperative approach.

The imperative setup worked, but it had a shape I did not like. The only record of what was running and how it was configured lived inside the cluster itself, in Helm release secrets, and in my shell history. If I wanted to upgrade a chart, I had to remember which values I had passed months ago. If the cluster died, the recovery plan was "reinstall everything from memory". And every change was a one-off command that left no trace anywhere I could review, diff, or roll back.

The instinct came from somewhere. During my LFX term I worked on meshery/schemas, the source of truth for the whole Meshery project: every construct is defined once there, and every component downstream takes reference from it. I wanted my cluster to work the same way.

That arrangement, applied to a cluster, is GitOps. The desired state of the cluster lives in a git repository, and a reconciler running inside the cluster continuously pulls that state and applies it. Git becomes the source of truth: a change is a commit, a review is a pull request, a rollback is a revert. If something drifts from what git says, the reconciler puts it back. If a change is not in a file, it does not really exist.

Everything below lives in my public lab repository, so you can read the real manifests as we go.

Argo CD
The repository layout
The app-of-apps
Migrating the imperative stack
The adoption drill
What each component taught me
The proof

Argo CD

I chose Argo CD for this. It is the reconciler: it watches a git repository, compares what is declared there against what is actually running in the cluster, and syncs the difference.

For the install itself I first went with the raw upstream install.yaml, committed straight into the repo, instead of the Helm chart or Autopilot. The reasoning was transparency: you can read every resource the installer creates, and committing it means even the installer is versioned. That choice did not survive contact with automation. Once Renovate started watching the repo, a 33,000 line vendored manifest was invisible to it; a pinned reference is not. So the install is now a small kustomization pointing at the exact upstream base that install.yaml is generated from, pinned by tag:

# kubernetes/bootstrap/argocd/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: argocd
resources:
  - github.com/argoproj/argo-cd/manifests/cluster-install?ref=v3.4.4

The property I actually cared about survives: the installer is still versioned, because the pin is the version. What changed is the shape of an upgrade. It used to be a regenerated 33,000 line file that no one truly reviews; now it is a one line diff that Renovate opens as a PR and CI renders before merge. Bootstrapping a fresh cluster is still two commands:

kubectl create namespace argocd
kubectl apply -k kubernetes/bootstrap/argocd

The neat part is what happens next: Argo CD manages itself. One of the Applications it reconciles points right back at the directory that defines its own installation. Upgrading Argo CD is now editing a file and pushing.

# kubernetes/clusters/devata/argocd.yaml
spec:
  source:
    repoURL: https://github.com/PragalvaXFREZ/lab.git
    targetRevision: main
    path: kubernetes/bootstrap/argocd
  syncPolicy:
    automated:
      selfHeal: true
      prune: false  # never let argocd prune its own install
    syncOptions:
      - ServerSideApply=true

Two details in that snippet carry weight. prune: false means Argo CD will never delete pieces of its own installation, even if they disappear from git; a bad commit should not be able to take down the engine that would fix it. And ServerSideApply=true is there because Argo CD's CRDs are so large they blow past the size limit of the client-side last-applied-configuration annotation.

The repository layout

The repo is split into three planes, by who applies them:

lab/
├── talos/              # machine configs, applied by talosctl
├── kubernetes/         # the ONLY path GitOps watches
│   ├── bootstrap/      # argocd install + the root app
│   ├── clusters/
│   │   └── devata/     # one child Application per component
│   ├── infra/          # values and manifests per component
│   │   ├── networking/     # cilium, metallb
│   │   ├── observability/  # kube-prometheus-stack, loki, promtail
│   │   └── controllers/    # nvidia-device-plugin, sealed-secrets
│   └── apps/           # workloads
└── lab-experiments/    # sandbox, never reconciled

kubernetes/ is the single GitOps-watched path. talos/ is applied by talosctl from my workstation, because the machine layer has to exist before there is a cluster to reconcile anything. And lab-experiments/ is the escape hatch: a place to try things without the reconciler ever touching them.

The app-of-apps

Argo CD's unit of work is an Application: one CRD instance that says "this git path renders to these resources, keep them in this namespace". Instead of registering every component by hand in the UI, I use the app-of-apps pattern: a single root Application that watches a directory of other Application manifests.

# kubernetes/bootstrap/root.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: devata-root
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/PragalvaXFREZ/lab.git
    targetRevision: main
    path: kubernetes/clusters/devata
    directory:
      recurse: true
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

devata-root watches kubernetes/clusters/devata/. Every YAML file in that directory is itself an Application pointing at a component. Adding a component to the cluster is now: commit a child Application file, push, done. The root notices the new file, creates the Application, and that Application syncs the component. Deleting the file prunes it. The whole cluster inventory is one ls:

argocd.yaml  cilium.yaml  hello.yaml  kps.yaml  loki.yaml
metallb.yaml  nvidia-device-plugin.yaml  promtail.yaml

This root app is the only thing I ever applied manually with kubectl apply -f root.yaml. Everything after that arrived through git.

Migrating the imperative stack

Bootstrapping the engine on a fresh cluster is the easy half. My problem was the brownfield half: devata already had six components running as hand-installed Helm releases, some of them load-bearing.

$ helm list -A
NAME                    NAMESPACE
cilium                  kube-system
kps                     monitoring
loki                    logging
metallb                 metallb-system
nvidia-device-plugin    nvidia-device-plugin
promtail                logging

The naive move would be a big-bang takeover: point Argo CD at everything at once and let it sync. On a cluster where one of those releases is the CNI (the thing pods need to have network at all) and another is the entire monitoring stack, that is how you turn a learning exercise into an outage. So the migration went one component at a time, least blast radius first, and each one followed the same drill.

The key realization that makes adoption safe: Argo CD does not care how resources got into the cluster. If the manifests it renders from git match what is already running, the diff is empty and syncing changes nothing. So the whole game is to reproduce, in git, exactly what Helm had installed, and to prove the diff is empty before letting the reconciler touch anything.

The adoption drill

Per component, the workflow looked like this:

Set up the GitHub repository, the app-of-apps root Application, and configure your repository to serve as the source of truth (once, see above).
helm list -A to find the next release to migrate.
helm get values <release> -n <namespace> to recover the exact values the release was installed with. This is the step that saves you: those values are the configuration you would otherwise have to remember.
Commit two things: the recovered values at kubernetes/infra/<domain>/<component>/values.yaml, and a child Application in kubernetes/clusters/devata/. The Application uses Argo CD's multi-source pattern: one source is the upstream chart repository with a pinned version, the other is my git repo providing the values file.
Automation stays off at first. The Application appears in Argo CD, but nothing syncs.
argocd app diff <name> until the diff is empty. Every line in that diff is a discrepancy between what git declares and what is running, and each one gets fixed in git, not in the cluster.
Flip automation on (selfHeal: true, prune: true), then drift-test it: change something trivial with kubectl and watch the reconciler put it back.
Retire the Helm release record. Helm stores its bookkeeping as a Secret named sh.helm.release.v1.<release>.v<N> in the release namespace. Deleting it removes the component from helm list for good. Helm no longer owns this component, git does.

Here is the first multi-source Application I wrote:

# kubernetes/clusters/devata/nvidia-device-plugin.yaml
spec:
  sources:
    - repoURL: https://nvidia.github.io/k8s-device-plugin
      chart: nvidia-device-plugin
      targetRevision: 0.19.3  # pinned; upgrading is editing this line
      helm:
        valueFiles:
          - $values/kubernetes/infra/controllers/nvidia-device-plugin/values.yaml
    - repoURL: https://github.com/PragalvaXFREZ/lab.git
      targetRevision: main
      ref: values

The second source contributes no manifests; ref: values just makes my repo addressable as $values, so the chart from NVIDIA's repo renders with the values file from mine.

Lesson

Name the Application after the release, not the chart. Charts embed the release name into resource names: my kube-prometheus-stack release is kps, so the resources are kps-grafana, kps-operator, and so on. If I had named the Application kube-prometheus-stack, Argo CD would have rendered a second, parallel stack with new names, and the diff could never reach empty.

What each component taught me

The drill was the same six times, but every component had its own personality.

nvidia-device-plugin went first as the safe rehearsal: a single DaemonSet, four lines of values, and (since the GPU in that node turned out to have a hardware fault) a component that advertises nothing anyway. Perfect crash test dummy. Its diff was empty on the very first render.

kube-prometheus-stack was the first component that was not plain, in two ways. Its CRDs are enormous, so like Argo CD itself it needs ServerSideApply=true. And the recovered values had a surprise in them: helm get values kps returned the Grafana admin password in plaintext. It had been sitting in the Helm release secret the whole time. That password never entered git. It moved into a manually created grafana-admin Secret in the cluster, values.yaml points the chart at it through grafana.admin.existingSecret, and retiring the Helm release records at the end of the drill had a satisfying side effect: it destroyed the plaintext copies. Sealing that Secret into git properly, encrypted, is the sealed-secrets workstream that comes next.

loki and promtail were the routine reps: recover values, commit, diff to empty, flip automation. By this point the drill felt mechanical, which is exactly what you want from your logging stack migration.

metallb is tracked as the upstream native manifests plus my address-pool config rather than a chart, and it introduced the next class of problem: fields that are supposed to differ from git. The controller injects caBundle certificates into its webhook configurations at runtime. Git says the field is empty, the cluster says it is a certificate, and that diff will never close because it is not drift, it is the component working as designed. The answer is ignoreDifferences:

ignoreDifferences:
  - group: apiextensions.k8s.io
    kind: CustomResourceDefinition
    jqPathExpressions:
      - .spec.conversion.webhook.clientConfig.caBundle
syncPolicy:
  syncOptions:
    - RespectIgnoreDifferences=true

RespectIgnoreDifferences=true matters: without it, ignored fields still get overwritten on sync. With it, Argo CD neither reports them as drift nor touches them.

cilium went last, deliberately. It is the CNI; if adopting it goes wrong, every pod on the cluster loses networking, including Argo CD itself. And it had the hardest version of the metallb problem: the chart's default hubble.tls.auto.method=helm generates fresh Hubble TLS certificates on every render. So cilium-ca and both Hubble cert Secrets differed on every single diff, and with self-heal on, the reconciler would have rotated Hubble's TLS forever, once per sync. Two clean options existed: switch cert generation to the chart's cronJob method (Cilium's documented GitOps pattern), or ignoreDifferences on the three Secrets. I went with ignoreDifferences plus RespectIgnoreDifferences, the same shape as metallb: the certs are runtime state that Helm happened to generate, not configuration I want git to own. Diff to empty, automation on, sh.helm.release.v1.cilium.v3 deleted.

The proof

With few pull requests and tinkering done here and there, I was able to get it done at the end:

Figure 1. helm list -A on devata returns nothing. All of the applications have been migrated to be declarative with the help of Argo CD.

An empty helm list -A does not mean Helm is gone; the charts are still rendered by Helm, inside Argo CD. What is gone is Helm as the owner of state on my cluster. The owner is git now:

$ argocd app list
NAME                  SYNC    HEALTH
argocd                Synced  Healthy
cilium                Synced  Healthy
devata-root           Synced  Healthy
hello                 Synced  Healthy
kps                   Synced  Healthy
loki                  Synced  Healthy
metallb               Synced  Healthy
nvidia-device-plugin  Synced  Healthy
promtail              Synced  Healthy

Every one of those is a file in the repo. Upgrading a chart is editing one pinned version line. Changing a dashboard is a pull request. And if devata dies tomorrow, the recovery plan is no longer "reinstall from memory", it is: build the machines with talosctl, apply two manifests, and watch Argo CD rebuild everything else from git. Pretty cool, huh ?

Originally published at pragalva.me.

DEV Community: Pragalva Sapkota

Observing the Probabilities

Abstract

Seeing the C learn

Chasing the cross-entropy to null

The relationship we wanted but couldn't have

The embedding that never learns

Dog and cat

Conclusion

Understanding LLMs

Motivation

Table of Contents

What's an LLM?

Recurrent Architecture

Convolutional Architecture

Transformer Architecture

Self-Attention Mechanism

BERT vs GPT

Understanding GPT Architecture

Summary

How I Made My Homelab Declarative

Motivation

Table of Contents

Argo CD

The repository layout

The app-of-apps

Migrating the imperative stack

The adoption drill

What each component taught me

The proof