mirror of
https://github.com/invoke-ai/InvokeAI.git
synced 2026-02-03 18:15:19 -05:00
c238a7f18b
Upgrade pydantic and fastapi to latest.
- pydantic~=2.4.2
- fastapi~=103.2
- fastapi-events~=0.9.1
**Big Changes**
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
**Invocations**
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when `invoke()` is called. We directly manipulated the fields and invocation models when calling `invoke()`.
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in `baseinvocation.py`, in the `InputField` function and `BaseInvocation.invoke_internal()` method.
In the end, this implementation is cleaner.
**Invocation Fields**
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the `type` field to invocations.
**Invocation Decorators**
With pydantic v2, we instead use the imperative `create_model()` API to create a new model with the additional field. This is done in `baseinvocation.py` in the `invocation()` wrapper.
A similar technique is used for `invocation_output()`.
**Minor Changes**
There are a number of minor changes around the pydantic v2 models API.
**Protected `model_` Namespace**
All models' pydantic-provided methods and attributes are prefixed with `model_` and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
```py
class IPAdapterModelField(BaseModel):
model_name: str = Field(description="Name of the IP-Adapter model")
base_model: BaseModelType = Field(description="Base model")
model_config = ConfigDict(protected_namespaces=())
```
**Model Serialization**
Pydantic models no longer have `Model.dict()` or `Model.json()`.
Instead, we use `Model.model_dump()` or `Model.model_dump_json()`.
**Model Deserialization**
Pydantic models no longer have `Model.parse_obj()` or `Model.parse_raw()`, and there are no `parse_raw_as()` or `parse_obj_as()` functions.
Instead, you need to create a `TypeAdapter` object to parse python objects or JSON into a model.
```py
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)
```
**Field Customisation**
Pydantic `Field`s no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a `json_schema_extra` arg on the field.
**Schema Customisation**
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:
- Our schema customization logic has been revised
- Schema parsing to build node templates has been revised
The specific aren't important, but this does present additional surface area for bugs.
**Performance Improvements**
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
101 lines
4.1 KiB
Python
101 lines
4.1 KiB
Python
import math
|
|
from typing import Optional
|
|
|
|
import torch
|
|
from PIL import Image
|
|
from torchvision.transforms.functional import InterpolationMode
|
|
from torchvision.transforms.functional import resize as tv_resize
|
|
|
|
|
|
class AttentionMapSaver:
|
|
def __init__(self, token_ids: range, latents_shape: torch.Size):
|
|
self.token_ids = token_ids
|
|
self.latents_shape = latents_shape
|
|
# self.collated_maps = #torch.zeros([len(token_ids), latents_shape[0], latents_shape[1]])
|
|
self.collated_maps: dict[str, torch.Tensor] = {}
|
|
|
|
def clear_maps(self):
|
|
self.collated_maps = {}
|
|
|
|
def add_attention_maps(self, maps: torch.Tensor, key: str):
|
|
"""
|
|
Accumulate the given attention maps and store by summing with existing maps at the passed-in key (if any).
|
|
:param maps: Attention maps to store. Expected shape [A, (H*W), N] where A is attention heads count, H and W are the map size (fixed per-key) and N is the number of tokens (typically 77).
|
|
:param key: Storage key. If a map already exists for this key it will be summed with the incoming data. In this case the maps sizes (H and W) should match.
|
|
:return: None
|
|
"""
|
|
key_and_size = f"{key}_{maps.shape[1]}"
|
|
|
|
# extract desired tokens
|
|
maps = maps[:, :, self.token_ids]
|
|
|
|
# merge attention heads to a single map per token
|
|
maps = torch.sum(maps, 0)
|
|
|
|
# store
|
|
if key_and_size not in self.collated_maps:
|
|
self.collated_maps[key_and_size] = torch.zeros_like(maps, device="cpu")
|
|
self.collated_maps[key_and_size] += maps.cpu()
|
|
|
|
def write_maps_to_disk(self, path: str):
|
|
pil_image = self.get_stacked_maps_image()
|
|
if pil_image is not None:
|
|
pil_image.save(path, "PNG")
|
|
|
|
def get_stacked_maps_image(self) -> Optional[Image.Image]:
|
|
"""
|
|
Scale all collected attention maps to the same size, blend them together and return as an image.
|
|
:return: An image containing a vertical stack of blended attention maps, one for each requested token.
|
|
"""
|
|
num_tokens = len(self.token_ids)
|
|
if num_tokens == 0:
|
|
return None
|
|
|
|
latents_height = self.latents_shape[0]
|
|
latents_width = self.latents_shape[1]
|
|
|
|
merged = None
|
|
|
|
for key, maps in self.collated_maps.items():
|
|
# maps has shape [(H*W), N] for N tokens
|
|
# but we want [N, H, W]
|
|
this_scale_factor = math.sqrt(maps.shape[0] / (latents_width * latents_height))
|
|
this_maps_height = int(float(latents_height) * this_scale_factor)
|
|
this_maps_width = int(float(latents_width) * this_scale_factor)
|
|
# and we need to do some dimension juggling
|
|
maps = torch.reshape(
|
|
torch.swapdims(maps, 0, 1),
|
|
[num_tokens, this_maps_height, this_maps_width],
|
|
)
|
|
|
|
# scale to output size if necessary
|
|
if this_scale_factor != 1:
|
|
maps = tv_resize(maps, [latents_height, latents_width], InterpolationMode.BICUBIC)
|
|
|
|
# normalize
|
|
maps_min = torch.min(maps)
|
|
maps_range = torch.max(maps) - maps_min
|
|
# print(f"map {key} size {[this_maps_width, this_maps_height]} range {[maps_min, maps_min + maps_range]}")
|
|
maps_normalized = (maps - maps_min) / maps_range
|
|
# expand to (-0.1, 1.1) and clamp
|
|
maps_normalized_expanded = maps_normalized * 1.1 - 0.05
|
|
maps_normalized_expanded_clamped = torch.clamp(maps_normalized_expanded, 0, 1)
|
|
|
|
# merge together, producing a vertical stack
|
|
maps_stacked = torch.reshape(
|
|
maps_normalized_expanded_clamped,
|
|
[num_tokens * latents_height, latents_width],
|
|
)
|
|
|
|
if merged is None:
|
|
merged = maps_stacked
|
|
else:
|
|
# screen blend
|
|
merged = 1 - (1 - maps_stacked) * (1 - merged)
|
|
|
|
if merged is None:
|
|
return None
|
|
|
|
merged_bytes = merged.mul(0xFF).byte()
|
|
return Image.fromarray(merged_bytes.numpy(), mode="L")
|