When configuring a multi-hop route with the attached Postman request (note this also applies to ipv6) the result from VAT looks like this:
vat# ip_fib_dump
...

{ "table": 1, "prefix": "16.0.2.0", "mask_length": 24, "path_count": 1, "weight": 1, "sw_if_index": 2, "is_local": 0, "is_drop": 0, "is_unreach": 0, "is_prohibit": 0, "next_hop_afi": 1, "next_hop": "16.0.1.3" }

,

it seems the first route was overwritten with the second one. Packet traffic from VPP also ignores the first route completely. This behaviour is consistent with the multipath flag not being set, although there may be other explanations as well.

configuring this through VAT like:
ip_add_del_route 192.168.2.5 sw_if_index 0 weight 1 multipath
ip_add_del_route 192.168.2.6 sw_if_index 0 weight 1 multipath

will result in:
vat# ip_fib_dump
...

{ "table": 1, "prefix": "16.0.2.0", "mask_length": 24, "path_count": 2, "weight": 1, "sw_if_index": 2, "is_local": 0, "is_drop": 0, "is_unreach": 0, "is_prohibit": 0, "next_hop_afi": 1, "next_hop": "16.0.1.3", "weight": 1, "sw_if_index": 2, "is_local": 0, "is_drop": 0, "is_unreach": 0, "is_prohibit": 0, "next_hop_afi": 1, "next_hop": "16.0.1.3" }

...which shows the same nexthop twice for some reason, likely a dump API bug. But in this state VPP does send packets over both routes (50/50 given equal weight values).