Alexander's blog RSS Feed

DeepSeek V4.1-Flash-1017 Brings Stronger Coding and a Web Search API

Mon, 19 Oct 2026 18:04:43 GMT

What Happened?

On October 17, 2026, DeepSeek released DeepSeek-V4.1-Flash-1017, a new post-training checkpoint of the V4.1-Flash model it first shipped in September. The weights are published on Hugging Face and ModelScope, and the model is already serving traffic on DeepSeek’s website, app and API.

The checkpoint arrived with a second launch that may matter even more to developers: DeepSeek opened its in-house web search engine to the public through two new endpoints, a Search API and a Fetch API. Until now that engine only powered DeepSeek’s own products.

DeepSeek describes the update as a “Pareto improvement”: higher benchmark scores, faster task completion and shorter outputs, all at once. In practice that means you get better results and pay for fewer tokens.

Why It Matters

Two trends meet in this release.

Open-weight models keep closing the gap on agentic coding. On DeepSeek’s own numbers, an open model with only about 16B active parameters per generated token now scores in the same range as top proprietary models on several software engineering benchmarks.
Agents need tools, not just tokens. A coding or research agent is only as good as the context it can pull in. Shipping a cheap, model-agnostic search and fetch layer next to the model gives developers a building block that used to require a third-party search provider.

For teams that run agents at scale, the cost side is the headline. The model is cheap per token, it writes shorter answers, and the tool calls it relies on are now priced per request.

Technical Details

The model. V4.1-Flash is a Mixture-of-Experts model built on what DeepSeek calls a Causal Encoder-Decoder (CED) design. According to DeepSeek and coverage of the September launch:

Size: about 552B total parameters, with roughly 8B active per token during prefill and 16B during decoding.
Layout: 40 Transformer layers, split into 20 causal encoder layers that process the input and 20 decoder layers that generate output.
Context: up to 1M tokens, with text and image input and text output.
Memory: an FP4 KV cache and compressed attention cut KV cache memory to about a quarter of the previous V4-Flash, which makes long contexts cheaper to serve.

The 1017 checkpoint keeps that architecture. What changed is post-training: DeepSeek used reinforcement learning with self-feedback on end-to-end projects, such as building games or 3D scenes from scratch, to improve long-horizon development work.

The benchmarks. These are DeepSeek’s self-reported figures, so treat them as a starting point rather than a final verdict:

DeepSWE v1.1: 77.0, up from 74.2 for the September V4.1-Flash. DeepSeek’s table lists Claude Opus 5 at 74.0 and GPT 5.6-Sol at 73.0.
Terminal-Bench 4.0: 42.3, up from 31.2, though Claude Opus 5 still leads at 51.8.
Agents’ Last Exam: 35.4, up from 31.8.

The checkpoint improves on its predecessor across every benchmark DeepSeek reported, but proprietary frontier models still lead on several of them, including Terminal-Bench, ProgramBench, NL2Repo and Humanity’s Last Exam. In short, it is very strong for its cost, not best at everything.

The Search and Fetch APIs. Both are simple REST endpoints on api.deepseek.com:

POST /v1/tools/search returns ranked web results for a query. You can ask for 1 to 50 results, optionally include page content, and use operators such as site:, -site:, lang:, after: and before:. Each result includes a rerank score (0–3) and an authority tier (0–4), plus a short snippet for UIs and a longer summary written for models.
POST /v1/tools/fetch takes a URL and returns the page as Markdown, which is the format most agents want anyway.

A minimal search request looks like this:

curl https://api.deepseek.com/v1/tools/search \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "vector database benchmarks site:github.com after:2026", "count": 5}'

What It Means for Developers

Cheap agent backends: the model is served as deepseek-flash through OpenAI- and Anthropic-compatible endpoints. DeepSeek lists peak prices of $0.30 per million input tokens (cache miss) and $1.20 per million output tokens, with off-peak rates at half price. Several third-party hosts list the snapshot for less.
Predictable tool pricing: Search and Fetch each cost $0.75 per 1,000 successful requests. Failed calls, timeouts and empty results are not billed, and the result count doesn’t change the price.
A free trial window: server-side Search and Fetch calls made through DeepSeek Harness, Claude Code or Codex are free until November 1, 2026 (00:00 Beijing time). That’s a good time to benchmark them against your current search provider.
Self-hosting is possible, but heavy: running a 552B MoE model yourself still means a multi-GPU server. Check the model card for the exact license and hardware notes before you plan a deployment.
Validate on your own tasks: the benchmark gains are self-reported. Run the checkpoint against your own repository or eval suite before switching production traffic.

One practical point: the Search and Fetch APIs are model-agnostic. Nothing stops you from wiring them into an agent that runs on a different model, which makes them interesting even if you never use DeepSeek’s LLM.

Conclusion

DeepSeek-V4.1-Flash-1017 is an incremental checkpoint on paper, but it shows how fast the open-weight tier is moving: better agentic coding scores, shorter outputs and a lower bill, all in a model you can download. The bigger long-term story may be the Search and Fetch APIs, which give developers a cheap, agent-friendly way to ground models in live web data. If you build coding or research agents, the free window until November 1 is a low-risk chance to try both.

Sources

TorchNeuron: AWS Trainium Becomes a Native PyTorch Backend

Mon, 19 Oct 2026 17:34:16 GMT

What Happened?

On October 19, 2026, AWS and the PyTorch team announced TorchNeuron, an open-source, native PyTorch backend for AWS Trainium chips. The project is licensed under Apache 2.0 and enters public beta on October 20, to coincide with PyTorch Conference North America in San Jose. It supports Trainium2 and Trainium3.

The pitch is simple: take ordinary PyTorch code, change the device to neuron, and run it. You shouldn’t need a Neuron-specific rewrite, a special tracing step or a separate model definition. If that holds up, it matters a lot for anyone who has avoided non-NVIDIA accelerators because of the migration cost.

Why It Matters

PyTorch has become the default language of AI. Amazon’s announcement says that about 85% of AI researchers and developers write their code in PyTorch. But in practice “PyTorch” has usually meant “PyTorch on CUDA”. Other accelerators have worked through adapter layers, separate compilation workflows or partial op coverage, and each of those adds friction:

Porting cost: moving a model to new hardware often meant rewriting and revalidating code, which could take months.
Debugging pain: graph-based or lazy-execution stacks make it harder to use print, breakpoints and Python control flow.
Ecosystem gaps: libraries such as Hugging Face Transformers, TorchTitan or vLLM expect a “real” device, not a bolted-on one.

TorchNeuron tries to remove that friction by making Trainium a first-class PyTorch device. For the industry, this is another step toward breaking the lock-in that CUDA has given NVIDIA. For developers, it means more hardware choice without learning a new framework.

How It Works Under the Hood

TorchNeuron is built on PyTorch’s official extension points for out-of-tree hardware, not on a fork.

PrivateUse1 device registration: Trainium is registered through PyTorch’s PrivateUse1 mechanism and exposed as the neuron device. As a result, torch.nn, torch.autocast, torch.distributed and torch.profiler work as written. Code written against the device-agnostic torch.accelerator API also runs unchanged.
Eager mode: operations run immediately, so normal Python debugging works. Each op is compiled into a Neuron executable (a NEFF file) and launched on the device. An experimental adaptive eager mode fuses operations and cuts launch overhead to get closer to compiled performance.
torch.compile: TorchDynamo captures an FX graph, AOTAutograd traces the backward pass, the Neuron backend lowers the graph through Torch-MLIR to StableHLO, and the Neuron compiler emits the final executable. You can compile a whole model or just parts of it. FlexAttention is supported natively.
Custom kernels with NKI: the Neuron Kernel Interface lets you write your own kernels and register them as regular PyTorch custom ops, including autograd support. AWS has also open-sourced NKI-lib, which includes optimized kernels such as FlashAttention and MoE blockwise kernels.

Here is what the developer-facing API looks like:

import torch

# Eager mode: the only change is the device
model = MyModel().to("neuron")
optimizer = torch.optim.AdamW(model.parameters())

# Compiled mode
torch.compiler.set_default_backend("neuron")
model.compile()

Hugging Face Transformers v5 can load models straight onto the device with device_map="neuron".

Distributed Training Support

Large-scale training is where Trainium is meant to compete, and TorchNeuron supports the standard PyTorch distributed stack:

Parallelism strategies: DDP, FSDP2, SimpleFSDP, tensor parallelism and pipeline parallelism, including combinations such as FSDP2 + TP.
Sharding primitives: DTensor and DeviceMesh.
Collectives: all_reduce, all_gather, reduce_scatter and point-to-point send/recv. Within a node these run on dedicated collective cores, and across nodes they run over Elastic Fabric Adapter (EFA).

There is also a torchtitan-neuron repository that plugs Trainium-specific kernels and configs into TorchTitan. The announcement includes an example that trains Llama 3 8B on a single trn2.48xlarge instance with SimpleFSDP and torch.compile.

What’s Not There Yet

This is a beta, and AWS is open about the gaps. In its run of PyTorch’s upstream test suite, about 39K tests were deliberately skipped for Neuron. The largest group (around 22K) covers operators that don’t have a native Neuron lowering yet. Features that are not supported in this first release include:

Sparse tensors and NestedTensor
Forward-mode autograd (JVP)
Dynamic and symbolic shapes
Arbitrary attention masks in native MHA (no-mask and causal masks work)
Per-channel quantization and bilinear/bicubic upsampling

FP8 and TorchAO support are in private beta. AWS also says it swept about 100K Hugging Face models in reduced configurations and is still working through the remaining failures. Customer numbers in the announcement are vendor-reported. For example, Deepgram says it got roughly 60% more audio processed per dollar than its GPU baseline. Benchmark your own workloads before you trust figures like that.

What It Means for Developers

Write device-agnostic code. If you use torch.accelerator and avoid hard-coded "cuda" strings, your code is much easier to move to Trainium and other backends.
Try it on a real model. Install torch-neuronx from the AWS Neuron pip repository, move a model to neuron, and check op coverage before you plan a migration.
Keep kernels as an escape hatch. Start with eager mode or torch.compile, and write NKI kernels only for the hot spots the profiler shows you.
Watch the dynamic shapes gap. Workloads with highly variable sequence lengths may run into the current limits on dynamic shapes.

Conclusion

TorchNeuron is less about one chip and more about a pattern: hardware vendors are meeting developers inside PyTorch instead of asking them to adopt new tooling. Because it is built on PrivateUse1, torch.compile and the standard distributed APIs, Trainium now behaves much more like any other PyTorch device. It’s still a beta with real gaps, but if you train or serve models on AWS, it’s worth testing. Compute choice is getting a little less tied to CUDA.

Sources

Understanding Hexagonal Architecture

Sat, 24 Dec 2022 04:31:39 GMT

What is Hexagonal Architecture?

Hexagonal architecture, also known as ports and adapters architecture, is a software design pattern that aims to decouple the business logic of a software application from its external dependencies, such as databases, messaging systems, and web interfaces.

The idea behind hexagonal architecture is to create a core domain of the application, which contains all the business logic and is independent of any external dependencies. This core domain is surrounded by a series of adapters, which allow the application to interact with external systems and devices.

Benefits of Hexagonal Architecture

Loose coupling: By separating the core domain from external dependencies, hexagonal architecture helps to reduce the level of coupling between different parts of the application. This makes it easier to modify or replace one part of the system without affecting the others.
Testability: Hexagonal architecture makes it easier to test the core domain of the application in isolation, as it is not dependent on external systems. This can lead to more reliable and maintainable tests.
Flexibility: The adapters in hexagonal architecture can be easily swapped out or replaced, which makes it easier to modify the application to work with different external systems or devices.

How to Implement Hexagonal Architecture

Identify the core domain of the application, which contains the business logic and is independent of external dependencies.
Create a series of interfaces or “ports” that define the ways in which the core domain can interact with external systems or devices.
Implement adapters for each external dependency, which implement the necessary ports and allow the core domain to interact with the external system or device.
Use dependency injection to inject the necessary adapters into the core domain, allowing it to interact with external dependencies through the ports.

Example of Hexagonal Architecture

Here is a simple example of how hexagonal architecture might be implemented in a web application:

The core domain of the application contains the business logic for creating and managing user accounts.
A port is defined for storing user accounts in a database.
An adapter is implemented for a specific database system (e.g. MySQL), which implements the database storage port.
A web interface adapter is implemented, which allows users to create and manage their accounts through a web browser. This adapter implements the necessary ports for interacting with the core domain and handles the details of rendering HTML pages and handling HTTP requests and responses.
The core domain is injected with the necessary adapters (database storage and web interface) at runtime, allowing it to interact with external dependencies through the defined ports.

Hexagonal architecture can be applied to a wide range of applications and architectures, including web, mobile, and desktop applications, as well as microservice architectures. It can help to improve the testability, maintainability, and flexibility of your software application.

Hello World

Fri, 09 Dec 2022 22:12:03 GMT

Hi everyone!

Welcome to the blog. My name is Alex and I am passionate about the world of software development. Here you will find articles and tutorials on topics related to software development, including programming languages, frameworks, agile methodologies and much more.

If you are a beginner in the world of software development, I hope this blog serves as a guide for you to start learning and better understand how the software development process works. If you are an experienced developer, I hope you find something interesting and useful here.

On this blog, my goal is to share my knowledge and experience in the field of software development to help others learn and improve their skills. So if you have any questions or suggestions, don’t hesitate to leave a comment or contact me.

I hope you enjoy the blog and learn a lot!

Best regards.