[Core] Cleanup Omni connector runtime and transfer backends (#5096)

Signed-off-by: spencerr221 <liubingyu62@gmail.com>

docs/configuration/stage_configs.md

@@ -65,7 +65,7 @@ connectors:
 
 | Connector class | Use case | `extra` keys |
 |-----------------|----------|--------------|
-| `SharedMemoryConnector` | Same-host KV transfer between stages (default for bundled YAMLs). | `shm_threshold_bytes` (int, default `65536`). |
+| `SharedMemoryConnector` | Same-host KV transfer between stages (default for bundled YAMLs). | None. All payloads use shared memory. |
 | `MooncakeStoreConnector` | Cross-host KV transfer over TCP. Required for multi-node deployments. | `host`, `metadata_server`, `master`, `segment` (int bytes), `localbuf` (int bytes), `proto` (`"tcp"` / `"rdma"`). |
 
 A stage references a connector by name in its `input_connectors` / `output_connectors`:

docs/design/feature/disaggregated_inference.md

@@ -66,8 +66,6 @@ runtime:
   connectors:
     connector_of_shared_memory:
       name: SharedMemoryConnector
-      extra:
-        shm_threshold_bytes: 65536
 ```
 
 Wire stages to connectors:

docs/design/feature/omni_connectors/shared_memory_connector.md

@@ -8,9 +8,7 @@ auto-configured when no explicit connector is specified for an edge.
 ## How It Works
 
 All payloads are serialized and stored in shared memory (`/dev/shm`); the SHM
-segment name is returned in metadata. The configuration exposes a
-`shm_threshold_bytes` field for a future inline-vs-SHM split, but the current
-implementation always uses shared memory regardless of payload size.
+segment name is returned in metadata.
 
 ## Configuration
 
@@ -19,8 +17,6 @@ runtime:
   connectors:
     connector_of_shared_memory:
       name: SharedMemoryConnector
-      extra:
-        shm_threshold_bytes: 65536
 ```
 
 ## Notes
@@ -166,27 +162,10 @@ This path is mainly for older code paths and is not the preferred mode for the c
 
 ### 6. Key Implementation Characteristics
 
-#### 6.1 Threshold Exists, but the Current Code Always Uses SHM
+#### 6.1 All Payloads Use Shared Memory
 
-The class keeps a `shm_threshold_bytes` field and still exposes metrics for inline writes. However, the current implementation uses:
-
-```python
-if True:
-    ...
-```
-
-inside `put()`, which means the current code path always writes to shared memory.
-
-So the design still suggests a future split between:
-
-- small payloads inline
-- large payloads in shared memory
-
-but the current behavior is effectively:
-
-- all payloads go through shared memory
-
-This should be documented because it affects real runtime behavior.
+`put()` writes every serialized payload to shared memory. The connector has no
+inline-payload path or size threshold.
 
 #### 6.2 Cleanup Is Currently Passive
 

docs/design/feature/ray_based_execution.md

@@ -47,7 +47,7 @@ When running on Ray, the system automatically adapts its communication strategy:
 
 *   **Cross-Node**: Recommended to use `MooncakeTransferEngineConnector` (RDMA, fastest) or `MooncakeStoreConnector` (TCP fallback).
 *   **Same-Node**: Can still use `SharedMemoryConnector` for efficiency, or Ray's native object store (plasma).
-*   **SHM threshold default differs**: when `worker_backend="ray"`, the SharedMemoryConnector default threshold is set to `sys.maxsize`, which forces payloads to go inline (no SHM). Override `shm_threshold_bytes` in the connector config if you want SHM for Ray runs.
+*   **SHM payload routing**: `SharedMemoryConnector` always stores payloads in `/dev/shm`.
 
 ### 2.4 Internal Helpers