You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .gemini/styleguide.md
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,18 @@
1
+
When performing code reviews on pull requests, you must strictly adhere to the following principles in addition to the API design guidelines above:
2
+
3
+
1.**Question the Necessity of Changes**: Do not assume that the pull request changes are strictly necessary. Critically review the proposed changes to ensure they add real value. Point out any code that solving a non-existent problem or adding unnecessary complexity.
4
+
5
+
2.**Call out "AI Slop"**: Actively look for and identify "AI slop"—generic, overly verbose, or hallucinated code that lacks context or violates best practices. If you suspect the code is AI slop, explicitly call it out.
6
+
7
+
3.**Poke Holes in the Implementation**: Your goal is to critically test the logic. Actively search for and point out failing edge cases, race conditions, or unhandled exceptions in the implementation.
8
+
9
+
4.**Demand Robustness**: Do not accept fragile code. If the proposed code is not robust enough or lacks proper error handling, explicitly tell the author why the current approach is brittle and what must be done to reinforce it.
10
+
11
+
5.**Respect Existing Repo Patterns**: Before suggesting review comments (like asking users to add boilerplate or specific patterns), actively check for existing design patterns across the repository. Do not suggest adding useless code or structures that contradict or fall outside the established Keras repo coding style.
12
+
13
+
14
+
15
+
1
16
# Keras Remote API design guidelines
2
17
3
18
These guidelines are meant to help focus design discussions and help us create delightful developer experiences for remote execution.
Copy file name to clipboardExpand all lines: README.md
+96-8Lines changed: 96 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -72,9 +72,10 @@ This adds the `keras-remote up`, `keras-remote down`, `keras-remote status`, and
72
72
- Python 3.11+
73
73
- Google Cloud SDK (`gcloud`)
74
74
- Run `gcloud auth login` and `gcloud auth application-default login`
75
-
-[Pulumi CLI](https://www.pulumi.com/docs/install/) (required for `[cli]` install only)
76
75
- A Google Cloud project with billing enabled
77
76
77
+
Note: The Pulumi CLI is bundled and managed automatically. It will be installed to `~/.keras-remote/pulumi` on first use if not already present.
78
+
78
79
## Quick Start
79
80
80
81
### 1. Configure Google Cloud
@@ -203,15 +204,102 @@ def train():
203
204
204
205
See [examples/Dockerfile.prebuilt](examples/Dockerfile.prebuilt) for a template.
205
206
207
+
## Handling Data
208
+
209
+
Keras Remote provides a declarative and performant Data API to seamlessly make your local and cloud data available to your remote functions.
210
+
211
+
The Data API is designed to be read-only. It reliably delivers data to your pods at the start of a job. For saving model outputs or checkpointing, you should write directly to GCS from within your function.
212
+
213
+
Under the hood, the Data API optimizes your workflows with two key features:
214
+
215
+
-**Smart Caching:** Local data is content-hashed and uploaded to a cache bucket only once. Subsequent job runs that use byte-identical data will hit the cache and skip the upload entirely, drastically speeding up execution.
216
+
-**Automatic Zip Exclusion:** When you reference a data path inside your current working directory, Keras Remote automatically excludes that directory from the project's zipped payload to avoid uploading the same data twice.
217
+
218
+
There are three main ways to handle data depending on your workflow:
219
+
220
+
### 1. Dynamic Data (The `Data` Class)
221
+
222
+
The simplest and most Pythonic approach is to pass `Data` objects as regular function arguments. The `Data` class wraps a local file/directory path or a Google Cloud Storage (GCS) URI.
223
+
224
+
On the remote pod, these objects are automatically resolved into plain string paths pointing to the downloaded files, meaning your function code never needs to know about GCS or cloud storage APIs.
225
+
226
+
```python
227
+
import pandas as pd
228
+
import keras_remote
229
+
from keras_remote import Data
230
+
231
+
@keras_remote.run(accelerator="v6e-8")
232
+
deftrain(data_dir):
233
+
# data_dir is resolved to a dynamic local path on the remote machine
234
+
df = pd.read_csv(f"{data_dir}/train.csv")
235
+
# ...
236
+
237
+
# Uploads the local directory to the remote pod automatically
238
+
train(Data("./my_dataset/"))
239
+
240
+
# Cache hit: subsequent runs with the same data skip the upload!
241
+
train(Data("./my_dataset/"))
242
+
```
243
+
244
+
**Note on GCS Directories:** When referencing a GCS directory with the `Data` class, you must include a trailing slash (e.g., `Data("gs://my-bucket/dataset/")`). If you omit the trailing slash, the system will treat it as a single file object.
245
+
246
+
You can also pass multiple `Data` arguments, or nest them inside lists and dictionaries (e.g., `train(datasets=[Data("./d1"), Data("./d2")])`).
247
+
248
+
### 2. Static Data (The `volumes` Parameter)
249
+
250
+
For established training scripts where data requirements are static, you can use the `volumes` parameter in the `@keras_remote.run` decorator. This mounts data at fixed, hardcoded absolute filesystem paths, allowing you to drop `keras_remote` into existing codebases without altering the function signature.
# Data is guaranteed to be available at these absolute paths
266
+
df = pd.read_csv("/data/train.csv")
267
+
model.load_weights("/weights/model.h5")
268
+
# ...
269
+
270
+
# No data arguments needed!
271
+
train()
272
+
273
+
```
274
+
275
+
### 3. Direct GCS Streaming (For Large Datasets)
276
+
277
+
If your dataset is very large (e.g., > 10GB), it is inefficient to download the entire dataset to the remote pod's local disk. Instead, skip the `Data` wrapper entirely and pass a GCS URI string directly. You can then use frameworks with native GCS streaming support (like `tf.data` or `grain`) to read the data on the fly.
0 commit comments