pasteurlabs/tesseract-core

Summary Add helpers to tesseract_core.runtime.jax_recipes that convert endpoint inputs to JAX arrays, without a copy where one isn't needed: as_jax_array(x) converts a single array. as_jax_arrays(tree) converts every array leaf in a pytree, such as inputs.model_dump(), and leaves other leaves alone. Use as_jax_arrays inside the jax_* helpers on inputs, tangent_vector and cotangent_vector. Give the PyTorch template's to_tensor the same GPU branch. Why is this needed? With gpu_transport="cuda_ipc", GPU inputs reach endpoints as IpcDeviceArray. Neither recipe converts them to its framework's array type. The obvious jnp.from_dlpack(x) / torch.from_dlpack(x) fails for host inputs, because the runtime decodes those to read-only NumPy arrays and DLPack refuses to export them. So every Tesseract has to branch on where each input lives. Usage example from tesseract_core.runtime.cuda.ipc import is_gpu_array def as_jax_array(x) -> jax.Array: if isinstance(x, jax.Array): return x

Description A pydantic default on an array-typed input (for example Differentiable[Array[(), Float32]] = Field(default=2.0)) is not compatible with abstract_eval when the Tesseract uses the JAX recipe (jax_abstract_eval). In the abstract-eval schema the field is typed as ShapeDType, but an omitted input keeps its default, which is a plain float. jax_abstract_eval then calls abstract_inputs.model_dump(), and pydantic emits a PydanticSerializationUnexpectedValue warning for that field. With warnings as errors (for instance a test suite that sets filterwarnings = error), the warning becomes a hard failure of the abstract_eval endpoint. apply with the same default works. Expected: omitting an input that has a default works in abstract_eval as it does in apply, with no warning. Either the default would be converted to an abstract value (shape () and the declared dtype), or schema generation would reject non-array defaults on array-typed fields up front. Workaround: declare the input as Arra

Description The runtime's compression option (--compression lz4 / TESSERACT_RUNTIME_COMPRESSION=lz4) is applied by tesseract-runtime apply, but ignored by tesseract-runtime serve: arrays in HTTP responses always come back uncompressed. The CLI path passes compression=config.compression to output_to_bytes (cli.py#L631), but create_response does not (serve.py#L102-L108), so served endpoints fall back to the default compression=None. The SDK client already decodes lz4 buffers, so the gap is on the server side only. Expected: served endpoints encode arrays with the configured compression, as the CLI does. Steps to reproduce tesseract_api.py: import numpy as np from pydantic import BaseModel from tesseract_core.runtime import Array, Float64 class InputSchema(BaseModel): n: int class OutputSchema(BaseModel): x: Array[(None,), Float64] def apply(inputs: InputSchema) -> OutputSchema: return OutputSchema(x=np.zeros(inputs.n)) $ export TESSERACT_API_PATH=$PWD/tesseract_api.py

Description The SDK client encodes input arrays through two separate, mutually exclusive paths, chosen wholesale by output_format: binref path (tesseract_core/sdk/tesseract.py:1094-1123): when output_format == "json+binref" and an input path is set, inputs are tree-mapped through encode_array_binref / encode_array_binref_pooled (tesseract_core/sdk/binref.py), writing .bin files to the mounted input dir. _encode_payload -> _encode_array path (tesseract_core/sdk/tesseract.py:1129): every other case; handles base64 / raw and the GPU device transports (cuda_ipc, cuda_vmm). Its encoding Literal is ["base64", "raw", "cuda_ipc", "cuda_vmm"] — note binref is absent, because binref never flows through here. Consequences: The two can't compose. A request is either all-binref or all-(base64/GPU), because the branch is selected by output_format, not per-array. You can't send large host inputs as binref while exporting GPU inputs by reference in the same call. binref-as-input is coupled to jso

Summary There is no supported, client-facing way to ask a Tesseract / client which device transports (gpu_transport values, e.g. cuda_ipc) it can use. Consumers that drive the GPU-direct path have to reach into private state — checking hasattr(client, "_gpu_transport") to tell an HTTPClient (transport-capable) apart from a LocalClient (not), and hardcoding the set of valid transport names. Expose a public accessor (e.g. a supported_device_transports property on the client/Tesseract, or a small helper) that reports which transports a given client supports. Why is this needed? The sibling wrappers (pasteurlabs/tesseract-torch#42, pasteurlabs/tesseract-jax#239) added an opt-in device-transport path (cuda_ipc) that keeps CUDA tensors on-device across the Tesseract boundary. To do that safely, each wrapper independently has to answer two questions that only tesseract-core can authoritatively answer: Can this client use a device transport at all? — today resolved by duck-typing hasattr(