Get desktop application:
View/edit binary Protocol Buffers messages
ModelService provides methods to query and update the state of the server, e.g. which models/versions are being served.
Gets status of model. If the ModelSpec in the request does not specify version, information about all versions of the model will be returned. If the ModelSpec in the request does specify a version, the status of only that version will be returned.
GetModelStatusRequest contains a ModelSpec indicating the model for which to get status.
Model Specification. If version is not specified, information about all versions of the model will be returned. If a version is specified, the status of only that version will be returned.
Response for ModelStatusRequest on successful run.
Version number and status information for applicable model version(s).
Reloads the set of served models. The new config supersedes the old one, so if a model is omitted from the new config it will be unloaded and no longer served.
open source marker; do not remove PredictionService provides access to machine-learned models loaded by model_servers.
Classify.
GetModelMetadata - provides access to metadata for loaded models.
Model Specification indicating which model we are querying for metadata. If version is not specified, will use the latest (numerical) version.
Metadata fields to get. Currently supported: "signature_def".
Model Specification indicating which model this metadata belongs to.
Map of metadata field name to metadata field. The options for metadata field name are listed in GetModelMetadataRequest. Currently supported: "signature_def".
MultiInference API for multi-headed models.
Predict -- provides access to loaded TensorFlow model.
Regress.
SessionService defines a service with which a client can interact to execute Tensorflow model inference. The SessionService::SessionRun method is similar to MasterService::RunStep of Tensorflow, except that all sessions are ready to run, and you request a specific model/session with ModelSpec.
Runs inference of a given model.
Model Specification. If version is not specified, will use the latest (numerical) version.
Tensors to be fed in the step. Each feed is a named tensor.
Fetches. A list of tensor names. The caller expects a tensor to be returned for each fetch[i] (see RunResponse.tensor). The order of specified fetches does not change the execution order.
Target Nodes. A list of node names. The named nodes will be run to but their outputs will not be fetched.
Options for the run call. **Currently ignored.**
NOTE: The order of the returned tensors may or may not match the fetch order specified in RunRequest.
Returned metadata if requested in the options.
Containers to hold repeated fundamental values.
Used in:
The canonical error codes for TensorFlow APIs. Warnings: - Do not change any numeric assignments. - Changes to this list should only be made if there is a compelling need that can't be satisfied in another way. Such changes must be approved by at least two OWNERS. Sometimes multiple error codes may apply. Services should return the most specific error code that applies. For example, prefer OUT_OF_RANGE over FAILED_PRECONDITION if both codes apply. Similarly prefer NOT_FOUND or ALREADY_EXISTS over FAILED_PRECONDITION.
Used in:
Not an error; returned on success
The operation was cancelled (typically by the caller).
Unknown error. An example of where this error may be returned is if a Status value received from another address space belongs to an error-space that is not known in this address space. Also errors raised by APIs that do not return enough error information may be converted to this error.
Client specified an invalid argument. Note that this differs from FAILED_PRECONDITION. INVALID_ARGUMENT indicates arguments that are problematic regardless of the state of the system (e.g., a malformed file name).
Deadline expired before operation could complete. For operations that change the state of the system, this error may be returned even if the operation has completed successfully. For example, a successful response from a server could have been delayed long enough for the deadline to expire.
Some requested entity (e.g., file or directory) was not found. For privacy reasons, this code *may* be returned when the client does not have the access right to the entity.
Some entity that we attempted to create (e.g., file or directory) already exists.
The caller does not have permission to execute the specified operation. PERMISSION_DENIED must not be used for rejections caused by exhausting some resource (use RESOURCE_EXHAUSTED instead for those errors). PERMISSION_DENIED must not be used if the caller can not be identified (use UNAUTHENTICATED instead for those errors).
The request does not have valid authentication credentials for the operation.
Some resource has been exhausted, perhaps a per-user quota, or perhaps the entire file system is out of space.
Operation was rejected because the system is not in a state required for the operation's execution. For example, directory to be deleted may be non-empty, an rmdir operation is applied to a non-directory, etc. A litmus test that may help a service implementor in deciding between FAILED_PRECONDITION, ABORTED, and UNAVAILABLE: (a) Use UNAVAILABLE if the client can retry just the failing call. (b) Use ABORTED if the client should retry at a higher-level (e.g., restarting a read-modify-write sequence). (c) Use FAILED_PRECONDITION if the client should not retry until the system state has been explicitly fixed. E.g., if an "rmdir" fails because the directory is non-empty, FAILED_PRECONDITION should be returned since the client should not retry unless they have first fixed up the directory by deleting files from it. (d) Use FAILED_PRECONDITION if the client performs conditional REST Get/Update/Delete on a resource and the resource on the server does not match the condition. E.g., conflicting read-modify-write on the same resource.
The operation was aborted, typically due to a concurrency issue like sequencer check failures, transaction aborts, etc. See litmus test above for deciding between FAILED_PRECONDITION, ABORTED, and UNAVAILABLE.
Operation tried to iterate past the valid input range. E.g., seeking or reading past end of file. Unlike INVALID_ARGUMENT, this error indicates a problem that may be fixed if the system state changes. For example, a 32-bit file system will generate INVALID_ARGUMENT if asked to read at an offset that is not in the range [0,2^32-1], but it will generate OUT_OF_RANGE if asked to read from an offset past the current file size. There is a fair bit of overlap between FAILED_PRECONDITION and OUT_OF_RANGE. We recommend using OUT_OF_RANGE (the more specific error) when it applies so that callers who are iterating through a space can easily look for an OUT_OF_RANGE error to detect when they are done.
Operation is not implemented or not supported/enabled in this service.
Internal errors. Means some invariant expected by the underlying system has been broken. If you see one of these errors, something is very broken.
The service is currently unavailable. This is a most likely a transient condition and may be corrected by retrying with a backoff. See litmus test above for deciding between FAILED_PRECONDITION, ABORTED, and UNAVAILABLE.
Unrecoverable data loss or corruption.
An extra enum entry to prevent people from writing code that fails to compile when a new code is added. Nobody should ever reference this enumeration entry. In particular, if you write C++ code that switches on this enumeration, add a default: case instead of a case that mentions this enumeration entry. Nobody should rely on the value (currently 20) listed here. It may change in the future.
Used in: ,
Specifies one or more fully independent input Examples. See examples at: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/example/example.proto
Used in:
Specifies one or more independent input Examples, with a common context Example. The common use case for context is to cleanly and optimally specify some features that are common across multiple examples. See example below with a search query as the context and multiple restaurants to perform some inference on. context: { feature: { key : "query" value: { bytes_list: { value: [ "pizza" ] } } } } examples: { feature: { key : "cuisine" value: { bytes_list: { value: [ "Pizzeria" ] } } } } examples: { feature: { key : "cuisine" value: { bytes_list: { value: [ "Taqueria" ] } } } } Implementations of ExampleListWithContext merge the context Example into each of the Examples. Note that feature keys must not be duplicated between the Examples and context Example, or the behavior is undefined. See also: tensorflow/core/example/example.proto https://developers.google.com/protocol-buffers/docs/proto3#maps
Used in:
Containers for non-sequential data.
Used in: ,
Each feature can be exactly one kind.
Containers for sequential data. A FeatureList contains lists of Features. These may hold zero or more Feature values. FeatureLists are organized into categories by name. The FeatureLists message contains the mapping from name to FeatureList.
Used in:
Used in:
Map from feature name to feature list.
Used in: ,
Map from feature name to feature.
Used in:
Used in: ,
Used in:
Used in:
Used in: ,
Used in: ,
Used in:
模型名
版本
请求总数:查询时刻之前的累加请求总数.
请求成功总数:查询时刻之前的累加请求成功总数.
请求失败总数:查询时刻之前的累加请求失败总数.
请求成功的总耗时:查询时刻之前的累加请求成功的总耗时(单位: ms)
请求成功次数 0~5ms
请求成功次数 5~10ms
请求成功次数 10~15ms
请求成功次数 >15ms
Used in:
Metadata for an inference request such as the model name and version.
Used in: , , , , , ,
Required servable name.
Optional choice of which version of the model to use. Recommended to be left unset in the common case. Should be specified only when there is a strong version consistency requirement. When left unspecified, the system will serve the best available version. This is typically the latest version, though during version transitions, notably when serving on a fleet of instances, may be either the previous or new version.
Use this specific version number.
Use the version associated with the given label. EXPERIMENTAL. DO NOT USE AT THIS TIME.
A named signature to evaluate. If unspecified, the default signature will be used.
Version number, state, and status for a single version of a model.
Used in:
Model version.
Model state.
Model status.
States that map to ManagerState enum in tensorflow_serving/core/servable_state.h
Used in:
Default value.
The manager is tracking this servable, but has not initiated any action pertaining to it.
The manager has decided to load this servable. In particular, checks around resource availability and other aspects have passed, and the manager is about to invoke the loader's Load() method.
The manager has successfully loaded this servable and made it available for serving (i.e. GetServableHandle(id) will succeed). To avoid races, this state is not reported until *after* the servable is made available.
The manager has decided to make this servable unavailable, and unload it. To avoid races, this state is reported *before* the servable is made unavailable.
This servable has reached the end of its journey in the manager. Either it loaded and ultimately unloaded successfully, or it hit an error at some point in its lifecycle.
Used as request type in: PredictionService.Classify, PredictionService.MultiInference, PredictionService.Predict, PredictionService.Regress
Used as response type in: PredictionService.Classify, PredictionService.MultiInference, PredictionService.Predict, PredictionService.Regress
Status that corresponds to Status in third_party/tensorflow/core/lib/core/status.h.
Used in: ,
Error code.
Error message. Will only be set if an error was encountered.