ezsx

systems / tools / 2026

ezsx

Проекты на Python: backend, Linux-инфраструктура, защищённые подключения, retrieval и GPU-вычисления.

  • backend
  • platform
  • networking
  • retrieval
  • compute

Selected work

05 systems

CUDA seed search

public repository

Полный перебор seed на GPU с проверками корректности, возобновляемыми запусками на двух разных GPU и воспроизводимыми результатами.

  • CUDA
  • profiling
  • verification
  • GPU
repository

Secure connectivity

private system

Серверный control plane для асинхронной выдачи конфигураций и управления жизненным циклом Linux-нод с AmneziaWG и Xray.

  • Python
  • PostgreSQL
  • Redis
  • Linux

rag_app

public repository

Self-hosted RAG и ReAct: гибридный retrieval, цитаты, локальный inference и отдельный контур оценки.

  • Python
  • Qdrant
  • LLM
  • evaluation
repository

repo-semantic-mcp

public repository

Поиск по репозиторию для coding agents: dense + sparse retrieval, взвешенный RRF, ограниченное расширение графа и диагностика свежести индекса.

  • Python
  • Qdrant
  • MCP
  • retrieval
repository

PixelBattle

public repository · 2024

Backend совместного холста в реальном времени для живого мероприятия: широковещательные обновления и rate limiting. На нагрузочном тесте система выдержала 1,5-2 тыс. одновременных подключений при задержке рассылки ниже 50 мс.

  • FastAPI
  • WebSocket
  • PostgreSQL
  • Prometheus
  • Flutter
repository

seedforge / verified GPU search

Надёжно запустить полный поиск seed на двух GPU.

Seed в Noita детерминированно задаёт мир. Seedforge реконструирует миллиарды таких миров на GPU, проверяет редкие объекты во всех 22 целевых биомах и сохраняет только канонические результаты, которые можно проверить и восстановить.

Главная работа состояла в том, чтобы довести унаследованный CUDA pipeline до рабочего, точного и устойчивого к сбоям состояния, а затем закрыть весь мир. Profiling и kernel tuning начались только после того, как pipeline стал стабильно запускаться, его результаты совпали с CPU-версией, а поиск охватил все 22 целевых биома.

project brief / 30 second read

GPU-система для полного поиска миров Noita с проверяемыми результатами и восстановлением после сбоев.

  1. challenge

    Унаследованный CUDA pipeline не запускался стабильно, возвращал некорректные результаты и не покрывал весь мир. Profiling и kernel tuning начались только после исправления этих проблем.

  2. built

    Сначала я восстановил CUDA pipeline, добился совпадения результатов на CPU, V100 и RTX и добавил все 22 целевых биома. Затем настроил распределение работы между двумя GPU, восстановление после сбоев и только после этого занялся kernel tuning.

  3. result

    Полный поиск проверил 2,147 млрд миров. Отдельный запуск на двух GPU обработал 433 / 433 ячеек без пропусков и ошибок.

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

Выдавать защищённые подключения и сохранять контроль над парком узлов.

Система аутентифицирует устройство, находит узел с готовым протоколом и свободным местом, затем возвращает конфигурацию AWG или Xray через единый асинхронный Connect Flow.

Главная сложность - сохранять согласованное состояние control plane и парка Linux-узлов при повторных попытках, перезапусках, пополнении резерва, очистке и изменении состава инфраструктуры.

project brief / 30 second read

Control plane, который выдаёт устройству готовую конфигурацию AWG или Xray и поддерживает парк Linux-узлов в рабочем состоянии.

  1. challenge

    Повторные подключения и сбои не должны создавать дублирующие задания, терять работу или повторно выдавать уже занятое место.

  2. built

    Я спроектировал единый Connect Flow, надёжную очередь заданий в PostgreSQL, быстрый кэш статусов в Redis, безопасное конкурентное выделение подключений и фоновые процессы обслуживания узлов.

  3. result

    Повторные запросы сходятся к одному заданию, за устройством остаётся одно активное подключение, а прерванная работа безопасно возвращается в очередь.

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

Отвечать по Telegram-корпусу с проверяемыми источниками.

Это не просто обёртка над векторной базой. Система обновляет меняющийся корпус, планирует каждый запрос, совмещает лексический и семантический retrieval, проверяет достаточность источников и только после этого формирует ответ с citations.

Весь pipeline работает локально между Windows, WSL2 и Docker: Qwen на V100, embedding и reranking на RTX 5060 Ti, FastAPI и Qdrant на CPU.

project brief / 30 second read

Self-hosted RAG-система отвечает по меняющемуся Telegram-корпусу и возвращает ответ со ссылками на проверяемые источники.

  1. challenge

    Retrieval должен находить и точные термины, и смысловые совпадения, не позволяя модели отвечать без достаточных источников.

  2. built

    Я объединил ingestion, ReAct planning, exact и semantic retrieval, reranking, проверку источников и локальный inference в Windows, WSL2 и Docker.

  3. result

    На выборке из 120 проверенных кейсов фактическая точность составила 0.898 для 105 вопросов с ответом, поддержка ответа источниками получила оценку 0.886 на 65 retrieval-кейсах, а все 15 запросов, требующих отказа, обработаны корректно.

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

Найти нужные файлы до первой правки.

Coding-агент силён, когда получил правильный контекст. В незнакомом репозитории дорого не написать код, а найти реализацию, тесты, документацию и конфигурацию, не приняв правдоподобное совпадение за доказательство.

repo-semantic-mcp - не скрытый coding-агент. Он поддерживает карту репозитория свежей, объединяет смысловой и точный retrieval, при необходимости добавляет ограниченный контекст из графа и возвращает диапазоны строк вместе с явными шагами проверки.

project brief / 30 second read

Retrieval-слой по репозиторию, который до первой правки отдаёт coding-агенту нужные файлы, диапазоны строк и шаги проверки.

  1. challenge

    В незнакомом коде правдоподобного смыслового совпадения недостаточно. Реализация, тесты, документация и конфигурация должны возвращаться как проверяемые основания для решения.

  2. built

    Я построил языковую индексацию, совместил точный и семантический retrieval, добавил ограниченный граф связей, контроль свежести и MCP handoff.

  3. result

    Зафиксированный self-repo benchmark показал 83.3% recall @ 10. В 19 из 24 задач все ожидаемые файлы попали в 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

Превратить принятый пиксель в общее событие.

PixelBattle обслуживал совместный холст во время live-события. Участники подключались по WebSocket, получали общее поле и меняли его по одному принятому пикселю.

Я отвечал за FastAPI backend и протокол Flutter-клиента: PostgreSQL хранил каноническое состояние пользователей и пикселей, а in-process ConnectionManager держал активные соединения и выделения и последовательно рассылал принятые изменения.

project brief / 30 second read

Backend совместного live-холста на FastAPI и WebSocket, где каждый принятый пиксель становится согласованным обновлением для подключённых клиентов.

  1. challenge

    Для одновременной работы участников требовались единое состояние холста, ограничения частоты действий и защита от устаревших записей.

  2. built

    Я разработал backend и протокол Flutter-клиента. PostgreSQL хранит каноническое состояние, WebSocket рассылает принятые изменения, а Prometheus показывает runtime-метрики.

  3. result

    На нагрузочном тесте система выдержала 1,5-2 тыс. одновременных подключений при задержке рассылки ниже 50 мс.

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

Исходный код проектов размещён на GitHub. Связаться со мной можно по email или в Telegram.

GitHub Email Telegram