Initial commit: TFGrid Economics documentation site
Some checks failed
Deploy to GitHub Pages / Deploy to GitHub Pages (push) Has been cancelled
Some checks failed
Deploy to GitHub Pages / Deploy to GitHub Pages (push) Has been cancelled
- Based on working minting_plan repository - Configured for threefold.info/economics deployment - Added ops documentation for server deployment - Updated baseUrl and URL configuration
This commit is contained in:
274
docs/node-economics/slices-overview.md
Normal file
274
docs/node-economics/slices-overview.md
Normal file
@@ -0,0 +1,274 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Understanding Slices
|
||||
|
||||
Slices are the fundamental unit of capacity allocation in TFGrid v4. Think of them as standardized "packages" of compute resources that make it easy to price, allocate, and utilize node capacity efficiently.
|
||||
|
||||
---
|
||||
|
||||
## What is a Slice?
|
||||
|
||||
A **slice** is a defined portion of a node's total resources, including:
|
||||
|
||||
- **CPU Cores**: Processing power allocated to the slice
|
||||
- **Performance (Passmark)**: Benchmark score indicating CPU performance
|
||||
- **Memory (RAM)**: Gigabytes of system memory
|
||||
- **Storage (SSD)**: Gigabytes of fast storage
|
||||
- **TPS (Tokens Per Second)**: For AI workloads, processing capability
|
||||
|
||||
Rather than selling "whole nodes" or arbitrary resource amounts, slices provide:
|
||||
- **Standardization**: Predictable resource bundles
|
||||
- **Flexibility**: Users can consume 1 slice or 100 slices
|
||||
- **Efficiency**: Better matching of supply to demand
|
||||
- **Clarity**: Transparent pricing per slice
|
||||
|
||||
---
|
||||
|
||||
## Why Slices?
|
||||
|
||||
### The Old Problem
|
||||
|
||||
**Without slices**:
|
||||
- Users need to understand complex hardware specifications
|
||||
- Pricing is inconsistent across different node types
|
||||
- Hard to compare value between providers
|
||||
- Resources often underutilized or over-provisioned
|
||||
|
||||
### The Slice Solution
|
||||
|
||||
**With slices**:
|
||||
- Simple, standardized packages (like buying "small", "medium", "large")
|
||||
- Consistent pricing model across the network
|
||||
- Easy comparison: "This slice costs X, provides Y resources"
|
||||
- Better utilization: Divide nodes into right-sized portions
|
||||
|
||||
---
|
||||
|
||||
## How Nodes Divide Into Slices
|
||||
|
||||
Each physical node can support a **maximum number of slices** based on its specifications.
|
||||
|
||||
### Example: 3Node Home
|
||||
|
||||
**Total Resources**:
|
||||
- 16 CPU cores
|
||||
- 22,000 Passmark score
|
||||
- 32 GB RAM
|
||||
- 1,000 GB SSD
|
||||
|
||||
**Maximum Slices**: 25
|
||||
|
||||
**Per Slice** (resources divided):
|
||||
- 2.3 cores (16 ÷ 7 slices actually used)
|
||||
- 3,143 Passmark performance
|
||||
- 4.0 GB RAM
|
||||
- 143 GB SSD
|
||||
|
||||
:::note Resource Allocation
|
||||
Not all nodes use their maximum slice count. The actual slices used depends on the node's resource constraints. For example, a 3Node Home is limited by RAM, so it provides 7 slices despite having capacity for 25.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Slice Types
|
||||
|
||||
Different workloads need different resource balances. ThreeFold offers several slice configurations:
|
||||
|
||||
### Standard Compute Slice
|
||||
**Best for**: General applications, web services, APIs
|
||||
|
||||
**Resources**:
|
||||
- ~2,000 Passmark performance
|
||||
- 4 GB RAM
|
||||
- Standard storage
|
||||
|
||||
**Price**: ~1.2 CC/month minimum
|
||||
|
||||
### Memory-Heavy Slice
|
||||
**Best for**: Databases, caching, memory-intensive applications
|
||||
|
||||
**Resources**:
|
||||
- Standard performance
|
||||
- 8 GB RAM (double standard)
|
||||
- Standard storage
|
||||
|
||||
**Price**: ~2.4 CC/month minimum
|
||||
|
||||
### AI Slice (Standard)
|
||||
**Best for**: AI inference, small models, development
|
||||
|
||||
**Resources**:
|
||||
- Moderate performance
|
||||
- 124 GB RAM
|
||||
- Shared GPU access
|
||||
|
||||
**Price**: ~50 CC/month minimum
|
||||
|
||||
### AI Slice (Dedicated GPU)
|
||||
**Best for**: AI training, large models, high-performance inference
|
||||
|
||||
**Resources**:
|
||||
- High performance
|
||||
- 124-250 GB RAM
|
||||
- Dedicated GPU (96-192 GB GPU memory)
|
||||
|
||||
**Price**: 500-1,000 CC/month minimum
|
||||
|
||||
See [TF Bid Packages](/node-economics/tf-bid-packages) for complete specifications.
|
||||
|
||||
---
|
||||
|
||||
## Slices and Farmer Income
|
||||
|
||||
Slices directly determine farmer earnings:
|
||||
|
||||
### Income Calculation
|
||||
|
||||
```
|
||||
Monthly Income = (Number of Active Slices) × (Price Per Slice) × (Utilization Rate)
|
||||
```
|
||||
|
||||
**Example**:
|
||||
- Node: Large TFGrid Node with 20 slices
|
||||
- Price per slice: 7.6 CC (minimum pricing)
|
||||
- Utilization: 80% (16 slices rented)
|
||||
- **Monthly Income**: 16 × 7.6 = 121.6 CC/month (~$15.56 at 1 CC = $0.128)
|
||||
|
||||
### Income Ranges
|
||||
|
||||
Each node type has:
|
||||
- **Minimum Income**: Conservative pricing, partial utilization
|
||||
- **Maximum Income**: Premium pricing, full utilization
|
||||
|
||||
See [Pricing Model](/node-economics/pricing-model) for detailed projections and ROI analysis.
|
||||
|
||||
---
|
||||
|
||||
## Slices and the 80% Revenue Share
|
||||
|
||||
The slice pricing includes the revenue share model:
|
||||
|
||||
1. **User pays for slice**: Example: 10 CC/month
|
||||
2. **Revenue distribution**:
|
||||
- **80%** → Farmer (8 CC)
|
||||
- **10%** → TFT Burn (1 CC worth of TFT burned)
|
||||
- **10%** → ThreeFold Operations (1 CC)
|
||||
|
||||
:::tip Farmer-First Economics
|
||||
With 80% going directly to farmers, the slice model ensures capacity providers receive the majority of value generated.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Oversubscription
|
||||
|
||||
One important note from the current calculation: **CPU oversubscription is not currently factored in**.
|
||||
|
||||
### What is Oversubscription?
|
||||
|
||||
In practice, most workloads don't use 100% of allocated CPU 100% of the time. Cloud providers often oversubscribe CPU (sell more CPU cores than physically exist) because:
|
||||
- Most workloads are bursty (high usage occasionally, low usage normally)
|
||||
- Statistical multiplexing: not all users peak at the same time
|
||||
- Better hardware utilization and economics
|
||||
|
||||
### Future Implementation
|
||||
|
||||
TFGrid may implement CPU oversubscription carefully:
|
||||
- **Benefit**: Higher effective income per node
|
||||
- **Risk**: Must ensure quality of service isn't degraded
|
||||
- **Balance**: Conservative ratios (e.g., 1.5x or 2x) rather than aggressive oversubscription
|
||||
|
||||
:::caution Current Status
|
||||
The income projections in this documentation assume **no CPU oversubscription**. Actual income could be higher if careful oversubscription is implemented in the future.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Slices in Practice
|
||||
|
||||
### For Users
|
||||
|
||||
**Simple shopping experience**:
|
||||
1. Browse available slice types
|
||||
2. See clear pricing and resources
|
||||
3. Deploy workloads to slices
|
||||
4. Scale up or down as needed
|
||||
|
||||
**No complex calculations** about "how many cores do I need vs. RAM vs. storage?"
|
||||
|
||||
### For Farmers
|
||||
|
||||
**Predictable capacity planning**:
|
||||
1. Know your node specifications
|
||||
2. Calculate maximum slices
|
||||
3. Set competitive pricing
|
||||
4. Track utilization and income
|
||||
|
||||
**Clear comparison** between different hardware investments.
|
||||
|
||||
---
|
||||
|
||||
## Example Scenarios
|
||||
|
||||
### Scenario 1: Web Hosting Company
|
||||
|
||||
**Needs**: Run 50 WordPress sites
|
||||
|
||||
**Solution**:
|
||||
- Rent 10 Standard Compute Slices
|
||||
- Each slice hosts 5 sites
|
||||
- Cost: 10 × 1.2 CC = 12 CC/month (~$1.54)
|
||||
- Clear, predictable pricing
|
||||
|
||||
### Scenario 2: AI Startup
|
||||
|
||||
**Needs**: Train a medium language model
|
||||
|
||||
**Solution**:
|
||||
- Rent 2 AI Slice Big (Nvidia 2x)
|
||||
- Dedicated 192 GB GPU memory each
|
||||
- Cost: 2 × 1,000 CC = 2,000 CC/month (~$256)
|
||||
- Direct comparison to AWS/GCP alternatives
|
||||
|
||||
### Scenario 3: Farmer Planning
|
||||
|
||||
**Hardware**: Investing in Mini 3 node
|
||||
|
||||
**Capacity**: 25 slices maximum
|
||||
|
||||
**Income Target**:
|
||||
- Conservative: 48 CC/month minimum (partial utilization)
|
||||
- Optimistic: 558 CC/month maximum (full utilization, premium pricing)
|
||||
- Realistic: ~200-300 CC/month with good network adoption
|
||||
|
||||
See [Node Specifications](/node-economics/node-specifications) for all node types.
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
✅ **Slices standardize capacity** into easy-to-understand packages
|
||||
|
||||
✅ **Better resource utilization** than whole-node or arbitrary allocations
|
||||
|
||||
✅ **Clear pricing model** for both users and farmers
|
||||
|
||||
✅ **Flexible scaling** - consume exactly what you need
|
||||
|
||||
✅ **Direct income correlation** - more slices rented = more income
|
||||
|
||||
✅ **Farmer-first revenue share** - 80% goes to capacity providers
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Node Specifications](/node-economics/node-specifications)** - See detailed specs for all node types
|
||||
- **[Pricing Model](/node-economics/pricing-model)** - Understand income projections and ROI
|
||||
- **[TF Bid Packages](/node-economics/tf-bid-packages)** - Explore standard ThreeFold offerings
|
||||
|
||||
:::tip Related Concept
|
||||
Slices work seamlessly with the [Cloud Credits (CC)](/core-concepts/token-system) stable pricing system, ensuring predictable economics for everyone.
|
||||
:::
|
Reference in New Issue
Block a user