DSN Standard
Last updated
Last updated
The DSN (Decentralized Subnet) standard is for deploying decentralized AI models within the Hypertensor economy with other subnet validator nodes. The DSN has a PoS (Proof of Stake) consensus mechanism to enter the DHT (Distributed Hash Table) of the subnet's peer-to-peer network. This can be used to deploy decentralized AI models or AI agents in a fault-tolerant decentralized environment that follows the Hypertensor SCP (Subnet Consensus Protocol).
https://github.com/hypertensor-blockchain/dsn The DSN has been adapted to deploy Llama, Mixtral, Falcon, and Bloom standards. Although, it can be adapted for any model type.
Similar to Ethereum's ERC20 standard or Solana's SPL token standard, the DSN can be customized to fit the needs of the subnet. Hypertensor employs smart contracts that can be used within the DSN as on-the-fly logic for governance, parameters, incentives logic, etc., or any customizable logic without requiring subnet validator nodes to upgrade the client itself.
Models are split between multiple nodes, each hosting specific transformer blocks of the model. Each server holds several consecutive blocks, the number of which depends on the server’s available GPU memory.
When generating tokens, a client stores the model’s token embeddings (which typically comprise a small fraction of the total parameter count and can fit in RAM in most modern laptops, servers, and workstations) locally and relies on servers to run Transformer blocks. Before each inference session, the client finds a chain of servers that collectively hold all model layers. Once the chain is formed, the client uses the local embedding layer to look up embedding vectors for prefix tokens, then sends those vectors to servers and receives new representations. Once the client obtains the outputs of the final block, it computes the next token probabilities and repeats this process. While the session is active, servers store attention keys and values from past client inputs and use them for subsequent inference steps. Clients also store past inputs to each server so that if any server fails or goes offline, another one can quickly take its place.
