go-attention: A Pure Go Attention and Transformer Implementation

The Go AI Gap That go-attention Tries to Fill

Python dominates machine learning tooling, and Go developers who want to run attention-based models inside a Go service have historically faced a choice: call out to a Python process over gRPC or HTTP, use CGo bindings to a C++ runtime, or reimplement the math themselves. Each option carries a cost. The Python sidecar adds a network hop and a second runtime to deploy. CGo bindings complicate cross-compilation and produce binaries that depend on shared libraries present on the target machine. Reimplementation is where go-attention positions itself.

The README states the library is a pure Go implementation of attention mechanisms and transformer layers, with zero external dependencies. That single constraint drives most of the design decisions visible in the material. If you ship a Go binary to an ARM edge device or a serverless container, a pure Go dependency graph means no libtorch, no ONNX runtime, and no version-matching between a C library and the Go toolchain. The README frames this as eliminating dependency resolution delays and cold starts.

The intended audience is narrow but real: Go backend engineers who need attention math inside an existing service, not ML researchers prototyping new architectures. The API surface reflects that. Types are plain slices (Vector is []float64, Matrix is []Vector), and the entry points are functions like DotProductAttention and constructors like NewMultiHeadAttention. There is no graph abstraction, no autograd tape, and no model serialization format described in the README.

What the API Actually Exposes

The README documents three levels of abstraction. The lowest is a standalone dot-product attention function that takes a query vector, a key matrix, and a value matrix, and returns an output plus the attention weights. The example uses a 4-dimensional query against three 4-dimensional keys, producing three weights that sum to roughly 1.0. Returning the weights alongside the output is a deliberate choice: it lets a caller inspect which keys received attention, which matters for debugging and for anything resembling interpretability work.

The middle level is multi-head attention. MultiHeadConfig takes NumHeads, DModel, DKey, DValue, and DropoutRate. The README notes that DKey and DValue are expected to be DModel divided by NumHeads, which is the standard convention. The Forward method accepts flattened matrices sized batchSize times seqLen, so the caller is responsible for reshaping sequences into a flat row layout before the call and interpreting the flat output afterward. That is a manual step the README does not provide a helper for.

The top level is a transformer layer. TransformerConfig adds DHidden for the feed-forward sublayer, and NewTransformerLayer wires self-attention and the feed-forward network together. Forward takes a Matrix of shape seqLen by DModel and returns the same shape. The README does not describe positional encoding, layer normalization placement, or residual connection handling, so a reader cannot confirm from the supplied material whether those are implemented internally or left to the caller. That is a gap worth checking in the source before adopting.

Getting It Running

Installation is a single module fetch:

go get github.com/takara-ai/go-attention

The README then suggests running the bundled examples with go run api_examples.go. Note that this command assumes the examples file sits in the current working directory after the module is fetched into the module cache. In a fresh project, a reader would typically create a main package that imports the attention or transformer subpackage directly rather than running the repository's own example file. The README does not show a go.mod snippet or a module path for the subpackages beyond the import lines in the code samples: github.com/takara-ai/go-attention/attention and github.com/takara-ai/go-attention/transformer.

Configuration is done through struct literals rather than files or environment variables. For multi-head attention, the required keys are NumHeads, DModel, DKey, DValue, and DropoutRate. For the transformer layer, they are DModel, NumHeads, DHidden, and DropoutRate. Constructors return an error, and the README shows the standard pattern of checking it with log.Fatal in examples. The Forward methods also return errors, which suggests input validation happens at call time rather than construction time, though the README does not enumerate which validation failures are possible.

The README includes an Example Output block showing attention weights of [0.523 0.174 0.302] for a specific query-key set. Those numbers are presented as illustrative output, not as a benchmark. A reader should treat them as a sanity check on shape and normalization rather than a performance figure.

The Benchmark Numbers and What They Do Not Cover

The README reports dot-product timings measured on an Apple M1 with go test -bench=. ./attention. Small vectors of 64 to 256 elements land around 17 to 62 nanoseconds per dot product. Medium vectors of 512 to 1024 land around 250 to 290 nanoseconds. Large vectors of 4096 and above land around 970 to 1230 nanoseconds. These are single-operation figures for the dot product itself, not end-to-end timings for a full attention pass or a transformer layer.

That distinction matters. A transformer layer forward pass involves matrix projections, the attention score computation, softmax, the weighted value sum, a feed-forward network with two linear layers, and whatever normalization and residual logic sits between them. A dot-product benchmark at 62 nanoseconds says nothing about how long layer.Forward takes on a realistic sequence length. The README does not publish layer-level or model-level timings, and it does not compare against a reference implementation, so the claim of production-grade performance rests on the dot-product microbenchmark alone.

The README also claims consistent performance across all hardware and across all input sizes, describing a single optimized code path with no performance cliffs. That is a strong claim. It is plausible for a straightforward loop-based implementation with assembly fast paths and fallbacks, which the README mentions under SIMD support. But the benchmark table itself is from one machine. Without results from other architectures, the cross-hardware consistency claim is unverified in the supplied material.

Limitations the README Leaves Open

The most significant open question is training. The README describes forward passes only. Every example calls Forward or DotProductAttention and inspects the output. There is no mention of gradients, a backward pass, an optimizer, or loss computation. If the library is inference-only, then adopting it means bringing your own training pipeline, training in another framework, and exporting weights into the Vector and Matrix types by hand. The README does not describe an import path for weights from any external format, so that transfer is on the adopter.

The numeric type is float64 throughout. That is a reasonable choice for numerical stability on CPUs without good float32 SIMD support, and it matches Go's default float. It also doubles memory traffic compared to float32 weights, which is a real cost for large models on memory-constrained edge devices. The README lists memory efficiency and object pools as optimizations but does not quantify the footprint of a given DModel and NumHeads combination.

DropoutRate appears in both configs, which implies the library has some notion of training versus inference mode, since dropout should be disabled at inference. The README does not show how to toggle that mode or whether it is controlled by a separate call. A reader cannot determine from the material whether dropout is applied unconditionally during Forward, which would make inference non-deterministic despite the README's determinism claim. That contradiction is worth resolving before use.

Finally, the README's performance section is truncated mid-list under Built-in Optimizations, so the full set of claimed optimizations is not visible in the supplied material.

How It Compares to Gorgonia and ONNX Runtime Bindings

Gorgonia is the closest Go-native alternative. It is a general automatic differentiation library with a computational graph, tensor operations, and gradient support. The difference in approach is architectural: Gorgonia builds a graph and differentiates through it, which makes it suitable for training models in Go. go-attention provides fixed forward operations on plain slices with no graph and, based on the README, no differentiation. If you need to train, Gorgonia covers ground go-attention does not. If you only need to run an attention layer inside a service, Gorgonia's graph machinery is overhead you would carry without using.

ONNX Runtime bindings offer a different trade. You get a mature, heavily optimized inference engine and access to models exported from PyTorch or TensorFlow. You also get a C library dependency, platform-specific binaries, and a build step that complicates Go cross-compilation. go-attention trades that ecosystem and optimization depth for a dependency graph that is entirely Go. For a serverless function where cold start and binary size dominate, that trade can favor go-attention. For a service running large models on GPU hardware, ONNX Runtime is the more capable choice, and go-attention does not claim GPU support in the material provided.

A third option is a Python sidecar. It keeps you in the ecosystem with the widest model support but adds a second runtime, a network boundary, and the deployment complexity of keeping two services in sync. go-attention removes that boundary at the cost of reimplementing weight loading yourself.

Maintenance, Licensing, and Upgrade Cost

The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. MIT imposes no copyleft obligation on your codebase, so linking go-attention into a proprietary service does not require you to publish your source. That is the permissive default most Go teams expect. The README does not list any third-party dependencies, which is consistent with the zero-dependency claim and means there is no transitive license surface to audit beyond the module itself.

The repository shows no releases in the retrieved metadata, so there are no tagged versions to pin against. Without tags, go get resolves to a commit on the main branch, and upgrades mean moving that pseudo-version forward deliberately. For a dependency you intend to ship, that is a real operational consideration: there is no semantic version boundary signaling when a breaking API change lands. You would need to read commit history or vendor the code.

The last push date in the metadata is 2026-06-15, which indicates recent activity, but the absence of releases and the truncated README make it hard to judge how stable the public API is. The MIT license and zero dependencies keep the legal and build-side upgrade cost low. The versioning situation keeps the API-side upgrade cost unpredictable.

Editorial conclusion

Teams building inference-only transformer pipelines in Go, especially for edge or serverless deployments where a single binary and zero CGo dependencies matter, should evaluate go-attention against their numerical precision requirements. Teams that need training loops, GPU acceleration, or a proven ecosystem of pretrained model support should not adopt it. Before committing, verify whether the repository includes backward-pass or gradient code, and check that float64 accumulation is acceptable for your model's weight magnitudes.

Official sources

1. Issues
2. License: MIT
3. README
4. takara-ai/go-attention on GitHub