Key takeaways
Most teams should exhaust prompting, RAG, and routing before fine-tuning. Fine-tune when style/domain errors persist on a clean eval set and you can maintain training data. API + RAG is cheaper to iterate for early products (/en/articles/china-llm-rag-selection-guide, /en/articles/china-llm-embedding-rag-setup-2026).
Choose API when…
Requirements change weekly, data is sparse/noisy, or you need multi-vendor failover. Use structured outputs and tool calling first (/en/articles/china-llm-json-structured-output-2026, /en/articles/china-llm-agent-tool-calling-2026).
Choose fine-tuning when…
Stable task, thousands of quality examples, measurable lift vs RAG, and ops capacity for eval/regressions. Confirm vendor fine-tune offerings and data residency (/en/articles/china-llm-compliance-overseas-2026). Self-host path: /en/articles/chinese-llm-self-hosting-guide-2026.
Next steps on Swift Horse
Optimization /en/articles/china-llm-optimization-guide-2026 → pricing /en/articles/china-llm-api-pricing-2026 → buyers /en/articles/china-llm-enterprise-buyers-guide-2026.
FAQ
Should I fine-tune DeepSeek or Qwen first?
Only after API baselines fail your eval—pick the vendor whose base model already wins your tasks.
Is RAG enough instead of fine-tuning?
Often yes for knowledge updates; fine-tune more for style/format habits.
How much data do I need?
Vendor minimums vary—budget for quality over raw volume and hold out a test set.
Is this official fine-tuning documentation?
No—independent Swift Horse decision guide; follow vendor consoles for steps.