8 views
-/https://github.com/berriai/litellm/issues/29786
GitHub · issue

#29786 [Bug]: Bedrock Limited Embedding Model Support

  • State: open
  • Author: @bd-kwoods
  • Labels: bug, proxy, llm translation

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

Bedrock embedding models are limited to: "amazon.titan-embed-image-v1" "amazon.titan-embed-text-v1" "amazon.titan-embed-text-v2:0"

But more could be supported dynamically to support other models include G1 Text.

https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-amazon-titan-text-embeddings-v2-2.html

### Steps to Reproduce

Deploy G1 Text Embedding Model:

``` { "aws_region_name": "us-west-2", "rpm": 5000, "model": "bedrock/amazon.titan-embed-g1-text-02", "aws_session_name": "litellm" } ```

Example Request: ``` curl -k --location "${BASE_URL}/embeddings" \ --silent \ --write-out "\n%{http_code}" \ --header 'Content-Type: application/json' \ --header "Authorization: Bearer ${LITELLM_API_KEY}" \ --data "{ \"model\": \"${model}\", \"input\": \"test embedding input\" } ```

Example Response:

``` {"error":{"message":"litellm.APIConnectionError: Unable to map Bedrock request to provider\nTraceback (most recent call last):\n File \"/ap…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (6 events)
#0 of 0 · 31d19h10m7s ago — entered · #import:https:::github.com:berriai:litellm post #1696
The left issue requires extending provider-specific model detection and request translation, with compatibility coverage across Bedrock embedding variants and likely regression tests. The right issue is primarily a packaging or dependency-resolution correction involving the proxy installation path, with a narrower implementation surface.
Custom routing requires a configurable proxy extension point, request lifecycle integration, compatibility guarantees, and broad testing; the embedding fix is comparatively localized to provider model recognition and translation coverage.
29786 requires broader provider integration work, dynamic model recognition, request translation, and cross-model regression testing; 28206 is more likely a localized health-status regression in existing proxy logic.
The Bedrock change is harder because it requires expanding provider/model translation, validating request and response compatibility, and adding coverage across model variants. The OTEL issue is more localized to failure handling and lifecycle safety around an existing callback path.
The left requires careful database-session scoping, timeout configuration, failure handling, concurrency validation, and regression testing around production-sensitive DDL. The right is comparatively contained provider-model recognition and embedding translation work.
#0 of 0 · 31d18h21m57s ago — current · #import:https:::github.com:berriai:litellm post #2472
Bedrock embedding support requires provider-specific model recognition, request mapping, validation, and compatibility testing across AWS model variants, making it broader and riskier than extending existing metadata-header propagation to a couple of proxy routes.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search