亚马逊AWS官方博客

Claude Code 接入自建开源模型:企业私有化与降本实践

摘要:企业使用 Claude Code 面临代码安全和成本压力双重挑战。本文介绍一套完整的解决方案:通过在 AWS SageMaker 上部署 Kimi/GLM 等开源模型,结合 LiteLLM Proxy实现智能路由,将支线任务分流到私有化模型处理。实测数据显示,单台 H200 部署成本约 $1000/天,相比等效 Claude API 调用成本降低约 70%,性价比提升 3.2倍。文章详细讲解架构设计、部署流程、动态路由策略及流式响应适配,提供可落地的企业级私有化方案


一、问题背景

Claude Code 是 Anthropic 推出的 AI 辅助编程工具,为开发者提供强大的代码生成、重构、问答等能力。其核心优势在于能够深度理解代码上下文,分析项目结构和代码依赖关系,提供精准的技术建议;支持多轮对话协作,逐步细化和迭代优化复杂任务;以及具备工具调用能力,可以执行 shell 命令、读写文件、搜索代码等操作。然而企业在实际使用 Claude Code 时面临两大核心痛点:

1.代码安全问题

默认情况下,Claude Code 需要将代码发送到云端 API 进行处理。对于金融、医疗、政务等对数据安全有严格要求的行业,这种方式存在明显风险:代码中可能包含商业机密、算法逻辑、业务规则,数据传输过程还可能涉及跨境合规问题。

2.成本压力

Claude系列模型的推理能力显著提升,能够处理更复杂的任务,企业员工发现越来越多的工作场景可以用 Claude Code 完成——从代码生成到文档撰写、从日志分析到数据处理。与此同时,企业内部正在大力推广”拥抱 AI”,鼓励所有员工使用 AI 工具提效,从最初的少数开发者试用到全员普及,Token 用量呈指数级增长。应用场景的爆发式增长导致 Token 使用量增长曲线异常陡峭。

从目前的态势看,Token 用量将保持高速持续增长,成本优化成为企业级应用的关键制约因素。

二、技术趋势观察

在企业级 AI 应用落地过程中,我们观察得到两点重要技术趋势:

Claude Code 作为 Agent Harness

Claude Code不仅仅作为一个Coding工具,通过Claude Agent SDK也可以构建通用的Agent平台。企业已经开始基于这种方式构建覆盖多个应用场景,包括数据分析,DevOps 自动化,原型生成等。使得Claude Code的应用范围更加广泛,针对的业务场景和任务难度层次更加多样化。

Litellm被广泛作为企业内部的大模型网管层

随着使用规模扩大,企业开始构建可审计、可管控的模型网管层。比较普遍的会采用Litellm作为网管层,它具备非常全面的模型供应商接入和模型使用管理能力,可以配置不同的用户权限,预算配额,模型范围,可以记录每次调用的输入输出、token 消耗、响应时间的审计日志,以及按部门、项目维度统计费用并设置预算告警的成本管理能力。在鲁棒性方面,Litellm的fallback机制也非常灵活,可以支持429限流/超时等问题引起的模型端点切换。

三、本文的解决方案

针对上述问题和观察到的技术趋势,本文提出的解决方案包括两个核心目标:

  • 私有化部署保障代码安全

通过在企业 VPC 内部署模型推理服务,确保代码不出内网。具体方案是在 Amazon SageMaker Endpoint上部署开源模型(GLM、Kimi 等),通过 LiteLLM Proxy 统一接入,对 Claude Code 透明,使得敏感项目的代码仅在 VPC 内流转,满足合规要求。

  • 任务动态路由优化成本

将 Claude Code 的任务分为主线和支线,差异化处理。主线任务(复杂推理、架构设计)路由到 Claude Sonnet 4.6 等顶级模型,支线任务(命令描述、条件判断)路由到私有化部署的开源模型,通过动态路由机制在保证效果的前提下降低综合成本。

3.1 Claude Code 企业内应用架构

在标准的企业应用场景中,Claude Code 通过 LiteLLM Proxy 统一对接后端模型服务,形成以下架构,它的优势在于提供统一接口,开发者使用 Claude Code 时无需关心后端模型差异;LiteLLM 支持 100+ 模型供应商,配置简单快速接入;MAAS 平台提供按需计费和自动扩展的弹性伸缩能力。但这种架构仍然存在代码外传和成本优化空间有限的问题。

本方案对参考架构进行了一些扩展, 如下图所示:

该架构添加了Task Router,它会区分主线任务与支线任务进行差异化处理:主线任务(复杂推理、架构设计)路由到 Claude Sonnet 4.6(Amazon Bedrock),支线任务(代码补全、命令描述)路由到 Kimi/GLM 等开源模型(Amazon SageMaker)。对于其他客户端(如问答、翻译、总结等任务),可直接路由到 SageMaker 上的开源模型,无需经过复杂的任务分类判断。

关于私有化的程度

需要说明的是,以上架构是一个混合私有化方案:支线任务在 VPC 内的 SageMaker 上处理,代码片段不出内网;主线任务仍路由到 Amazon Bedrock 上的 Claude Sonnet,代码会发送至外部。对于大多数企业,这一方案已可满足合规要求—— Amazon Bedrock 提供 VPC Endpoint 接入、数据不用于模型训练,具备 SOC2、ISO27001 等合规认证。

若业务有”代码零出境”的严格要求,可将主线任务也路由到 Amazon SageMaker 上能力更强的开源模型,代价是复杂推理任务的效果可能有所下降,需根据实际业务效果评估取舍。

3.2 实现过程

3.2.1 开源模型部署(SGLang on Amazon SageMaker)

本方案的核心是在 Amazon SageMaker Endpoint上部署开源 LLM,使用 SGLang 作为推理引擎。

Amazon SageMaker Endpoint 是 AWS 提供的托管 LLM 推理服务,提供弹性计算能力,支持 FTP(Flexible Training Plan)资源预留方式,内置监控、日志、指标采集能力。选择 SageMaker 的原因在于其灵活的计费模式(FTP 预留实例可降低 30-50% 成本),完整的监控能力(CloudWatch 集成自动采集推理延迟、吞吐量、错误率),托管运维特性(自动扩缩容、滚动更新、健康检查减少运维负担),企业级 SLA(99.9% 可用性保障适合生产环境),以及支持 VPC 内部署确保数据不出企业内网满足合规要求。

SGLang 是由 LMSYS 开发的 LLM 推理引擎,提供 RadixAttention、高效 KV Cache 管理、批处理优化等特性。选择 SGLang 的原因在于其原生实现了 Amazon SageMaker Inference API 规范无需额外适配,RadixAttention 技术大幅提升 prefix cache 命中率实现高吞吐优化,LMSYS 团队持续维护的活跃社区能够快速支持最新开源模型,且已在多个企业场景验证具备生产级稳定性。

大模型部署和推理调优的内容是一个独立的大话题,本文不展开详述,仅提供关键信息:

推荐模型选择: 根据支线任务的特点,推荐以下开源模型Kimi-K2.5/GLM-5作为支线任务的主力模型

部署工具: 使用claude-code-aws-skills/sglang-deploy低门槛部署SageMaker Endpoint

部署完成后,记录 SageMaker Endpoint 的名称(如 kimi-endpoint),后续在 LiteLLM 配置中使用。

3.2.2 LiteLLM Proxy 服务配置

LiteLLM Proxy 的核心配置文件如下, 把SageMaker Endpoint添加到model_list中。

# 全局设置
general_settings:
  store_model_in_db: true  # 记录模型调用信息
  store_prompts_in_spend_logs: true  # 记录完整 prompt 用于审计
  master_key: "sk-1234..."  # Proxy 访问密钥
 
# 路由器配置
router_settings:
  timeout: 180  # 请求超时时间(秒)
  stream_timeout: 1  # 流式响应超时
 
# 自定义 Callback Handler
litellm_settings:
  callbacks:
    - "stream_anthropic_schema_fixer.hook" # Schema 修复 Hook
    - "dynamic_tagging_handler.proxy_handler_instance" # 动态路由 Hook
  verbose: true  # 开启详细日志
 
# 模型列表
model_list:
  # SageMaker 部署的开源模型
  - model_name: sagemaker-kimi-2-5
    litellm_params:
      model: sagemaker-chat/<sagemaker-endpoint>
      aws_region_name: us-east-1
      timeout: 180
      max_tokens: 8192
      drop_params: true  # 移除 SageMaker 不支持的参数
  # AWS Bedrock 上的 Claude 模型
  - model_name: bedrock-claude-sonnet46
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-4-6-v1:0
      aws_region_name: us-west-2
      timeout: 300

其中的callbacks部分注册了2个自定义 Hook,是方案的核心部分,后续章节会详细说明。

Litellm 可以通过Docker Compose 一键容器化部署。docker-compose中可以使用litellm的官方镜像,然后把Mount hook脚本到指定路径。如下docker-compose.yaml 可供参考:

# docker-compose.yml
services:
  litellm:
    image: ghcr.io/berriai/litellm:v1.82.3-stable
    restart: always
    volumes:
      - ./config.yaml:/app/config.yaml
      - ./stream_anthropic_schema_fixer.py:/app/stream_anthropic_schema_fixer.py:ro
      - ./dynamic_tagging_handler.py:/app/dynamic_tagging_handler.py:ro
    command:
      - "--config=/app/config.yaml"
    ports:
      - "8080:4000"
    environment:
      DATABASE_URL: "postgresql://llmproxy:dbpassword9090@db:5432/litellm"
      STORE_MODEL_IN_DB: "True"
      ENABLE_ANTHROPIC_SCHEMA_FIX: "true"
    env_file:
      - .env  # 存放 AWS credentials
    depends_on:
      - db
 …

3.2.3 Claude Code 对接配置

Claude Code 通过环境变量指定Litellm Proxy Server,可以创建以下shell alias:

alias cc_proxy="ANTHROPIC_API_KEY=<litellm_virtual_key> \
ANTHROPIC_BASE_URL=http://litellm-alb-2-313999498.us-east-1.elb.amazonaws.com \
ANTHROPIC_DEFAULT_OPUS_MODEL=bedrock-claude-opus46 \
ANTHROPIC_DEFAULT_SONNET_MODEL=bedrock-claude-sonnet46 \
ANTHROPIC_DEFAULT_HAIKU_MODEL=bedrock-claude-haiku45 \
CLAUDE_CODE_SUBAGENT_MODEL=bedrock-claude-sonnet45 \
claude"

配置说明:

  • ANTHROPIC_BASE_URL:指向 LiteLLM Proxy 的 服务地址
  • ANTHROPIC_DEFAULT_*_MODEL:映射到 LiteLLM config.yaml 中定义的 model_name

配置完成后,运行 cc_proxy 即可启动对接 LiteLLM 的 Claude Code 会话。

3.2.4 动态任务路由Hook

智能路由的前提是对Claude Code 任务进行拆分,通过对Claude Code执行过程的拆解,它并不是单一串行的大模型调用。它在执行任务时,会将工作分解为主线任务和支线任务。

主线任务是用户直接发起的、需要深度推理的核心工作,例如代码重构与架构设计、复杂 bug 的排查与修复、技术选型与方案评审等。

支线任务是在执行主线任务过程中 Claude Code 自动触发的辅助工作,主要包括文本生成类(会话标题生成、Bash 命令描述生成、操作总结)、预测/建议类(下一步建议)、判断/评估类(Hook 条件评估)、内容处理类(网页摘要)等。

其中支线任务是可以切换到其他开源模型进行处理的,但是主线任务不行。首先两者对 Prompt Cache 依赖性不同。主线任务依赖完整的上下文,切换模型会导致 cache 失效;而支线任务通常是独立的、短上下文任务,cache 命中率本身就低。从推理复杂度来看,主线任务需要顶级模型的深度推理能力,支线任务则可以用较小模型处理从而降低成本。

案例:Hook 条件评估任务

agent-prompt-hook-condition-evaluator 为例,这个system prompt主要判断是否要启动一个SubAgent,这是典型的支线任务:

[System Prompt]:
You are evaluating a hook in Claude Code.
Your response must be a JSON object matching one of the following schemas:
1. If the condition is met, return: {"ok": true}
2. If the condition is not met, return: {"ok": false, "reason": "Reason for why it is not met"}

这种任务具有输入输出格式固定(JSON)、上下文长度短、推理逻辑简单(模式匹配)、对响应速度要求高等特征,使用开源模型即可满足需求,无需调用类似Claude Sonnet等更高级智能水平的模型。

Litellm提供了自定义 Callback Handler机制,可以根据 Message 特征动态修改目标模型,核心实现如下:

# dynamic_tagging_handler.py
from litellm.integrations.custom_logger import CustomLogger
import litellm
class DynamicRoutingHandler(CustomLogger):
    def log_pre_api_call(self, kwargs, response_obj, start_time, end_time):
        """在 API 调用前拦截请求,修改路由目标"""
        # 1. 提取所有 message 的文本内容
        messages = kwargs.get("messages", [])
        full_text = self._extract_all_text(messages)
        # 2. 检测是否为 Hook 条件评估任务
        if self._is_hook_evaluator_prompt(full_text):
            print(f"[DynamicRouting] Detected hook evaluator prompt, routing to sagemaker-kimi-2-5")
            kwargs["model"] = "sagemaker-kimi-2-5"
        return kwargs
    def _extract_all_text(self, messages):
        """提取消息中的所有文本(支持多模态消息)"""
        text_parts = []
        for msg in messages:
            content = msg.get("content", "")
            if isinstance(content, str):
                text_parts.append(content)
            elif isinstance(content, list):
                # 处理多模态消息(文本 + 图片)
                for block in content:
                    if block.get("type") == "text":
                        text_parts.append(block.get("text", ""))
        return " ".join(text_parts)
    def _is_hook_evaluator_prompt(self, text):
        """检测是否为 Hook 条件评估 Prompt"""
        # 特征字符串列表
        markers = [
            "You are evaluating a hook in Claude Code",
            "hook condition",
            "Return your evaluation as a JSON object",
            '"satisfied": true'
        ]
        # 至少匹配 3 个特征才认为是该任务(避免误判)
        match_count = sum(1 for marker in markers if marker in text)
        return match_count >= 3
# 注册 Handler
proxy_handler_instance = DynamicRoutingHandler()

log_pre_api_call 是核心的callback函数,在 LiteLLM 调用后端模型之前触发。_is_hook_evaluator_prompt 通过关键字匹配识别任务类型(采用多特征阈值机制避免误判)。以上代码仅仅是一个示例,可以继续添加更多任务类型的检测逻辑:

def _detect_task_type(self, text, messages):
    """综合判断任务类型"""
    if self._is_hook_evaluator(text):
        return "sagemaker-kimi-2-5"
    elif self._is_session_title_generator(text):
        return "sagemaker-kimi-2-5"
    elif self._is_bash_description_writer(text):
        return "sagemaker-kimi-2-5"
    elif len(text) > 10000:  # 长文本任务
        return "bedrock-claude-sonnet46"
    else:
        return None  # 保持原始模型

完整代码可见附件。

3.2.5 Streaming Schema 对齐问题

Claude Code 默认使用 streaming 模式 与模型交互,实时展示生成内容并支持中途打断。然而,在对接开源模型时,会遇到一个兼容性挑战。

核心问题:Claude Code 仅保证 Claude 模型兼容

Claude Code 的版本迭代速度极快,其流式响应解析器完全针对 Anthropic Messages API 设计,期望严格的 schema 结构。当通过 LiteLLM 对接开源模型时,由于多数推理引擎基于 OpenAI API 标准,在格式转换过程中会出现字段映射不完整(如 cache_creation_input_tokensusage 对象缺失)。这个问题不仅限于LiteLLM的SageMaker provider,任意方式部署的开源模型都可能遇到。
因此,我们需要一个通用且非侵入式的 schema 修复机制 —— 在不修改 LiteLLM 源码的前提下,通过 callback hook 在响应流转过程中动态补齐缺失字段,确保 Claude Code 能够正常解析。LiteLLM 提供了 async_post_call_streaming_iterator_hook,允许在流式响应返回给客户端之前,逐chunk 修复 schema。

核心实现思路

1. 拦截 LiteLLM 返回的 SSE 事件流

2. 解析每个事件的 JSON 数据

3. 根据事件类型(message_start / message_delta / message_stop)补充缺失字段

4. 重新编码为 SSE 格式并转发

核心逻辑如下,完整代码见附录链接:

# stream_anthropic_schema_fixer.py
from litellm.integrations.custom_logger import CustomLogger
class AnthropicSchemaFixerHook(CustomLogger):
    async def async_post_call_streaming_iterator_hook(
        self,
        user_api_key_dict,
        response: AsyncGenerator,
        request_data: dict
    ) -> AsyncGenerator:
        """拦截流式响应,逐 chunk 修复 schema"""
        last_usage: Optional[Dict[str, Any]] = None
        chunk_count = 0
        async for chunk in response:
            chunk_count += 1
            # Pass through non-bytes chunks
            if not isinstance(chunk, bytes):
                yield chunk
                continue
            try:
                # Decode SSE format: "event: xxx\ndata: {...}\n\n"
                decoded = chunk.decode("utf-8")
                # Check if this is an SSE event with data
                if not decoded.startswith("event:") and not decoded.startswith("data:"):
                    yield chunk
                    continue
                # Parse SSE format
                event_type, data_json = self._parse_sse(decoded)
                # Apply fixes based on event type
                modified = False
                if event_type == "message_start":
                    modified = self._fix_message_start(data_json)
                elif event_type == "message_delta":
                    delta_modified, usage = self._fix_message_delta(data_json)
                    modified = delta_modified
                    # Track usage for message_stop
                    if usage:
                        last_usage = usage
                elif event_type == "message_stop":
                    modified = self._fix_message_stop(data_json, last_usage)
                # Re-encode if modified
                if modified:
                    yield self._rebuild_sse(event_type, data_json)
                else:
                    yield chunk
            except Exception as e:
                yield chunk
# 实例化并注册
hook = AnthropicSchemaFixerHook()

具体的配置方式请参见 3.2.2 节,重点关注 callbacks 的注册和 docker-compose 中的环境变量设置。修复后,Claude Code 可以正常解析流式响应,避免 fallback 到非流式模式。对于Coding场景,非流式接口可能会导致SageMaker出现60s timeout问题。

四、总结与展望

通过本文介绍的架构,企业可以在使用 Claude Code 时获得显著优势。在安全性方面,LiteLLM Proxy 和 Amazon SageMaker Endpoint 均部署在企业内网,敏感代码仅在 VPC 内流转,满足金融、医疗等行业的严格合规要求,同时可审计的模型调用链路确保所有请求日志本地存储。在成本控制方面,以单台 H200 理想情况下满负荷运行为例,部署 Kimi-K2.5 的日均成本约为 $1000;等效工作量(1000 output tokens/s,cache 命中率 80%)若调用 Claude Haiku 4.5 API,日均成本约为 $3200。性价比提升最大空间约为 3.2 倍。

目前Kimi-2.5/GLM-5等新一代模型的代码能力已逐渐接近头部闭源模型的水平, 随着开源模型能力的持续提升,这意味着未来更多任务可能下沉到开源模型处理,私有化部署的优势将更加明显。与此同时企业内 Token 用量持续高速增长,私有化部署为大规模高并发使用打开了成本优化空间,为企业构建更加自主可控的AI 基础设施提供支撑。

➡️ 下一步行动:

相关产品:

相关文章:

五、附录

相关链接

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营,具体信息以中国区域官网为准。

本篇作者

李元博

亚马逊云科技 AI/ML GenAI 解决方案架构师,专注于 AI/ML 特别是 GenAI 场景落地的端到端架构设计和业务优化。在互联网行业工作多年,在用户画像、精细化运营、推荐系统、大数据处理方面有丰富的实战经验。

王泽耀

亚马逊云科技解决方案架构师,面向国内大型企业品牌出海,致力于亚马逊云科技云服务在国内的应用及推广。曾就职于 IBM,服务国内不同行业企业客户。


AWS 架构师中心:云端创新的引领者

探索 AWS 架构师中心,获取经实战验证的最佳实践与架构指南,助您高效构建安全、可靠的云上应用