ezsx

systems / tools / 2026

ezsx

Python systems across backend, Linux infrastructure, secure connectivity, retrieval, and GPU compute.

  • backend
  • platform
  • networking
  • retrieval
  • compute

Selected work

05 systems

CUDA seed search

public repository

GPU-assisted exhaustive seed search with correctness gates, resumable heterogeneous-GPU runs, and reproducible results.

  • CUDA
  • profiling
  • verification
  • GPU
repository

Secure connectivity

private system

Server-side control plane for asynchronous configuration issuance and Linux node lifecycle around AmneziaWG and Xray.

  • Python
  • PostgreSQL
  • Redis
  • Linux

rag_app

public repository

Self-hosted RAG and ReAct with hybrid retrieval, citations, local inference, and an independent evaluation pipeline.

  • Python
  • Qdrant
  • LLM
  • evaluation
repository

repo-semantic-mcp

public repository

Code-aware repository retrieval for coding agents: dense + sparse search, weighted RRF, bounded graph expansion, and freshness diagnostics.

  • Python
  • Qdrant
  • MCP
  • retrieval
repository

PixelBattle

public repository · 2024

Backend for a real-time collaborative canvas at a live event, with broadcast updates and action rate limiting; load-tested at 1.5-2K concurrent connections with broadcast latency below 50 ms.

  • FastAPI
  • WebSocket
  • PostgreSQL
  • Prometheus
  • Flutter
repository

seedforge / verified GPU search

Run a reliable exhaustive seed search across two GPUs.

A Noita seed deterministically defines a world. Seedforge reconstructs billions of those worlds on GPU, checks 22 target biomes for rare objects, and keeps only canonical, recoverable results.

The central work was making the inherited path operational, accurate, complete and crash-safe. Kernel profiling and tuning came after that foundation worked end to end.

project brief / 30 second read

A verified GPU system that exhaustively searches Noita worlds and preserves canonical, recoverable results.

  1. challenge

    The inherited CUDA search path did not run reliably, return correct results, or cover the full world. Performance only mattered after the system worked end to end.

  2. built

    I restored the native pipeline, proved CPU, V100 and RTX agreement, covered all 22 target biomes, and added crash-safe work distribution across two unequal GPUs.

  3. result

    The completed census scanned 2.147B world seeds. A separate dual-GPU run accepted all 433 cells with 0 missing and 0 invalid.

technical layer / profilerInspect the CUDA workerV100 · 80 SM · 960 × 64 · 3.08 / 32 lanesexpand profilercollapse profiler
launch hierarchyP6 diagnostic snapshot
GPUV10080 SM
grid960 blocks2 waves
block64 threads2 warps
warp3.08 / 32active lanes
instruction pipelinesP6 whole kernel · % active-cycle peak
ALU / INT7.94%indices · bitwise · counters
FMA pipe5.54%includes FP32 math
LSU / LD-ST8.18%arena · maps · bitsets
CBU / control4.20%gates · branches · retry
XU / special4.09%special-function path
FP640.14%parity-sensitive RNG

Source-informed phase highlight; measured values remain whole-kernel. These independent peak-utilization counters do not sum to 100%. FMA is not a pure FP32 counter. FP16, Tensor and TEX were 0% in this snapshot.

mixed irregular workloadINT / memory / control dominate; FP64 is a narrow game-parity path, not the bottleneck.
final P7 launch1440 blocks × 64 · 3 waves · span 8The counters shown here predate that final kernel.
pipeline / loadNsight Compute · coalmine
Compute SOL17.41%
DRAM SOL8.00%
Issue slots busy20.39%
Achieved occupancy14.66%
dependent memory waits47.71%long_scoreboard sample share
instruction queue pressure36.57%lg_throttle sample share
execution trace / final P7 schematicOne warp through the search
dispatching 64-thread blocks
  1. 01span × 8each CUDA thread receives a short seed span
  2. 02optional precheckreject or bypass before world reconstruction
  3. 03Wang layoutPRNG, Wang layout and path-bit inputs
  4. 04path + retrybitmap predicates, DFS, visited state and retry
  5. 05spawn hooksbounds, room, color, biome and chunk gates
  6. 06pixel-scenedescriptor selection and nested spawn indexing
  7. 07hit filtermatch counters accept only requested records
  8. 08binary hitGPU result first; canonical evidence is host-side
  • seed span
  • configured reject
  • active lane
  • accepted binary hit
release evidence / host sidebinary payload → canonical bytes → CPU = V100 = RTX

Sequence, lane masks, SM cohort and duration are schematic - not stage-time or per-SM telemetry. Static prechecks are configuration dependent; the profiled default coalmine command bypassed them. The 3.08-lane and pipeline counters are P6 diagnostic context, while this trace follows the final P7 search shape.

profiler readingSparse, divergent and latency / issue limited.

Peak compute and DRAM remain mostly idle. A historical P3 differential isolated pathfinding plus retry at 83.8%; the P6 counters above profile the whole kernel, and neither number is final-P7 stage-time attribution. Dependent memory work, queue pressure and only 3-4 active lanes still show meaningful headroom.

* 59.5k V100 + 75.7k RTX 5060 Ti, measured independently on the coalmine workload before orchestration overhead.

Seedforge extends the upstream NoitaSeedSearcherCUDA engine. Telescope parity is a sampled independent cross-check; documented residuals are not presented as exhaustive game parity.

vpn server / secure connectivity control plane

Issue secure connections without losing control of the node fleet.

The system authenticates a device, finds protocol-ready capacity and returns an AWG or Xray configuration through one asynchronous Connect Flow.

The larger job is keeping the control-plane ledger and the Linux fleet truthful through retries, restarts, refills, cleanup and node lifecycle changes.

project brief / 30 second read

A secure-connectivity control plane that issues AWG or Xray configurations and keeps the Linux node fleet recoverable.

  1. challenge

    Concurrent reconnects, retries, restarts, and node drift had to stay consistent without duplicate allocations or lost work.

  2. built

    I designed the authenticated Connect Flow, durable PostgreSQL job queue, Redis status cache, transaction-safe allocation, and fleet maintenance workers.

  3. result

    Repeated requests converge on one durable job, each device keeps one active slot, and interrupted work returns safely to processing.

architecture decision / task deliveryWhy the queue lives in PostgreSQLcore state · jobq · leases · retry · DLQexpand architecturecollapse architecture
control plane / data planecurrent Connect Flow
01 · edgeNginx + auth-serviceroute · limits · identity
02 · issueuser-api + Redisdedupe · pending / ready
03 · durable statePostgreSQLcore tables + jobq
user-workergenerate_configdevice-scoped queue
maintenance-workernode lifecyclenode-scoped queue
Linux node fleet / data plane
AWGXrayACTIVE only after protocol-ready bootstrap
durable job anatomyPostgreSQL-backed jobq
  1. enqueueidem_keyoptional shared DB transaction
  2. claimSKIP LOCKEDparallel workers
  3. executelease + heartbeatcrash recovery
  4. resolvesuccess / retry / DLQbounded outcome
fast wake-upLISTEN / NOTIFY
delivery fallbackperiodic poll
per-key serializationnode:{node_id} · user:{user_id}:device:{device_id}advisory lock prevents overlapping work for one resource
why PostgreSQL fits here

A durable task queue, not an event stream.

Control-plane work is coupled to relational node, slot and policy state. PostgreSQL keeps those invariants close, supports transactional enqueue where a flow needs it, and provides leases, delayed retry and deduplication without a second durability and backup plane.

current fitPostgreSQL jobqstate-coupled control-plane tasks
revisit forRabbitMQbroker-scale routing, fan-out or message throughput
revisit forKafkareplayable event streams and many independent consumers

Scoped choice, not a universal rule. Long remote handlers also consume database connections, so worker concurrency and pool headroom are explicit operational constraints.

Connect Flow is the current public issuance path; legacy /config is not presented as the primary interface.

Fleet cards are representative architecture, not live node counts or per-node telemetry.

rag_app / self-hosted evidence system

Answer questions over Telegram with evidence you can inspect.

This is not a vector-database wrapper. The system maintains a changing corpus, plans each question, combines lexical and semantic recall, checks whether the evidence is sufficient, and only then writes a cited answer.

The full path is self-hosted across Windows, WSL2 and Docker: Qwen on a V100, embedding and reranking on an RTX 5060 Ti, and FastAPI plus Qdrant on CPU.

project brief / 30 second read

A self-hosted evidence system that answers questions over a changing Telegram corpus with inspectable citations.

  1. challenge

    Retrieval had to recover exact terms and semantic matches without allowing unsupported answers.

  2. built

    I combined ingestion, ReAct planning, exact and semantic retrieval, reranking, evidence checks, and local inference across Windows, WSL2, and Docker.

  3. result

    Across 120 reviewed cases, factual quality reached 0.898 on 105 answerable questions, evidence support reached 0.886 on 65 retrieval cases, and all 15 refusal cases were handled correctly.

technical layer / evidence pathInspect one question through retrievalRUN-008 trace · 3 queries · 28 hits · 5 sourcesexpand retrievalcollapse retrieval
four different jobsrecall first · precision later
01BM25≥ 100recovers exact names, acronyms and rare terms
02dense≥ 40recovers paraphrases and overall semantic meaning
03ColBERT128-d / tokenfinds the best document match for each query token
04cross-encoderpost-search gatere-sorts evidence and cuts low-relevance candidates
representative query tracerecorded evaluation path
questionКого Financial Times назвала человеком года в 2025?
  1. 01query plan3 subqueries
  2. 02hybrid search28 documents
  3. 03evidence gate5 documents
  4. 04nugget coverage1.00 · no refinement
retrieval funnelminimum candidate limits
lexical laneBM25 · ≥ 100sparse-only query normalization
semantic lanedense · ≥ 40raw query · no prefix
native weighted RRFRRF · 3 : 1 · ≥ 50BM25 3 : dense 1
late interactionColBERT · 128-dMaxSim over token vectors
multi-query mergeMMR · λ 0.7MMR-style λ 0.7 · max 30
source diversityup to 3 results per channel and subquery
surviving evidencecross-encoder logits
#sourcescoredecision
01techsparks6.6keep
02ai_ml_big_data5.2keep
03techsparks3.5keep
04data_secrets2.5keep
05ai_ml_big_data2.4keep
CE re-sort · gap + cutoff · cosine recall guard
release contract5 numbered citations → local LLM → final SSE event
heterogeneous runtimeone system · three execution boundaries
Windows host · V100 32GBgenerationQwen3.5-35B-A3B · GGUF Q4_K_M
WSL2 native · RTX 5060 Tiretrieval modelsembed · ColBERT · reranker
Docker · CPU onlyAPI + stateFastAPI · Qdrant · Langfuse

The V100 runs in Windows TCC mode. GPU retrieval stays WSL2-native on the RTX 5060 Ti, while Docker remains CPU-only; explicit HTTP boundaries make that hardware constraint an ordinary service topology.

The trace is a recorded RUN-008 example, not live telemetry: 3 planned queries, 28 retrieved documents, 5 kept citations and 1.00 coverage.

Public metrics keep their denominators separate: RUN-009 has 120 reviewed questions; factual uses 105 answerable items, while evidence support uses the 65 retrieval-evidence cases.

repo-semantic-mcp / retrieval substrate for coding agents

Find the files that matter before the first edit.

Coding agents are strong once they have the right context. In an unfamiliar repository, the expensive part is locating implementation, tests, docs and configuration without mistaking a plausible match for evidence.

repo-semantic-mcp is not a hidden coding agent. It keeps repository maps fresh, combines meaning with exact terms, adds bounded structural context when useful, and hands the agent file ranges plus explicit verification actions.

project brief / 30 second read

A repository retrieval layer that gives coding agents the right files, line ranges, and verification steps before they edit.

  1. challenge

    In an unfamiliar codebase, plausible semantic matches are not enough. Implementation, tests, docs, and configuration must return as verifiable evidence.

  2. built

    I built language-aware indexing, exact and semantic retrieval, a bounded relation graph, freshness tracking, and MCP handoff.

  3. result

    The frozen self-repo baseline reached 83.3% recall @ 10. In 19 / 24 tasks, every expected file appeared within the top 20.

technical layer / context contractInspect one repository-context request1 repo · hybrid seeds · bounded graph · exact verificationexpand context pathcollapse context path
request + readiness gateread state before retrieval
agent questionWhere is start_watcher recovery decided after a branch switch?
  • repo_root · explicit
  • route · hybrid
  • graph · expand
  • rerank · auto
  • top_k · 8
compact readiness
repositoryrepo-semantic-mcptarget verified
searchusableindex contract matches
watcherrunningincremental freshness
grapheffectiveexpansion allowed

If this gate reports recovery or a hard contract mismatch, retrieval explains the state; it does not silently rebuild the index or graph.

two-level ranking pathrank fusion first · bounded reorder second
01denseweight 0.8raw question · paraphrases and intent
02sparseweight 1.4code-normalized terms · exact anchor retained
03graphweight 0.5explicit expand · typed neighbors from strong seeds
04reranktop 80optional code-aware reorder · candidates survive failure
fusion contractweighted RRF · k = 60dense + sparse fuse first; that ranked slate and graph fuse again - raw scores are never treated as one scale
exact-evidence guardup to 5 exact hits pinned500 ms stage deadline · 400 ms HTTP timeout
live-tree verificationrg --fixed-strings --line-number start_watcher .
representative context slateimplemented paths · schematic order, not live telemetry
#file / rangeoriginwhy it matters
01status/index_status.py · L196-301D · Swatcher state and recovery actions
02status/summary.py · L319-477D · S · Gcompact state and next-action policy
03watcher.py · L71-185D · Gruntime watcher and event batching
04indexer.py · L265-458S · Gbounded startup reconcile
05P6.C readiness specD · Gagent-facing readiness contract

D dense · S sparse · G graph

response envelopeevidence with gaps and actions
file_groups
paths · chunk ids · line ranges
matched_terms
start_watcher · branch switch · recovery
uncovered_terms
catch-up timeout
evidence_paths
typed structural steps
verification
required · exact anchor detected
recommended next actions
01read_file_rangeread the ranked implementation ranges
02run_local_rgverify the identifier in the live tree
03retry_with_path_filternarrow only if the slate is broad
multi-repository runtimeshared substrate · isolated repository state
process-wideregistry · embedding provider · Qdrant clientone MCP / HTTP service
per repositoryindexer · manifest · watcher · graph maintenanceindependent lifecycle and leases
pool bound10 live repositoriesexplicit target or active default
retrieval substrate, not a hidden planner

The service returns grounded candidates and diagnostics. The coding agent still reads source, verifies exact literals, forms the change plan and owns the edit.

The request above is a representative schematic assembled from implemented contracts, not a recorded query or live telemetry. Graph expansion is optional and compatibility-auto is disabled by default.

Scale counts come from the dated May 7 private-repository checkpoint. Retrieval metrics come from a frozen 24-task self-repository, file-localization artifact with no line-range labels - not a neutral public benchmark; exact identifiers still require local rg.

PixelBattle / real-time event backend

Turn one accepted pixel into a shared moment.

PixelBattle powered a collaborative canvas for a live event. Participants joined over WebSocket, loaded the same field and changed it one accepted pixel at a time.

I owned the FastAPI backend and its protocol for the Flutter client: PostgreSQL held canonical users and pixels, while an in-process ConnectionManager held live sockets and selections and fanned accepted changes out sequentially.

project brief / 30 second read

A FastAPI and WebSocket backend for a collaborative live canvas where each accepted pixel becomes a consistent update for connected clients.

  1. challenge

    Concurrent participants needed one canonical canvas, per-user action limits, and protection against stale writes.

  2. built

    I built the backend and Flutter protocol. PostgreSQL holds canonical state, WebSocket distributes accepted changes, and Prometheus exposes runtime signals.

  3. result

    Load testing reached 1.5-2K simultaneous connections with broadcast latency below 50 ms.

technical layer / accepted pixelInspect one accepted pixelWebSocket · bounds · cooldown · PostgreSQL · broadcastexpand runtimecollapse runtime
request pathone user update_pixel
  1. 01receivetyped WebSocket message
  2. 02validatebounds + user cooldown
  3. 03persisttimestamp-guarded upsert
  4. 04releasepixel_update delta
rejection boundaryInvalid coordinates, an active cooldown or a stale action return an error and stop before broadcast.
accepted orderingThe upsert returns a row only when it applies the candidate. Cooldown state and the live delta follow that canonical write.
state ownershipdurable truth vs live session
PostgreSQL / canonical
  • users + ban state
  • pixels by coordinate
  • last pixel update
  • pixel action time
ConnectionManager / memory
  • user sockets
  • admin sockets
  • nickname map
  • live selections
process configuration
  • field size
  • cooldown value
field_state compositionPersisted pixels come from PostgreSQL; selections are joined from process memory when the response is built.
broadcast semanticscurrent single-instance contract
01accepted pixel
02ConnectionManager.broadcastfor recipient → await send_text
03users + admins
architecture boundaryBroadcast is in-process and sequential. No RabbitMQ, Kafka, Redis pub/sub or cross-node delivery is claimed.
runtime signalsactual Prometheus instrumentation
Gaugeactive_websocket_connectionsconnected user sockets
Counterws_messages_sentmessages sent through metric wrapper
Counterws_messages_receivedmessages received through metric wrapper
load-test evidence
1.5-2Ksimultaneous connections
< 50 msbroadcast update latency

The concurrency and latency figures are reported load-test results. They are not derived from a Prometheus latency histogram.

The Flutter application appears only at the integration boundary; this story covers the backend and WebSocket contract.

The shown runtime is a single-instance design. Horizontal fan-out would require an explicit shared delivery layer and connection routing.

Systems

working set
backend
Python / FastAPI / PostgreSQL / Redis / ClickHouse
platform
Linux / Docker / Compose / Swarm / Ansible / observability
networking
AmneziaWG / Xray / routing / firewall / DNS
retrieval
Qdrant / hybrid search / reranking / evaluation / MCP
compute
CUDA / profiling / exhaustive search

direct contact

Contact

Project source code is on GitHub. You can reach me by email or Telegram.

GitHub Email Telegram