生成式 AI 定制光谱：从提示工程到 AWS 上的自定义模型

本文将说明如何为你的工作负载选择合适的生成式 AI 定制方法，避免过度工程或投入不足。

AWS 通过 Amazon Bedrock 提供对 Anthropic、Meta、Mistral 和 Amazon 基础模型的访问，以及构建从聊天机器人、代码助手到文档处理器和自主 Agent 等各种应用所需的基础设施。模型已经具备可用性。更困难的问题是：针对你的特定问题，应该如何使用这些模型。

能够访问 Anthropic Claude、Amazon Nova 或 Llama，并不意味着你天然知道如何让它们适用于自己的具体用例。你应该写出更好的提示词？通过检索增强生成（Retrieval Augmented Generation，RAG）接入自己的文档？进行微调？还是从头训练？选项太多会造成决策瘫痪，而选错方案的代价很高。

团队经常在一个结构良好的提示词本可在一下午解决问题时，直接跳到微调。另一些团队则在提示工程上停滞数周，尽管其用例显然需要领域专属训练数据。这两类错误都会造成真实的计算成本、上线延期带来的时间成本，以及当模型输出无法获得利益相关者认可时的信誉损失。

本文提供一套 8 步决策框架，即 AWS 上的生成式 AI 定制光谱。阅读后，你将了解哪种方法适合自己的用例、成本如何、需要多少数据，以及何时应升级到下一层级。核心原则是：从最简单的方法开始，只有在确有必要时才深入。

解决方案概览

定制光谱：从最简单到最复杂的可视化阶梯： 并非每个生成式 AI 问题都需要相同程度的投入。定制光谱是一道阶梯，每上升一步，所需工作量、成本和数据要求都会增加，但你获得的控制力和领域专属性也会随之提高。

图 1：生成式 AI 定制光谱，从直接使用模型到训练自定义模型

该光谱可分为三类：

使用（USE）： 不改动模型，只改变与模型沟通的方式。第 1 至 2 步：直接使用现有模型，或通过系统指令、少样本示例和思维链推理改进提示词。当你从一个提示词扩展到生产工作负载中的数百个提示词时，可以使用提示词评估，根据准确性和稳健性指标衡量提示词质量。提示词优化可自动重写提示词，使其在所选模型上表现更好，从而消除流程中的人工试错。

增强（ENHANCE，驾驭模型）： 在模型周边增加能力，模型权重保持冻结。第 3 至 5 步：利用你的文档为模型提供依据（RAG）、缓存高成本提示词，或将大模型的知识蒸馏到更小、更快的模型中。这正是业界所谓的“驾驭（harnessing）”模型：使用外部工具、数据源和优化方案包装模型，同时不改变其权重。

训练（TRAIN）： 改变模型本身。第 6 至 8 步：使用标注数据更新权重（微调）、用海量无标注语料扩展基础知识（持续预训练），或从头构建完全自定义的模型（Amazon Nova Forge）。

规则是：从第 1 步开始。只有当前步骤无法满足准确性、延迟或领域要求时，才向上升级。大多数工作负载永远不需要超过第 3 步。

架构概览：AWS 服务映射

下图将光谱中的每个步骤映射到相应支持它的 AWS 服务。

图 2：光谱中每一步如何映射到 Amazon Bedrock、Amazon SageMaker 和 Amazon Nova Forge

决策流程

下图总结了从一个步骤升级到下一个步骤时应关注的升级信号。

图 3：各步骤的升级信号，从直接使用到 Amazon Nova Forge

类比：厨师的厨房

厨师类比很有效，因为它提供了一个贯穿全部八个步骤的单一主角（厨师即模型）。它也让升级成本一目了然：写出更精准的点单要求无需成本，而把厨师送去烹饪学校则意味着数月投资以及厨房产出的损失。对于蒸馏，可以这样理解：“主厨的品鉴菜单无可挑剔，但每道菜要花 45 分钟，食材成本也高得惊人。把三款最畅销菜教给线厨，让他们在 10 分钟内以三分之一的成本出餐。”这直接对应蒸馏的权衡：针对你已验证的特定任务，较小的学生模型以更快速度和更低成本复现教师模型的输出。

图 4：定制光谱的厨师类比

技术拆解：光谱的 8 个步骤

以下各节依次介绍每个步骤：其作用、适用场景，以及提示你应升级到下一步的信号。

第 1 步：直接使用现有模型（Amazon Bedrock：Claude、Nova、OpenAI、Llama）

通过 Amazon Bedrock 直接调用基础模型（FM），无需任何定制。可通过单一 API 从 Claude、Amazon Nova、Llama、Mistral 等模型中进行选择。关于不同 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中的 Supported models by AWS Region。

何时使用： 适用于摘要、翻译、头脑风暴和代码生成等通用任务，且可接受现成模型的准确性。不需要训练数据，也无需进行设置，只需一次 API 调用。

何时升级： 输出过于泛化、格式错误，或未遵循你的领域惯例。

真实案例：

• Dovetail：使用 Amazon Bedrock 且无需模型定制，在一天内完成原型开发，并在仅两周内发布新的生成式 AI 功能。

第 2 步：提示工程与上下文学习（系统提示词、少样本、思维链）

通过系统提示词、少样本示例和思维链推理，优化你向模型下达指令的方式，而不改变模型权重。

何时使用： 模型具备所需知识，但需要在格式、语气或推理路径方面获得引导。这适用于绝大多数用例。

何时升级： 提示词长度超过约 2,000 个 token、模型仍在幻觉生成领域专属事实，或者需要模型并不具备的知识。

构建有效的提示词

为了充分发挥 Amazon Bedrock 上提示工程的效果，应使用五个构建模块组织每个提示词：清晰的指令（使用动作动词并明确范围）、充分的上下文（当前状态、依赖关系、约束条件）、具体要求（功能性和非功能性要求）、输出格式（仅代码、分步说明、对比）以及质量指标（预期行为、边界情况、性能目标）。

一个常见错误是堆砌指令，或在缺乏明确性的情况下倾倒上下文。相反，应让提示词细节与任务复杂度相匹配。快速任务只需要最少的上下文，而复杂的功能需求则需要全面的规格说明。

真实案例：

第 3 步：检索增强生成（RAG）

使用 Amazon Bedrock Knowledge Bases 这一全托管 RAG 功能，在推理时为模型提供外部知识。模型生成的答案将以你的数据为依据，无需重新训练即可减少幻觉。

何时使用： 模型需要访问私有、频繁更新或领域专属的数据，例如内部文档、政策和产品目录。

何时升级： 检索延迟超出要求、上下文窗口溢出，或模型仍无法对检索内容进行正确推理。

真实案例：

• Fractal Analytics：使用 Amazon Bedrock 和 RAG 为呼叫中心 Agent 构建统一知识库，实现通话处理时间缩短 10% 至 15%、30% 的来电分流，以及每月超过 20 万次查询。
• EXL：借助 Amazon Bedrock 上由 RAG 驱动的虚拟助手处理和评估大量文档，将保险核保成本降低了 80%。

参考资料：Guidance for Building Custom Chatbots Using RAG on Amazon Bedrock

第 4 步：提示词缓存与上下文优化（降低重复查询的延迟和成本）

对常用提示词前缀（系统指令、少样本示例、大型上下文）进行预处理和缓存，使重复查询跳过冗余计算。在不改变输出质量的前提下，降低延迟和成本。

何时使用： 高流量、重复性查询且共享上下文的场景。例如，客户支持机器人、文档问答，以及使用相同系统提示词的代码助手。

何时升级： 当仅靠缓存无法解决模型规模或成本问题，而你需要一款能提供相同质量、更小且更便宜的模型时。

真实案例：

• inGenious.ai：测试并验证了多个大语言模型（LLM），在不牺牲理解能力的前提下实现了不足 1 秒的聊天机器人响应；借助 Amazon Nova，聊天机器人的理解能力提升了 80%。

参考资料：Effectively use prompt caching on Amazon Bedrock

第 5 步：模型蒸馏（训练更小的模型模仿更大的模型）

将知识从较大的“教师”模型迁移到较小的“学生”模型。学生模型学习针对特定用例复现教师模型的输出，以一小部分成本和延迟提供近乎相同的质量。

何时使用： 你已使用大模型验证了质量，但需要更低成本、更快速度，或需要在边缘侧部署。根据 Amazon Bedrock Model Distillation 于 2025 年 5 月发布的正式可用公告，Amazon Bedrock Model Distillation 生成的学生模型速度最高可提升 500%，成本最高可降低 75%，准确性损失低于 2%。

何时升级： 蒸馏模型无法匹配所需的语气、格式或推理风格，这意味着需要通过微调直接更新模型权重。

真实案例：

• Goodnotes：将其 AI 驱动的“Ask Goodnotes”功能从 Amazon Elastic Kubernetes Service（Amazon EKS）上的自托管模型迁移至 Amazon Bedrock 上的 Anthropic Claude，以提高可扩展性和成本效益。

参考资料：Amazon Bedrock Model Distillation

第 6 步：微调

使用标注数据（输入—输出对）更新模型权重，以永久改变模型的行为、风格或领域准确性。可采用适用于较小数据集的参数高效微调（PEFT/LoRA），或采用用于全面更新的全量微调（Full Fine-Tuning）。

何时使用： 在提示工程和 RAG 之后，模型的语气、格式或任务专属推理仍不匹配。你拥有数千个展示预期行为的标注示例。

何时升级： 模型不理解领域术语或概念。它需要的是基础知识，而不仅是行为调整。

真实案例：

• Trellix（网络安全）：使用 Amazon Bedrock 和 Anthropic Claude 构建生成式 AI 安全工具。他们针对网络安全集成微调模型，每项集成节省超过 40 小时的开发时间，并将新安全集成的上市时间缩短了 90%。

强化微调（RFT）：标准微调（SFT）要求你为希望模型学习的每一种行为提供黄金标准的标注输入—输出对。对于代码生成、结构化输出准确性和多步骤推理等任务，手工创建这些完美示例成本高昂，而且通常并不现实，因为验证正确性远比演示正确做法便宜。RFT 通过让你定义一个为输出评分的奖励函数来解决这一问题，模型学习针对该信号进行优化。若没有托管基础设施，实现 RFT 需要构建自定义训练循环、管理 GPU 集群，并在策略

This post shows you how to pick the right generative AI customization approach for your workload without over-engineering or under-investing.

AWS provides access to foundation models from Anthropic, Meta, Mistral, and Amazon through Amazon Bedrock, along with the infrastructure to build everything from chatbots and code assistants to document processors and autonomous agents. The models are available. The harder question is what to do with them for your specific problem.

Having access to Anthropic Claude, Amazon Nova, or Llama does not automatically mean you know how to make them work for your specific use case. Should you write a better prompt? Plug in your documents with Retrieval Augmented Generation (RAG)? Fine-tune? Train something from scratch? The number of options creates decision paralysis, and choosing wrong is expensive.

Teams often jump straight to fine-tuning when a well-structured prompt would have solved the problem in an afternoon. Other teams stay stuck on prompt engineering for weeks when their use case clearly needs domain-specific training data. Both mistakes cost real money in compute, real time in delayed launches, and real credibility when model outputs do not land with stakeholders.

This post gives you an 8-step decision framework, the generative AI customization spectrum on AWS. You will walk away knowing which approach fits your use case, what it costs, how much data you need, and when to escalate to the next level. The core principle: start with the simplest approach and go deeper only when you must.

Solution overview

The customization spectrum, a visual staircase from simplest to most complex: Not every generative AI problem needs the same level of investment. The customization spectrum is a staircase where each step increases in effort, cost, and data requirements, but also in the degree of control and domain specificity you gain.

Figure 1: The generative AI customization spectrum, from using a model as-is to training a custom model

The spectrum breaks into three categories:

USE: Don’t touch the model. Change how you talk to it. Steps 1–2: Use existing models as-is, or improve your prompts with system instructions, few-shot examples, and chain-of-thought reasoning. As you scale from one prompt to hundreds across production workloads, you can use prompt evaluation to measure prompt quality against accuracy and robustness metrics. Prompt optimization automatically rewrites prompts to perform better on your chosen model, removing manual trial-and-error from the process.

ENHANCE (harness the model): Add things around the model. Weights stay frozen. Steps 3–5: Ground the model with your documents (RAG), cache expensive prompts, or distill a large model’s knowledge into a smaller, faster one. This is what the industry calls “harnessing” a model: wrapping it with external tools, data sources, and optimizations while leaving its weights untouched.

TRAIN: Change the model itself. Steps 6–8: Update weights with your labeled data (fine-tuning), expand foundational knowledge with massive unlabeled corpora (continued pre-training), or build a fully custom model from scratch (Amazon Nova Forge).

The rule: start at Step 1. Move up only when the current step fails your accuracy, latency, or domain requirements. Most workloads never need to go past Step 3.

Architecture overview: AWS service mapping

The following diagram maps each step of the spectrum to the AWS services that support it.

Figure 2: How each step of the spectrum maps to Amazon Bedrock, Amazon SageMaker, and Amazon Nova Forge

Decision flow

The following diagrams summarize the escalation signals that tell you when to move from one step to the next.

Figure 3: Escalation signals for each step, from as-is use through Amazon Nova Forge

Analogy: The chef’s kitchen

The chef analogy works well because it gives you a single protagonist (the chef is the model) to follow through all eight steps. It also makes the escalation cost obvious: writing sharper orders costs nothing, while sending a chef to culinary school costs months of investment and lost kitchen output. For distillation: “The head chef’s tasting menu is flawless but takes 45 minutes per plate and costs a fortune in ingredients. Teach the line cook the three bestsellers, serve them in 10 minutes at a third of the cost.” That maps directly to the distillation tradeoff: a smaller student model replicating the teacher’s outputs faster and cheaper for the specific tasks you have validated.

Figure 4: The chef’s analogy for the customization spectrum

Technical breakdown: the 8 steps of the spectrum

The following sections cover each step in order: what it does, when to use it, and the signal that tells you to escalate to the next step.

Step 1: Using existing models as-is (Amazon Bedrock: Claude, Nova, OpenAI, Llama)

Call a foundation model (FM) directly through Amazon Bedrock with zero customization. Choose from Claude, Amazon Nova, Llama, Mistral, and others through a single API. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock.

When to use: General-purpose tasks like summarization, translation, brainstorming, and code generation where off-the-shelf accuracy is acceptable. No training data needed, no setup required, only an API call.

When to progress: Output is too generic, wrong format, or doesn’t follow your domain conventions.

Real-world examples:

• Dovetail: Creates prototypes within a day and releases new generative AI features in only two weeks using Amazon Bedrock with no model customization.

Step 2: Prompt engineering and in-context learning (system prompts, few-shot, chain-of-thought)

Optimize how you instruct the model with system prompts, few-shot examples, chain-of-thought reasoning, without changing model weights.

When to use: The model has the knowledge but needs guidance on format, tone, or reasoning path. This works for the majority of use cases.

When to progress: Prompt exceeds approximately 2,000 tokens, still hallucinating domain-specific facts, or requires knowledge the model doesn’t have.

Structuring effective prompts

To get the most out of prompt engineering on Amazon Bedrock, structure every prompt using five building blocks: clear instructions (use action verbs and specify scope), sufficient context (current state, dependencies, constraints), specific requirements (functional and non-functional), output format (code only, step-by-step, comparison), and quality indicators (expected behavior, edge cases, performance targets).

A common mistake is overloading instructions or dumping context without specificity. Instead, scale your prompt detail to the task complexity. Quick tasks need minimal context, while complex feature requests demand comprehensive specifications.

Real-world examples:

Step 3: Retrieval-augmented generation (RAG)

Supply the model with external knowledge at inference time using Amazon Bedrock Knowledge Bases, the fully managed RAG capability. The model generates answers grounded in your data, reducing hallucinations without retraining.

When to use: The model needs access to private, frequently updated, or domain-specific data (internal docs, policies, product catalogs).

When to progress: Retrieval latency exceeds requirements, context window overflows, or the model still can’t reason correctly over retrieved content.

Real-world examples:

• Fractal Analytics: Built a unified knowledge base for call center agents using Amazon Bedrock and RAG, achieving 10–15 percent reduction in call handling time, 30 percent call deflection, and 200K+ monthly queries.
• EXL: Reduced insurance underwriting costs by 80 percent using a RAG-powered virtual assistant on Amazon Bedrock that processes and evaluates extensive documents.

Reference: Guidance for Building Custom Chatbots Using RAG on Amazon Bedrock

Step 4: Prompt caching and context optimization (reducing latency and cost for repeated queries)

Pre-process and cache frequently used prompt prefixes (system instructions, few-shot examples, large context) so repeated queries skip redundant computation. Reduce latency and cost without changing output quality.

When to use: High-volume, repetitive queries with shared context. For example, customer support bots, document Q&A, code assistants hitting the same system prompt.

When to progress: You need a smaller, cheaper model that delivers the same quality, when caching alone can’t solve the model size/cost problem.

Real-world example:

• inGenious.ai: Tested and validated multiple large language models (LLMs) to achieve chatbot responses in less than 1 second without sacrificing comprehension, improving chatbot comprehension by 80 percent using Amazon Nova.

Reference: Effectively use prompt caching on Amazon Bedrock

Step 5: Model distillation (training smaller models to mimic larger ones)

Transfer knowledge from a larger “teacher” model to a smaller “student” model. The student learns to replicate the teacher’s outputs for your specific use case, delivering near-identical quality at a fraction of the cost and latency.

When to use: You’ve validated quality with a large model but need it cheaper, faster, or deployable at the edge. Amazon Bedrock Model Distillation produces student models that are up to 500 percent faster and up to 75 percent less expensive than the teacher, with less than 2 percent accuracy loss (per the Amazon Bedrock Model Distillation general availability announcement, May 2025).

When to progress: The distilled model can’t match the tone, format, or reasoning style you need, which means the model’s weights need direct updating through fine-tuning.

Real-world example:

• Goodnotes: Transitioned from a self-hosted model on Amazon Elastic Kubernetes Service (Amazon EKS) to Anthropic Claude on Amazon Bedrock to improve scalability and cost-effectiveness for its AI-powered “Ask Goodnotes” feature.

Reference: Amazon Bedrock Model Distillation

Step 6: Fine-tuning

Update model weights using your labeled data (input-output pairs) to permanently change the model’s behavior, style, or domain accuracy. Available as Parameter-Efficient Fine-Tuning (PEFT/LoRA) for smaller datasets or Full Fine-Tuning for comprehensive updates.

When to use: Tone, format, or task-specific reasoning doesn’t match after prompt engineering and RAG. You have thousands of labeled examples showing desired behavior.

When to progress: The model doesn’t understand domain terminology or concepts. It needs foundational knowledge, not only behavioral adjustment.

Real-world example:

• Trellix (Cyber security): Built generative AI security tools using Amazon Bedrock and Anthropic Claude. They fine-tuned models for cyber security integration, saving over 40 hours of development time per integration and achieving a 90% reduction in time-to-market for new security integrations.

Reinforcement fine-tuning (RFT): Standard fine-tuning (SFT) requires you to produce gold-standard labeled input-output pairs for every behavior you want the model to learn. For tasks like code generation, structured output accuracy, and multi-step reasoning, creating these perfect examples by hand is expensive and often impractical, because verifying correctness is far cheaper than demonstrating it. RFT solves this by letting you define a reward function that scores outputs, and the model learns to optimize against that signal. Without managed infrastructure, implementing RFT requires building custom training loops, managing GPU clusters, and orchestrating reward model serving alongside policy training. Amazon Bedrock makes this accessible as a fully managed service: you supply prompts (up to 20,000 per job) and a scoring function, and Bedrock handles the reinforcement learning pipeline end-to-end. RFT became available for Amazon Nova models in December 2025 and expanded to open-weight models including OpenAI GPT OSS 20B and Qwen 3 32B in February 2026. For a complete implementation walkthrough, see Reinforcement fine-tuning on Amazon Bedrock with OpenAI-Compatible APIs on the AWS Machine Learning Blog (March 2026).

Reference: Amazon Bedrock fine-tuning

Data requirements:

Method	Data needed
PEFT	Few thousand labeled examples
Full Fine-Tuning	Tens of thousands of labeled examples
DPO – Direct Preference Optimization	Pairs of preferred/non-preferred responses

Direct Preference Optimization (DPO) aligns model outputs with human preferences by training directly on pairs of preferred and non-preferred responses, alleviating the need for a separate reward model. For implementation details, see Customize Amazon Nova in Amazon SageMaker AI using Direct Preference Optimization.

Step 7: Continued pre-training (massive unlabeled domain corpus)

Expand the model’s foundational knowledge by training on large volumes of unlabeled, domain-specific data (documents, transcripts, code, research papers). This is self-supervised learning where the model learns your domain’s language, concepts, and relationships at a fundamental level.

When to use: The model doesn’t understand your domain terminology even after fine-tuning. You have massive proprietary corpora (1B+ tokens) that represent knowledge no public model has seen.

The historic challenge with continued pre-training (CPT) is catastrophic forgetting: training on domain-specific data improves domain performance while degrading general reasoning, instruction following, and safety alignment. Amazon Nova Forge addresses this with data mixing, which blends your proprietary corpus with Amazon Nova-curated training data at every training phase. The curated datasets are organized by domain and designed to preserve general performance while your data reshapes the model’s domain expertise. For implementation details, see the Continued Pre-Training and Mid-Training documentation in the Amazon Nova Forge User Guide.

RAG retrieval returns correct document chunks but the model still produces incoherent synthesis. When the retriever surfaces the right paragraphs and the model still cannot combine them into a valid response, the problem is comprehension, not information access. Additional prompt engineering will not bridge that gap because the missing knowledge is architectural, not factual.

Reasoning over domain structure fails even when individual facts are correct. A model fine-tuned on insurance claims data can learn to fill standardized forms, but it can’t reason about subrogation chains or multi-party liability cascades because those relationship patterns never appeared in its pre-training data. Feeding large volumes of unstructured domain documents through CPT builds the structural comprehension that labeled fine-tuning examples can’t replicate.

The model consistently misinterprets domain-specific terminology even when Amazon Bedrock Knowledge Bases retrieves the correct context and fine-tuning examples demonstrate proper usage. Legal contracts, patent filings, pharmaceutical compound nomenclature, and financial regulatory filings use language that the model’s original pre-training corpus underrepresents, so its internal token representations lack the structural foundation needed to parse these domains correctly.

When to progress: No existing model architecture fits your requirements, and you need full control over training data, checkpoints, and model design.

Real-world example:

• Sonrai: Accelerates precision medicine research by 50 percent with 5x fewer errors, saving up to $20,000 per experiment, using Amazon Bedrock for single-cell RNA-seq data analysis with domain-specific model customization.

Data requirements: 1B+ tokens of unlabeled domain content for mid-training, and 1T+ tokens for full continued pre-training.

Step 8: Custom model training, Amazon Nova Forge (fully custom foundation model)

Build your own frontier foundation model using the Amazon Nova architecture, intermediate checkpoints, and Amazon-curated training data mixed with your proprietary data. This is the “open training” paradigm: you start from early model checkpoints, blend proprietary data, and create a model trained for your domain from scratch.

When to use: Off-the-shelf models and all previous customization steps can’t meet your accuracy requirements. You have machine learning (ML) expertise, large proprietary datasets, and need durable competitive differentiation. This is typically the path when you intend to monetize your model as a core product or service offering. Amazon Nova Forge makes this investment worthwhile by providing managed training infrastructure, Amazon-curated data mixing, and intermediate checkpoints, significantly reducing the time and cost to build a production-ready custom foundation model.

When NOT to use: For most customers, Steps 1–7 are sufficient. Nova Forge is for specialized industries requiring deep domain expertise such as pharma, robotics, finance, manufacturing.

Real-world examples:

• Nimbus Therapeutics: Used Amazon SageMaker to accelerate the design of candidate drugs with custom-trained models on proprietary molecular data.

What makes Forge different:

• Access to intermediate model checkpoints (pre-trained, mid-trained, post-trained).
• Data mixing with Amazon-curated datasets (helps prevent catastrophic forgetting).
• Multi-turn RFT in customer’s own environment (robotics simulators, code validators).

Reference: Building specialized AI without sacrificing intelligence: Nova Forge data mixing in action

RL with custom reward functions: Amazon Nova Forge supports reinforcement learning (RL) where you connect your own environment as the reward signal. Chemistry simulations that score molecular designs, robotics physics engines that penalize collisions, code validators that check compilation success: these connect directly to the training loop so the model learns to optimize against your business-specific evaluation criteria rather than generic human preference labels. Nova Forge also supports multi-turn rollouts for training complex agent workflows and sequential decision-making tasks.

On-demand inference for custom models: Custom Amazon Nova models trained after July 2025 support pay-per-token inference on Amazon Bedrock with no Provisioned Throughput required. You can train a custom model and serve it at standard per-call rates, the same pricing model as non-customized Amazon Bedrock model inference. This changes the cost calculation for Steps 6-8 significantly, since you no longer need to commit to allocated capacity before validating production traffic.

Why Nova Forge over building a custom pipeline on Amazon SageMaker: Amazon SageMaker gives you raw infrastructure: GPU clusters, distributed training libraries, and custom containers with full control over every training parameter. Amazon Nova Forge is a fully managed service that gives you a curated path. You start from model checkpoints that Amazon has already trained on billions of tokens, blend your data with Amazon-curated corpora organized by domain, and run push-button recipes optimized for the Nova architecture. The practical difference is timeline and team size. A custom training project that would otherwise require a dedicated ML team and months of iteration collapses into a managed workflow that produces a deployable model in weeks, because the infrastructure decisions, recipe tuning, and data mixing ratios are already solved. This reduces your time to market so you can focus on your domain data and use case rather than building and maintaining training infrastructure.

Nova Forge SDK (pip install amzn-nova-forge): Available on GitHub since March 2026, the SDK provides a unified Python interface spanning the complete customization lifecycle. ForgeTrainer manages training job configuration and execution, ForgeEvaluator runs model evaluations against your benchmarks, ForgeDeployer handles deployment to Amazon Bedrock or Amazon SageMaker endpoints, and ForgeInference wraps inference calls against custom models. The SDK runs on Amazon SageMaker Training Jobs or Amazon SageMaker HyperPod, alleviating the need to manage distributed training configurations, gradient checkpointing strategies, or cluster fault tolerance.

Figure 6: Quick reference comparing effort, data, time, and AWS service for each step

Decision framework

The spectrum is a diagnostic process, not a menu where you pick the most advanced option your budget allows. Start at Step 1, validate the output against your requirements, and if it fails, identify why it fails. That specific failure mode maps to exactly one next step on the spectrum.

Production systems often layer multiple steps together because real workloads have compound requirements. RAG plus fine-tuning is the most common hybrid: fine-tune the model for behavioral alignment and domain-specific formatting, then use RAG for dynamic knowledge that changes faster than any training cycle can keep up with. Teams also commonly distill a fine-tuned model to achieve both behavioral alignment and production-grade latency in a single serving configuration. The spectrum helps you identify which capabilities your system needs. The final architecture combines whatever steps address your specific failure modes.

Common mistakes to avoid

Serving a large teacher model in production without distilling. If you validated quality with a larger model during prototyping, distill into a smaller student model before scaling to production traffic.

Choosing continued pre-training because “we have a lot of data.” Data volume alone does not justify CPT. If your data consists of factual reference material like product specifications or policy documents, RAG handles it at lower cost because the information changes frequently and the model only needs to cite it, not internalize it.

Jumping to fine-tuning because “RAG is too slow.” Fine-tuning changes model behavior, not inference speed. If retrieval latency is the bottleneck, the fix is better chunking strategies, hybrid search configurations, or prompt caching.

When to escalate: Matching your problem to the right step

No existing model architecture fits your requirements, or you need full control over training phases with proprietary reward environments? Build from early checkpoints with data mixing and custom RL through Amazon Nova Forge (Step 8).

Model does not understand domain language or structural patterns even after fine-tuning with representative examples? The gap is comprehension, not behavior. Continued Pre-Training (Step 7) with your raw domain corpus builds the foundational understanding that fine-tuning cannot add.

Model tone, reasoning style, or task execution does not match your requirements despite having correct knowledge? Fine-tune (Step 6). Use SFT when you can demonstrate correct behavior through labeled examples, or RFT when you can define correctness as a reward function.

You validated quality with a large model but need it cheaper and faster for production? Distill (Step 5). Amazon Bedrock Model Distillation uses a teacher model to generate synthetic training data, then fine-tunes a smaller student model to replicate the teacher’s outputs for your specific use case.

RAG works but latency or cost is too high for production volume? Cache repeated prompt prefixes (Step 4). Amazon Bedrock prompt caching pre-computes the static portions of each request so repeated queries skip redundant computation.

Model hallucinates domain-specific facts? The model lacks knowledge it was never trained on. Ground it with your data through Amazon Bedrock Knowledge Bases (Step 3), since providing knowledge at inference time is cheaper and faster than any form of model training.

Output is generic or poorly formatted? The model needs better instructions. Improve your prompt (Step 2) by adding system instructions, specifying output format, and including few-shot examples that demonstrate the structure you want.

Conclusion

You now have a clear path from “we have a foundation model” to “we have a model that works for our specific use case.” The spectrum is not about using the most advanced technique available. It is about using the simplest technique that meets your accuracy, latency, and domain requirements.

Here’s the short version: Amazon Bedrock handles Steps 1–7: prompt engineering, RAG through Knowledge Bases, prompt caching, model distillation, and fine-tuning. When you need deeper customization, Amazon SageMaker AI gives you managed infrastructure for continued pre-training. And when your use case demands a fully custom frontier model, such as in specialized industries like pharma or defense, you can use Amazon Nova Forge to build one from intermediate checkpoints with your own data mixing.

To get started, try your use case with an existing model on Amazon Bedrock. If the output meets your requirements, you are done. If it doesn’t, identify what is failing, find that failure mode in the escalation signals, and move to the next step. Start simple. Escalate only when you have evidence that the current step is insufficient.

---

About the authors

Bhavya Sruthi Sode

Bhavya is a Technical Account Manager at Amazon Web Services, focused on AI/ML. She helps customers design resilient, scalable, and secure cloud architectures while driving successful outcomes in their enterprise cloud environments. With a background in Machine Learning, she is passionate about helping organizations transform their AI aspirations into practical solutions.

Nitin Eusebius

Nitin is a Principal Solutions Architect and Generative AI Tech Lead at AWS. He works with executive and technology leaders on enterprise transformation, cloud strategy, and AI engineering, including the adoption of generative and agentic AI. With over 20 years of experience across enterprise technology, cloud architecture, and large-scale digital platforms, Nitin helps organizations design secure, resilient, and production-ready systems.