The fastest way to start using DeepSeek-V3.2 is via the DeepSeek API, which is intentionally compatible with the OpenAI /v1/chat/completions format. You sign up for an API key in the DeepSeek console, point your existing OpenAI SDK (Python, Node, etc.) at DeepSeek’s base URL, and set the model field to the appropriate V3.2 model (for example, deepseek-chat variant mapped to V3.2-Exp once exposed). From there, it’s standard chat-completion usage: you send a list of messages, optionally define tools/functions, and read the streamed or non-streamed response. This is the best route if you want to try the model without touching infrastructure.
If you need tighter control, you can self-host the open-weight checkpoint. DeepSeek publishes V3.2-Exp weights on Hugging Face, and there are ready-made deployment guides for vLLM and SGLang, both of which support tensor parallelism and long-context optimizations out of the box. The vLLM “getting started” recipe shows how to install nightly vLLM and DeepSeek’s custom ops, launch a multi-GPU server, and expose an OpenAI-compatible HTTP endpoint. SGLang’s docs (which DeepSeek officially recommends) explain how to run DeepSeek V3-family models with FP8 kernels, MLA optimizations, and “DP attention” settings tuned specifically for these MoE architectures. Once you have a local endpoint, your app code looks the same as with the hosted API—just with a different URL and, if you choose, different default sampling parameters.
When your application involves retrieval or knowledge grounding, you’ll typically pair DeepSeek-V3.2 with a vector database such as Milvus or Zilliz Cloud. The usual pattern is: (1) build an ingestion pipeline that creates embeddings and stores them in Milvus or Zilliz Cloud collections, (2) expose a small service that translates user queries into vector searches, and (3) wrap DeepSeek-V3.2 behind a RAG service that first queries the vector DB, then calls the LLM with a compact context of retrieved passages. V3.2’s tool-calling support lets you formalize this as functions (semantic_search, fetch_by_id, etc.) so the model can explicitly decide when to call Zilliz Cloud rather than always relying on a fixed pre-retrieval step. Start simple with “retrieve then answer,” then iterate into tool-based or multi-step agents once you’re comfortable with the basics.