The graph-shaped Keras. When your model has skip connections, multiple inputs, multiple outputs, or shared layers, Sequential collapses — Functional carries on. ResNet, U-Net, multi-modal models all live here. The whole API is output = layer(input) chained until you hand the result to keras.Model(inputs, outputs).
Why Sequential isn't enough
Real-world models aren't linear pipelines. They branch, merge, and loop. Sequential can only express a single straight line of layers — input goes in one end, comes out the other, with nothing skipping ahead or rejoining. The moment your architecture needs a second input, a residual add, or a branch that merges back later, Sequential has no syntax for it.
The Functional API builds directed acyclic graphs (DAGs) of layers, supporting:
- Multiple inputs — Combine text + image + metadata
- Multiple outputs — Predict class label + confidence score simultaneously
- Skip connections — ResNet's residual blocks that skip over layers
- Shared layers — Same weights applied to different inputs (Siamese networks for similarity)
- Nested models — Use one model as a layer inside another
Why it's the production default
The Functional API is the most commonly used model-building approach in production Keras code. It's more flexible than Sequential while remaining declarative and serializable — because you describe the graph rather than running arbitrary Python, Keras can save the architecture to JSON, plot it, and reconstruct it without your source. That's the line that separates it from full Model subclassing (the next track): subclassing buys you imperative control flow but gives up the static, serializable graph. Reach for Functional whenever the architecture is a fixed DAG; reach for subclassing only when you genuinely need per-step Python logic.